31

As I understand it, SSL involved the use of a public-private key pair. How does this enable two-way communication?

Suppose I have some server with which I wish to communicate securely. I connect to it, and it supplies me a certificate, which contains its public key (assume the certificate is valid). I then take my request, and encrypt it with this public key, and transmit the resultant ciphertext to the server. This communication is secure from eavesdropping. But how does the server return to me my results securely? I lack a public/private key pair, and have no certificates.

Paŭlo Ebermann
  • 22,946
  • 7
  • 82
  • 119
GWLlosa
  • 659
  • 1
  • 6
  • 8

7 Answers7

16

That's not quite correct. In SSL, two things happen:

  • First, a session key is negotiated using something like the Diffie-Hellman method. That generates a shared session key but never transmits the key between parties.

  • Second, that session key is used in a normal symmetric encryption for the duration of the connection.

SSL does use public/private in one way, because an X509 certificate is used to identify at least one end of the connection. Those certs are signed using an asymmetric key pair.

cypherfox
  • 1,442
  • 8
  • 16
Charlie Martin
  • 617
  • 4
  • 11
10

The result depends much on the type of certificate the server has and the chosen algorithm - the answers already given all give just some cases.

If the client does not have a certificate, as in your example, there are three possibilities:

  • RSA key exchange algorithm: the client picks a random pre-master secret value and sends it to the server, encrypted by the RSA key given in the server certificate, which must have keyEncipherment bit enabled in its key usage.
  • DH_DSS, DH_RSA, ECDH_ECDSA or ECDH_RSA key exchange algorithm: The client generates an ephemeral (freshly random generated) Diffie-Hellman key to do key agreement against the fixed key present in the server certificate, which must have keyAgreement bit enabled in its key usage.
  • DHE_RSA, ECDHE_RSA, DHE_DSS or ECDHE_ECDSA key exchange algorithm: server sends an ephemeral (freshly random generated) Diffie-Hellman key in addition to the certificate and the client answers with its own ephemeral Diffie-Hellman key. The server certificate is only used to authenticate the server via a signature, the pre-master secret comes entirely from the Diffie-Hellman algorithm.

If the client does have a certificate, the choices are the same, but the difference is that in the non-ephemeral Diffie-Hellman cases, a client may send a client certificate containing a fixed key for key agreement.

So, to simplify things: if the client does not have a certificate, the client either sends a "shared secret" encrypted to the server or generates a random key and does key agreement. After this, there is a securely shared key and everything else is just symmetric encryption with that key.

Nakedible
  • 1,460
  • 11
  • 15
5

If you have secure communications in one direction, you can always have secure communications in both directions. The sender could just generate a random string, send it to the other side, and then they could communicate bidirectionally using that random string as a key.

The sole purpose of the public-private key pair is for authentication, not encryption. If I want to send my credit card information to Amazon, I want to make sure I'm really talking to Amazon and not someone else. Since Amazon doesn't care who I am (because I'll send a user and password anyway), there's no reason I need a public-private key pair or certification.

With no certificate on either side, we could still establish a connection secure from eavesdropping. But neither side would have any idea who they were talking to.

David Schwartz
  • 4,739
  • 21
  • 31
4

Essentially, the client generates a random symmetric key, and sends it to the server using the server's Public Key. The client already knows this symmetric key, so the server does not need to send anything back, thereby eliminating the need for every client to have a Public Key.

The request is then encrypted using the same random key, which both parties now have, and so two-way communication continues.

3

SSL/TLS is a protocol which allows the use of several algorithm combinations (cryptographic suites), for key exchange, authentication, encryption, integrity protection. The answer on your question depends on which one is used. During session startup, client and server negotiate which algorithms will be used.

All of them rely on authentication of at least one side (normally the server) to avoid man-in-the-middle attacks.

The main communication will be encrypted symmetrically. Here are some ways to get the symmetric key:

  • The client chooses the session key (or some important part of it) randomly, and encrypts it with the public key of the server. The server then can decrypt it.
  • Client and server use the Diffie-Hellman key exchange algorithm to get a key, and after this the server signs the resulting key (and other session parameters) by its private key (which can be checked by the client).

In both cases, the client has to check the certificates of the server to ensure that it really speaks to whoever it thinks to speak to.

In the case of client authentication, also the client has to sign the session data so the server can verify it.

In these signature schemes, each signing party has a certificate which links the public key to some other information, which the other party can use to verify that the key pair belongs to the right owner.

There are also certificate-less authentication (and key exchange) schemes, like password based authentication in SRP. Still, without authentication of at least one side it will not work.

Community
  • 1
Paŭlo Ebermann
  • 22,946
  • 7
  • 82
  • 119
1

All the previous answers do adress the question. But I would like to point to http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html which gives complete working example of SSL verfication and use process using Firefox connecting to amazon.com. It nicely explains how keys are derived (after certificate verification) for symmetric encryption for secure communication.

Mike Edward Moras
  • 18,161
  • 12
  • 87
  • 240
vaichidrewar
  • 119
  • 2
1

After the server presents a user with its certificate, a fresh, secret value should be generated and returned by the user after being encrypted with the server's public key. The initial messages by both parties should also contain a fresh nonce. The three random values should then be used to derive (often a SHA-1 hash of the values) a new, shared key to use for future symmetric encryption. Since an eavesdropper can not discern the third value, they will be unable to derive the symmetric key used for future communication.

Only after the symmetric key has been derived should the user begin sending requests.

bzc
  • 545
  • 9
  • 21