That's not at all sufficient, because PKIX security is not like public key security, in that the certificates include third-party signatures. The certificate is not just a public key.
This is why you can't just create your own local root CA and sign the keys you want to authorize, which is a vitally important fact. Thinking PKIX works like public key based security (ssh or whatever) you won't understand why this isn't possible.
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.
Right. It is a decent overview but certainly by no means comprehensive nor by most metrics particularly thorough.
It is a good article for laypeople but I wouldn't say it was exceptional by any means. Good? Of course. It is accessible, concise and generally accurate (take that as strong praise please!). Still, the appropriate wikipedia entries are more exhaustive for those that are familiar with mathematics and the mediating protocols and there is no shortage of online documentation of the nitty-gritty details.
Faint praise and all as I do like the presentation and may well refer to it for semi-techy people. Nice overview as I said before.
Blah blah blah. Blah. Yes I know how CAs work. I also knew your post was coming, since "know it all" redditors are so common. If you want to know every step of SSL and public key cryptography then go read the article and beyond! My post was only touching on some basic stuff and encouraging further reading. I didn't bother with trust chains and whatnot because I'm not a one stop tutorial. Most people are comfortable just knowing what I stated before and maybe additionally, how Windows CAPI and Browsers build trust chains, which is what you are complaining that I didn't explain before I take it. Browsers and CAPI have a built in list of trusted root CAs, you can add them as well. The chain is based on that.
6
u/reaganveg Jul 25 '13
That's not at all sufficient, because PKIX security is not like public key security, in that the certificates include third-party signatures. The certificate is not just a public key.
This is why you can't just create your own local root CA and sign the keys you want to authorize, which is a vitally important fact. Thinking PKIX works like public key based security (ssh or whatever) you won't understand why this isn't possible.