Hacker News new | past | comments | ask | show | jobs | submit login

That was the first and only CA to be excused for that.

When ANSSI did it, they got name-constrained to French TLDs only: https://bugzilla.mozilla.org/show_bug.cgi?id=952572

When CNNIC did it, they were distrusted: https://blog.mozilla.org/security/2015/04/02/distrusting-new...




Right, because the security of the CA system is a game of probability. No, one bad apple spoils the haul.


Probability has nothing to do with it. Trustwave was excused because what they were doing was not expressly prohibited at the time and other CAs were probably doing the same thing. Trustwave proactively came forward about what they had done. They shouldn't have been the only ones to be distrusted as a result. CAs are not going to be excused for this again, as CNNIC and ANNSI show.


It was not expressly prohibited to have third parties sign a certificate for google.com?

Security isn't some taxation game where you find a loophole for your weekend car in the rules, it's about outcomes.


No, it wasn't. That's because the certificates we're talking about were intended to substitute for Google's. They were for enterprise networks, some of them with legal requirements to monitor outgoing traffic (Google Mail in particular is a big problem at regulated financial firms.) The CA=YES certificates were housed in DLP and proxy appliances that ran only on the borders of their own networks.

Enterprises wanted these certificates because the alternative to them is installing additional root certificates on everyone's desktop machines, which is a logistical pain.

I'm not excusing that CA transaction. Issuing CA=YES certificates as a convenience for enterprise security teams is terribly irresponsible, and never should have been allowed.

But, at the the the Trustwave thing happened, it was not expressly black-letter against the rules, and so Trustwave didn't get the CA death penalty for it.

They would, supposedly, if they did it again.


This is getting circular. I'm fully aware of the purpose of these certificates. The discussion was "did Mozilla make the right decision in excusing a CA that essentially decided to create an extra root CA". The result was a rogue google certificate in the wild. I guess browsers don't care that it was only intended for proxying employee traffic, after all.

I certainly think that in the circumstances, no, they did not. The Mozilla CA policy isn't some legally binding document. They are free to change it and still death-penalty whoever was ultimately responsible for these rogue certificates.


I'm not sure what you expect from Mozilla. It would be nice if there was a way to instantaneously kill a CA and ensure all of its issued certificates continued to work, so that a big chunk of the Internet wouldn't suddenly break. If that capability existed, Mozilla or Google could nuke CAs left or right without even checking the Basic Requirements. But it doesn't, and so the process for handling CA inclusion is done by the book.

In this case, the book said "I guess proxy MITM CA=YES certificates are fine, as long as you're careful".


We're getting to the root of the issue after all. Mozilla simply wasn't prepared to nuke a popular CA unless Google and Microsoft joined in to the fun.

Policy was just the excuse. We saw what happened with CNNIC. Coordinated press releases.


I don't know, it seems like, however unprepared anyone is to nuke a popular CA, they're going to be even less prepared if that CA didn't actually violate the policy.

You keep writing as if it's common sense that the policy should say "nobody can issue CA=YES certificates to enterprises". But while I agree strongly that they shouldn't, this is not common sense. The certificates that Trustwave sold were never deployed on the public Internet, and their disclosure outside of whatever giant bank bought them would presumably have been accompanied by massive civil liability.

The policy didn't mention this behavior not because it never occurred to anyone to ban it, but because it was overtly, actively thought to be OK, by pretty much every stakeholder, until browsers started getting better at monitoring certificate issuance.

Really, the simple truth is: you have Google to thank for pretty much every positive shift in norms about SSL/TLS CAs. Until they built the team they have doing this today (which is amazing), certificate issuance was --- not hyperbolically, but actually, factually --- the lawless wild west.†

Do I wish they'd built that team a few years earlier? Yes, of course. I also wish heap and integer overflows were better known in the early 90s. You can't always get what you want.

The Google team will pointedly add that we should be thanking the Mozilla team for the work they've been doing on keeping a coherent CA policy and trusted root set going all these years; as you can see from this thread, it's a thankless task. I don't agree with all of Mozilla's decisions, but if you throw down in a m.d.s.policy thread about them being incompetent or ineffectual, be prepared to have people who have forgotten more about certificate issuance than you've ever learned give you some pretty vivid comparisons to how other certificate stores have been managed all this time.


No, nothing like that. The browsers had not made it clear to CAs before 2012 that such products were not to be sold. I distinctly remember seeing these sorts of products quite publicly for sale (but in the hundreds-of-thousands-of-dollars range, I think) on CAs' websites in the late '00s.

It was a different time then, and we've gotten better at expecting CAs to be competent. The probability that action will be taken today for the same thing is 1.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: