6

I'm sure there's plenty of obvious reasons for this, but why can't an SSL session be started with one round-trip?

It seems like this would be enough:

  1. Client sends their public key
  2. Server responds with:
  • Its certificate (public key + whatever is needed to verify it)
  • A symmetric key to use (encrypted with the client's public key / signed with the server's private key)

The problems I can think of are:

  1. You may need to know the version of the protocol beforehand.
  • It seems like the protocol could be designed so that the client first sends a version, then their public key, and if the server doesn't understand it, it sends a "try this version" message", which would be faster in the best case (client and server both understand the same protocol), and just as fast as SSL in the worst case ("version 2...my public key", "I don't understand, use version 1", "version 1...my public key", "my certificate...encrypted key).
  • To make the protocol more backwards compatible, you could have two versions, one for the public keys to be exchanges and one for everything else. Only the public key version would break compatibility and require the second round-trip.
  • Obviously this wouldn't be backwards compatible with SSL now, but why wasn't it there in the first place?

  1. Maybe more work for the server, since it needs to (1) generate a cryptographically secure symmetric key, (2) encrypt that key using public key encryption, (3) sign the result of that using public key encryption. Is the problem that it would be too easy to overload the server?

  2. Something I'm missing?

This has just been bothering me all day, since it seems so obvious, but there has to be some glaring flaw that I'm missing (and that's why I'm not a security researcher).

EDIT:

A link posted by @lour has this quote:

In a TLS handshake, the "Finished" messages serve to validate the entire handshake. These messages are based on a hash of the handshake so far processed by a PRF keyed with the new master secret (serving as a MAC), and are also sent under the new Cipher Spec with its keyed MAC, where the MAC key again is derived from the master secret. The protocol design relies on the assumption that any server and/or client authentication done during the handshake carries over to this. While an attacker could, for example, have changed the cipher suite list sent by the client to the server and thus influenced cipher suite selection (presumably towards a less secure choice) or could have made other modifications to handshake messages in transmission, the attacker would not be able to round off the modified handshake with a valid "Finished" message: every TLS cipher suite is presumed to key the PRF appropriately to ensure unforgeability. Once the handshake has been validated by verifying the "Finished" messages, this confirms that the handshake has not been tampered with, thus bootstrapping secure encryption (using algorithms as negotiated) from secure authentication.

So why not just have the server and client both sign their cipher-negotation messages with their private keys? I know, more work, but still faster than an RTT, right?

Community
  • 1
Brendan Long
  • 2,878
  • 1
  • 19
  • 27
  • 4
    Have you looked into Google's False Start implementation? https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00 & more info here http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html – lew Sep 21 '11 at 04:21
  • 1
    Your protocol lacks a lot of feature of SSL, like client side cert usage if asked by the server, and pedestrian stuff like protocol version and cipher suite negotiation. Cutting features makes for simpler protocols, news at 11. – Bruno Rohée Sep 21 '11 at 14:30
  • @Bruno Rohee - Client-side cert usage is extremely rare. When needed, the server could request it and it would be no slower than it already is. – Brendan Long Sep 21 '11 at 20:13

3 Answers3

17

If I understand your proposal correctly, there are at least two vulnerabilities in it:

Replay attack

An attacker may be able to sniff an encrypted communication, record it and replay it at a later time.

There are two common approaches to prevent it: Usage of time stamps, which only works in a controlled environment in which you can be sure that the clocks are synchronized. Therefore the common approach In order to prevent this, both parties have to send a random number and require the other party to prove that it got this number, by either sending it back or using it in some mathematical operation.

Man in the middle attack

The browser sends his public key to an attacker. The attacker contacts the real server and sends his own public key.

The server answers with his certificate and the session key both signed with the private key of the server and encrypted with the public key of the attacker.

The attacker decrypts information, and re-encrypts it with the public key of the client. The signature stays valid because the attacker does not modify the certificate or session key. It stores the session key for later use.

The client verifies the certificate and signature of the real server, and is happy.

Other approaches

There is another approach by Google called SSL False Start, that does not have these issues.

Community
  • 1
Hendrik Brummermann
  • 27,118
  • 6
  • 79
  • 121
  • 1
    Your MITM attack doesn't work as the phase "he attacker decrypts information, and re-encrypts it with the public key of the client" violates the proposed protocol, as it should also be signed by the server private key, which the MITM don't have. – Bruno Rohée Sep 21 '11 at 14:26
  • @Bruno Rohée, the attacker is will not modify the certificate nor the session key, so the signature stays valid. Unless the server does not sign the certificate and session key directly, but the encrypted data stream. If you had this uncommon approach in mind, please edit your proposal to make that obvious. – Hendrik Brummermann Sep 21 '11 at 14:46
  • @Hendrik Brummermann, I was definitely thinking that the encrypted data would be signed (to prevent exactly the situation you mentioned). What I was thinking is: The signature by the server doesn't contain anything private, so it can be in-the-clear; the symmetric needs to be encrypted, and encrypting it with the client's public key means only the client can read it. If the client's public key was replaced, when the MITM tries to re-encrypt it, they would also need the server's private key to sign it. – Brendan Long Sep 21 '11 at 16:15
  • The replay attack definitely sounds like "something I was missing". Thanks. – Brendan Long Sep 21 '11 at 16:22
  • @Hendrik Brummerman it all depends on what the proposed protocol actually sign, if it's the whole message and not the key. Applying the usual "encrypt then sign" protects about your MITM attack. You seem to assume it's "sign then encrypt", which would indeed be vulnerable. The spec is too unclear to settle that I think ;-) – Bruno Rohée Sep 26 '11 at 09:26
4

It is theoretically possible to do it more quickly than it is done. A lot of the reason why it works the way it does is due to history - Netscape essentially cooked up SSL on their own in about 1994, and it was also largely responsible for the revisions that became SSL 3.0 - it wasn't moved to the IETF until after that time, and the IETF essentially reissued the SSL 3.0 spec as TLS 1.0, in order to foster backward-compatibility. So, a lot of the decisions had been made at that point.

Some reasons why it can't be done more quickly are results of the flexibility included in the system. For example, the server can decide whether or not to demand a client certificate from the user, and the connection can support switching ciphersuites as needed. Renegotiation is supported in a variety of cases.

In the end, it doesn't matter much - most implementations make use of resumption, where the client specifies an established session ID on a new connection and the server simply picks up where it left off. In practice, browsers will do a full handshake once, and then resume the session over and over. When you combine that with HTTP keepalive (the usual state of affairs in HTTP/1.1), the result is that you don't really do as many full handshakes as you'd think.

If TLS were redesigned from scratch today, it may have been done differently. Nevertheless, the chattiness of TLS isn't a major practical problem.

Steve Dispensa
  • 3,441
  • 16
  • 20
2

3 . Something I'm missing?

The simplest problem with your proposal is that the server has no way to authenticate the client public key that it's handed on the first leg, so using that key to encrypt the symmetric key leaves the connection wide open to Man In The Middle.

With the current system, the many (clients) need to look up the few (server) keys to validate that they're talking to who they think they are (e.g., "www.google.com"). To reverse that would require a relatively massive lookup system against essentially arbitrary and changing identifiers ("dhcp123.dialup.bigisp.net").

If you're looking to save a hop, take a page from Microsoft. Once upon a time IE would combine the ACK (third leg of the three way handshake) with the HTTP request data payload in one packet. In general, only IIS servers would play that game, of course.

I'm not convinced that disrupting these things to save one or two packets is worth it in any case, but it's a worthy gedankenexperiment.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • I'm assuming that the server doesn't care who the client is. By encrypting the symmetric key with the client's public key, then signing that encrypted data with the server's private key, the server can be sure that only that client has the symmetric key (or if there is a MITD, they would know because the signature would be wrong). Who the client is doesn't matter (although you could store their public key in a database if you wanted to use it for authentication, but presumably you're only authenticating your own users). – Brendan Long Sep 21 '11 at 16:20
  • No, you don't fully understand the implications here. If there is a MITM, they can't "know because the signature would be wrong" - the signature can only be wrong if the party knows who it wants to talk to and has some way of verifying that they're talking to them. If "the server doesn't care who the client is," then that aspect of the security has been thrown out the window, and completely compromised the security of the solution. – gowenfawr Sep 21 '11 at 18:30
  • 1
    Assume you have a response from the server containing `signed(encrypted(symmetric key))`. If the MITM replaces the client's public key, then the client won't be able to decrypt the `encrypted(symmetric key)`. If the MITM decrypts it and re-encrypts it, the signature will be wrong. If the MITM wants to re-sign it, they need the server's private key (which we assume they don't have). – Brendan Long Sep 21 '11 at 19:13
  • The client knows that their talking to the server, because the server's certificate is signed by a CA (this is no different than normal SSL). The server doesn't care who the client is, just that the connection with them is secure (this is also no different than normal SSL). If you want to verify the client using a certificate as well, it could be requested by the server (extra round-trip, no different than normal SSL). – Brendan Long Sep 21 '11 at 19:16
  • "If the MITM replaces the client's public key," it will then re-encrypt whatever the real server sends back encrypted with the MITM key using the clients original key, and the client will never notice. So that's not the problem. You're correct, however, that the client will eventually get the chance to determine that the server cert isn't what it expects. But at that point, you've saved nothing over the traditional SSL workings, and you've actually lost various computation cycles, so why are we riding this horsie again? – gowenfawr Sep 21 '11 at 20:00
  • You're missing an important step. The encrypted symmetric key is **signed by the server**. The MITM can fix the payload, but it **can't re-sign it** because they don't have the server's private key. And remember, the MITM can't replace the server's certificate, because their certificate is signed by a CA (which the client already trusts). – Brendan Long Sep 21 '11 at 20:10
  • We agree on everything you just said. The difference is that I'm asserting that throwing the client key into the mix up front to save a theoretical packet is useless because a) it doesn't have any of the protections you're describing here with the server cert, so b) you'll need to go on to do the traditional server protections in any case, at which point c) there's no reason to throw that initial client key exchange in *at all*, thus d) this truncated SSL handshake provides zero improvement, which is 3. the something you're missing. – gowenfawr Sep 21 '11 at 20:25
  • **I'm talking about encryption.** No one uses SSL for client-authentication. I've literally seen it used one website in my entire life (a certificate authority). If you're using it for client authentication, then yes, you need a way to trust the client's certificate, but **that's no different than SSL now**. – Brendan Long Sep 22 '11 at 01:27
  • And yes, you do need the client's key, to prevent the **exact attack you just described like 3 comments ago**. – Brendan Long Sep 22 '11 at 01:27
  • That's it, you're off the island. – gowenfawr Sep 22 '11 at 13:29