THE SSL PROTOCOL

2.3 Errors

　　Error handling in the SSL connection protocol is very simple. When an error is detected, the detecting party sends a message to the other party. Errors that are not recoverable cause the client and server to abort the secure connection. Servers and client are required to "forget" any session-identifiers associated with a failing connection.
The SSL Handshake Protocol defines the following errors:

　　NO-CIPHER-ERROR

　　This error is returned by the client to the server when it cannot find a cipher or key size that it supports that is also supported by the server. This error is not recoverable.

　　NO-CERTIFICATE-ERROR

　　When a REQUEST-CERTIFICATE message is sent, this error may be returned if the client has no certificate to reply with. This error is recoverable (for client authentication only).

　　BAD-CERTIFICATE-ERROR

This error is returned when a certificate is deemed bad by the receiving party. Bad means that either the signature of the certificate was bad or that the values in the certificate were inappropriate (e.g. a name in the certificate did not match the expected name). This error is recoverable (for client authentication only).

　　UNSUPPORTED-CERTIFICATE-TYPE-ERROR

　　This error is returned when a client/server receives a certificate type that it can't support. This error is recoverable (for client authentication only).

2.4 SSL Handshake Protocol Messages

　　The SSL Handshake Protocol messages are encapsulated in the SSL Record Protocol and are composed of two parts: a single byte message type code, and some data. The client and server exchange messages until both ends have sent their "finished" message, indicating that they are satisfied with the SSL Handshake Protocol conversation. While one end may be finished, the other may not, therefore the finished end must continue to receive SSL Handshake Protocol messages until it too receives a "finished" message.

　　After the pair of session keys has been determined by each party, the message bodies are encrypted using it. For the client, this happens after it verifies the session-identifier or creates a new session key and has sent it to the server. For the server, this happens after the session-identifier is found to be good, or the server receives the client's session key message.

　　The following notation is used for SSLHP messages:

　　char MSG-EXAMPLE
　　char FIELD1
　　char FIELD2
　　char THING-MSB
　　char THING-LSB
　　char THING-DATA[(MSB<<8)|LSB];
...

　　This notation defines the data in the protocol message, including the message type code. The order is presented top to bottom, with the top most element being transmitted first, and the bottom most element transferred last.

　　 For the "THING-DATA" entry, the MSB and LSB values are actually THING-MSB and THING-LSB (respectively) and define the number of bytes of data actually present in the message. For example, if THING-MSB were zero and THING-LSB were 8 then the THING-DATA array would be exactly 8 bytes long. This shorthand is used below.

　　 Length codes are unsigned values, and when the MSB and LSB are combined the result is an unsigned value. Unless otherwise specified lengths values are "length in bytes".

2.5 Client Only Protocol Messages
　
　　There are several messages that are only generated by clients. These messages are never generated by correctly functioning servers. A client receiving such a message closes the connection to the server and returns an error status to the application through some unspecified mechanism.

　　CLIENT-HELLO (Phase 1; Sent in the clear)

　　char MSG-CLIENT-HELLO
　　char CLIENT-VERSION-MSB
　　char CLIENT-VERSION-LSB
　　char CIPHER-SPECS-LENGTH-MSB
　　char CIPHER-SPECS-LENGTH-LSB
　　char SESSION-ID-LENGTH-MSB
　　char SESSION-ID-LENGTH-LSB
　　char CHALLENGE-LENGTH-MSB
　　char CHALLENGE-LENGTH-LSB
　　char CIPHER-SPECS-DATA[(MSB<<8)|LSB]
　　char SESSION-ID-DATA[(MSB<<8)|LSB]
　　char CHALLENGE-DATA[(MSB<<8)|LSB]

　　When a client first connects to a server it is required to send the CLIENT-HELLO message. The server is expecting this message from the client as its first message. It is an error for a client to send anything else as its first message.

　　The client sends to the server its SSL version, its cipher specs (see below), some challenge data, and the session-identifier data. The session-identifier data is only sent if the client found a session-identifier in its cache for the server, and the SESSION-ID-LENGTH will be non-zero. When there is no session-identifier for the server SESSION-ID-LENGTH must be zero. The challenge data is used to authenticate the server. After the client and server agree on a pair of session keys, the server returns a SERVER-VERIFY message with the encrypted form of the CHALLENGE-DATA.

　　Also note that the server will not send its SERVER-HELLO message until it has received the CLIENT-HELLO message. This is done so that the server can indicate the status of the client's session-identifier back to the client in the server's first message (i.e. to increase protocol efficiency and reduce the number of round trips required).

　　The server examines the CLIENT-HELLO message and will verify that it can support the client version and one of the client cipher specs. The server can optionally edit the cipher specs, removing any entries it doesn't choose to support. The edited version will be returned in the SERVER-HELLO message if the session-identifier is not in the server's cache.

　　The CIPHER-SPECS-LENGTH must be greater than zero and a multiple of 3. The SESSION-ID-LENGTH must either be zero or 16. The CHALLENGE-LENGTH must be greater than or equal to 16 and less than or equal to 32.

　　This message must be the first message sent by the client to the server. After the message is sent the client waits for a SERVER-HELLO message. Any other message returned by the server (other than ERROR) is disallowed.