DigiCert Statement on Trustico Certificate Revocation
digicert.com
digicert.com
CAB forum has its own lists elsewhere. A relevant difference is that CAB forum discusses creating and modifying policy but is not involved in enforcement. The root programs typically deal with enforcement.
The CA/B is a standing meeting between two groups with very different objectives that have an ongoing need to reach some sort of agreement: the Certificate Authorities and the Browsers (in reality more or less the Operating System vendors except Mozilla represents the Free Unixes). This meeting must not appear to be a cartel because cartels are illegal, so it mustn't discuss prices or agree what products should or should not be marketed.
m.d.s.policy is de facto the only public oversight for the entire Web PKI. Mozilla as a Browser vendor (and as hinted above, on behalf of all the Free Unixes) gets to insist upon Rules, not only enforcing rules agreed at CAB, but also making its own rules on top for Certificate Authorities in its Trust Store. As a Charity one of its rules is that it insists on doing almost everything in Public using m.d.s.policy, there is no other obligation on a Certificate Authority to engage with the public at all, but Mozilla's rules force them to tell Mozilla important things via this public group and to answer questions impertinent members of the public (like me) ask them on m.d.s.policy.
Mozilla (and other Browser vendors) is entirely free to insist upon whatever rules they want. The CA/B does not bind them, like the UN it is a forum to meet, and to come to agreements, but it cannot force you to agree to anything you don't want. Two recent illustrative examples:
The CA/B took ages to reform the Domain Validation methods, terribly weak methods had been popular for years, with all sorts of stupid design flaws, and after it did finally vote on a reformed list of methods, CA members claimed a bunch of patents needed to be licensed stalling things for months extra. Mozilla cut through the bullshit and said essentially "See that list of ten methods you voted on that's stuck in Lawyer hell? Too bad, our policy now requires you obey the list which we're naming the Ten Blessed Methods"
Google wanted to reduce the maximum lifetime of new certificates. It takes ages to get CAs to introduce a new rule, and then years while the old certificates made under the old rule expire, too long for Google. So they made an ultimatum, fix it or we'll just tell Chrome to reject certificates after 90 days, and that's the new maximum certificate lifetime. The CA/B eventually voted through a compromise 825 days (which goes into effect tomorrow, 1 March 2018) instead of the previous 39 month limit.
oh snap, as they say
Well, that's one way to ensure they're considered "comprimised".
> Trustico® followed the requests of DigiCert by initially recovering Private Keys from cold storage and subsequently e-mailing the associated order number and Private Keys to DigiCert in a ZIP file. The file did not contain any other type of data.
[1]: https://www.trustico.com/news/2018/symantec-revocation/certi...
The core issue is 1) they had the keys at all 2) they decided to compromise them by emailing them DigiCert
Saying "hey, we did nothing wrong, all we did is email the keys we had to DigiCert" just isn't a very compelling defense to claims they had the keys and emailed them to DigiCert. More like a "total admission of guilt" than a defense, really.
They did this without notifying their customers in advance, so literally, they were going to intentionally screw their customers by revoking all their active SSL certificates without their authorisation and without any notice. Which then happened.
This would have affected ALL certificates, but since Digicert said no, they then pulled all of these generated private keys from storage which they should NOT have been storing -- on their reseller web interface when you generate a certificate (which is a questionable activity but lets just go with it for the argument).. a few days after you place the order the private key disappears from the web interface. You would therefor assume they deleted it. It seems they kept a copy of all of them this whole time - which is doubly irresponsible let alone stupid.
All I can say is thankfully LetsEncrypt is making these guys mostly irrelevant...
The good news is, as far as I know, they're only revoking the certificates that used the generator at least (though I haven't confirmed that) -- so hopefully most people that used a normal CSR certificate won't have them revoked.
Bunch of morons, I can't see why they thought this was a good idea, and as the commentator above said, this response doesn't sound better in any way. It just proves they are intentionally screwing their customers for no real reason. Even if they were intent on this distrust process, they should have at least been ensuring customers got new certificates first and had plenty of notice -- e.g. how the chrome distrust worked. They didn't.
To my knowledge all CAs under Symantec's control, including RapidSSL, are affected[1], with only a handful of exceptions for cross-signed intermediates where Symantec was not under control of issuance. IIRC they belong to Apple and Google (and maybe a few others).
[1]: https://security.googleblog.com/2017/09/chromes-plan-to-dist...
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-CAs to behave. (Well, at least CT logs are becoming a thing now)
It would also eliminate today's more or less awkward validation routines that depend on third parties querying DNS/HTTP/whois-email addresses. The registry has the definite database, mapping the domain to your account at your registrar, anyways. They should simply have a public key upload button next to your domain name in your registrar's domain name control panel that immediately returns an appropriate certificate, no further validation needed :)
Tying PKI to DNS veers pretty close to DANE, and I imagine most of the criticism against DANE would remain valid.
Maybe it's not so bad to make it more obvious what a fancy .ly or .lol TLD really stands for?
Funny thing about ccTLDs are that end-users might actually have some sort of opinion one way or the other about their trustworthyness, foreign or not. At least a tld is somewhat more visible and relatable in URLs compared to unfamiliar CA company names.
I can assure you that we, Let's Encrypt, are not doing the minimum. We are headed in quite the opposite direction. It's not easy to keep things simple while improving security but it can be done.
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 not intended as a means to revoke previously issued certificates, only an indication of which CAs are _currently_ allowed to issue new certificates.
That said, I agree with you, but the general consensus doesn't seem to, that we de facto trust registries/registrars as stewards of domain ownership, so we may as well de jure make them CAs, since they already have an account relationship.
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.
The CA/B mailing list can't do much about shady behaviour they don't know anything about.
I do trust in Mozilla to ensure that the game rules for CAs are strict enough that my trust in the green lock isn't 0. It's not 100% either but it's above 50%. When I connect to a website and it has SSL, I'm fairly certain it's the right place.
Most likely there will never be a replacement for it, any PKI requires some third party to vouch for an endpoint otherwise you get easy MitM (I believe there is a proof floating around somewhere from the area of Signal Theory).
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 by a "forwarder" daemon that is placed between the nameserver or httpd and the internet.
IMO, much less complex than SSL/TLS, x509 and commercial CAs and control over encryption does not require third parties.
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.
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.)
But the average user has no idea if the website saying it's paypal really is paypal. Could be payscam instead, operated by Mr. Untrustworthy, AZ.
SSH works because the servers and endpoints you connect to are usually endpoints the user has setup themselves and are in the local area network.
>Unfortunately for users, this is delegating the intervention to humans that have no "skin in the game".
CA's do have skin in the game. If they fuck it up too often nobody will trust them anymore to verify trust. See: StartSSL, Symantec and soon Trustico.
If the encryption is defeated then the CA's entire business model collapses. The CA's have strong incentives to not fuck it up or not get caught doing so.
With Certificate Transparency we have tools to catch anyone trying to not get caught cheating.
>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.)
To verify the key of a endpoint you either have to decide yourself if it is trustworthy or rely on a third party.
If you don't verify with a third party and you don't ask the user if the connection is okay, MitM is trivial.
If you ask the user, social engineering can make MitM trivial.
A third party will be required in some way, be it a CA or the Web of Trust or something else. However, the CA model has been the only one that successfully operated at this scale. The WoT has largely degraded to TOFU for 90% of users.
https://www.trustico.com.au/ssltools/create/csr-pem/create-a...
Generated server-side.
I'm done with these companies, Let's Encrypt seems to be the only people doing it right.
regardless of who discloses the private key, a CA is required to revoke any keys that they learn have been compromised within 24 hours. CAs have been reprimanded in the past for failing to do so.
The only ambiguity is the initial request to revoke by trustico - essentially for a CA the question is whether trustico is the agent for the certificatesTo clarify they disclosed private keys to an entity other than the owner of the key, which automatically starts a 24 hour countdown for the CA.
The only ambiguity here is whether a reseller like trustico gets to decide to revoke certificates that they sold or whether the end users are the owner and so are the only people who can request revocation without proof of key compromise.
From the point of view of the CA the initial “revoke all these certs “ email could have been any random person on the internet collecting public certificates, and then telling the CA to revoke them.
The communication that needlessly included the private keys was equivalent to someone trawling github or what have you, then reporting all private keys that they found to the appropriate CA. It doesn’t matter how someone proves access to the private key, and it doesn’t matter who demonstrates it, all that matters is that someone said “here is evidence this key is no longer under complete control by its owner”.
At that point a CA must revoke and no one gets to stop that.
Hopefully the fact that revocation is largely broken doesn't make this worse...
Trustico want to sell their customers their own branded certs, and DigiCert aren't going to just let those customers go.
I for one am done with all of them and had any affected sites shifted to auto-renew certs within about 20 min.
If its just "for your convenience" I would have walked off this keypair years ago.
Private key generated for me one line and held in your keystore? No thank you.
Personally thinks that centralized CA proving trust of unknowns of long distance again and again prove that the security of centralized trust is weak!
How is this not related to "the big distrust"? Unreal.
This implies that Trustico was sent the keys (or recieved them somehow) from a third party who had compromised them.
20k certs implies a tremendous number of clients; seems tome it's more likely one of Trustico's intermediate CA certs got compromised and these 20k are newly issues ones against that compromised CA cert.
They’re not the only party to do so either, e.g. DNSimple (which is otherwise a great company!) also provide APIs to have them generate and store certificates including private keys: https://developer.dnsimple.com/v2/certificates/#getCertifica...
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 certificates is too difficult, then feed improvements upstream. And yes, I know how horrible openssl's UI is for dealing with anything other than CN based certs. It's awful enough for those, an absolutely atrocious for pretty much anything else.
For the record, CN has been deprecated in certificates since ~2000 (RFC 2818), and practically obsoleted since 2011 (RFC 6125). Regardless of all this, I have dealt (in 2017) with parties who don't understand SAN over CN, and have even had their software stacks blow up when I provide a cert with SANs only, and no CN.
In fairness, though, your certificate vendor already has the power to issue a brand new certificate for your domain if they wanted to quietly snoop on traffic.
Same thing with AWS generating SSH keys if you want them to - they can get at all the data on your server anyways. No, it's not the greatest practice, but it probably does help a bit for making things easier for less-technical users.
If a hypothetical Bad Guy has got a different Certificate for my site they cannot "quietly snoop on traffic". They have to do an active Man-in-the-middle attack on each connection or else it's completely opaque to them. Each of the clients they do this to receives a free Smoking Gun, a copy of their illegitimate certificate showing who signed it and when. In a future where CT policy enforcement is completed (not yet but maybe soon) they must also have logged the certificate so that everybody can see it, or it won't work.
If the hypothetical Bad Guy has my Private Key, they can quietly snoop traffic using ciphersuites which lack "Forward Secrecy" although no popular browser will choose this unless forced to, and in TLS 1.3 Forward Secrecy is mandatory.
If the Bad Guy has my Private Key and is willing to do a Man-in-the-middle attack the same applies as above, except that I don't learn anything from Certificate Transparency since they can use my cert as they know the key for it.
You're the security hero we need, but not the one we deserve
> We have purchased thousands of certificates using Trustico as a reseller within the last years. Back in these days Trustico created CSR / Private Key pair within their online platform (Yes, you read it right - you can create CSR/Private Key on their webpage !!!) which was the default at this time and it is still possible to do so in their web interface.
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 can go wrong.
However, even if we assume Trustico was an authorized party, the keys became compromised the moment they were disclosed to DigiCert unless the terms their users agreed to included DigiCert as an authorized party. Even if they were you could make an argument that those keys were compromised due to the fact that they were literally sent via email, unless they were properly encrypted and what not.
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 owners of the old Symantec root, to issue revocations.
When Digicert said no, that's not how it works, they responded by sending over all of the private keys they had. The fact that they had those keys, and the fact that they sent them via email to Digicert, is entirely separate from any technical problem that Symantec or Digicert may have had.
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?
They also state in the MDSP thread, "We were also a victim whereby Symantec mis-issued SSL Certificates owned by us, subsequently we were asked to keep the matter quiet, under a confidentially notice."
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.
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?
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.
You pretty much have to concentrate it down to a small subset of trusted certificate authorities to sign your certificate.
Also, it should be a way to verify that random people aren't able to get certificates on behalf of a domain they don't own (there's nothing stopping me from generating a cert for google.com - but it should be impossible for me to get it trusted by your browser).