0

If an encrypted connection can be compromised when a server's private key is stollen, why don't servers simply generate a new private key for each unique session. It seems like it would eliminate a point of vulnerability if it was just generated as needed.

I'm assuming that it has something to do with verifying authority chains, or performance, or something like that, but I was wondering if anyone knows for sure why it's not done that way?

  • 4
    They do, it's called forward secrecy. – AndrolGenhald Nov 29 '18 at 22:00
  • 1
    And for TLS 1.3 it is the one remaining method for master secret and thus session key derivation. Of course, a server could cheat and not generate new key pairs per connection, but I guess that's easily detected. The keys of the temporary key pairs are called ephemeral keys, and "ephemeral" is the final E in DHE and ECDHE in TLS ciphersuites before TLS 1.3. – Maarten Bodewes Nov 29 '18 at 22:07
  • @AndrolGenhald - Although OP also mentions verifying the authority chain, so maybe they meant no permanent key (server certificate)? – Clockwork-Muse Nov 29 '18 at 22:10
  • @Clockwork-Muse Yeah, but the question also mentions "encrypted connection" and "unique session" which all point to the confidentiality of the connections, rather than server authenticity. And with the old RSA and the (hardly used) DH cipher suites a permanent private key is used. Anyway, the question points to very little knowledge about TLS, I would propose to Nosajimiki to read the TLS RFC very carefully first, and possibly find a few tutorials as otherwise things will be hard to explain. – Maarten Bodewes Nov 29 '18 at 22:18
  • @AndrolGenhald Thanks, that link answered my question. I assumed that the private key in a PFX file was used in the actual encryption, I did not realise it was just used for authentication. – Nosajimiki Nov 29 '18 at 22:36
2

When you connect to a server there are two types of encryption in play.

First, there's a public-private keypair associated with asymmetric encryption that is used to validate your identity. Typically (in the case of visiting HTTPS websites), you create a long lived pair of keys (one public and one private), submit the public key part and identifying information to a trusted certificate authority (CA), prove your identity to the certificate authority's satisfaction (e.g., verify you control the domain the certificate is being issued for), and the certificate authority signs the certificate for you. Now you post your CA-signed certificate publicly on your website. Anyone connecting to the website for the first time, whose browser/OS already trusts the CA that signed your certificate, can verify the identity of the website you are connecting to by issuing challenges to the CA-signed certificate that you can only answer if you control the websites private key. Note the certificate is only used for the authentication of identity (by relying on chain of trust with certificate authority) at the start of a conversation.

To actually transmit data, you don't use asymmetric encryption as asymmetric encryption is slow and only encrypts short messages. Symmetric encryption is much faster and work well to encrypt arbitrarily large messages quickly. For the symmetric encryption part, you use key exchange protocols like DHE to have both servers negotiate a shared symmetric key that will be used to encrypt and decrypt messages, and the key exchange protocol can negotiate a random symmetric key without actually sending the shared symmetric key over the network.

For an example of a key exchange protocol that doesn't send the full key over the network for Alice to send a message to Bob, first they both agree on two numbers generator (g) and modulus (N) and each picks a secret random number a and b (Alice generates a and Bob generates b; note Alice will never learn b and Bob will never learn a). Then Bob send a message to Alice containing Kb = g^b mod N. Alice calculates the shared secret key K = g^(ab) mod N by calculating K = Kb^a mod N. Alice uses the secret key K to symmetrically encrypt her message and sends it to Bob along with Ka = g^a mod N that Bob will need to decrypt. If a network eavesdropper Eve listens in on their messages, they see g, N, g^a mod N, g^b mod N and the encrypted message, but do not have a known feasible way to calculate K without additionally knowing a or b. This key exchange however is still vulnerable to active tampering, where Alice could try sending a message to Bob, but instead Eve pretends to be Bob. This is why in addition to forward secrecy at the start of the conversation you need Alice and Bob to identify each other (which is customarily done using the long lived certificates signed by CAs).

Forward secrecy does your suggestion of not reusing the random symmetric keys at all, but renegotiating them with each exchanged message.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.