UPDATE: Edited because I’m a dumbass who doesn’t know what a CSR is.
There is a distinct chance I’m very wrong about my recent realization regarding TLS. It’s TLS, so apparently everyone gets it wrong, even the folks who wrote TLS. So if this is possible then tell me how. Just pick a web server and tell me how to do this. I can’t figure it out, so I’m going to ask this one simple question:
Why can’t I use a private certificate I purchased from a Certificate Authority (CA) to sign a secondary private key that I put on the server?
It’s not self-signed, as I’m proving I did purchase a certificate and funneled more money into the “Random Bits For Cash” industry. Instead this would be me basically adding one more link between me and the CA so that I don’t have to put my real key on any servers. The reason I ask is because the #1 flaw of TLS is that someone who’s not you (the CA) has your private key, can give it to anyone they want, and you have to put this key on your servers making them valuable and vulnerable targets.
This is totally off the top of my head, but I think it might work like this:
- I buy my certificate from RandomBits Corp by sending my signing request and all the things necessary.
- They do nothing to confirm my identity, and then give me a certificate that’s totally secure and works because the browsers have given them a monopoly.
- I take my tools and generate a secondary key pair that’s exactly the same information as the original, and the tools would just read my real private key to do that for me.
- I use my real private key to sign this new certificate proving I do actually own both, and put this new secondary key set on my server, plus my real public key, and all the usual CA information.
I probably got the signing sequence wrong and such. Too much painting going on, but the gist of it is then a browser can confirm this secondary key like this:
- Server presents the secondary key just like normal, but includes the real public key.
- Browser uses the real public key to check the signature on the secondary key, confirms it’s all in the CA certificate chain, that the information (server, identity, etc) are the same in both, and then uses TACK to ensure forward secrecy.
- After that, if the secondary key changes, but if everything checks out, then the user can be warned about it, or just go with TACK. This part is debatable since being able to change the key might be important to allow for changing keys if they’re compromised, so probably allow this as an option.
The reason this might be a good thing is that one of the primary attack vectors that TLS proponents seem to gloss over is accessing the private key.
You have the problem of an attacker compromising a server and then gaining decryption access for all traffic to a domain. If you have hundreds of machines that manage your https traffic then they all need the private keys, so that’s a huge attack vector. You can mitigate some of this, but ultimately the best solution is for each of those servers to get their own key to reduce your potential damage. You also have difficulty in giving your key to a 3rd party to handle your https traffic for you.
By allowing people to sign their own secondary key, you solve the following problems:
- The NSA can’t get the private key even if they get on the server or somehow get it like they seem to be able to right now. They could sign Man In The Middle (MITM) keys, but if browsers are using TACK and warning about secondary key changes, then that’s blocked. To get at the traffic on millions of connections to large sites they would need the secondary keys of every server, not just the one big key.
- Attackers can’t destroy your certificate investment by compromising one server, and can’t get access to all traffic by getting at one server. One server means only that one server’s traffic is compromised, and then you just rotate the key.
- It solves problem of allowing a 3rd party handle my https traffic. Rather than give Amazon or Cloudfront my private key, I give them my secondary key setup and then I don’t worry about them having rogue employees stealing my keys or leaking them to others without my permission.
It also doesn’t seem to have any technical reasons to block it. It’s a one time thing that is done on first connect and should only add a small amount of overhead to that connection, where then TACK would take over from then on. Also, it seems any time someone wants to make TLS more secure there’s a small faction of detractors who trot out the “performance” criticism and it ends up being bullshit anyway. Maybe this time we can just admit that it’s not too bad to make clients do some more work to secure things better.
Of course, I could be a total idiot and this is something that browsers and web servers support, but I have honestly never ran into it. Looking at the TLS standard I think it’s not supported, and I don’t remember this being in any protocols. All the docs for setting up a web server say put a real private key on your server, so if it’s supported then I’m not the only idiot.
However, what if I’m right and we could secure up a major flaw in the internet by changing how keys are stored on servers? Don’t even take my back-of-the-napkin design here (please don’t). Just set a future design goal to be this:
No TLS server will ever store the real private key.
As long as we have PKI that can sign keys, then this should be feasible and realistic. I’m also baffled why I didn’t think of this before, and wondering why I can’t find anyone else who has. Feel free to comment and tell me if someone else already thought of this and if it got shot down for some reason. I’m very curious.