2/5/2020
`
`The SSL 0.2 Protocol
`
`You are currently viewing a snapshot of www.mozilla.org taken on
`April 21, 2008. Most of this content is highly out of date (some pages
`haven't been updated since the project began in 1998) and exists for
`historical purposes only. If there are any pages on this archive site
`that you think should be added back to www.mozilla.org, please file
`a bug.
`
`Mozilla
`
`About
`Developers
`Store
`Support
`Products
`
`search mozilla:
`
`SSL 0.2 PROTOCOL SPECIFICATION
`
` Go
`
`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:
`
`https://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft02
`
`1/22
`
`Juniper Ex. 1052-p. 1
`Juniper v Implicit
`
`

`

`2/5/2020
`
`The SSL 0.2 Protocol
`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
`Request For Comments: XXXX
`Category: Informational
`
`Kipp E.B. Hickman
`Netscape Communications Corp.
`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.
`
`https://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft02
`
`2/22
`
`Juniper Ex. 1052-p. 2
`Juniper v Implicit
`
`

`

`The SSL 0.2 Protocol
`2/5/2020
`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):
`
`https://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft02
`
`3/22
`
`Juniper Ex. 1052-p. 3
`Juniper v Implicit
`
`

`

`2/5/2020
`MAC-DATA[MAC-SIZE]
`ACTUAL-DATA[N]
`PADDING-DATA[PADDING]
`
`The SSL 0.2 Protocol
`
`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
`
`https://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft02
`
`4/22
`
`Juniper Ex. 1052-p. 4
`Juniper v Implicit
`
`

`

`2/5/2020
`at all times.
`
`The SSL 0.2 Protocol
`
`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.
`
`https://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft02
`
`5/22
`
`Juniper Ex. 1052-p. 5
`Juniper v Implicit
`
`

`

`The SSL 0.2 Protocol
`2/5/2020
`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
`
`https://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft02
`
`6/22
`
`Juniper Ex. 1052-p. 6
`Juniper v Implicit
`
`

`

`2/5/2020
`
`The SSL 0.2 Protocol
`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]
`
`https://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft02
`
`7/22
`
`Juniper Ex. 1052-p. 7
`Juniper v Implicit
`
`

`

`2/5/2020
` char SESSION-ID-DATA[(MSB<<8)|LSB]
` char CHALLENGE-DATA[(MSB<<8)|LSB]
`
`The SSL 0.2 Protocol
`
`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
`https://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft02
`
`8/22
`
`Juniper Ex. 1052-p. 8
`Juniper v Implicit
`
`

`

`The SSL 0.2 Protocol
`2/5/2020
`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).
`
`https://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft02
`
`9/22
`
`Juniper Ex. 1052-p. 9
`Juniper v Implicit
`
`

`

`2/5/2020
`
`The SSL 0.2 Protocol
`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]
`
`https://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft02
`
`10/22
`
`Juniper Ex. 1052-p. 10
`Juniper v Implicit
`
`

`

`The SSL 0.2 Protocol
`2/5/2020
`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-