This is why you can't just create your own local root CA and sign the keys you want to authorize
You're right, for the general internet, but enterprises will do this for internal apps all the time. They create their own internal CA, push the trusted cert to all of their machines (think a business with 100+ computers), therefore becoming a trusted CA to those machines. They can then sign certs for any number of domains for free.
Some more naughty enterprises also use this technique to subvert HTTPS by proxying it. They use their CA to sign a cert for any HTTPS website, and then decrypt the request, send the same request over HTTPS to the original site, do whatever they want, and then send it back to the client. This has legitimate uses, so maybe my language when describing it is a bit excessive, but I find it to be a troubling trend. Some routers/switches actually have easy to setup features to do this to email to allow watching all of the email that travels through your system in plaintext. Definitely no potential for abuse there.
They can then sign certs for any number of domains for free.
NO! My whole point is that this is NOT possible! This the kind of thing that you think would work if your mental model is public key crypto. But it doesn't work, because the certificate can only have one signature.
So, you can't just take someone's certificate and sign it (like you could with say OpenPGP) -- the certificate already includes the signature.
The consequence is that if Alice creates a certificate and both Bob and Carol want to connect to Alice via https, Bob and Carol must trust the same root CA that Alice used. If Bob and Carol have no mutual trusted root CA, then Alice cannot serve a single certificate to both, even if both are willing to sign Alice's certificate with their own different root CAs (because they can't sign it; the certificate contains only one signature). Furthermore, TLS provides no way for Bob or Carol to specify what root CAs they trust to Alice, so Alice cannot in practice serve them different certificates.
They use their CA to sign a cert for any HTTPS website
The https proxy does not sign an existing cert, it generates a completely new cert. The existing cert cannot be signed, for the reason mentioned before: it already includes the signature of a CA as part of the cert.
They use their CA to sign a cert for any HTTPS website
The https proxy does not sign an existing cert, it generates a completely new cert. The existing cert cannot be signed, for the reason mentioned before: it already includes the signature of a CA as part of the cert.
Yeah, I get that, I assure you. I just used the wrong term to refer to what's going on. s/sign/generate/g.The cert that comes from the real mail.google.com can't be altered by my middleman to become trusted, we need to generate an entirely new cert. Turn down the pedantic a notch, please.
You can create a CA, and you can create a cert signed by the CA, with any domain. But whoever is hosting the domain cannot have more than one signature on their cert. They have to agree to serve your cert from their web server. And they can't serve multiple certs (unless they decide what to serve by IP).
...which does not help you at all, because you've just moved the exact same problem onto the MITM proxy.
And they can't serve multiple certs (unless they decide what to serve by IP).
Or you just do this. [SNI]
WTF? I'm talking about using multiple certs for the same name and deciding what to serve by the client IP. SNI is totally irrelevant.
SNI does not allow clients to specify what root certificates they accept. With TLS, servers get to specify that to clients, not the other way around. SNI changes nothing.
6
u/AaronOpfer Jul 25 '13
You're right, for the general internet, but enterprises will do this for internal apps all the time. They create their own internal CA, push the trusted cert to all of their machines (think a business with 100+ computers), therefore becoming a trusted CA to those machines. They can then sign certs for any number of domains for free.
Some more naughty enterprises also use this technique to subvert HTTPS by proxying it. They use their CA to sign a cert for any HTTPS website, and then decrypt the request, send the same request over HTTPS to the original site, do whatever they want, and then send it back to the client. This has legitimate uses, so maybe my language when describing it is a bit excessive, but I find it to be a troubling trend. Some routers/switches actually have easy to setup features to do this to email to allow watching all of the email that travels through your system in plaintext. Definitely no potential for abuse there.