30
$\begingroup$

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.

Improve this question
$\endgroup$
2
  • 3
    $\begingroup$ The public key is only used during connection setup, to negiotiate a key pair (or two of them?) for symmetric encryption. You would't want to use asymmetric encryption for the whole connection. $\endgroup$
    – Paŭlo Ebermann
    Jul 12, 2011 at 20:56
  • $\begingroup$ If you think about it, if you have secure one-way communication, you have secure two-way communication (assuming you have a two-way communication channel at all). If I have a secure path to you, I can make up a random key, send it to you over that path, and then you can use that to encrypt messages to me, giving you a secure path to me. $\endgroup$
    – David Schwartz
    Aug 20, 2011 at 10:14

7 Answers 7

Reset to default
17
$\begingroup$

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.

Improve this answer
$\endgroup$
10
  • $\begingroup$ SSL can use Diffie-Hellman to generate the session key $\endgroup$
    – Géal
    Jul 13, 2011 at 7:48
  • $\begingroup$ @Soumya92, no it doesn't, re-read the description and follow the link to en.wikipedia.org/wiki/… and note that TLS isn't actually identical to SSL. But the original SSL handshake is like having an empty PreMasterSecret. $\endgroup$
    – Charlie Martin
    Jul 13, 2011 at 19:25
  • $\begingroup$ @CharlieMartin Noted and corrected $\endgroup$
    – Soumya
    Jul 13, 2011 at 19:41
  • $\begingroup$ and don't believe everything that wikipedia says. $\endgroup$
    – Jus12
    Jul 16, 2011 at 18:00
  • 2
    $\begingroup$ Netscape developed SSL 2.0 which is now all-but-abandoned. SSL 3.0 was developed and Netscape evaporated and handed stewardship of the protocol spec to the IETF who promptly renamed it TLS 1.0 (to fit their nomenclature). SSL 3.0 and TLS 1.0 are nearly identical. Nobody (give or take) uses TLS 1.1 or 1.2. The use of Diffie-Hellman to agree upon an ephemeral key is an option that client and server may choose to agree upon, but it's totally an option and not preferred by most sites due to the computational expense. $\endgroup$
    – Marsh Ray
    Aug 5, 2011 at 3:37
10
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • $\begingroup$ In the newest TLS 1.2, the *DH_* algorithm names are declared as "historical" (RFC 5246, page 49 (at the bottom)). $\endgroup$
    – Paŭlo Ebermann
    Aug 16, 2011 at 21:08
  • 2
    $\begingroup$ In TLS 1.2, there is a special "signature_algorithms" extension, which specifies the possible signature types. That supercedes the definition of the signature algorithm inside the key exchange name. Hence, the key exchange algorithms in TLS 1.2 could be just "DH" and "ECDH". That's why the *DH_* names are historical - the algorithms themselves are not deprecated in any way. $\endgroup$
    – Nakedible
    Aug 16, 2011 at 22:17
  • $\begingroup$ Ah, thanks. I'll have to reread the whole document, I think. $\endgroup$
    – Paŭlo Ebermann
    Aug 16, 2011 at 22:19
5
$\begingroup$

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.

Improve this answer
$\endgroup$
4
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • $\begingroup$ both client and server contribute to the generation of the master secret key, from which encryption and authentication keys are derived. The client's contribution to the MSK is encrypted using the server's public key, the server's is sent in cleat. The server needs to have a certified public key but needs not to prove he knows the associated secret key. This is achieved implicitly by showing that he can decrypt the client's contribution. $\endgroup$
    – giuper
    Jul 13, 2011 at 12:37
  • $\begingroup$ @giuper, well, they both contribute, but I think that's a less-important detail. I think Soumya92's answer provides just about the optimal level of detail. Given that the original question-asker seems to be asking mostly for the basic concept and intuition, I think Soumya92's answer is at the right level of detail, and any more detail risks making it confusing. $\endgroup$
    – D.W.
    Aug 15, 2011 at 3:57
  • $\begingroup$ Thank you for answering it terms that answer the question. No more detail was needed. $\endgroup$
    – Bodman
    Nov 6, 2016 at 2:53
3
$\begingroup$

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.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Note: I think you refer to authentication via a certificate. You didn't mention it. $\endgroup$
    – Jus12
    Jul 16, 2011 at 19:06
  • $\begingroup$ And of course, the client needs a certificate too, to support the client authentication. $\endgroup$
    – Jus12
    Jul 16, 2011 at 19:07
  • $\begingroup$ @Jus: You are right. $\endgroup$
    – Paŭlo Ebermann
    Jul 16, 2011 at 19:47
  • $\begingroup$ Not all of them rely on authentication of at least one side. There are "DH_anon" algorithms which do not authenticate either side - these are not enabled normally. These are obviously vulnerable to man-in-the-middle if there is nothing else validating the peer. $\endgroup$
    – Nakedible
    Aug 16, 2011 at 22:45
  • $\begingroup$ Are there ciphersuites that only perform client authentication? Which ones? $\endgroup$
    – Maarten Bodewes ♦
    Sep 8, 2014 at 14:07
1
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • $\begingroup$ nonces are used to avoid replay attacks, and not for "protecting" the secret value from eveasdroppers. And, TLS does not require the server to have an encryption key. A DSA key will also work. The two parties will use DH key exchange in this case. $\endgroup$
    – Jus12
    Jul 16, 2011 at 18:25
  • $\begingroup$ I never said the nonces are used to protect the secret value... $\endgroup$
    – Brandon Carter
    Jul 16, 2011 at 19:21
  • $\begingroup$ I am assuming you meant that the "third value that the eavesdropper cannot discern" is a nonce. At least thats what it seems from the text. $\endgroup$
    – Jus12
    Jul 16, 2011 at 19:37
1
$\begingroup$

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.

Improve this answer
$\endgroup$
1
  • 2
    $\begingroup$ Please edit your link-only answer. Links to external resources are encouraged, but you should add context around the link so your fellow users will have some idea what it is and why it’s there. Additionally, you should always quote the most relevant part of an important link, in case the target site is unreachable or goes permanently offline. For details, read How do I write a good answer?. $\endgroup$
    – e-sushi
    Sep 8, 2014 at 10:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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