Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DigiCert Statement on Trustico Certificate Revocation

digicert.com

Post reply on HN
Print view View original

61–70 of 76 posts

Re: DigiCert Statement on Trustico Certificate Revocation

#61

Post by zaarn »

feelin_googley wrote: post #42
0x0 wrote: post #34

Earlier quoted context omitted.

See, that requires trusting that all CAs actually respect the CAA records. AFAIK, CAA records aren't validated by end-user client software during SSL negotiation. I would love to see some technical measure implemented where DV SSL certificate issuance and validation was tied to the TLD registry and the domain's particular registrar. It would eliminate the frankly unnecessary trust we put in all root CAs and their sub…

"They should have a public key upload button next to your domain name in your registrars domain name control panel..." What about putting the public key in a subdomain. DNSCurve uses this approach to encrypt DNS packets. If an authoritative nameserver for a domain can manage encryption of DNS packets without SSL/TLS, x509 and a CA system, is there any reason why an httpd could not do the same? Management is handled b…

The issue is trust.

Can you trust that the other end of the DNSCurve system is not operated by Mr. Evil? Can you do that automatically, ie, without human intervention at all?

The CA-based PKI system allows one to trust that the endpoint of a website is who they say they are and not a middlebox manipulating traffic. Additionally guarantees are available through EV certificates which also tell you who is operating the endpoint.

DNSCurvse is most likely not able to assure you that the response you got is really from the authorative nameserver. It can only tell you that it was encrypted but there is no identity assurance.

Re: DigiCert Statement on Trustico Certificate Revocation

#62

Post by Someone1234 »

xorcist wrote: post #24
geofft wrote: post #15

Earlier quoted context omitted.

> How is this not related to "the big distrust"? Unreal. If you mean the Symantec distrust - it's financially related but not technically related. In particular, it looks like Trustico ended their business agreement with Symantec (over the Symantec distrust) and signed a new contract with Comodo to resell Comodo certs instead. They wanted to move all their customers to the Comodo certs, and asked Digicert, the new ow…

This is all kinds of crazy at the same time. Why would Trustico want to revoke certificates under the previous root anyway? Why not just start issuing certificates under the new, and just skip the part about broadcasting their little secret to the world?

Both Digicert and Trustico were trying to compete for the former Symantec customers. Both sent customers a replacement key for their soon-to-be broken Symantec keys (with Digicert's needing to be renewed directly with them, and Trustico (via Comodo) with them).

This MIGHT have been a misguided attempt by Trustico to sow mistrust between Digicert and Trustico's own customers. If Trustico can convince people that Digicert (who purchased Symantec) wasn't to be trusted and this mass revocation was their fault, then Trustico might get more renews.

It also discontinues any relationship Digicert and Trustico's customers have with one another, since they'd all get nice shiny Comodo certs.

You can see Trustico's statement here:

https://www.trustico.com/news/2018/symantec-revocation/certi...

Only problem with Trustico's plan is that they shouldn't have even had over 20K's worth of private keys in cold storage. And while it was to their advantage in that they forced Digicert's hand, it also may have irreparably damaged Trustico's reputation.

Re: DigiCert Statement on Trustico Certificate Revocation

#63

Post by mook »

BillinghamJ wrote: post #14
regecks wrote: post #12

Earlier quoted context omitted.

Well, Trustico is a reseller. There's very little to stop them doing anything they want, since they are not subject to CABF regulations. For example, consider this page: https://www.trustico.com.au/ssltools/create/csr-pem/create-a... The best part - it doesn't even use browser crypto. The private key is generated server-side and then rendered in the server response. Private key generation on the reseller-side - what…

They are still effectively subject to the CA/B rules. The issuer of the certs is subject to the rules, and they must ensure compliance of any companies they delegate to.

Given that they have access to private keys they shouldn't, should Comodo (their new CA partner) then think about stopping them from reselling? Obviously, they've already terminated their relationship with Symantec...

Re: DigiCert Statement on Trustico Certificate Revocation

#64

Post by rzr999 »

On a side note they have a shady business model. When it comes to using certificates regularly they withhold funds if you don't buy enough certificates from them until you top up with 200 USD again. That means funds just get stuck. They won't return them even if you cancel the account.

Re: DigiCert Statement on Trustico Certificate Revocation

#65

Post by tialaramex »

dullgiulio wrote: post #20
geofft wrote: post #15

Earlier quoted context omitted.

> How is this not related to "the big distrust"? Unreal. If you mean the Symantec distrust - it's financially related but not technically related. In particular, it looks like Trustico ended their business agreement with Symantec (over the Symantec distrust) and signed a new contract with Comodo to resell Comodo certs instead. They wanted to move all their customers to the Comodo certs, and asked Digicert, the new ow…

Thank you for your explanation. I remember part of the Symantec problem was the uncontrolled resellers practices. Isn't this just some more dust under the rag coming out now?

The big Symantec problem was RAs rather than resellers. The difference probably doesn't mean much to customers, but it means a lot in terms of trust.

Symantec trusted the RAs to do Validation. So although we believe CrossCert (the Korean RA which made all this kick off) were actually making some sort of attempt to validate, since Symantec exercised no effective oversight and relied entirely upon third party auditors (whose role is _audit_ not actively overseeing everything) we can't be sure. We know CrossCert validated bogus certificates for example.com, which although it's scarcely google.com or a major bank is still very wrong. Executives at Symantec essentially did not do their job on this, that's why even if they hadn't quit the market voluntarily they were in the process of being forced to let somebody else do the actual oversight. Board-level incompetence is very widespread, but that's no reason we have to tolerate it in the Web PKI.

Trustico was not trusted to validate things, so if they tried to sell some customer certificates for example.com, the customer would have to prove to Symantec that they legitimately controlled example.com to get their certificate. They could still cause (as seen here) mayhem, but only for their own customers, so arguably caveat emptor.

Re: DigiCert Statement on Trustico Certificate Revocation

#66

Post by icebraining »

zokier wrote: post #38
bostik wrote: post #32

Earlier quoted context omitted.

> They apparently have a [webgui] “certificate wizard” that will generate the certificate and corresponding private key for you. Any company doing that deserves to have their decision makers crucified, head down, on the outer wall of the town church, with the nails hammered through their genitals. If you didn't create the private key yourself, by definition it's not private. If generating CRSs and handling the certif…

That's bit harsh. I bet that significant amount of the impacted people had only the vaguest idea what they were actually buying ("a lock icon for the web thingy"), and never even heard of private keys, never mind CSRs or actually understanding public-key crypto and PKI.

I find this argument unconvincing, but even if you really feel the need to help people generate keys, you do it in JS in the browser, without ever sending them to your server! Open source code to do this has been around since 2001: http://webcache.googleusercontent.com/search?q=cache:87MSSBj...

Re: DigiCert Statement on Trustico Certificate Revocation

#67

Post by zaarn »

0x0 wrote: post #43
toast0 wrote: post #41

Earlier quoted context omitted.

> See, that requires trusting that all CAs actually respect the CAA records. AFAIK, CAA records aren't validated by end-user client software during SSL negotiation. I think the CAB rules require respecting CAA records? If a CA gets caught on that, they'll have some amount of hell to pay. Client software can't go back in time to verify what the CAA records were at the time the certificate was issued. CAA records are n…

I found your last paragraph especially well phrased! You're also on point regarding the CAA records. But to me the current system still feels too reactionary. I'd love to see a system where we need to put less trust in all third parties playing by the rules pinkie-promise. Diginotar, StartSSL and Symantec are all examples of CAs gone wild, and I think we've just seen the tip of the iceberg yet.

And all examples of CAs essentially no longer in business (or bought up by DigiCert).

Re: DigiCert Statement on Trustico Certificate Revocation

#68

Post by WorldMaker »

Someone1234 wrote: post #62
xorcist wrote: post #24

Earlier quoted context omitted.

This is all kinds of crazy at the same time. Why would Trustico want to revoke certificates under the previous root anyway? Why not just start issuing certificates under the new, and just skip the part about broadcasting their little secret to the world?

Both Digicert and Trustico were trying to compete for the former Symantec customers. Both sent customers a replacement key for their soon-to-be broken Symantec keys (with Digicert's needing to be renewed directly with them, and Trustico (via Comodo) with them). This MIGHT have been a misguided attempt by Trustico to sow mistrust between Digicert and Trustico's own customers. If Trustico can convince people that Digic…

Certainly seems like Comodo should be seriously reviewing their relationship with Trustico now.

Re: DigiCert Statement on Trustico Certificate Revocation

#69

Post by feelin_googley »

zaarn wrote: post #61
feelin_googley wrote: post #42

Earlier quoted context omitted.

"They should have a public key upload button next to your domain name in your registrars domain name control panel..." What about putting the public key in a subdomain. DNSCurve uses this approach to encrypt DNS packets. If an authoritative nameserver for a domain can manage encryption of DNS packets without SSL/TLS, x509 and a CA system, is there any reason why an httpd could not do the same? Management is handled b…

The issue is trust. Can you trust that the other end of the DNSCurve system is not operated by Mr. Evil? Can you do that automatically, ie, without human intervention at all? The CA-based PKI system allows one to trust that the endpoint of a website is who they say they are and not a middlebox manipulating traffic. Additionally guarantees are available through EV certificates which also tell you who is operating the…

"Can you do that automatically, ie, without human intervention at all?"

Why not use something like SSH authentication keys to verify the endpoint? (e.g. ed25519 which can be generated very fast)

Consider the vast number of endpoints that are now currently being verified using authentication keys.

For something like encryption, I believe some human intervention will always be required. Only a human can answer the question: "Do you trust this?"

The issue is which humans are intervening: (a) the humans at each endpoint, or (b) the humans at each endpoint plus third parties.

Letting the www commercial CA vendors and commercial ad-supported www browser authors answer the question "Do you trust this?" on behalf of users is still human intervention. Unfortunately for users, this is delegating the intervention to humans that have no "skin in the game". The third parties are not the ones with the need to encrypt. They stand nothing to lose if the encryption is defeated.

Common sense suggests this is the wrong approach. (And that's ignoring the ever-increasing number of exposed flaws and "incidents" regarding www commercial CAs, like the one being discussed in this thread.)

Re: DigiCert Statement on Trustico Certificate Revocation

#70

Post by stevekemp »

xwvvvvwx wrote: post #11

Apparently they had a web front end where customers could request private keys ... https://twitter.com/GossiTheDog/status/968834765888589825

And execute arbitrary commands as root:

https://twitter.com/Manawyrm/status/969230542578348033

Post reply on HN