1

From what I understand, when you send information to a website over SSL, you encrypt the information you send with their public key.

However, if you want to be able to decrypt the information they reply with, you are going to need a private/public key combination yourself. I don't ever recall having been prompted for an RSA key by my browser, or been required to generate one; where does this key come from?

If your browser creates one for you, is it generated once and then stored on your computer forever, or is a new key generated for every session or site?

0

3 Answers 3

2

During the TLS handshake the client will use the public key of the server, which it was passed following the ServerHello message, to encrypt a pre-master secret. It is not the entire session key. In the ClientHello message and ServerHello message the two parties swap random values. The server and the client now use the pre-master secret and the random values to generate the same master secret, which can be used as a session key.

The server's public key is used because in asymmetric cryptography the only person who will be able to decrypt the message will be the holder of the private key.

Check out the wikipedia page for more details on the TLS handshake.

0

There's a few ways this can work. But this gist is that your asymmetric keys are used more for identity validation rather than encryption. While typically only the server needs to verify its identity, sometimes the server can request that the browser identity itself back using a client certificate. Try it out here if you like.

†: Startcom is a certificate authority famous for providing free certificates, but for also having a website so totally unusable that people actually pay for certificates anyway, just so they don't have to use startcom's site.

Once the identities are squared away, the client and server go about establishing a session key for the actual encryption. So while the certificate identity stuff uses RSA, the actual session encryption generally uses AES or RC4, or Blowfish -- symmetric ciphers where the same key is used to both encrypt and decrypt. These are dramatically faster.

There's a couple of ways to go about generating a session key. How it is done depends on what features are supported by the server and browser. The older more naive approach is to simply generate a random number and send it encrypted using the public key. THe problem is that if the session is captured by an attacker who later acquires the private key, he'll be able to decrypt past sessions.

A better solution that is gaining traction uses Diffie-Hellman key negotiation to generate a shared secret that is never communicated. The negotiation still uses the asymmetric keys to ensure that the negotiated key isn't corrupted by a man-in-the-middle, but the important point is that the key never transits the wire, not can it be derived by anything that gets communicated. This means that when the connection closes and the client and server both forget the key, the data, if captured, can never be decrypted again. This topic gets plenty of attention here on this site under the moniker Perfect Forward Secrecy.

1
  • The 'older more naive approach' you describe does not correspond to anything that actually happens in SSL. The session key is not generated by the client; is not encrypted; is not transmitted; and is not decrypted. It is calculated independently by both peers via a key agreement protocol.
    – user207421
    Mar 21, 2017 at 4:03
-1

Their public key is used to allow your browser to send a session key to them. Once that's been achieved, your browser and their server both know the session key, and use it to encrypt in both directions.

The session key is ginned up on the fly by your browser, a new one for each session, no interaction required.

2
  • This is not actually how the TLS handshake works. If answers are going to be posted they need to be factually correct.
    – NRCocker
    May 29, 2014 at 4:23
  • The session key is not generated by the client; is not encrypted; is not transmitted; and is not decrypted. It is calculated independently by both peers via a key agreement protocol.
    – user207421
    Mar 21, 2017 at 4:02

Not the answer you're looking for? Browse other questions tagged .