diff options
author | Nikos Mavrogiannopoulos <nmav@gnutls.org> | 2001-03-25 10:17:38 +0000 |
---|---|---|
committer | Nikos Mavrogiannopoulos <nmav@gnutls.org> | 2001-03-25 10:17:38 +0000 |
commit | 930e774023bb7864924117d4e248d9e7dda05572 (patch) | |
tree | da2ca84e22b141c224ab71954621a5eb2ed325c2 | |
parent | 8aa867b2dfaa5b1833a988c70d7a1c29d77dcd3b (diff) | |
download | gnutls-930e774023bb7864924117d4e248d9e7dda05572.tar.gz |
added SSL v2 spec
-rw-r--r-- | doc/protocol/ssl-2.txt | 1486 |
1 files changed, 1486 insertions, 0 deletions
diff --git a/doc/protocol/ssl-2.txt b/doc/protocol/ssl-2.txt new file mode 100644 index 0000000000..9ce3d2ac5c --- /dev/null +++ b/doc/protocol/ssl-2.txt @@ -0,0 +1,1486 @@ + [Documentation] + + SSL 2.0 PROTOCOL SPECIFICATION + +If you have questions about this protocol specification, please ask them in +Netscape's newsgroup for SSL developers, netscape.dev.ssl. More information +about the netscape.dev.ssl newsgroup may be found at this URL: +http://home.netscape.com/eng/ssl3/ssl-talk.html + ------------------------------------------------------------------------ + +THIS PROTOCOL SPECIFICATION WAS REVISED ON NOVEMBER 29TH, 1994: + + * a fundamental correction to the client-certificate authentication + protocol, + * the removal of the username/password messages, + * corrections in some of the cryptographic terminology, + * the addition of a MAC to the messages [see section 1.2], + * the allowance for different kinds of message digest algorithms. + +THIS DOCUMENT WAS REVISED ON DECEMBER 22ND, 1994: + + * The spec now defines the order the clear key data and secret key data + are combined to produce the master key. + * The spec now explicitly states the size of the MAC instead of making + the reader figure it out. + * The spec is more clear on the actual values used to produce the session + read and write keys. + * The spec is more clear on how many bits of the session key are used + after they are produced from the hash function. + +THIS DOCUMENT WAS REVISED ON JANUARY 17TH, 1995: + + * Defined the category to be informational. + * Clarified ordering of data elements in various places. + * Defined DES-CBC cipher kind and key construction. + * Defined DES-EDE3-CBC cipher kind and key construction. + +THIS DOCUMENT WAS REVISED ON JANUARY 24TH, 1995: + + * Fixed bug in definition of CIPHER-CHOICE in CLIENT-MASTER-KEY message. + The previous spec erroneously indicated that the CIPHER-CHOICE was an + index into the servers CIPHER-SPECS-DATA array, when it was actually + supposed to be the CIPHER-KIND value chosen by the client. + * Clarified the values of the KEY-ARG-DATA. + +THIS DOCUMENT WAS REVISED ON FEBRUARY 9TH, 1995: + + The spec has been clarified to indicate the byte order of sequence + numbers when they are being applied to the MAC hash function. + * The spec now defines the acceptable length range of the CONNECTION-ID + parameter (sent by the server in the SERVER-HELLO message). + * Simplified the specification of the CIPHER-KIND data. The spec language + has been changed yet the format remains compatible with all existing + implementations. The CIPHER-KIND information is now a three byte value + which defines the type of cipher and the length of the key. The key + length is no longer separable from the CIPHER-KIND. + * Explained how the KEY-ARG-DATA is retained with the SESSION-ID when the + session-identifier cache is used. + + ------------------------------------------------------------------------ + +Experimental Kipp E.B. Hickman +Request For Comments: XXXX Netscape Communications Corp. +Category: Informational Last Update: Feb. 9th, 1995 + + The SSL Protocol + +Status of this Memo + + This is a DRAFT specification. + + This RFC specifies a security protocol for the Internet community, and + requests discussion and suggestions for improvements. Distribution of + this memo is unlimited. + +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. + +Motivation + + 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. + + * The channel is authenticated. The server endpoint of the + conversation is always authenticated, while the client endpoint is + optionally authenticated. + + * The channel is reliable. The message transport includes a message + integrity check (using a MAC). + +1. SSL Record Protocol Specification + + 1.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 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. + + 1.2 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). + + 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. + +2. SSL Handshake Protocol Specification + + 2.1 SSL Handshake Protocol Flow + + 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. + + 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 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. 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. + + Phase 2 + + The second phase is the 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 something from the + client and send a request. 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). + + 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). + + 2.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". + + 2.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 + + 2.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 + + 2.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. + + 2.3 Errors + + Error handling in the SSL connection protocol is very simple. When + an error is detected, the detecting party sends a message to the + other party. Errors that are not recoverable cause the client and + server to abort the secure connection. Servers and client are + required to "forget" any session-identifiers associated with a + failing connection. + + The SSL Handshake Protocol defines the following errors: + + NO-CIPHER-ERROR + This error is returned by the client to the server when it + cannot find a cipher or key size that it supports that is + also supported by the server. This error is not recoverable. + + NO-CERTIFICATE-ERROR + When a REQUEST-CERTIFICATE message is sent, this error may be + returned if the client has no certificate to reply with. This + error is recoverable (for client authentication only). + + BAD-CERTIFICATE-ERROR + This error is returned when a certificate is deemed bad by + the receiving party. Bad means that either the signature of + the certificate was bad or that the values in the certificate + were inappropriate (e.g. a name in the certificate did not + match the expected name). This error is recoverable (for + client authentication only). + + UNSUPPORTED-CERTIFICATE-TYPE-ERROR + This error is returned when a client/server receives a + certificate type that it can't support. This error is + recoverable (for client authentication only). + + 2.4 SSL Handshake Protocol Messages + + The SSL Handshake Protocol messages are encapsulated in the SSL + Record Protocol and are composed of two parts: a single byte + message type code, and some data. The client and server exchange + messages until both ends have sent their "finished" message, + indicating that they are satisfied with the SSL Handshake Protocol + conversation. While one end may be finished, the other may not, + therefore the finished end must continue to receive SSL Handshake + Protocol messages until it too receives a "finished" message. + + After the pair of session keys has been determined by each party, + the message bodies are encrypted using it. For the client, this + happens after it verifies the session-identifier or creates a new + session key and has sent it to the server. For the server, this + happens after the session-identifier is found to be good, or the + server receives the client's session key message. + + The following notation is used for SSLHP messages: + + char MSG-EXAMPLE + char FIELD1 + char FIELD2 + char THING-MSB + char THING-LSB + char THING-DATA[(MSB<<8)|LSB]; + ... + + This notation defines the data in the protocol message, including + the message type code. The order is presented top to bottom, with + the top most element being transmitted first, and the bottom most + element transferred last. + + For the "THING-DATA" entry, the MSB and LSB values are actually + THING-MSB and THING-LSB (respectively) and define the number of + bytes of data actually present in the message. For example, if + THING-MSB were zero and THING-LSB were 8 then the THING-DATA array + would be exactly 8 bytes long. This shorthand is used below. + + Length codes are unsigned values, and when the MSB and LSB are + combined the result is an unsigned value. Unless otherwise + specified lengths values are "length in bytes". + + 2.5 Client Only Protocol Messages + + There are several messages that are only generated by clients. + These messages are never generated by correctly functioning + servers. A client receiving such a message closes the connection + to the server and returns an error status to the application + through some unspecified mechanism. + + CLIENT-HELLO (Phase 1; Sent in the clear) + + char MSG-CLIENT-HELLO + char CLIENT-VERSION-MSB + char CLIENT-VERSION-LSB + char CIPHER-SPECS-LENGTH-MSB + char CIPHER-SPECS-LENGTH-LSB + char SESSION-ID-LENGTH-MSB + char SESSION-ID-LENGTH-LSB + char CHALLENGE-LENGTH-MSB + char CHALLENGE-LENGTH-LSB + char CIPHER-SPECS-DATA[(MSB<<8)|LSB] + char SESSION-ID-DATA[(MSB<<8)|LSB] + char CHALLENGE-DATA[(MSB<<8)|LSB] + + When a client first connects to a server it is required to send + the CLIENT-HELLO message. The server is expecting this message + from the client as its first message. It is an error for a client + to send anything else as its first message. + + The client sends to the server its SSL version, its cipher specs + (see below), some challenge data, and the session-identifier data. + The session-identifier data is only sent if the client found a + session-identifier in its cache for the server, and the + SESSION-ID-LENGTH will be non-zero. When there is no + session-identifier for the server SESSION-ID-LENGTH must be zero. + The challenge data is used to authenticate the server. After the + client and server agree on a pair of session keys, the server + returns a SERVER-VERIFY message with the encrypted form of the + CHALLENGE-DATA. + + Also note that the server will not send its SERVER-HELLO message + until it has received the CLIENT-HELLO message. This is done so + that the server can indicate the status of the client's + session-identifier back to the client in the server's first + message (i.e. to increase protocol efficiency and reduce the + number of round trips required). + + The server examines the CLIENT-HELLO message and will verify that + it can support the client version and one of the client cipher + specs. The server can optionally edit the cipher specs, removing + any entries it doesn't choose to support. The edited version will + be returned in the SERVER-HELLO message if the session-identifier + is not in the server's cache. + + The CIPHER-SPECS-LENGTH must be greater than zero and a multiple + of 3. The SESSION-ID-LENGTH must either be zero or 16. The + CHALLENGE-LENGTH must be greater than or equal to 16 and less than + or equal to 32. + + This message must be the first message sent by the client to the + server. After the message is sent the client waits for a + SERVER-HELLO message. Any other message returned by the server + (other than ERROR) is disallowed. + + 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-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 + + 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. + + 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 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. + + 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. + + 2.6 Server Only Protocol Messages + + There are several messages that are only generated by servers. The + messages are never generated by correctly functioning clients. + + 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 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. + + SERVER-VERIFY (Phase 1; Sent encrypted) + + 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 + 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 + SEVER-FINISHED message. + + 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. + + 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. + + 2.7 Client/Server Protocol Messages + + These messages are generated by both the client and the server. + + 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): + + 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. + +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". + + 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 + + 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 + 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 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. + +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. + + 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. + + 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 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 El Gamal. + + 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 + AOL/Netscape Communications Corp. + 466 Ellis Street + Mountain View, CA 94043-4042 + kipp@netscape.com |