9 ms·
Mozilla to Certificate Authorities: no subordinate CAs for traffic interception
- onedognight 15y agoThank you Mozilla.
- melvinram 15y agoFor the uninformed, what does this mean? (Btw, I did read the post; I just didn't understand it.)
- mbrubeck 15y agoThis Ars article from last week gives some context and explanation: http://arstechnica.com/business/news/2012/02/critics-slam-ssl-authority-for-minting-cert-used-to-impersonate-sites.ars http://arstechnica.com/business/news/2012/02/critics-slam-ss... In short, at least one CA, Trustwave, has issued a "subordinate CA certificate" (which allows another party to issue certs which will be trusted as if they were from Trustwave) to a network admin who used it to create forged certificates and intercept SSL traffic on their internal network.
- dmboyd 15y agoHas there been any talk about which company received the subordinated cert? The excuse for it being used in an internal network only doesn't really hold any weight due to the ability to install custom certs on all web browsers.
- LaGrange 15y agoThis way even user-installed browsers would accept the subordinated cert. It's one of those things I believe should be prosecuted.
- matkam 15y agoApparently some root certificate authorities have been issuing certificates that lets others generate their own, valid certificates at their own discretion. Sounds these subordinate CA certificates are being used for SSL man-in-the-middle attacks (http://en.wikipedia.org/wiki/Man-in-the-middle_attack http://en.wikipedia.org/wiki/Man-in-the-middle_attack). So say your employer wants to monitor everything you're doing at work. In order to get around the fact that a lot of your network data is encrypted, they put in a device between your network connection and the internet that looks at all your network traffic. For any connection that is SSL encrypted (like https pages), it will forge its own valid certificate, and use it to prove to your web browser (etc) that nothing is wrong with the connection. Meanwhile, its logging the content of your Gmail, etc.
- astrodust 15y agoThis is the unfortunate flaw with SSL and TLS. The certificates are bound only to the "domain name" which is a wobbly concept at best without DNSsec to validate your DNS responses. Anyone clever enough to create a DNS redirector that turns paypal.com into 10.0.0.2 on their closed network could also create an accompanying SSL certificate that they own for paypal.com and you'd be none the wiser as they proxy all of your traffic through their server, logging every bit of it.
- jvdongen 15y agoAnd even if the IP address is unaltered - what will prevent the owner of the closed network from routing every http(s) request silently through a proxy on its way out to the Internet?
- omgtehlion 15y agoIf you have a router with “deep packet inspection” there’s no need to change IP address.
- icebraining 15y agoOr if you just set up a transparent HTTP proxy.
- robtoo 15y agoI would feel a lot more confident about actual compliance if Chrome came on board with this as well.
- duskwuff 15y agoFor historical reasons (viz. NSS), Mozilla maintains its own list of trusted CAs. Chrome uses whatever is provided by the OS, so they aren't in a position to make the same sorts of demands. Not that I disagree with the sentiment -- there's just a very specific reason why Mozilla is involved, and it's not simply because they write a web browser.
- joshtalon 15y agoChrome already has a mechanism to detect a MITM for Google's servers by embedding those servers' public keys into Chrome itself. Of course, that doesn't stop a company from placing locally-trusted rogue certificates on computers they control, overriding Chromes public-key pinning check. But it means that they can't MITM a connection from your personal laptop when you're on their network.
- rwmj 15y agoFirst of all .. are they going to enforce this? Indeed, can they enforce it? Is it possible to detect such certificates and will Mozilla remove root CAs. Secondly, this doesn't do anything for the fundamental broken design of CAs which is that any CA in the world can issue a certificate for any website. Firefox ships with dozens of certificates for such eminent organizations as "OISTE WISeKey Global Root GA CA" (who they?), basically anyone who can stump up the fee and fill in a form on Mozilla's website. Any of these could issue duplicate or fraudulent certificates, and any of them could be attacked.
- throwaway64 15y agoIt can be enforced, because the certificate chain will indicate that the x.509 cert has been signed by an intermediate CA
- rwmj 15y agoSuch certificates are allowed in general, just not if the site is a 'global' site (whatever the definition of 'global' would be). That's why I don't think this is enforcible.
- jbri 15y agoWhere are you getting this "allowed in general" thing from? I can't see anything in there at all that would imply that.
- pilif 15y agoMany certificates that you can buy today are issued by legitimate resellers of bigger CA's. That's done by the big CA (which is in the list of trusted roots) handing out a CA certificate to the reseller. We'd probably want to keep this as is or the already way too big list of roots in the browsers becomes totally unmanageable. Or we move back to the days of only a handful of roots, which probably means also going back to the old prices ($500+ a year for a non-ev one)
- jtchang 15y agoSuppose you visit https://mail.google.com/ https://mail.google.com/ from inside a corporate network. Assuming ideal scenarios no one can snoop on your traffic between you and Google because of SSL. If a company wants to monitor you they have lots of options. One option is to try and record all traffic between you and Gmail. However if the try to do that your web browser will pop up a warning saying mail.google.com is pretending to be someone else. To get around this a company can create fake certificates that are trusted by your browser. Then they need to intercept the traffic and basically pretend they are gmail all the way recording you. Ignoring the fact that companies already have a lot of rights to snoop on whatever you do this is just bad precedent.
- dekz 15y agoOr they can provide default VMs which have a company certificate as a trusted root, either locally or in the Active Directory. Then it's simply a intercept and dump without the browser complaining. (I cannot confirm the active directory problem in other browsers apart from IE)
- mikemaccana 15y agoInterestingly, Chrome and Gmail do strange things when you MITM attack them. Try enabling Charles Proxy and watch all he requests to securebriwsing.Google.com.
- icebraining 15y agoSee dektz's reply. Companies create their own CA cert (you can do that using e,g. openssl) and use domain policies to install it on every machine they control. Then they can setup a proxy that takes the CA cert and dynamically generates certs for each domain that is accessed over HTTPS (Squid can do that).
- wcchandler 15y agoSo this article is suggesting that this practice is wrong and will not be tolerated or that the root CA authorities should not be the ones to generate the certificates?
- zokier 15y agoSo did they decide what to do with the TrustWave-case? Are they forgiven for their confession? That seems to be the implication of this announcement.
- joshtalon 15y agoMakes you wonder what actually happened with TrustWave (there's obviously more to it than "Oh, this was an ethical dilemma so we stopped."). Probably their customer found a way into the intermediate CA private key and was being naughty with it. What I think sparked Mozilla is TrustWave's claim that this kind of thing is widespread and commonplace among CA's. That's shouldn't surprise anyone, though.
- yason 15y agoI think CA's are problematic nevertheless because they involve a third party I never invited. I would much prefer to have a ssh style public key fingerprint that you must verify and accept for one site, and know that once I've decided to trust them, nothing can come between me and them unlike with SSL certification chain. I would prefer to receive my bank's public key on paper when signing up for online banking and verify that it equals what I see when I first connect to their servers. This reduces the MITM to the initial handshake. This could be worked out to a degree with some p2p scheme or a set of DHTs for popularity count. Fingerprints would be submitted to a public service that accumulates submissions from different users, identified by the same public key used to sign the submissions. Trustworthiness would be weighted based on the history and age of the users' submissions: someone who has used the same public key and submitted fingerprints for five years is likely to be a real user that you can trust instead of a bot that generates new identities in order to submit false fingerprints to launch a MITM. There are numerous ways to implement this. One positive thing would be to bring the same attention to trustworthiness to people's minds that they must employ in "real" life as well, i.e. offline. A website that's never fraudulent or genuine (unless you got it in writing) but shades of trust more reflects the interactions we encounter in real life (can I trust this guy because my friend said he's ok?).
- joshtalon 15y ago> This reduces the MITM to the initial handshake. Mostly. No matter much you trim your certificate chain, there's nothing preventing Google/your bank/Amazon/etc from sharing their private key with, say, Uncle Sam. However, the backdoor admin access that the gov't gets to sites like TwitterFace and Gmail probably makes that a pointless effort. Confidentiality/Authenticity are pretty much impossible to guarantee unless you control everything on both ends.
- dasil003 15y agoUm, that's not MITM then is it? I mean yes, if you're paranoid enough you probably should build an underground bunker in the mountains and grow your food, but objectively there is a huge security difference between whatever shenanigans a trusted partner may be up to and a large body of auto-trusted with potentially leak able-to-who-knows-where subcerts.
- yason 15y agoI think CA's are problematic nevertheless because they involve a third party I never invited. I would much prefer to have a ssh style public key fingerprint that you must verify and accept for one site, and know that once I've decided to trust them, nothing can come between me and them unlike with SSL certification chain. I would prefer to receive my bank's public key on paper when signing up for online banking and verify that it equals what I see when I first connect to their servers. This reduces the MITM to the initial handshake. This could be worked out to a degree with some p2p scheme or a set of DHTs for popularity count. Fingerprints would be submitted to a public service that accumulates submissions from different users, identified by the same public key used to sign the submissions. Trustworthiness would be weighted based on the history and age of the users' submissions: someone who has used the same public key and submitted fingerprints for five years is likely to be a real user that you can trust instead of a bot that generates new identities in order to submit false fingerprints to launch a MITM. There are numerous ways to implement this. One positive thing would be to bring the same attention to trustworthiness to people's minds that they must employ in "real" life as well, i.e. offline. A website that's never fraudulent or genuine (unless you got it in writing) but shades of trust more reflects the interactions we encounter in real life (can I trust this guy because my friend said he's ok?).
- DrCatbox 15y agoAwesome news, finally someone stands up to the blatant misuse of trust. I work in such a company where SSL mitm is a part of day-to-day development. It is disgusting that the security of SSL is broken for the sake of corporate control over its workers.
- tptacek 15y agoMozilla was faced with what appears to be the worst possible abuse of the privilege of being a Mozilla CA root. The abuse happened for commercial purposes. The transaction that occurred was on its face abusive of the CA system. The CA hasn't (and probably can't) name the company that was given illegitimate CA privileges. In response to this, Mozilla sent out a letter. That letter doesn't even instruct CAs not to sell subCAs! It says, "don't sell them for MITM purposes". I think Mozilla is between a rock & a hard place here, but there is no spin I think you can put on this story in which Mozilla stood up against abuse of trust.
- feralchimp 15y ago> Mozilla is between a rock & a hard place here, but there is no spin I think you can put on this story in which Mozilla stood up against abuse of trust I'm not sure it's worth our energy to be so disappointed in Mozilla here. That "they're between a rock and a hard place" precisely is the spin within which they stood up against abuse of trust. They have sent out a letter so far. One of your worries appears to be that it sets the precedent that companies who do what Trustwave did can expect (only) letters in the future. But (iirc, and perhaps even in the bugzilla thread) one of the stated purposes of the letter is to set the opposite precedent: to publicly warn commercial CA's that future bullshit will result in distrusting. I happen to think Trustwave had plenty of warning without the letter, but this particular hard place is particularly thorny because Mozilla is such a central policy hub. That's a problem you touched on above, that we agree needs a fix, but it's the way things are today. The other half of the hard place is that before Trustwave pulled this BS, they issued a whole lot of legit commercial certs to a predominantly innocent user population. And you know, they can and should all go acquire certs from someone else, but they can't do that overnight. So if we really want Trustwave to get distrusted, I feel like we should focus our energy on a) telling people that Trustwave sucks and urging them to migrate, and b) paying attention/effort to initiatives like the one you mentioned from MM.
- tptacek 15y agoThis is being read as good news, as Mozilla sticking up for its own users by enforcing a new control on its CAs. But what it actually reads like to me is a surrender. For once, I'll line up with the howl- at- the- moon crowd and say that, excepting the fact that Mozilla might have been boxed into a corner here, this is a bit of a travesty. What you're not getting in this story is the following set of facts: * A Mozilla-approved CA appears to have sold one of its customers a CA=YES cert --- in other words, they sold one of their customers the ability to be a CA. * The customer wanted the cert to implement a "data loss protection" system. These are systems that either sit on the network or on everyone's machine and scan traffic to make sure people aren't exfiltrating company secrets. DLP systems want to see inside of SSL/TLS traffic. * You don't need a CA cert to look inside the SSL/TLS traffic of your users. What you're meant to do is, create your own self-signed CA root certificate and install it yourself in all your users' browsers. Yes, this is painful. * So instead of incurring that pain, this particular company got a CA to, in effect, install that certificate in the browser of every computer on the Internet. That they didn't intend to MITM the traffic of every one of those computers is beside the point. * Instead of the exact audit and certification process used by Mozilla to add new CAs, this chained sub-CA was audited by the CA itself. But: before you say, "well at a minimum you'd hope the CA audited them!", you should know: the primary business of this particular CA is auditing. * The CA didn't appear to have told anyone this for a long time (I want to be careful to point out that I don't know exactly what the timelines are here; from the CRLs, it doesn't look great). * Something happened that caused the CA to announce that they had issued the cert. * A long discussion happened on Mozilla Bugzilla, under a critical security blocker bug that more or less requested that the CA be removed from Firefox. * Publicly, the policy response from Mozilla was, "they came forward, and removing their cert from the roots is an extreme punishment". I think behind the scenes, getting rid of this CA was problematic for other (valid) reasons. * So instead, stern letter to all the CAs. Yay! The Internet is safe again. I don't know how much more cut-and-dry an abuse of the CA system you can get than selling your CA status to random unnameable companies so that they can implement MITM systems. But more than that: it is simply batshit crazy that CAs are allowed to sell CA=YES certs at all. I don't get it. Maybe someone working at a browser vendor can reply to this comment and explain to us why any one company is trusted to make a decision like that for the entire Internet? I am a vocal and public fan of SSL/TLS, and I've even on occasion stuck up for X.509 (horrid as this certificate format is). But this stuff here is the part of the SSL/TLS system that the privacy zealots are right about. I'm hopeful that we'll see adoption of a system like Moxie Marlinspike proposed with "Convergence", where instead of blindly accepting Mozilla's policy decisions (and updating our policies once- in- a- blue- moon), we'll have end-user-selectable trust roots and thus an incentive for someone (maybe the EFF) to do a good job running such a root. I'm also hopeful that at some point we'll manage to figure out a UX for website trust that is better than what we came up with in 1997.
- unseen 15y agoThey have ruined security for everyone by allowing government agencies (they didn't even bother to setup a front) and other questionable entities on that list. The correct response is not to send out a nice letter asking everyone to please give up crucial business information, but to kick everyone off that list and start over. Mozilla was compromised, not the CAs.
- guelo 15y agoShould we remove Trustwave from our personal browsers? Or as admins from our users' browsers?
- drcube 15y agoTime to eliminate CAs altogether. I don't see why my trust in them should be assumed: http://convergence.io/details.html http://convergence.io/details.html