path: root/doc/protocol/ssl-version2.txt

                              [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