Versions: 00
Kipp E.B. Hickman
Internet Draft Netscape Communications Corp
April 1995 (Expires 10/95)
The SSL Protocol
1. STATUS OF THIS MEMO
This document is an Internet-Draft.Internet-Drafts are working documents
of the Internet Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material or to
cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the "1id-
abstracts.txt" listing contained in the Internet- Drafts Shadow Directories
on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US
West Coast), or munnari.oz.au (Pacific Rim).
2. ABSTRACT
This document specifies the Secure Sockets Layer (SSL) protocol, a
security protocol that provides privacy over the Internet. The protocol
allows client/server applications to communicate in a way that cannot be
eavesdropped. Server's are always authenticated and clients are optionally
authenticated.
3. INTRODUCTION
The SSL Protocol is designed to provide privacy between two
communicating applications (a client and a server). Second, the protocol is
designed to authenticate the server, and optionally the client. SSL requires
a reliable transport protocol (e.g. TCP) for data transmission and
reception.
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.
The SSL protocol provides "channel security" which has three basic
properties:
The channel is private. Encryption is used for all messages after a
simple handshake is used to define a secret key. Symmetric
cryptography is used for data encryption (e.g. DES, RC4, etc.)
The channel is authenticated. The server endpoint of the conversation
is always authenticated, while the client endpoint is optionally
authenticated. Asymmetric cryptography is used for authentication
Hickman [page 1]
(e.g. Public Key Cryptography).
The channel is reliable. The message transport includes a message
integrity check (using a MAC). Secure hash functions (e.g. MD2,
MD5) are used for MAC computations.
The SSL protocol is actually composed of two protocols. At the lowest
level, layered on top of some reliable transport protocol, is the "SSL
Record Protocol". The SSL Record Protocol is used for encapsulation of
all transmitted and received data, including the SSL Handshake Protocol,
which is used to establish security parameters.
4. SSL Record Protocol Specification
4.1 SSL Record Header Format
In SSL, all data sent is encapsulated in a record, an object which is
composed of a header and some non-zero amount of data. Each record
header contains a two or three byte length code. If the most significant bit
is set in the first byte of the record length code then the record has no
padding and the total header length will be 2 bytes, otherwise the record
has padding and the total header length will be 3 bytes. The record header
is transmitted before the data portion of the record.
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 by (using a "C"-like notation):
RECORD-LENGTH = ((byte[0] & 0x7f) << 8)) | byte[1];
Where byte[0] represents the first byte received and byte[1] the second
byte received. When the 3 byte header is used, the record length is
computed as follows (using a "C"-like notation):
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
Hickman [page 2]
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.
4.1.1 SSL Record Data Format
The data portion of an SSL record is composed of three components
(transmitted and received in the order shown):
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 ]
Where the SECRET data is fed to the hash function first, followed by the
ACTUAL-DATA, which is followed by the PADDING-DATA which is
finally followed by the SEQUENCE-NUMBER. The SEQUENCE-
NUMBER is a 32 bit value which is presented to the hash function as four
bytes, with the first byte being the most significant byte of the sequence
number, the second byte being the next most significant byte of the
sequence number, the third byte being the third most significant byte, and
the fourth byte being the least significant byte (that is, in network byte
order or "big endian" order).
MAC-SIZE is a function of the digest algorithm being used. For MD2 and
MD5 the MAC-SIZE will be 16 bytes (128 bits).
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).
Hickman [page 3]
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 comparison 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 two byte header, the maximum record length is 32767 bytes. For the
three 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 all sequence numbers are
initialized to zero. The transmit sequence number is incremented after
every message sent, starting with the CLIENT-HELLO and SERVER-
HELLO messages.
5. SSL Handshake Protocol Specification
5.1 SSL Handshake Protocol Flow
The SSL Handshake Protocol is used to negotiate security enhancements
to data sent using the SSL Record Protocol. The security enhancements
consist of authentication, symmetric encryption, and message integrity.
The SSL Handshake Protocol has two major phases. The first phase is
used to establish private communications. The second phase is used for
client authentication.
5.1.1 Phase 1
The first phase is the initial connection phase where both parties
communicate their "hello" messages. The client initiates the conversation
by sending the CLIENT-HELLO message. The server receives the
Hickman [page 4]
CLIENT-HELLO message and processes it responding with the
SERVER-HELLO message.
At this point both the client and server have enough information to know
whether or not a new "master key" is needed (The master key is used for
production of the symmetric encryption session keys). 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
server's 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.
5.1.2 Phase 2
The second phase is the client authentication phase. The server has already
been authenticated by the client in the first phase, so this phase is primarily
used to authenticate the client. In a typical scenario, the server will require
authentication of the client and send a REQUEST-CERTIFICATE
message. The client will answer in the positive if it has the needed
information, or send an ERROR message if it does not. This protocol
specification does not define the semantics of an ERROR response to a
server request (e.g., an implementation can ignore the error, close the
connection, etc. and still conform to this specification). In addition, it is
permissable for a server to cache client authentication information with the
"session-id" cache. The server is not required to re-authenticate the client
on every connection.
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
Hickman [page 5]
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).
5.2 Typical Protocol Message Flow
The following sequences define several typical protocol message flows for
the SSL Handshake Protocol. In these examples we have two principals in
the conversation: the client and the server. We use a notation commonly
found in the literature [10]. When something is enclosed in curly braces
"{something}key" then the something has been encrypted using "key".
5.2.1 Assuming no session-identifier
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
5.2.2 Assuming a session-identifier was found by both client & server
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
5.2.3 Assuming a session-identifier was used and client authentication
is used
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.
5.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:
Hickman [page 6]
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).
5.4 SSL Handshake Protocol Messages
The SSL Handshake Protocol messages are encapsulated using 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 receives a
"finished" message from its peer.
After the pair of session keys has been determined by each party, the
message bodies are encrypted. For the client, this happens after it verifies
the session-identifier or creates a new master 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 master 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.
Hickman [page 7]
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".
5.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.
5.5.1 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
Hickman [page 8]
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.
5.5.2 CLIENT-MASTER-KEY (Phase 1; Sent primarily in the clear)
char MSG-CLIENT-MASTER-KEY
char CIPHER-KIND[3]
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-KIND field indicates which cipher was chosen from the
server's CIPHER-SPECS.
The CLEAR-KEY-DATA contains the clear portion of the MASTER-
KEY. The CLEAR-KEY-DATA is combined with the SECRET-KEY-
DATA (described shortly) to form the MASTER-KEY, with the
SECRET-KEY-DATA being the least significant bytes of the final
MASTER-KEY. The ENCRYPTED-KEY-DATA contains the secret
portions of the MASTER-KEY, encrypted using the server's 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 SECRET-KEY-DATA[SECRET-LENGTH]
SECRET-LENGTH is the number of bytes of each session key that is
being transmitted encrypted. The SECRET-LENGTH plus the CLEAR-
KEY-LENGTH equals the number of bytes present in the cipher key (as
defined by the CIPHER-KIND). It is an error if the SECRET-LENGTH
found after decrypting the PKCS#1 formatted encryption block doesn't
match the expected value. It is also an error if CLEAR-KEY-LENGTH is
non-zero and the CIPHER-KIND is not an export cipher.
If the key algorithm needs an argument (for example, DES-CBC's
initialization vector) then the KEY-ARG-LENGTH fields will be non-
Hickman [page 9]
zero and the KEY-ARG-DATA will contain the relevant data. For the
SSL_CK_RC2_128_CBC_WITH_MD5,
SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5,
SSL_CK_IDEA_128_CBC_WITH_MD5,
SSL_CK_DES_64_CBC_WITH_MD5 and
SSL_CK_DES_192_EDE3_CBC_WITH_MD5 algorithms the KEY-ARG
data must be present and be exactly 8 bytes long.
Client and server session key production is a function of the CIPHER-
CHOICE:
SSL_CK_RC4_128_WITH_MD5
SSL_CK_RC4_128_EXPORT40_WITH_MD5
SSL_CK_RC2_128_CBC_WITH_MD5
SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
SSL_CK_IDEA_128_CBC_WITH_MD5
KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE,
CONNECTION-ID ]
KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE,
CONNECTION-ID ]
CLIENT-READ-KEY = KEY-MATERIAL-0[0-15]
CLIENT-WRITE-KEY = KEY-MATERIAL-1[0-15]
Where KEY-MATERIAL-0[0-15] means the first 16 bytes of the KEY-
MATERIAL-0 data, with KEY-MATERIAL-0[0] becoming the most
significant byte of the CLIENT-READ-KEY.
Data is fed to the MD5 hash function in the order shown, from left to
right: first the MASTER-KEY, then the "0" or "1", then the
CHALLENGE and then finally the CONNECTION-ID.
Note that the "0" means the ascii zero character (0x30), not a zero value.
"1" means the ascii 1 character (0x31). MD5 produces 128 bits of output
data which are used directly as the key to the cipher algorithm (The most
significant byte of the MD5 output becomes the most significant byte of
the key material).
SSL_CK_DES_64_CBC_WITH_MD5
KEY-MATERIAL-0 = MD5[ MASTER-KEY, CHALLENGE,
CONNECTION-ID ]
CLIENT-READ-KEY = KEY-MATERIAL-0[0-7]
CLIENT-WRITE-KEY = KEY-MATERIAL-0[8-15]
For DES-CBC, a single 16 bytes of key material are produced using MD5.
The first 8 bytes of the MD5 digest are used as the CLIENT-READ-KEY
while the remaining 8 bytes are used as the CLIENT-WRITE-KEY. The
initialization vector is provided in the KEY-ARG-DATA. Note that the
raw key data is not parity adjusted and that this step must be performed
before the keys are legitimate DES keys.
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
Hickman [page 10]
KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE,
CONNECTION-ID ]
KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE,
CONNECTION-ID ]
KEY-MATERIAL-2 = MD5[ MASTER-KEY, "2", CHALLENGE,
CONNECTION-ID ]
CLIENT-READ-KEY-0 = KEY-MATERIAL-0[0-7]
CLIENT-READ-KEY-1 = KEY-MATERIAL-0[8-15]
CLIENT-READ-KEY-2 = KEY-MATERIAL-1[0-7]
CLIENT-WRITE-KEY-0 = KEY-MATERIAL-1[8-15]
CLIENT-WRITE-KEY-1 = KEY-MATERIAL-2[0-7]
CLIENT-WRITE-KEY-2 = KEY-MATERIAL-2[8-15]
Data is fed to the MD5 hash function in the order shown, from left to
right: first the MASTER-KEY, then the "0", "1" or "2", then the
CHALLENGE and then finally the CONNECTION-ID. Note that the
"0" means the ascii zero character (0x30), not a zero value. "1" means the
ascii 1 character (0x31). "2" means the ascii 2 character (0x32).
A total of 6 keys are produced, 3 for the read side DES-EDE3 cipher and 3
for the write side DES-EDE3 function. The initialization vector is
provided in the KEY-ARG-DATA. The keys that are produced are not
parity adjusted. This step must be performed before proper DES keys are
usable.
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 discovered.
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.
5.5.3 CLIENT-CERTIFICATE (Phase 2; Sent encrypted)
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
Hickman [page 11]
no registered certificate).
CERTIFICATE-TYPE is one of:
SSL_X509_CERTIFICATE
The CERTIFICATE-DATA contains an X.509 (1988) [3] signed
certificate.
The RESPONSE-DATA contains the authentication response data. This
data is a function of the AUTHENTICATION-TYPE value sent by the
server.
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 KEY-MATERIAL-0
the KEY-MATERIAL-1 (only if defined by the cipher kind)
the KEY-MATERIAL-2 (only if defined by the cipher kind)
the CERTIFICATE-CHALLENGE-DATA (from the
REQUEST-CERTIFICATE message)
the server's signed certificate (from the SERVER-HELLO
message)
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.
5.5.4 CLIENT-FINISHED (Phase 2; Sent encrypted)
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.
Hickman [page 12]
5.6 Server Only Protocol Messages
There are several messages that are only generated by servers. The
messages are never generated by correctly functioning clients.
5.6.1 SERVER-HELLO (Phase 1; Sent in the clear)
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 server's 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 in the same manner as
the CLIENT-READ-KEY and CLIENT-WRITE-KEY:
SERVER-READ-KEY = CLIENT-WRITE-KEY
SERVER-WRITE-KEY = CLIENT-READ-KEY
Note that when keys are being derived and the SESSION-ID-HIT flag is
set and the server discovers the client's session-identifier in the servers
cache, then the KEY-ARG-DATA is used from the time when the
Hickman [page 13]
SESSION-ID was established. This is because the client does not send
new KEY-ARG-DATA (recall that the KEY-ARG-DATA is sent only in
the CLIENT-MASTER-KEY message).
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 length of the CONNECTION-ID must
be between 16 and than 32 bytes, inclusive.
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-0
char CIPHER-KIND-1
char CIPHER-KIND-2
Where CIPHER-KIND is one of:
SSL_CK_RC4_128_WITH_MD5
SSL_CK_RC4_128_EXPORT40_WITH_MD5
SSL_CK_RC2_128_CBC_WITH_MD5
SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
SSL_CK_IDEA_128_CBC_WITH_MD5
SSL_CK_DES_64_CBC_WITH_MD5
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
This list is not exhaustive and may be changed in the future.
The SSL_CK_RC4_128_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 at least 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_128_WITH_MD5 to have a key length of 128 bits. The
SSL_CK_RC4_128_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.
5.6.2 SERVER-VERIFY (Phase 1; Sent encrypted)
char MSG-SERVER-VERIFY
Hickman [page 14]
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 server's 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 SERVER-FINISHED message.
5.6.3 SERVER-FINISHED (Phase 2; Sent encrypted)
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.
Hickman [page 15]
5.6.4 REQUEST-CERTIFICATE (Phase 2; Sent encrypted)
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:
SSL_AT_MD5_WITH_RSA_ENCRYPTION
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.
5.7 Client/Server Protocol Messages
These messages are generated by both the client and the server.
5.7.1 ERROR (Sent clear or encrypted)
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.
Appendix A: ASN.1 Syntax For Certificates
Certificates are used by SSL to authenticate servers and clients. SSL
Certificates are based largely on the X.509 [3] certificates. An X.509
certificate contains the following information (in ASN.1 [1] notation):
Hickman [page 16]
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:
The X.509-Certificate::signatureAlgorithm and
CertificateInfo::signature fields must be identical in value.
The issuer name must resolve to a name that is deemed acceptable by
the application using SSL. How the application using SSL does this is
outside the scope of this memo.
Certificates are validated using a few straightforward steps. First, the
signature on the certificate is checked and if invalid, the certificate is
invalid (either a transmission error or an attempted forgery occurred).
Next, the CertificateInfo::issuer field is verified to be an issuer that the
application trusts (using an unspecified mechanism). The
CertificateInfo::validity field is checked against the current date and
verified.
Finally, the CertificateInfo::subject field is checked. This check is
optional and depends on the level of trust required by the application using
SSL.
Hickman [page 17]
Appendix B: Attribute Types and Object Identifiers
SSL uses a subset of the X.520 selected attribute types as well as a
few specific object identifiers. Future revisions of the SSL protocol
may include support for more attribute types and more object
identifiers.
B.1 Selected attribute types
commonName { attributeType 3 }
The common name contained in the distinguished name contained
within a certificate issuer or certificate subject.
countryName { attributeType 6 }
The country name contained in the distinguished name contained
within a certificate issuer or certificate subject.
localityName { attributeType 7 }
The locality name contained in the distinguished name contained
within a certificate issuer or certificate subject.
stateOrProvinceName { attributeType 8 }
The state or province name contained in the distinguished name
contained within a certificate issuer or certificate subject.
organizationName { attributeType 10 }
The organization name contained in the distinguished name contained
within a certificate issuer or certificate subject.
organizationalUnitName { attributeType 11 }
The organizational unit name contained in the distinguished name
contained within a certificate issuer or certificate subject.
B.2 Object identifiers
md2withRSAEncryption { ... pkcs(1) 1 2 }
The object identifier for digital signatures that use both MD2 and RSA
encryption. Used by SSL for certificate signature verification.
md5withRSAEncryption { ... pkcs(1) 1 4 }
The object identifier for digital signatures that use both MD5 and RSA
encryption. Used by SSL for certificate signature verification.
rc4 { ... rsadsi(113549) 3 4 }
The RC4 symmetric stream cipher algorithm used by SSL for bulk
encryption.
Appendix C: Protocol Constant Values
This section describes various protocol constants. A special value needs
mentioning - the IANA reserved port number for "https" (HTTP using
SSL). IANA has reserved port number 443 (decimal) for "https". IANA
has also reserved port number 465 for "ssmtp" and port number 563 for
"snntp".
Hickman [page 18]
C.1 Protocol Version Codes
#define SSL_CLIENT_VERSION 0x0002
#define SSL_SERVER_VERSION 0x0002
C.2 Protocol Message Codes
The following values define the message codes that are used by version
2 of the SSL Handshake Protocol.
#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
C.3 Error Message Codes
The following values define the error codes used by the ERROR message.
#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
C.4 Cipher Kind Values
The following values define the CIPHER-KIND codes used in the
CLIENT-HELLO and SERVER-HELLO messages.
#define SSL_CK_RC4_128_WITH_MD5
0x01,0x00,0x80
#define SSL_CK_RC4_128_EXPORT40_WITH_MD5
0x02,0x00,0x80
#define SSL_CK_RC2_128_CBC_WITH_MD5
0x03,0x00,0x80
#define SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
0x04,0x00,0x80
#define SSL_CK_IDEA_128_CBC_WITH_MD5
0x05,0x00,0x80
#define SSL_CK_DES_64_CBC_WITH_MD5
0x06,0x00,0x40
#define SSL_CK_DES_192_EDE3_CBC_WITH_MD5
0x07,0x00,0xC0
C.5 Certificate Type Codes
The following values define the certificate type codes used in the
SERVER-HELLO and CLIENT-CERTIFICATE messages.
#define SSL_CT_X509_CERTIFICATE 0x01
Hickman [page 19]
C.6 Authentication Type Codes
The following values define the authentication type codes used in the
REQUEST-CERTIFICATE message.
#define SSL_AT_MD5_WITH_RSA_ENCRYPTION 0x01
C.7 Upper/Lower Bounds
The following values define upper/lower bounds for various protocol
parameters.
#define SSL_MAX_MASTER_KEY_LENGTH_IN_BITS 256
#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
C.8 Recommendations
Because protocols have to be implemented to be of value, we recommend
the following values for various operational parameters. This is only a
recommendation, and not a strict requirement for conformance to the
protocol.
Session-identifier Cache Timeout
Session-identifiers are kept in SSL clients and SSL servers. Session-
identifiers should have a lifetime that serves their purpose (namely,
reducing the number of expensive public key operations for a single
client/server pairing). Consequently, we recommend a maximum session-
identifier cache timeout value of 100 seconds. Given a server that can
perform N private key operations per second, this reduces the server load
for a particular client by a factor of 100.
Appendix D: Attacks
In this section we attempt to describe various attacks that might be used
against the SSL protocol. This list is not guaranteed to be exhaustive. SSL
was defined to thwart these attacks.
D.1 Cracking Ciphers
SSL depends on several cryptographic technologies. RSA Public Key
encryption [5] is used for the exchange of the session key and client/server
authentication. Various cryptographic algorithms are used for the session
cipher. If successful cryptographic attacks are made against these
technologies then SSL is no longer secure.
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 approach is easier than
cracking the cryptographic technologies for all possible messages. Note
that SSL tries to make the cost of such of an attack greater than the
Hickman [page 20]
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.
D.2 Clear Text Attack
A clear text attack is done when the attacker has an idea of what kind of
message is being sent using encryption. The attacker can generate a data
base whose keys are the encrypted value of the known text (or clear text),
and whose values are the session cipher key (we call this a "dictionary").
Once this data base is constructed, a simple lookup function identifies the
session key that goes with a particular encrypted value. Once the session
key is known, the entire message stream can be decrypted. Custom
hardware can be used to make this cost effective and very fast.
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).
The 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".
D.3 Replay
The replay attack is simple. A bad-guy records a communication session
between a client and server. Later, it reconnects to the server, and plays
back the previously recorded client messages. 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
Hickman [page 21]
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.
D.4 The Man In The Middle
The man in the middle attack works by having three people in a
communications session: the client, the server, and the bad guy. The bad
guy sits between the client and the server on the network and intercepts
traffic that the client sends to the server, and traffic that the server
sends to
the client.
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.
Hickman [page 22]
Appendix E: Terms
Application Protocol
An application protocol is a protocol that normally layers directly on
top of TCP/IP. For example: HTTP, TELNET, FTP, and SMTP.
Authentication
Authentication is the ability of one entity to determine the identity of
another entity. Identity is defined by this document to mean the
binding between a public key and a name and the implicit ownership
of the corresponding private key.
Bulk Cipher
This term is used to describe a cryptographic technique with certain
performance properties. Bulk ciphers are used when large quantities of
data are to be encrypted/decrypted in a timely manner. Examples
include RC2, RC4, and IDEA.
Client
In this document client refers to the application entity that is initiates a
connection to a server.
CLIENT-READ-KEY
The session key that the client uses to initialize the client read cipher.
This key has the same value as the SERVER-WRITE-KEY.
CLIENT-WRITE-KEY
The session key that the client uses to initialize the client write cipher.
This key has the same value as the SERVER-READ-KEY.
MASTER-KEY
The master key that the client and server use for all session key
generation. The CLIENT-READ-KEY, CLIENT-WRITE-KEY,
SERVER-READ-KEY and SERVER-WRITE-KEY are generated
from the MASTER-KEY.
MD2
MD2 [8] is a hashing function that converts an arbitrarily long data
stream into a digest of fixed size. This function predates MD5 [7]
which is viewed as a more robust hash function [9].
MD5
MD5 [7] is a hashing function that converts an arbitrarily long data
stream into a digest of fixed size. The function has certain properties
that make it useful for security, the most important of which is it's
inability to be reversed.
Nonce
A randomly generated value used to defeat "playback" attacks. One
party randomly generates a nonce and sends it to the other party. The
receiver encrypts it using the agreed upon secret key and returns it to
the sender. Because the nonce was randomly generated by the sender
this defeats playback attacks because the replayer can't know in
advance the nonce the sender will generate. The receiver denies
connections that do not have the correctly encrypted nonce.
Hickman [page 23]
Non-repudiable Information Exchange
When two entities exchange information it is sometimes valuable to
have a record of the communication that is non-repudiable. Neither
party can then deny that the information exchange occurred. Version 2
of the SSL protocol does not support Non-repudiable information
exchange.
Public Key Encryption
Public key encryption is a technique that leverages asymmetric ciphers.
A public key system consists of two keys: a public key and a private
key. Messages encrypted with the public key can only be decrypted
with the associated private key. Conversely, messages encrypted with
the private key can only be decrypted with the public key. Public key
encryption tends to be extremely compute intensive and so is not
suitable as a bulk cipher.
Privacy
Privacy is the ability of two entities to communicate without fear of
eavesdropping. Privacy is often implemented by encrypting the
communications stream between the two entities.
RC2, RC4
Proprietary bulk ciphers invented by RSA (There is no good reference
to these as they are unpublished works; however, see [9]). RC2 is
block cipher and RC4 is a stream cipher.
Server
The server is the application entity that responds to requests for
connections from clients. The server is passive, waiting for requests
from clients.
Session cipher
A session cipher is a "bulk" cipher that is capable of encrypting or
decrypting arbitrarily large amounts of data. Session ciphers are used
primarily for performance reasons. The session ciphers used by this
protocol are symmetric. Symmetric ciphers have the property of using
a single key for encryption and decryption.
Session identifier
A session identifier is a random value generated by a client that
identifies itself to a particular server. The session identifier can be
thought of as a handle that both parties use to access a recorded secret
key (in our case a session key). If both parties remember the session
identifier then the implication is that the secret key is already known
and need not be negotiated.
Session key
The key to the session cipher. In SSL there are four keys that are called
session keys: CLIENT-READ-KEY, CLIENT-WRITE-KEY,
SERVER-READ-KEY, and SERVER-WRITE-KEY.
SERVER-READ-KEY
The session key that the server uses to initialize the server read cipher.
This key has the same value as the CLIENT-WRITE-KEY.
Hickman [page 24]
SERVER-WRITE-KEY
The session key that the server uses to initialize the server write cipher.
This key has the same value as the CLIENT-READ-KEY.
Symmetric Cipher
A symmetric cipher has the property that the same key can be used for
decryption and encryption. An asymmetric cipher does not have this
behavior. Some examples of symmetric ciphers: IDEA, RC2, RC4.
References
[1] CCITT. Recommendation X.208: "Specification of Abstract Syntax
Notation One (ASN.1). 1988.
[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.
Patent Statement
This version of the SSL protocol relies on the use of patented public key
encryption technology for authentication and encryption. The Internet
Standards Process as defined in RFC 1310 requires a written statement
from the Patent holder that a license will be made available to applicants
under reasonable terms and conditions prior to approving a specification as
a Proposed, Draft or Internet Standard.
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
Hickman [page 25]
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
These patents are stated by PKP to cover all known methods of practicing
the art of Public Key encryption, including the variations collectively
known as ElGamal.
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.
Security Considerations
This entire document is about security.
Author's Address
Kipp E.B. Hickman
Netscape Communications Corp.
501 East Middlefield Rd.
Mountain View, CA 94043
kipp@netscape.com
Hickman [page 26]