The First Few Milliseconds of an HTTPS Connection

http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html

by moserware • 17 years ago

236 33 17 years ago

gsmaverick• 17 years ago

Wow, thanks for taking the time to do this in-depth writeup. Really cool to see what all goes on in milliseconds of time.

messel• 17 years ago

Love the play by play. Was aware of the handshake after that I thought there would be some matrix like kung-fu fight scene... Seriously, thanks for the share and kudos to the author.

edave• 17 years ago

Really well written! One thing I was curious about was the use of TLS_RSA_WITH_RC4_128_MD5 instead of TLS_DHE_RSA_WITH_AES_256_CBC_SHA: what's the difference between these setups in terms of mem/cpu usage? Obviously it varies between servers, but is it roughly 2x, 10x slower?

brl6• 17 years ago

The relative cost of the symmetric bulk encryption algorithms (RC4 vs AES here) is irrelevant compared to the expense of the key exchange/agreement and authentication.

The first ciphersuite uses the most common option where the server sends a certificate containing an RSA public key and the client chooses a random number, encrypts it with this key, and sends the encrypted value to the server. The server then decrypts this value with the private half of the key and derives the session keys from it. The expense of this decryption increases with the length of the RSA modulus.

The second ciphersuite uses ephemeral diffie-hellman where both sides choose a random number, and then exchange them. In order to accomplish this securely, the server must at least provide a certificate with an RSA key that supports signing (and signature verification) so that the client can verify that the diffie-hellman parameter received from the server has not been tampered with.

The DH parameter sent from the client to the server needs to be checked out too, and there are two ways this can be accomplished. If the server certificate contains a second RSA key which is marked as suitable for encryption, then the client can simply encrypt with this key as in the simple RSA key exchange described above. If this encryption key does not exist, then TLS provides a crazy way that the handshake can still succeed:

1) The server generates a temporary RSA key pair (very expensive)

2) The server signs the public half of the key pair with the RSA signing key in the certificate, and sends it to the client.

3) The client uses this key to encrypt the diffie-hellman value to send to the server.

When the diffie-hellman parameters have been exchanged the server must perform an RSA private-key operation to either decrypt the client value or verify the signature on it. This has the same cost as in the first type of key exchange and depends again on the length of the RSA key. After verifying the client value, the server must complete the DH protocol which requires an expensive modular exponentiation which is roughly as expensive as an RSA operation.

So no matter what, the second option is going to perform worse than the first option. The real reason though that the server probably rejected the second ciphersuite is because no certificate was available with an RSA signing key needed to complete the protocol.

tptacek8• 17 years ago

Unfortunately, RC4 and AES are not comparably secure, and by conflating the cipher with the protocol variants, that issue is somewhat muddied by the article. Nobody should be using RC4. It's also a bit misleading to say that AES encrypts "16 bytes at a time" where RC4 encrypts 1 at a time: AES can easily be turned into a byte-at-a-time stream cipher using CTR mode; there's just not much value to doing so in TLS.

There's another reason why DHE isn't super popular: inside enterprises, security groups will have reasons to want to monitor connections to their servers. DHE makes that pretty much impossible, by decoupling the server's private key from the actual session key. This sounds like a good thing until you realize that such monitoring has no privacy implications at all (they own the server, they can just sniff the sockets), only (negative) operational implications.

brl6• 17 years ago

I need to correct something here. The temporary RSA key generation is never used for ephemeral DH, but rather for the situation where RSA key exchange is requested and only a signing key is available.

The server does not even verify an explicit signature on the client DH value because this is covered when the entire handshake is validated in the final step (The finish message).

Since the server does not perform an RSA operation on the client value, my conclusion about performance is totally bogus.

bsaunder2• 17 years ago

Excellent write up.

I frequently wish descriptions like this existed in a fractal form with ever increasing complexity that could be "zoomed in" (or out) for more or less detail. Many times the problem is the inverse, some overly generalized news blurb lacking details or even reference links.

This seems like the well crafted super magnified version. I loved all of the in-line reference links!

yan• 17 years ago

This is actually exactly the project I've been planning for a while and am starting in a week or so!

If you (or anyone really) are interested in hearing me out or helping, email me.

ludwig• 17 years ago

No way. I've also been thinking about that project for a while now.

tybris• 17 years ago

That is amazingly insightful.

tptacek8• 17 years ago

This is a fine article. Unfortunately, it describes very specifically how not to verify an PKCS RSA signature, perpetuating a mistake that screwed over browser vendors a couple years back:

http://www.matasano.com/log/558/public-key-signature-forgery...

To wit: you verify specifically cannot look at the SHA-1 hash at the end of an RSA block and compare it to your own hash, because there are hundreds of zillions of other RSA blocks that can result from the RSA algorithm that could contain a SHA-1 block of an attacker's choosing.

Vendors learned the hard way that to verify an RSA signature, you have to reconstruct the entire m block you'd expect to see, and byte compare it to the entire "decrypted" m block from the certificate.

Crypto sucks.

moserware3• 17 years ago

Good point! If I update the post to indicate that the length is also checked in secvfy.c: http://www.koders.com/c/fid7EBD6C04C1D001D6410ED86171294E237...

and link to the matasano series, would that better address your concern?

tptacek8• 17 years ago

Don't link to that source code. Mozilla's RSA implementation is really hard to follow. The most important security check there is nowhere near the function you've linked to. The "length" of the block isn't the issue (the "length" is the key size); verifying that every bit of the expected m block matches, bit for bit, with the received m block is.

Don't get me wrong. Great article. It has to be possible for general practitioners to write about encryption without inciting people to write their own, the same way it has to be possible for general practitioners to write about brain surgery without inciting people to cut other people's heads open. You didn't intend this as an implementation guide. =)

cperciva• 17 years ago

Not exactly. Yes, you have to verify the padding; no, you don't have to build a decrypted signature and compare the two byte by byte.

The lesson here is "use proper padding and follow the published instructions for verifying it".

CGamesPlay• 17 years ago

Very nice writeup there; good job :)

The First Few Milliseconds of an HTTPS Connection

Related Stories