Lockpicking 101, the Miller Champion Padlock
The client picks a secret, random number and sends it to the server, encrypted using the server's RSA public key. The client and server then communicate using encryption and MAC keys which are derived from this secret.
The current versions are SSLv3 and TLS1.2.
SSL was invented by Netscape in the 90's, and the only real version is SSLv3, redesigned by Paul Kocher and released in 1996. SSLv2 and SSLv1 are broken, and must not be used. TLS was a follow on design. TLS versions 1.0 and 1.1 should not be used. The current living protocol is TLS, and TLS 1.3 is being developed.
The basic protocol begins with a two round handshake. After the handshake, data flows in records which are protected with the MAC, and encrypted. There are also a record type for alerts and errors — out of band data communicated between the peer SSL layers.
| ClientHello | → | offers encryptions and sends a 32-byte nonce | |
| ← | ServerHello | accepts encryptions and sends a 32-byte nonce | |
| ← | Certificate | server sends its public key in a signed certificate | |
| ← | ServerHelloDone | server round finished | |
| ClientKeyExchange | → | send 48 byte pre-master secret, encrypted with server key | |
| ChangeCipherSpec | → | last unencrypted message client to server | |
| Finished | → | sends MAC of keys to authenticate | |
| ← | ChangeCipherSpec | last unencrypted message server to client | |
| ← | Finished | sends MAC of keys to authenticate |
The client and server both pick 32 bytes of random data and share it with each other, in the clear. The client picks the 48 byte random key for the session, and sends it to the server securely using public-key cryptography. From this pre-master secret and the client and server random data, a cryptographic pseudo-random generator generates a Master Secret, which is further expanded by a PRG to the various needed keys:
The use of the PRG is to make these six keys "independently random", even though theoretically they are completely dependent.
SSL streams are sent by records, which have a record header and a body. The header encodes the type:
The server might ask for client credentials. The client cannot push them at the server. If the server requires client credentials, it adds a CertificateRequest message to its ServerHello. In response, the client must send both its certificate and a CertificateVerify message in its ClientKeyExchange message. The CertificateVerify message is the client's RSA signature on a hash of all handshake messages, including the client and server random values.
Alternative authentications:
SSLv3 can use ephemeral RSA or DH/DSS as two alternatives to the basic RSA public key cryptography. Both modify the basic protocol by including a ServerKeyExchange message among the ServerHello messages. In ephemeral RSA, the server generates a fresh RSA key, signs it with its "real" RSA key, and sends this key, along with the other messages, in the hello response. The client checks the signature, and then uses the fresh (ephemeral) key rather than the real key to encrypt in its ClientKeyExchange.
The motivation is to allow a weaker key for encryption than for signatures, as this is permitted for export to all countries.
For DH/DSS, the ServerKeyExchange message includes the server's half of the Diffie-Hellman key exchange protocol, with a DSS signature by the server's ceritificate. The client checks the signature, using the sent public key certificate, after checking the signature on the certificate. It then generates a its response to the Diffie-Hellman key xchange and sends it as the ClientKeyExchage. Both sides complete the Diffie-Hellman calculation and use the result as the per-master, continuing as before.
More stuff
Rehandshake: During an ongoing connection, the client can send another ClientHello message. The server can ignore this, or respond by re-initiating the handshake protocol. The server can also renegotiate an hello by sending a HelloRequest, to which the client can respond with the ClientHello, re-initiating the handshake protocol. Neither SSlv3 nor TLS oblige that the client or server agree to renegotiate.
Session resumption: The ServerHello contains a session identifier. A connection that was closed on a session that continue might be resumed when the ClientHello contains this identifier. The server can respond with this id in its ServerHello. The master secret it retrieved for the session, however the particualar keys, IV's, etc., are renewed as from the fresh client and server random values that were sent in the hello messages.
Alert message: The last record type provides continuous communication between the peer SSL layers. In particular, a session can be closed by messages at this layer. A session closed by TCP FIN's is not the same thing, as the close might not be authentic. A villainous third party could have sent a FIN (or RST) to the port. The application might have some security properties associated with close, and would therefore like to know if the close is authentic.
Bigger picture issues
Limitations:
The largest limitation of SSL is that it authenticates the communication endpoints very early. One symptom of this is that SSL does not play well with virtual hosting for web servers. A typical web server servers multiple web sites. At the time SSL is being setup, the server does not know which site will be requested. The selection of the particular hosted site is part of the HTTP protocol, and that protocol hasn't started yet.
The PKI:
The big picture is "client sends random number to server secured by said server's public key". This is self-contained and flawless. Except how does the client get the server's public key? If it does not have it, it can request it from a repository of keys. Actually, to avoid any uncertainty in this step, the server must send its public key in the ServerHello.
Great. So how do we know the server isn't lying? Because the public key is signed by a root of trust. The signature says: the root of trust believes this document is accurate. The mathematics of the signature means that the client can believe that the root of trust believes this.
Why should we believe the root of trust? The signature on the server's public key is verified using the root of trust's public key. So we must believe, in fact,
This list assumes there are no technical flaws in the system. Technical flaws do exist, however. The signature might rely on the MD5 hash, and the MD5 is not secure. Hence the existence of the signature is not actually linked to the root of trust's beliefs. The signature can be produced without the root of trust's involvement, independent of what the root of trust believes.
In a chain of certificates, where the root of trust T signs an intermediate authority A which then signs a server certificate S, the statement is that T believes that A believes that the document for S is accurate. The question is, does T believe the document for S is accurate? For about 5 years, IE neglected to check this reasoning, and assumed that T would believe whatever A believed. The problem is, A does not need to say only what it believes. It can say other things. It might even lie.
References