I hope it's not overly pedantic to point out that what you linked to is not a CAB forum thread. That's a thread on the Mozilla security policy list, which many root programs and CAs make use of for disclosure and discussion.
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.
From that thread, as a snarky aside: "I know from dealing with Let's Encrypt users that people can get some ideas about what's going on with the Web PKI that bear no resemblance to reality, and although we have no formal duty to teach them better, there's no benefit to the world from pretending they're right."
"Trustico’s CEO indicated that Trustico held the private keys for those certificates, and then emailed us approximately 20,000 certificate private keys."
Well, that's one way to ensure they're considered "comprimised".
Trustico now posted a statement on their site[1]. My favourite part is this:
> 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.
What a bizarre defense. Do they think this makes them look...better?
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.
The secondary part is that they requested mass revocation of active certificates, including from brands such as RapidSSL which were not being browser distrusted AFAIK (even though some others were.. if I need to be corrected on this please let me know).
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.
> The secondary part is that they requested mass revocation of active certificates, including from brands such as RapidSSL which were not being browser distrusted AFAIK (even though some others were.. if I need to be corrected on this please let me know).
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).
The DV CA space is such a mess. I still wish DV certificate issuance was the responsibility of the domain registrar, with technical measures taken to prevent competing registrars from misissuance. This way, you don't need to play whack-a-mole around your certificates, just pick a reputable registrar when you buy your domain, avoid the need to "prove" you hold the domain (your registrar control panel is today already the sole security barrier protecting your domain), and avoid the possibility that a third party can play the impostor game. And it would bring some meaning back to the reputation of different TLDs and their various registrars.
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-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 :)
> 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 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.
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.
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).
"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 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.
"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.)
SSH authentication is TOFU, trust on first use. The user will be asked to confirm if the endpoint is legit.
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.
> 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
Tying PKI to DNS veers pretty close to DANE, and I imagine most of the criticism against DANE would remain valid.
Maybe, but today's DV PKI is already trusting DNS 100%, since certificates are issued based on using DNS responses to validate the certificate request. If you don't trust the governing body of a specific ccTLD, for example, you are already worse off today - a hostile ccTLD DNS operator could very well arrange to fake DNS responses for the duration of a certificate request?
Maybe it's not so bad to make it more obvious what a fancy .ly or .lol TLD really stands for?
Even non DV PKI uses a lot of trust of the DNS. Where I work, I got our first non-DV certificate issued, and while the CA verified our organization exists (and made our certs show the city listed in our corporation filing instead of the city I wanted to show), the only reason they issued certificates to me is because I did essentially Domain Validation for the domain.
Yep, it's a race to the bottom for CAs to perform the absolute minimum work necessary, because otherwise competitors come in and make things easier for customers. Paying a premium for the services of a stricter CA currently has no benefits, since end-users have no way to evaluate whether a certificate is legitimate vs sloppily or maliciously issued by a different CA.
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.
"it's a race to the bottom for CAs to perform the absolute minimum work necessary"
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.
Sorry, I was mostly having the various commercial EV services in mind for that comment. Thanks for all the great work your team seems to be consistently doing!
To clarify trustico disclosed private keys to an entity other than the owner of the key, which automatically starts a 24 hour countdown for the CA.
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.
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.
Nobody who has depth in the business would create keypairs online if they could avoid it. So I ask myself if key escrow requirements "back then" permitted this kind of engagement with an agent, on behalf of government or other constrained PKI contexts where escrow was a requirement.
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.
> 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 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.
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.
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.
Probably. In some amount of fairness, Trustico's stated motivation was that they didn't feel like they trusted Symantec (reasonable!) and the same people were involved with the move to Digicert (which I think is correct, some employees moved but technical oversight should have moved to the more organizationally-competent Digicert team) and the same problems were likely to happen again (I think Digicert is generally good at being a competent CA, but it's not unreasonable for them to decide the risk is too high if some of the same people were around).
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."
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.
If they operate as any other CA does, there's no reason to assume that they would have had any way to have the private keys which would only ever be on customer systems.
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 apparently have a “certificate wizard” that will generate the certificate and corresponding private key for you. Of course that’s practical for the end user (generating a CSR can be cumbersome), but obviously insecure.
> 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 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.
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...
> If you didn't create the private key yourself, by definition it's not private.
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.
> 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.
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.
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...
This is not wrong, but in the context of them generating and storing private keys for their users it means there's nothing in the Baseline Requirements preventing them from doing so if the subscriber (user) agrees to it.
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.
I recently learned in my security class that certificates are the way by which domains are publicly identified. But I don’t understand why there hasn’t been any alternatives besides trusting these companies to issue certificates...
It would be really hard to keep everyone's browsers/operating systems updated with a list of certificates as they're generated and renewed.
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).
