Cryptography Reference
In-Depth Information
For each session, the SSL client and server keep an internal state which contains a
session identifier, the peer certificate, the cipher suite choice, and a master secret (a 48-
byte symmetric key which is set up at the beginning of the session). It also contains a
compression algorithm choice. A session can include several connections. A connection
state includes a server and a client nonce, an initialization vector, a sequence number
which is incremented for each message, and a set of four secret symmetric keys for
MAC and encryption in the two ways: two for the client and two for the server.
The cipher suite specifies the algorithm which is used for peer authentication and
key agreement in the handshake protocol, and the symmetric algorithms for encryption
and MAC in the record protocol. The latter algorithm pair is often called the “cipher
spec.” The cipher spec of a session can be changed through the SSL Change Cipher
Spec Protocol. It is typically run once at the beginning of the protocol in order to set
it up.
An extra protocol, the SSL Alert Protocol, is used to handle alert messages. They
can be simple warning alerts or fatal alerts. In the latter case the connection aborts.
Other connections in the session can continue, but no new connection can be launched
in the session.
12.3.1 Handshake
When a new session starts, the client and the server agree on a protocol version,
negotiate a cipher spec, optionally authenticate each other by using certificates, and
exchange a key as follows.
1. The client first sends a ClientHello message which includes the session
identifier, the set of all cipher suites that he can accept, and a nonce to the
server.
2. The server responds by sending a ServerHello message. This includes the
session identifier, the cipher suite he selected in the set of the client, and a
nonce. He usually sends his certificate in order to be authenticated. The cer-
tificate may include material for a Diffie-Hellman key agreement as explained
in Section 12.3.6. Otherwise the server needs to send a specific key exchange
message. He may also send a certificate request if he wishes to authenticate the
client.
3. Based on this the client may send his certificate if requested by the server. He
may also send a key exchange message depending on which key algorithm was
selected in the cipher suite. This is the ClientKeyExchange message. The
client and the server can then compute four symmetric secret keys: two for
encryption in one way or another and two for MAC in one way or another.
4. The client sends a protected MAC of all previous handshake messages. This
ensures that no messages were lost, swapped, or replayed.
5. Similarly, the server responds by a protected MAC of all previous handshake
messages.
Search WWH ::




Custom Search