rdist

December 17, 2007

SSL design principles talk

Filed under: Crypto,Network,Security — Nate Lawson @ 11:12 am

I recently gave a talk to a networking class at Cal Poly on the design principles behind SSL. The talk was a bit basic because I had to assume the class had little security experience. My approach was to discuss how it works and stop at each phase of the protocol, asking what security flaws might be introduced by changing or removing elements. This worked well to get them thinking about why SSL has certain components that appear weird at first glance but make sense after closer inspection.

Others have told me that they use a similar technique when learning a new crypto algorithm by starting with the simplest primitive, identifying attacks, and then adding subsequent elements until the whole algorithm is present. If attacks still exist, the algorithm is flawed.

For example, consider DSA, one of the more complex signature schemes. Use the random value k directly (instead of calculating r = (gk mod p) mod q) and the signature operation is simply:

s = k-1(H(m)) + x mod q

This introduces a fatal flaw. k-1 can be calculated from k via the extended Euclidean algorithm. The message is usually known, and thus H(m) is also. Thus, this would directly reveal the private key x to any recipient!

The references section at the end of the talk gives a good intro to the design principles behind SSL, especially the Wagner et al paper. My next articles will explain some SSL attacks in more detail.

6 Comments

  1. Wonderful set of slides on SSL, thanks so much for breaking a difficult concept down! If you have a moment, I hope you don’t mind some additional questions.

    – How exactly is the SSL session key generated? Do the client and server exchange public keys or just the server? Does the client generate a token/key and then send that back encrypted with the Server’s public key? I’ve never been able to figure this one out exactly.

    – On identity (MD5 hash), how exactly does that work again? MD5 (or SHA-1) makes a hash of the message, then that hash is encrypted using the public key of the recipient system?

    Thanks so much for your time, and keep up the tremendous work!

    lance

    PS: Is SSL even used anymore or primarily TLS?

    Comment by lance — December 17, 2007 @ 12:34 pm

  2. lance, thanks for the comment.

    Normally, only the server sends a public key. The SSL session key is generated from the ClientKeyExchange, ClientRandom, and ServerRandom messages. Since the latter two are public (but hopefully random), only the ClientKeyExchange contributes entropy to the session key. Assuming RSA is the public key algorithm, the server decrypts the ClientKeyExchange method and then hashes the contents (i.e., the client’s randomly generated PreMasterSecret) with the Client/ServerRandom messages to produce the shared key. The client does the same. (Quiz: why are the Client/ServerRandom messages included in the session key generation process if they’re public?)

    If client certificate authentication is being used, the client sends its certificate (and thus public key) in response to the server’s CertificateRequest message. The client then uses its private key to sign a hash of all the handshake messages so far and sends the result as a CertificateVerify message. The server can check the cert and verify the signature on the hash via the client’s public key.

    Identity is a separate function in SSL. Normally, people establish identity via standard username/password authentication (Base64) within an established SSL session. But client cert authentication can also be used and is more secure although has the overhead of cert management. The recently standardized TLS+SRP protocol is a great middle ground where a password is used as the authenticator but in a method that is secure against dictionary and other attacks.

    TLS 1.0 is really just SSL 3.0 with a few minor changes. The name change was partially to satisfy Microsoft, who weren’t happy about Netscape being the initiator of the SSL name. A few important bugs were fixed in the recent TLS 1.1 release, which I’ll be posting about next.

    Comment by Nate Lawson — December 17, 2007 @ 1:04 pm

  3. Two more questions :)

    – Does the URL you are requesting show in clear or encrypted text? It looks like that part is encrypted, but the server certificate is not, which means you can at least sniff what the domain is you are requesting, but not perhaps the full URL.

    – If you are making repeated page requests to a single SSL domain (such as a bank), do you go through the SSL handshake / key exchange for each page, or only once for a ‘session’?

    Comment by lance — December 17, 2007 @ 2:03 pm

  4. The URL is encrypted since no application data is exchanged until SSL has activated the record layer. The server certificate is not encrypted since it needs to be provided to the client for validation before the client can trust that it is encrypting the ClientKeyExchange message to the right server. This is not considered a security flaw since anyone can connect to the server and request the cert, and the IP addresses on the packets give away the server’s identity also. There are algorithms for anonymous key exchange (i.e. EDH) where an encrypted session is established without an observer being able to see any credentials.

    You should be more worried about the length of the packet since that tends to give away even more about your data. The SSL record layer does support multiple messages, so you could send a record that is discarded that is of random length, hiding the length of your actual data.

    My talk gives an example of session resumption, a way to skip the handshake on subsequent connections to the same server. There are various requirements for resuming a session, one of them being that both sides still have to have the session keys cached. I think a common period for servers discarding session keys is one hour, but it depends on the load on the site.

    Comment by Nate Lawson — December 17, 2007 @ 5:56 pm

  5. Are you going to discuss the usability flaws in SSL? As a protocol it’s fine, but as a technology to secure web transactions it’s worthless. Studies have repeatedly shown that nobody notices the padlock or if it’s missing, and people just click through warnings about expired or mismatched certificates :(

    Comment by Mike Hearn — December 18, 2007 @ 1:23 pm

  6. Mike, no. I did briefly mention this in my talk for the class, but I’m going to focus more on crypto/implementation flaws.

    Comment by Nate Lawson — December 19, 2007 @ 11:18 am


RSS feed for comments on this post.

Blog at WordPress.com.