Solving The #1 Flaw In TLS

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:

  1. I buy my certificate from RandomBits Corp by sending my signing request and all the things necessary.
  2. 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.
  3. 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.
  4. 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:

  1. Server presents the secondary key just like normal, but includes the real public key.
  2. 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.
  3. 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:

  1. 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.
  2. 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.
  3. 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.

3 thoughts on “Solving The #1 Flaw In TLS

  1. I’m reasonably sure what you’re looking for here is being issued a “CA” or “signing” certificate from your CA. If you look at a typical browser that’s connecting to an SSL Site, you’ll see 3 levels of certificate.

    A “Root” certificate (actually in the browser),
    a “CA Chain” certificate (that’s queried for by the browser and cached for a period of time),
    the actual SSL/TLS certificate issued to you, the server owner.

    Now, typically your certificate provider owns both the Root and the Chain cert. They use the chain for extra security, and easy rotation over a period of years. If you’re really big (the only example I have is, you can get your CA to issue you a signing cert so you can sign your own certs. They use this for a 3-month (or so, I’m not sure I don’t work there) rotation period of the actual domain certificates. At the end of the 3 months, they swap out the certificate, revoke the old one, and carry on.

    So, I figure what you want is just a CA signing cert to be able to sign your own certificates that govern your domain(s). And why we can’t get them for domains we can prove that we own is an excellent and open question. I don’t have a good answer and would be very curious to know.

    If this doesn’t match up with what you wanted, please let me know. And I’m always curious for feedback or if I was incorrect in any of the above.


  2. As you said its mostly the “bits for cash” monopoly, but also becuase (as far as I know) we dont support semi privileged keys. You could act as a CA for anyone and they’ll be trusted, and despite the sorry state TLS is in, this would be worse.

    If it worked like buying signing cert for * and you could create single domain certs for and I would be one of the first to jump on board, despite the outrageous cost of wildcard compared to single domain certs.


    • No, remember in my post I said it’d only work as a proxy key for your one key and domain, just like it does now. You wouldn’t be able to act as a CA for the entire internet, just your one domain name.


Comments are closed.