Experimental Kipp E.B. Hickman
Request For Comments: XXXX Netscape Communications Corp.
Last Update: Nov. 29th, 1994
The advantage of the SSL Protocol is that it is application protocol independent. A "higher level" application protocol (e.g. HTTP, FTP, TELNET, etc.) can layer on top of the SSL Protocol transparently. The SSL Protocol can negotiate an encryption algorithm and session key as well as authenticate a server before the application protocol transmits or receives its first byte of data. All of the application protocol data is transmitted encrypted, ensuring privacy.
Note that in the long header case (3 bytes total), the second most significant bit in the first byte has special meaning. When zero, the record being sent is a data record. When one, the record being sent is a security escape (there are currently no examples of security escapes; this is reserved for future versions of the protocol). In either case, the length code describes how much data is in the record.
The record length code does not include the number of bytes consumed by the record header (2 or 3). For the 2 byte header, the record length is computed as follows:
RECORD-LENGTH = ((byte[0] & 0x7f) << 8)) | byte[1];When the 3 byte header is used, the record length is computed as follows:
RECORD-LENGTH = ((byte[0] & 0x3f) << 8)) | byte[1]; IS-ESCAPE = (byte[0] & 0x40) != 0; PADDING = byte[2];The record header defines a value called PADDING. The PADDING value specifies how many bytes of data were appended to the original record by the sender. The padding data is used to make the record length be a multiple of the block ciphers block size when a block cipher is used for encryption.
The sender of a "padded" record appends the padding data to the end of its normal data and then encrypts the total amount (which is now a multiple of the block cipher's block size). The actual value of the padding data is unimportant, but the encrypted form of it must be transmitted for the receiver to properly decrypt the record. Once the total amount being transmitted is known the header can be properly constructed with the PADDING value set appropriately.
The receiver of a padded record decrypts the entire record data (sans record length and the optional padding) to get the clear data, then subtracts the PADDING value from the RECORD-LENGTH to determine the final RECORD-LENGTH. The clear form of the padding data must be discarded.
MAC-DATA[MAC-SIZE] ACTUAL-DATA[N] PADDING-DATA[PADDING]ACTUAL-DATA is the actual data being transmitted (the message payload). PADDING-DATA is the padding data sent when a block cipher is used and padding is needed. Finally, MAC-DATA is the Message Authentication Code.
When SSL records are sent in the clear, no cipher is used. Consequently the amount of PADDING-DATA will be zero and the amount of MAC-DATA will be zero. When encryption is in effect, the PADDING-DATA will be a function of the cipher block size. The MAC-DATA is a function of the CIPHER-CHOICE (more about that later).
The MAC-DATA is computed as follows:
MAC-DATA = HASH[ SECRET, ACTUAL-DATA, PADDING-DATA, SEQUENCE-NUMBER ]The SECRET value is a function of which party is sending the message. If the client is sending the message then the SECRET is the CLIENT-WRITE-KEY (the server will use the SERVER-READ-KEY to verify the MAC). If the client is receiving the message then the SECRET is the CLIENT-READ-KEY (the server will use the SERVER-WRITE-KEY to generate the MAC).
The SEQUENCE-NUMBER is a counter which is incremented by both the sender and the receiver. For each transmission direction, a pair of counters is kept (one by the sender, one by the receiver). Every time a message is sent by a sender the counter is incremented. Sequence numbers are 32 bit unsigned quantities and must wrap to zero after incrementing past 0xFFFFFFFF.
The receiver of a message uses the expected value of the sequence number as input into the MAC HASH function (the HASH function is chosen from the CIPHER-CHOICE). The computed MAC-DATA must agree bit for bit with the transmitted MAC-DATA. If the comparision is not identity then the record is considered damaged, and it is to be treated as if an "I/O Error" had occurred (i.e. an unrecoverable error is asserted and the connection is closed).
A final consistency check is done when a block cipher is used and the protocol is using encryption. The amount of data present in a record (RECORD-LENGTH))must be a multiple of the cipher's block size. If the received record is not a multiple of the cipher's block size then the record is considered damaged, and it is to be treated as if an "I/O Error" had occurred (i.e. an unrecoverable error is asserted and the connection is closed).
The SSL Record Layer is used for all SSL communications, including handshake messages, security escapes and application data transfers. The SSL Record Layer is used by both the client and the server at all times.
For a six byte header, the maximum record length is 32767 bytes. For the seven byte header, the maximum record length is 16383 bytes. The SSL Handshake Protocol messages are constrained to fit in a single SSL Record Protocol record. Application protocol messages are allowed to consume multiple SSL Record Protocol record's.
Before the first record is sent using SSL the sender and receiver send/receive sequence numbers to zero.
At this point both the client and server have enough information to know whether or not a new master key is needed. When a new master key is not needed, both the client and the server proceed immediately to phase 2.
When a new master key is needed, the SERVER-HELLO message will contain enough information for the client to generate it. This includes the servers signed certificate (more about that later), a list of bulk cipher specifications (see below), and a connection-id (a connection-id is a randomly generated value generated by the server that is used by the client and server during a single connection). The client generates the master key and responds with a CLIENT-MASTER-KEY message (or an ERROR message if the server information indicates that the client and server cannot agree on a bulk cipher).
It should be noted here that each SSL endpoint uses a pair of ciphers per connection (for a total of four ciphers). At each endpoint, one cipher is used for outgoing communications, and one is used for incoming communications. When the client or server generate a session key, they actually generate two keys, the SERVER-READ-KEY (also known as the CLIENT-WRITE-KEY) and the SERVER-WRITE-KEY (also known as the CLIENT-READ-KEY). The master key is used by the client and server to generate the various session keys (more about that later).
Finally, the server sends a SERVER-VERIFY message to the client after the master key has been determined. This final step authenticates the server, because only a server which has the appropriate public key can know the master key.
When a party is done authenticating the other party, it sends its finished message. For the client, the CLIENT-FINISHED message contains the encrypted form of the CONNECTION-ID for the server to verify. If the verification fails, the server sends an ERROR message.
Once a party has sent its finished message it must continue to listen to its peers messages until it too receives a finished message. Once a party has both sent a finished message and received its peers finished message, the SSL handshake protocol is done. At this point the application protocol begins to operate (Note: the application protocol continues to be layered on the SSL Record Protocol).
client-hello C -> S: challenge, cipher_specs
server-hello S -> C: connection-id,server_certificate,cipher_specs
client-master-key C -> S: {master_key}server_public_key
client-finish C -> S: {connection-id}client_write_key
server-verify S -> C: {challenge}server_write_key
server-finish S -> C: {new_session_id}server_write_key
client-hello C -> S: challenge, session_id, cipher_specs
server-hello S -> C: connection-id, session_id_hit
client-finish C -> S: {connection-id}client_write_key
server-verify S -> C: {challenge}server_write_key
server-finish S -> C: {session_id}server_write_key
client-hello C -> S: challenge, session_id, cipher_specs
server-hello S -> C: connection-id, session_id_hit
client-finish C -> S: {connection-id}client_write_key
server-verify S -> C: {challenge}server_write_key
request-certificate S -> C: {auth_type,challenge'}server_write_key
client-certificate C -> S: {cert_type,client_cert,
response_data}client_write_key
server-finish S -> C: {session_id}server_write_key
In this last exchange, the response_data is a function of the
auth_type.
The SSL Handshake Protocol defines the following errors:
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".
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 servers 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 servers 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.
char MSG-CLIENT-MASTER-KEY
char CIPHER-CHOICE
char KEY-LENGTH-MSB
char KEY-LENGTH-LSB
char CLEAR-KEY-LENGTH-MSB
char CLEAR-KEY-LENGTH-LSB
char ENCRYPTED-KEY-LENGTH-MSB
char ENCRYPTED-KEY-LENGTH-LSB
char KEY-ARG-LENGTH-MSB
char KEY-ARG-LENGTH-LSB
char CLEAR-KEY-DATA[MSB<<8|LSB]
char ENCRYPTED-KEY-DATA[MSB<<8|LSB]
char KEY-ARG-DATA[MSB<<8|LSB]
The client sends this message when it has determined a master key for
the server to use. Note that when a session-identifier has been agreed
upon, this message is not sent. The CIPHER-CHOICE field indicates which cipher was chosen from the server's CIPHER-SPECS. The value is an index into the CIPHER-SPECS array sent by the server to the client in the SERVER-HELLO message (recall that each element of the array is a 3 byte value known as a CIPHER-KIND). The KEY-LENGTH fields (MSB and LSB) when combined yield the actual size of the key to use (in bits). KEY-LENGTH must be a multiple of 8. The server must verify that the CIPHER-CHOICE value is legal, and if not send an ERROR and close the connection.
The CLEAR-KEY-DATA contains the clear portion of the MASTER-KEY. The ENCRYPTED-KEY-DATA contains the secret portions of the MASTER-KEY, encrypted using the servers public key. The encryption block is formatted using block type 2 from PKCS#1 [5]. The data portion of the block is formatted as follows:
char MASTER-KEY[SECRET-LENGTH]
SECRET-LENGTH is the number of bytes of each session key that
is being transmitted encrypted. It is derived from the
CIPHER-CHOICE value and can be computed by subtracting the
CLEAR-KEY-LENGTH * 8 from the KEY-LENGTH. It is an
error if the difference does not equal the value defined by the
CIPHER-CHOICE. It is also an error if the KEY-LENGTH
doesn't match the length specified by the
CIPHER-CHOICE. Finally, it is an error if
CLEAR-KEY-LENGTH is non-zero and the CIPHER-CHOICE
specifies a a CIPHER-KIND that is not an export cipher. If the key algorithm needs an argument (for example, DES's initialization vector) then the KEY-ARG-LENGTH fields will be non-zero and the KEY-ARG-DATA will contain the relevant data.
The client produces its session keys as follows:
CLIENT-READ-KEY = HASH[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ] CLIENT-WRITE-KEY = HASH[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]Where the HASH function is chosen from the CIPHER-CHOICE. Conversion of the hash value into a key is cipher type specific. The following rules are used:
The CLIENT-MASTER-KEY message must be sent after the CLIENT-HELLO message and before the CLIENT-FINISHED message. The CLIENT-MASTER-KEY message must be sent if the SERVER-HELLO message contains a SESSION-ID-HIT value of 0.
char MSG-CLIENT-CERTIFICATE
char CERTIFICATE-TYPE
char CERTIFICATE-LENGTH-MSB
char CERTIFICATE-LENGTH-LSB
char RESPONSE-LENGTH-MSB
char RESPONSE-LENGTH-LSB
char CERTIFICATE-DATA[MSB<<8|LSB]
char RESPONSE-DATA[MSB<<8|LSB]
This message is sent by one an SSL client in response to a server
REQUEST-CERTIFICATE message. The CERTIFICATE-DATA
contains data defined by the CERTIFICATE-TYPE value. An
ERROR message is sent with error code
NO-CERTIFICATE-ERROR when this request cannot be answered
properly (e.g. the receiver of the message has no registered
certificate). CERTIFICATE-TYPE is one of:
When AUTHENTICATION-TYPE is SSL_AT_MD5_WITH_RSA_ENCRYPTION then the RESPONSE-DATA contains a digital signature of the following components (in the order shown):
The digital signature is constructed using MD5 and then encrypted using the clients private key, formatted according to PKCS#1's digital signature standard [5]. The server authenticates the client by verifying the digital signature using standard techniques. Note that other digest functions are supported. Either a new AUTHENTICATION-TYPE can be added, or the algorithm-id in the digital signature can be changed.
This message must be sent by the client only in response to a REQUEST-CERTIFICATE message.
char MSG-CLIENT-FINISHED
char CONNECTION-ID[N-1]
The client sends this message when it is satisfied with the server.
Note that the client must continue to listen for server messages until
it receives a SERVER-FINISHED message. The
CONNECTION-ID data is the original connection-identifier the
server sent with its SERVER-HELLO message, encrypted using
the agreed upon session key. "N" is the number of bytes in the message that was sent, so "N-1" is the number of bytes in the message without the message header byte.
For version 2 of the protocol, the client must send this message after it has received the SERVER-HELLO message. If the SERVER-HELLO message SESSION-ID-HIT flag is non-zero then the CLIENT-FINISHED message is sent immediately, otherwise the CLIENT-FINISHED message is sent after the CLIENT-MASTER-KEY message.
char MSG-SERVER-HELLO
char SESSION-ID-HIT
char CERTIFICATE-TYPE
char SERVER-VERSION-MSB
char SERVER-VERSION-LSB
char CERTIFICATE-LENGTH-MSB
char CERTIFICATE-LENGTH-LSB
char CIPHER-SPECS-LENGTH-MSB
char CIPHER-SPECS-LENGTH-LSB
char CONNECTION-ID-LENGTH-MSB
char CONNECTION-ID-LENGTH-LSB
char CERTIFICATE-DATA[MSB<<8|LSB]
char CIPHER-SPECS-DATA[MSB<<8|LSB]
char CONNECTION-ID-DATA[MSB<<8|LSB]
The server sends this message after receiving the clients
CLIENT-HELLO message. The server returns the
SESSION-ID-HIT flag indicating whether or not the received
session-identifier is known by the server (i.e. in the servers
session-identifier cache). The SESSION-ID-HIT flag will be
non-zero if the client sent the server a session-identifier (in the
CLIENT-HELLO message with SESSION-ID-LENGTH != 0)
and the server found the client's session-identifier in its cache. If
the SESSION-ID-HIT flag is non-zero then the
CERTIFICATE-TYPE, CERTIFICATE-LENGTH and
CIPHER-SPECS-LENGTH fields will be zero. The CERTIFICATE-TYPE value, when non-zero, has one of the values described above (see the information on the CLIENT-CERTIFICATE message).
When the SESSION-ID-HIT flag is zero, the server packages up its certificate, its cipher specs and a connection-id to send to the client. Using this information the client can generate a session key and return it to the server with the CLIENT-MASTER-KEY message.
When the SESSION-ID-HIT flag is non-zero, both the server and the client compute a new pair of session keys for the current session derived from the MASTER-KEY that was exchanged when the SESSION-ID was created. The SERVER-READ-KEY and SERVER-WRITE-KEY are derived from the original MASTER-KEY keys as follows (the hash function used is chosen from the CIPHER-CHOICE):
SERVER-READ-KEY = HASH[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ] SERVER-WRITE-KEY = HASH[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]Recall that the MASTER-KEY is given to the server in the CLIENT-MASTER-KEY message. The CHALLENGE is given to the server by the client in the CLIENT-HELLO message. The CONNECTION-ID is given to the client by the server in the SERVER-HELLO message. This makes the resulting cipher keys a function of the original session and the current session. Note that the master key is never directly used to encrypt data, and therefore cannot be easily disovered.
The CONNECTION-ID-DATA is a string of randomly generated bytes used by the server and client at various points in the protocol. The CLIENT-FINISHED message contains an encrypted version of the CONNECTION-ID-DATA.
The CIPHER-SPECS-DATA define a cipher type and key length (in bits) that the receiving end supports. Each SESSION-CIPHER-SPEC is 3 bytes long and looks like this:
char CIPHER-KIND
char KEY-BITS-MSB
char KEY-BITS-LSB
Where CIPHER-KIND is one of:
This list is not exhaustive and may be changed in the future.
The SSL_CK_RC4_EXPORT40_WITH_MD5 cipher is an RC4 cipher where some of the session key is sent in the clear and the rest is sent encrypted (exactly 40 bits of it). MD5 is used as the hash function for production of MAC's and session key's. This cipher type is provided to support "export" versions (i.e. versions of the protocol that can be distributed outside of the United States) of the client or server.
An exportable implementation of the SSL Handshake Protocol will have secret key lengths restricted to 40 bits. For non-export implementations key lengths can be more generous (we recommend the full 128 bits). It is permissible for the client and server to have a non-intersecting set of stream ciphers. This, simply put, means they cannot communicate.
Version 2 of the SSL Handshake Protocol defines the SSL_CK_RC4_WITH_MD5 to have a key length of 128 bits. The SSL_CK_RC4_EXPORT40_WITH_MD5 also has a key length of 128 bits. However, only 40 of the bits are secret (the other 88 bits are sent in the clear by the client to the server).
The SERVER-HELLO message is sent after the server receives the CLIENT-HELLO message, and before the server sends the SERVER-VERIFY message.
char MSG-SERVER-VERIFY
char CHALLENGE-DATA[N-1]
The server sends this message after a pair of session keys
(SERVER-READ-KEY and SERVER-WRITE-KEY) have been
agreed upon either by a session-identifier or by explicit
specification with the CLIENT-MASTER-KEY message. The
message contains an encrypted copy of the CHALLENGE-DATA sent
by the client in the CLIENT-HELLO message. "N" is the number of bytes in the message that was sent, so "N-1" is the number of bytes in the CHALLENGE-DATA without the message header byte.
This message is used to verify the server as follows. A legitimate server will have the private key that corresponds to the public key contained in the server certificate that was transmitted in the SERVER-HELLO message. Accordingly, the legitimate server will be able to extract and reconstruct the pair of session keys (SERVER-READ-KEY and SERVER-WRITE-KEY). Finally, only a server that has done the extraction and decryption properly can correctly encrypt the CHALLENGE-DATA. This, in essence, "proves" that the server has the private key that goes with the public key in the servers certificate.
The CHALLENGE-DATA must be the exact same length as originally sent by the client in the CLIENT-HELLO message. Its value must match exactly the value sent in the clear by the client in the CLIENT-HELLO message. The client must decrypt this message and compare the value received with the value sent, and only if the values are identical is the server to be "trusted". If the lengths do not match or the value doesn't match then the connection is to be closed by the client.
This message must be sent by the server to the client after either detecting a session-identifier hit (and replying with a SERVER-HELLO message with SESSION-ID-HIT not equal to zero) or when the server receives the CLIENT-MASTER-KEY message. This message must be sent before any Phase 2 messages or a SEVER-FINISHED message.
char MSG-SERVER-FINISHED
char SESSION-ID-DATA[N-1]
The server sends this message when it is satisfied with the clients
security handshake and is ready to proceed with transmission/reception
of the higher level protocols data. The SESSION-ID-DATA is
used by the client and the server at this time to add entries to their
respective session-identifier caches. The session-identifier caches
must contain a copy of the MASTER-KEY sent in the
CLIENT-MASTER-KEY message as the master key is used for all
subsequent session key generation. "N" is the number of bytes in the message that was sent, so "N-1" is the number of bytes in the SESSION-ID-DATA without the message header byte.
This message must be sent after the SERVER-VERIFY message.
char MSG-REQUEST-CERTIFICATE
char AUTHENTICATION-TYPE
char CERTIFICATE-CHALLENGE-DATA[N-2]
A server may issue this request at any time during the second phase of
the connection handshake, asking for the client's certificate. The
client responds with a CLIENT-CERTIFICATE message immediately
if it has one, or an ERROR message (with error code
NO-CERTIFICATE-ERROR) if it doesn't. The
CERTIFICATE-CHALLENGE-DATA is a short byte string (whose
length is greater than or equal to 16 bytes and less than or equal to
32 bytes) that the client will use to respond to this message. The AUTHENTICATION-TYPE value is used to choose a particular means of authenticating the client. The following types are defined:
The SSL_AT_MD5_WITH_RSA_ENCRYPTION type requires that the client construct an MD5 message digest using information as described above in the section on the CLIENT-CERTIFICATE message. Once the digest is created, the client encrypts it using its private key (formatted according to the digital signature standard defined in PKCS#1). The server authenticates the client when it receives the CLIENT-CERTIFICATE message.
This message may be sent after a SERVER-VERIFY message and before a SERVER-FINISHED message.
char MSG-ERROR
char ERROR-CODE-MSB
char ERROR-CODE-LSB
This message is sent when an error is detected. After the message
is sent, the sending party shuts the connection down. The receiving
party records the error and then shuts its connection down. This message is sent in the clear if an error occurs during session key negotiation. After a session key has been agreed upon, errors are sent encrypted like all other messages.
X.509-Certificate ::= SEQUENCE {
certificateInfo CertificateInfo,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING
}
CertificateInfo ::= SEQUENCE {
version [0] Version DEFAULT v1988,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo
}
Version ::= INTEGER { v1988(0) }
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE {
notBefore UTCTime,
notAfter UTCTime
}
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY ALGORITHM OPTIONAL
}
For SSL's purposes we restrict the values of some of the X.509 fields:
Finally, the CertificateInfo::subject field is checked. This check is optional and depends on the level of trust required by the application using SSL.
#define SSL_CLIENT_VERSION 0x0002 #define SSL_SERVER_VERSION 0x0002
#define SSL_MT_ERROR 0 #define SSL_MT_CLIENT_HELLO 1 #define SSL_MT_CLIENT_MASTER_KEY 2 #define SSL_MT_CLIENT_FINISHED 3 #define SSL_MT_SERVER_HELLO 4 #define SSL_MT_SERVER_VERIFY 5 #define SSL_MT_SERVER_FINISHED 6 #define SSL_MT_REQUEST_CERTIFICATE 7 #define SSL_MT_CLIENT_CERTIFICATE 8
#define SSL_PE_NO_CIPHER 0x0001 #define SSL_PE_NO_CERTIFICATE 0x0002 #define SSL_PE_BAD_CERTIFICATE 0x0004 #define SSL_PE_UNSUPPORTED_CERTIFICATE_TYPE 0x0006
#define SSL_CK_RC4_WITH_MD5 0x01 #define SSL_CK_RC4_EXPORT40_WITH_MD5 0x02 #define SSL_CK_RC2_CBC_WITH_MD5 0x03 #define SSL_CK_RC2_CBC_EXPORT40_WITH_MD5 0x04 #define SSL_CK_IDEA_CBC_WITH_MD5 0x05
#define SSL_CT_X509_CERTIFICATE 0x01
#define SSL_AT_MD5_WITH_RSA_ENCRYPTION 0x01
#define SSL_MAX_MASTER_KEY_LENGTH_IN_BITS 128 #define SSL_MAX_SESSION_ID_LENGTH_IN_BYTES 16 #define SSL_MIN_RSA_MODULUS_LENGTH_IN_BYTES 64 #define SSL_MAX_RECORD_LENGTH_2_BYTE_HEADER 32767 #define SSL_MAX_RECORD_LENGTH_3_BYTE_HEADER 16383
Attacks against a specific communications session can be made by recording the session, and then spending some large number of compute cycles to crack either the session key or the RSA public key until the communication can be seen in the clear. This is easier than cracking the cryptographic technologies for all cases, but it is still possible. Note that SSL tries to make the cost of such of an attack greater than the benefits gained from a successful attack, thus making it a waste of money/time to perform such an attack.
There have been many books [9] and papers [10] written on cryptography. This document does not attempt to reference them all.
Because of the very nature of SSL clear text attacks are possible. For example, the most common byte string sent by an HTTP client application to an HTTP server is "GET". SSL attempts to address this attack by using large session cipher keys. First, the client generates a key which is larger than allowed by export, and sends some of it in the clear to the server (this is allowed by United States government export rules). The clear portion of the key concatenated with the secret portion make a key which is very large (for RC4, exactly 128 bits).
That way that this "defeats" a clear text attack is by making the amount of custom hardware needed prohibitively large. Every bit added to the length of the session cipher key increases the dictionary size by a factor of 2. By using a 128 bit session cipher key length the size of the dictionary required is beyond the ability of anyone to fabricate (it would require more atoms to construct than exist in the entire universe). Even if a smaller dictionary is to be used, it must first be generated using the clear key bits. This is a time consumptive process and also eliminates many possible custom hardware architectures (e.g. static prom arrays).
The second way that SSL attacks this problem is by using large key lengths when permissible (e.g. in the non-export version). Large key sizes require larger dictionaries (just one more bit of key size doubles the size of the dictionary). SSL attempts to use keys that are 128 bits in length.
Note that the consequence of the SSL defense is that a brute force attack becomes the cheapest way to attack the key. Brute force attacks have well known space/time tradeoffs and so it becomes possible to define a cost of the attack. For the 128 bit secret key, the known cost is essentially infinite. For the 40 bit secret key, the cost is much smaller, but still outside the range of the "random hacker".
SSL defeats this attack using a "nonce" (the connection-id) which is "unique" to the connection. In theory the bad-guy cannot predict the nonce in advance as it is based on a set of random events outside the bad-guys control, and therefore the bad-guy cannot respond properly to server requests.
A bad-guy with large resources can record many sessions between a client and a server, and attempt to choose the right session based on the nonce the server sends initially in its SERVER-HELLO message. However, SSL nonces are at least 128 bits long, so a bad-guy would need to record approximately 2^64 nonces to even have a 50% chance of choosing the right session. This number is sufficiently large that one cannot economically construct a device to record 2^64 messages, and therefore the odds are overwhelmingly against the replay attack ever being successful.
The man in the middle operates by pretending to be the real server to the client. With SSL this attack is impossible because of the usage of server certificates. During the security connection handshake the server is required to provide a certificate that is signed by a certificate authority. Contained in the certificate is the server's public key as well as its name and the name of the certificate issuer. The client verifies the certificate by first checking the signature and then verifying that the name of the issuer is somebody that the client trusts.
In addition, the server must encrypt something with the private key that goes with the public key mentioned in the certificate. This in essence is a single pass "challenge response" mechanism. Only a server that has both the certificate and the private key can respond properly to the challenge.
If the man in the middle provides a phony certificate, then the signature check will fail. If the certificate provided by the bad guy is legitimate, but for the bad guy instead of for the real server, then the signature will pass but the name check will fail (note that the man in the middle cannot forge certificates without discovering a certificate authority's private key).
Finally, if the bad guy provides the real server's certificate then the signature check will pass and the name check will pass. However, because the bad guy does not have the real server's private key, the bad guy cannot properly encode the response to the challenge code, and this check will fail.
In the unlikely case that a bad guy happens to guess the response code to the challenge, the bad guy still cannot decrypt the session key and therefore cannot examine the encrypted data.
[2] CCITT. Recommendation X.209: "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
[3] CCITT. Recommendation X.509: "The Directory - Authentication Framework". 1988.
[4] CCITT. Recommendation X.520: "The Directory - Selected Attribute Types". 1988.
[5] RSA Laboratories. PKCS #1: RSA Encryption Standard, Version 1.5, November 1993.
[6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard, Version 1.5, November 1993.
[7] R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. April 1992.
[8] R. Rivest. RFC 1319: The MD2 Message Digest Algorithm. April 1992.
[9] B. Schneier. Applied Cryptography: Protocols, Algorithms, and Source Code in C, Published by John Wiley & Sons, Inc. 1994.
[10] M. Abadi and R. Needham. Prudent engineering practice for cryptographic protocols. 1994.
The Massachusetts Institute of Technology and the Board of Trustees of the Leland Stanford Junior University have granted Public Key Partners (PKP) exclusive sub-licensing rights to the following patents issued in the United States, and all of their corresponding foreign patents:
Cryptographic Apparatus and Method
("Diffie-Hellman")............................... No. 4,200,770
Public Key Cryptographic Apparatus
and Method ("Hellman-Merkle").................... No. 4,218,582
Cryptographic Communications System and
Method ("RSA")................................... No. 4,405,829
Exponential Cryptographic Apparatus
and Method ("Hellman-Pohlig").................... No. 4,424,414
Public Key Partners has provided written assurance to the Internet Society that parties will be able to obtain, under reasonable, nondiscriminatory terms, the right to use the technology covered by these patents. This assurance is documented in RFC 1170 titled "Public Key Standards and Licenses". A copy of the written assurance dated April 20, 1990, may be obtained from the Internet Assigned Number Authority (IANA).
The Internet Society, Internet Architecture Board, Internet Engineering Steering Group and the Corporation for National Research Initiatives take no position on the validity or scope of the patents and patent applications, nor on the appropriateness of the terms of the assurance. The Internet Society and other groups mentioned above have not made any determination as to any other intellectual property rights which may apply to the practice of this standard. Any further consideration of these matters is the user's own responsibility.