diff options
Diffstat (limited to 'doc/protocol/ssl-version2.txt')
| -rw-r--r-- | doc/protocol/ssl-version2.txt | 1486 |
1 files changed, 0 insertions, 1486 deletions
diff --git a/doc/protocol/ssl-version2.txt b/doc/protocol/ssl-version2.txt deleted file mode 100644 index 9ce3d2ac5c..0000000000 --- a/doc/protocol/ssl-version2.txt +++ /dev/null @@ -1,1486 +0,0 @@ - [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 |