7/10/24, 11:28 AM
`SSL Protocol V. 3.0
`The Wayback Machine - https://web.archive.org/web/19970614041044/http://home.netscape.com:80/eng/ssl3/…
`
`The SSL Protocol
`Version 3.0
`
`Internet Draft
`
`March 1996 (Expires 9/96)
`
`Alan O. Freier, Netscape Communications
`Philip Karlton, Netscape Communications
`Paul C. Kocher, Independent Consultant
`
`Table of Contents
`
`1. Status of this memo
`
`2. Abstract
`
`3. Introduction
`
`4. Goals
`
`5. Goals of this document
`
`6. Presentation language
`
`6.1 Basic block size
`6.2 Miscellaneous
`6.3 Vectors
`6.4 Numbers
`6.5 Enumerateds
`6.6 Constructed types
`
`6.6.1 Variants
`
`6.7 Cryptographic attributes
`6.8 Constants
`
`7. SSL protocol
`
`7.1 Session and connection states
`7.2 Record layer
`
`7.2.1 Fragmentation
`7.2.2 Record compression and decompression
`7.2.3 Record payload protection and the CipherSpec
`
`7.3 Change cipher spec protocol
`7.4 Alert protocol
`
`https://web.archive.org/web/19970614041044/http://home.netscape.com/eng/ssl3/ssl-toc.html
`
`Google Exhibit 1021
`Google v. Ericsson
`
`1/3
`
`

`

`7/10/24, 11:28 AM
`
`SSL Protocol V. 3.0
`
`7.4.1 Closure alerts
`7.4.2 Error alerts
`
`7.5 Handshake protocol overview
`7.6 Handshake protocol
`
`7.6.1 Hello messages
`7.6.2 Server certificate
`7.6.3 Server key exchange message
`7.6.4 Certificate request
`7.6.5 Server hello done
`7.6.6 Client certificate
`7.6.7 Client key exchange message
`7.6.8 Certificate verify
`7.6.9 Finished
`
`7.7 Application data protocol
`
`8. Cryptographic computations
`
`8.1 Asymmetric cryptographic computations
`
`8.1.1 RSA
`8.1.2 Diffie-Hellman
`8.1.3 Fortezza
`
`8.2 Symmetric cryptographic calculations and the CipherSpec
`
`8.2.1 The master secret
`8.2.2 Converting the master secret into keys and MAC secrets
`
`Appendices
`
`A. Protocol constant values
`
`A.1 Reserved port assignments
`
`A.1.1 Record layer
`
`A.2 Change cipher specs message
`A.3 Alert messages
`A.4 Handshake protocol
`
`A.4.1 Hello messages
`A.4.2 Server authentication and key exchange messages
`
`A.5 Client authentication and key exchange messages
`
`A.5.1 Handshake finalization message
`
`A.6 The CipherSuite
`A.7 The CipherSpec
`
`B. Glossary
`
`https://web.archive.org/web/19970614041044/http://home.netscape.com/eng/ssl3/ssl-toc.html
`
`2/3
`
`

`

`7/10/24, 11:28 AM
`C. CipherSuite definitions
`
`D. Implementation Notes
`
`SSL Protocol V. 3.0
`
`D.1 Temporary RSA keys
`D.2 Random Number Generation and Seeding
`D.3 Certificates and authentication
`D.4 CipherSuites
`
`E. Version 2.0 Backward Compatibility
`
`E.1 Version 2 client hello
`E.2 Avoiding man-in-the-middle version rollback
`
`F. Security analysis
`
`F.1 Handshake protocol
`
`F.1.1 Authentication and key exchange
`F.1.2 Version rollback attacks
`F.1.3 Detecting attacks against the handshake protocol
`F.1.4 Resuming sessions
`F.1.5 MD5 and SHA
`
`F.2 Protecting application data
`F.3 Final notes
`
`G. Patent Statement
`
`References
`
`Authors
`
`Other contributors
`
`Early reviewers
`
`SSL Version 3.0 - March 1996
`
`https://web.archive.org/web/19970614041044/http://home.netscape.com/eng/ssl3/ssl-toc.html
`
`3/3
`
`

`

`7/10/24, 11:29 AM
`SSL 3.0 Specification
`The Wayback Machine - https://web.archive.org/web/19970617034012/http://home.netscape.com:80/eng/ssl3/…
`
`1. Status of this memo
`
`This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering
`Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working
`documents as Internet-Drafts.
`
`Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or
`made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference
`material or to cite them other than as work in progress.
`
`To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the
`Internet Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu
`(US West Coast), or munnari.oz.au (Pacific Rim).
`
`2. Abstract
`
`This document specifies Version 3.0 of the Secure Sockets Layer (SSL V3.0) protocol, a security protocol
`that provides communications privacy over the Internet. The protocol allows client/server applications to
`communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.
`
`3. Introduction
`
`The primary goal of the SSL Protocol is to provide privacy and reliability between two communicating
`applications. The protocol is composed of two layers. At the lowest level, layered on top of some reliable
`transport protocol (e.g., TCP[TCP]), is the SSL Record Protocol. The SSL Record Protocol is used for
`encapsulation of various higher level protocols. One such encapsulated protocol, the SSL Handshake
`Protocol, allows the server and client to authenticate each other and to negotiate an encryption algorithm
`and cryptographic keys before the application protocol transmits or receives its first byte of data. One
`advantage of SSL is that it is application protocol independent. A higher level protocol can layer on top of
`the SSL Protocol transparently.
`
`The SSL protocol provides connection security that has three basic properties:
`
`The connection is private. Encryption is used after an initial handshake to define a secret key.
`Symmetric cryptography is used for data encryption (e.g., DES[DES], RC4[RC4], etc.)
`The peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g.,
`RSA[RSA], DSS[DSS], etc.).
`The connection is reliable. Message transport includes a message integrity check using a keyed
`MAC. Secure hash functions (e.g., SHA, MD5, etc.) are used for MAC computations.
`
`4. Goals
`
`The goals of SSL Protocol v3.0, in order of their priority, are:
`
`1. Cryptographic security
`SSL should be used to establish a secure connection between two parties.
`2. Interoperability
`
`https://web.archive.org/web/19970617034012/http://home.netscape.com/eng/ssl3/3-SPEC.HTM#1
`
`1/24
`
`

`

`7/10/24, 11:29 AM
`
`SSL 3.0 Specification
`Independent programmers should be able to develop applications utilizing SSL 3.0 that will then be
`able to successfully exchange cryptographic parameters without knowledge of one another's code.
`
`Note:It is not the case that all instances of SSL (even in the same application domain) will be able to
`successfully connect. For instance, if the server supports a particular hardware token, and the client does
`not have access to such a token, then the connection will not succeed.
`
`3. Extensibility
`SSL seeks to provide a framework into which new public key and bulk encryption methods can be
`incorporated as necessary. This will also accomplish two sub-goals: to prevent the need to create a
`new protocol (and risking the introduction of possible new weaknesses) and to avoid the need to
`implement an entire new security library.
`4. Relative efficiency
`Cryptographic operations tend to be highly CPU intensive, particularly public key operations. For
`this reason, the SSL protocol has incorporated an optional session caching scheme to reduce the
`number of connections that need to be established from scratch. Additionally, care has been taken to
`reduce network activity.
`
`5. Goals of this document
`
`The SSL Protocol Version 3.0 Specification is intended primarily for readers who will be implementing
`the protocol and those doing cryptographic analysis of it. The spec has been written with this in mind, and
`it is intended to reflect the needs of those two groups. For that reason, many of the algorithm-dependent
`data structures and rules are included in the body of the text (as opposed to in an Appendix), providing
`easier access to them.
`
`This document is not intended to supply any details of service definition nor interface definition, although
`it does cover select areas of policy as they are required for the maintenance of solid security.
`
`6. Presentation language
`
`This document deals with the formatting of data in an external representation. The following very basic
`and somewhat casually defined presentation syntax will be used. The syntax draws from several sources in
`its structure. Although it resembles the programming language 'C' in its syntax and XDR [XDR] in both its
`syntax and intent, it would be risky to draw too many parallels. The purpose of this presentation language
`is to document SSL only, not to have general application beyond that particular goal.
`
`6.1 Basic block size
`
`The representation of all data items is explicitly specified. The basic data block size is one byte (i.e. 8
`bits). Multiple byte data items are concatenations of bytes, from left to right, from top to bottom. From the
`bytestream a multi-byte item (a numeric in the example) is formed (using C notation) by:
`
`value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | ... | byte[n-1];
`
`This byte ordering for multi-byte values is the commonplace network byte order or big endian format.
`
`6.2 Miscellaneous
`
`Comments begin with "/*" and end with "*/".
`
`Optional components are denoted by enclosing them in italic "[ ]" brackets.
`https://web.archive.org/web/19970617034012/http://home.netscape.com/eng/ssl3/3-SPEC.HTM#1
`
`2/24
`
`

`

`7/10/24, 11:29 AM
`SSL 3.0 Specification
`Single byte entities containing uninterpreted data are of type opaque.
`
`6.3 Vectors
`
`A vector (single dimensioned array) is a stream of homogeneous data elements. The size of the vector may
`be specified at documentation time or left unspecified until runtime. In either case the length declares the
`number of bytes, not the number of elements, in the vector.
`
`The syntax for specifying a new type T' that is a fixed length vector of type T is
`
`T T'[n];
`
`Here T' occupies n bytes in the data stream, where n is a multiple of the size of T. The length of the vector
`is not included in the encoded stream.
`
`In the following example, Datum is defined to be three consecutive bytes that the protocol does not
`interpret, while Data is three consecutive Datum, consuming a total of nine bytes.
`
`/* three uninterpreted bytes of data */
`opaque Datum[3];
`Datum Data[9]; /* 3 consecutive 3 byte vectors */
`
`Variable length vectors are defined by specifying a subrange of legal lengths, inclusively, using the
`notation . When encoded, the actual length precedes the vector's contents in the byte stream. The length
`will be in the form of a number consuming as many bytes as required to hold the vector's specified
`maximum (ceiling) length. A variable length vector with an actual length field of zero is referred to as an
`empty vector.
`
`T T';
`
`In the following example, mandatory is a vector that must contain between 300 and 400 bytes of type
`opaque. It can never be empty. The actual length field consumes two bytes, a uint16, sufficient to represent
`the value 400 (see Section 6.4). On the other hand, longer can represent up to 800 bytes of data, or 400
`uint16 elements, and it may be empty. Its encoding will include a two byte actual length field prepended
`to the vector.
`
`/* length field is 2 bytes, cannot be empty */
`opaque mandatory<300..400>;
`uint16 longer<0..800>;
`/* zero to 400 16-bit unsigned integers */
`
`6.4 Numbers
`
`The basic numeric data type is an unsigned byte (uint8). All larger numeric data types are formed from
`fixed length series of bytes concatenated as described in Section 6.1 and are also unsigned. The following
`numeric types are predefined.
`
`uint8 uint16[2];
`uint8 uint24[3];
`uint8 uint32[4];
`uint8 uint64[8];
`
`6.5 Enumerateds
`
`An additional sparse data type is available called enum. A field of type enum can only assume the values
`declared in the definition. Each definition is a different type. Only enumerateds of the same type may be
`assigned or compared. Every element of an enumerated must be assigned a value, as demonstrated in the
`following example. Since the elements of the enumerated are not ordered, they can be assigned any unique
`value, in any order.
`https://web.archive.org/web/19970617034012/http://home.netscape.com/eng/ssl3/3-SPEC.HTM#1
`
`3/24
`
`

`

`7/10/24, 11:29 AM
`enum { e1(v1), e2 (v
`
`1
`
`SSL 3.0 Specification
`), ... , en (vN), [(n)] } Te;
`
`Enumerateds occupy as much space in the byte stream as would its maximal defined ordinal value. The
`following definition would cause one byte to be used to carry fields of type Color.
`
`enum { red(3), blue(5), white(7) } Color;
`
`One may optionally specify a value without its associated tag to force the width definition without
`defining a superfluous element. In the following example, Taste will consume two bytes in the data stream
`but can only assume the values 1, 2 or 4.
`
`enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
`
`The names of the elements of an enumeration are scoped within the defined type. In the first example, a
`fully qualified reference to the second element of the enumeration would be Color.blue. Such
`qualification is not required if the target of the assignment is well specified.
`
`/* overspecified, but legal */
`Color color = Color.blue;
`Color color = blue;
`/* correct, type is implicit */
`
`For enumerateds that are never converted to external representation, the numerical information may be
`omitted.
`
`enum { low, medium, high } Amount;
`6.6 Constructed types
`
`Structure types may be constructed from primitive types for convenience. Each specification declares a
`new, unique type. The syntax for definition is much like that of C.
`
`struct {
`T1 f1;
`T2 f2;
`...
`Tn fn;
`
`} [T];
`
`The fields within a structure may be qualified using the type's name using a syntax much like that
`available for enumerateds. For example, T.f2 refers to the second field of the previous declaration.
`Structure definitions may be embedded.
`
`6.6.1 Variants
`
`Defined structures may have variants based on some knowledge that is available within the environment.
`The selector must be an enumerated type that defines the possible variants the structure defines. There
`must be a case arm for every element of the enumeration declared in the select. The body of the variant
`structure may be given a label for reference. The mechanism by which the variant is selected at runtime is
`not prescribed by the presentation language.
`
`struct {
`T1 f1;
`T2 f2;
` ....
`Tn fn;
`select (E) {
` case e1: Te1;
`https://web.archive.org/web/19970617034012/http://home.netscape.com/eng/ssl3/3-SPEC.HTM#1
`
`4/24
`
`

`

`7/10/24, 11:29 AM
`
`SSL 3.0 Specification
`
` case e2: Te2;
` ....
` case en: Ten;
`} [fv];
`
`} [Tv];
`
`For example
`
`enum { apple, orange } VariantTag;
`struct {
`uint16 number;
`opaque string<0..10>;
`
`/* variable length */
`
`} V1;
`struct {
`uint32 number;
`opaque string[10];
`
`/* fixed length */
`
`} V2;
`struct {
`/* value of variant selector is implicit */
`select (VariantTag) {
`/* definition of VariantBody, tag = apple */
` case apple: V1;
`/* definition of VariantBody, tag = orange */
` case orange: V2;
`} variant_body; /* optional label on the variant portion */
`} VariantRecord;
`
`Variant structures may be qualified (narrowed) by specifying a value for the selector prior to the type. For
`example, a
`
`orange VariantRecord
`
`is a narrowed type of a VariantRecord containing a variant_body of type V2.
`
`6.7 Cryptographic attributes
`
`The four cryptographic operations digital signing, stream cipher encryption, block cipher encryption, and
`public key encryption are designated digitally-signed, stream-ciphered, block-ciphered, and public-
`key-encrypted, respectively. A field's cryptographic processing is specified by prepending an appropriate
`key word designation before the field's type specification. Cryptographic keys are implied by the current
`session state (see Section 7.1).
`
`In digital signing, one-way hash functions are used as input for a signing algorithm. In RSA signing, a 36-
`byte structure of two hashes (one SHA and one MD5) is signed (encrypted with the private key). In DSS,
`the 20 bytes of the SHA hash are run directly through the Digital Signing Algorithm with no additional
`hashing.
`
`In stream cipher encryption, the plaintext is exclusive-ORed with an identical amount of output generated
`from a cryptographically-secure keyed pseudorandom number generator.
`
`In block cipher encryption, every block of plaintext encrypts to a block of ciphertext. Because it is
`unlikely that the plaintext (whatever data is to be sent) will break neatly into the necessary block size
`(usually 64 bits), it is necessary to pad out the end of short blocks with some regular pattern, usually all
`zeroes.
`
`In public key encryption, one-way functions with secret "trapdoors" are used to encrypt the outgoing data.
`Data encrypted with the public key of a given key pair can only be decrypted with the private key, and
`vice-versa.
`
`In the following example:
`
`https://web.archive.org/web/19970617034012/http://home.netscape.com/eng/ssl3/3-SPEC.HTM#1
`
`5/24
`
`

`

`7/10/24, 11:29 AM
`stream-ciphered struct {
`uint8 field1;
`uint8 field2;
`digitally-signed opaque hash[20];
`} UserType;
`
`SSL 3.0 Specification
`
`The contents of hash are used as input for a signing algorithm, then the entire structure is encrypted with a
`stream cipher.
`
`6.8 Constants
`
`Typed constants can be defined for purposes of specification by declaring a symbol of the desired type and
`assigning values to it. Under-specified types (opaque, variable length vectors, and structures that contain
`opaque) cannot be assigned values. No fields of a multi-element structure or vector may be elided.
`
`For example,
`
`struct {
`uint8 f1;
`uint8 f2;
`} Example1;
`Example1 ex1 = {1, 4};
`
`7. SSL protocol
`
`/* assigns f1 = 1, f2 = 4 */
`
`SSL is a layered protocol. At each layer, messages may include fields for length, description, and content.
`SSL takes messages to be transmitted, fragments the data into manageable blocks, optionally compresses
`the data, applies a MAC, encrypts, and transmits the result. Received data is decrypted, verified,
`decompressed, and reassembled, then delivered to higher level clients.
`
`7.1 Session and connection states
`
`An SSL session is stateful. It is the responsibility of the SSL Handshake protocol to coordinate the states
`of the client and server, thereby allowing the protocol state machines of each to operate consistently,
`despite the fact that the state is not exactly parallel. Logically the state is represented twice, once as the
`current operating state, and (during the handshake protocol) again as the pending state. Additionally,
`separate read and write states are maintained. When the client or server receives a change cipher spec
`message, it copies the pending read state into the current read state. When the client or server sends a
`change cipher spec message, it copies the pending write state into the current write state. When the
`handshake negotiation is complete, the client and server exchange change cipher spec messages (see
`Section 7.3), and then communicate using the newly agreed-upon cipher spec.
`
`An SSL session may include multiple secure connections; in addition, parties may have multiple
`simultaneous sessions.
`
`The session state includes the following elements:
`
`session identifier
`An arbitrary byte sequence chosen by the server to identify an active or resumable session state
`peer certificate
`X509.v3[X509] certificate of the peer. This element of the state may be null.
`compression method
`The algorithm used to compress data prior to encryption.
`cipher spec
`
`https://web.archive.org/web/19970617034012/http://home.netscape.com/eng/ssl3/3-SPEC.HTM#1
`
`6/24
`
`

`

`7/10/24, 11:29 AM
`
`SSL 3.0 Specification
`Specifies the bulk data encryption algorithm (such as null, DES, etc.) and a MAC algorithm (such as
`MD5 or SHA). It also defines cryptographic attributes such as the hash_size. (See Appendix A.7 for
`formal definition.)
`master secret
`48-byte secret shared between the client and server.
`is resumable
`A flag indicating whether the session can be used to initiate new connections.
`
`The connection state includes the following elements:
`
`server and client random
`Byte sequences that are chosen by the server and client for each connection.
`server write MAC secret
`The secret used in MAC operations on data written by the server.
`client write MAC secret
`The secret used in MAC operations on data written by the client.
`server write key
`The bulk cipher key for data encrypted by the server and decrypted by the client.
`client write key
`The bulk cipher key for data encrypted by the client and decrypted by the server.
`initialization vectors
`When a block cipher in CBC mode is used, an initialization vector (IV) is maintained for each key.
`This field is first initialized by the SSL handshake protocol. Thereafter the final ciphertext block
`from each record is preserved for use with the following record.
`sequence numbers
`Each party maintains separate sequence numbers for transmitted and received messages for each
`connection. When a party sends or receives a change cipher spec message, the appropriate
`sequence number is set to zero. Sequence numbers are of type uint64 and may not exceed 264-1.
`
`7.2 Record layer
`
`The SSL Record Layer receives uninterpreted data from higher layers in non-empty blocks of arbitrary
`size.
`
`7.2.1Fragmentation
`
`The record layer fragments information blocks into SSLPlaintext records of 214 bytes or less. Client
`message boundaries are not preserved in the record layer (i.e., multiple client messages of the same
`ContentType may be coalesced into a single SSLPlaintext record).
`
`struct {
`uint8 major, minor;
`} ProtocolVersion;
`enum {
`
`change_cipher_spec(20), alert(21), handshake(22),
`application_data(23), (255)
`} ContentType;
`struct {
`ContentType type;
`ProtocolVersion version;
`uint16 length;
`opaque fragment[SSLPlaintext.length];
`} SSLPlaintext;
`
`type
`
`The higher level protocol used to process the enclosed fragment.
`https://web.archive.org/web/19970617034012/http://home.netscape.com/eng/ssl3/3-SPEC.HTM#1
`
`7/24
`
`

`

`SSL 3.0 Specification
`
`7/10/24, 11:29 AM
`version
`The version of protocol being employed. This document describes SSL Version 3.0 (See Appendix
`A.1.1).
`length
`The length (in bytes) of the following SSLPlaintext.fragment. The length should not exceed 214.
`fragment
`The application data. This data is transparent and treated as an independent block to be dealt with by
`the higher level protocol specified by the type field.
`
`Note: Data of different SSL Record layer content types may be interleaved. Application data is generally of lower precedence for
`transmission than other content types.
`
`7.2.2 Record compression and decompression
`
`All records are compressed using the compression algorithm defined in the current session state. There is
`always an active compression algorithm, however initially it is defined as CompressionMethod.null. The
`compression algorithm translates an SSLPlaintext structure into an SSLCompressed structure.
`Compression functions erase their state information whenever the CipherSpec is replaced.
`
`Note: The CipherSpec is part of the session state described in Section 7.1. References to fields of the
`CipherSpec are made throughout this document using presentation syntax. A more complete description of
`the CipherSpec is shown in Appendix A.7.
`
`Compression must be lossless and may not increase the content length by more than 1024 bytes. If the
`decompression function encounters an SSLCompressed.fragment that would decompress to a length in
`excess of 214 bytes, it should issue a fatal decompression_failure alert (Section 7.4.2).
`
`struct {
`ContentType type;
`ProtocolVersion version;
`uint16 length;
`opaque fragment[SSLCompressed.length];
`} SSLCompressed;
`
`/* same as SSLPlaintext.type */
`/* same as SSLPlaintext.version */
`
`length
`The length (in bytes) of the following SSLCompressed.fragment. The length should not exceed 214 +
`1024.
`fragment
`The compressed form of SSLPlaintext.fragment.
`
`Note: A CompressionMethod.null operation is an identity operation; no fields are altered. (See Appendix
`A.4.1)
`
`Implementation note: Decompression functions are responsible for ensuring that messages cannot cause
`internal buffer overflows.
`
`7.2.3 Record payload protection and the CipherSpec
`
`All records are protected using the encryption and MAC algorithms defined in the current CipherSpec.
`There is always an active CipherSpec, however initially it is SSL_NULL_WITH_NULL_NULL, which does not
`provide any security.
`
`Once the handshake is complete, the two parties have shared secrets which are used to encrypt records and
`compute keyed message authentication codes (MACs) on their contents. The techniques used to perform
`the encryption and MAC operations are defined by the CipherSpec and constrained by
`
`https://web.archive.org/web/19970617034012/http://home.netscape.com/eng/ssl3/3-SPEC.HTM#1
`
`8/24
`
`

`

`7/10/24, 11:29 AM
`SSL 3.0 Specification
`CipherSpec.cipher_type. The encryption and MAC functions translate an SSLCompressed structure into
`an SSLCiphertext. The decryption functions reverse the process. Transmissions also include a sequence
`number so that missing, altered, or extra messages are detectable.
`
`struct {
`ContentType type;
`ProtocolVersion version;
`uint16 length;
`select (CipherSpec.cipher_type) {
` case stream: GenericStreamCipher;
` case block: GenericBlockCipher;
`} fragment;
`} SSLCiphertext;
`
`type
`
`The type field is identical to SSLCompressed.type.
`
`version
`The version field is identical to SSLCompressed.version.
`
`length
`The length (in bytes) of the following SSLCiphertext.fragment. The length may not exceed 214 +
`2048.
`
`fragment
`The encrypted form of SSLCompressed.fragment, including the MAC.
`
`7.2.3.1 Null or standard stream cipher
`
`Stream ciphers (including BulkCipherAlgorithm.null - See Appendix A.7 ) convert
`SSLCompressed.fragment structures to and from stream SSLCiphertext.fragment structures.
`
`stream-ciphered struct {
` opaque content[SSLCompressed.length];
` opaque MAC[CipherSpec.hash_size];
`} GenericStreamCipher;
`
`The MAC is generated as:
`
`hash(MAC_write_secret + pad_2 +
`hash (MAC_write_secret + pad_1 + seq_num + length + content));
`
`where "+" denotes concatenation.
`
`pad_1
`
`The character 0x36 repeated 48 time for MD5 or 40 times for SHA.
`
`The character 0x5c repeated the same number of times.
`seq_num
`The sequence number for this message.
`
`pad_2
`
`hash
`
`The hashing algorithm derived from the cipher suite.
`
`Note that the MAC is computed before encryption. The stream cipher encrypts the entire block, including
`the MAC. For stream ciphers that do not use a synchronization vector (such as RC4), the stream cipher
`state from the end of one record is simply used on the subsequent packet. If the CipherSuite is
`SSL_NULL_WITH_NULL_NULL, encryption consists of the identity operation (i.e., the data is not
`
`https://web.archive.org/web/19970617034012/http://home.netscape.com/eng/ssl3/3-SPEC.HTM#1
`
`9/24
`
`

`

`7/10/24, 11:29 AM
`SSL 3.0 Specification
`encrypted and the MAC size is zero implying that no MAC is used). SSLCiphertext.length is
`SSLCompressed.length plus CipherSpec.hash_size.
`
`7.2.3.2 CBC block cipher
`
`For block ciphers (such as RC2 or DES), the encryption and MAC functions convert
`SSLCompressed.fragment structures to and from block SSLCiphertext.fragment structures.
`
`block-ciphered struct {
`opaque content[SSLCompressed.length];
`opaque MAC[CipherSpec.hash_size];
`uint8 padding[GenericBlockCipher.padding_length];
`uint8 padding_length;
`} GenericBlockCipher;
`
`The MAC is generated as described in Section 7.2.3.1.
`
`padding
`Padding that is added to force the length of the plaintext to be a multiple of the block
`cipher's block length.
`
`padding_length
`The length of the padding must be less than the cipher's block length and may be zero. The
`padding length should be such that the total size of the GenericBlockCipher structure is a
`multiple of the cipher's block length.
`
`The encrypted data length (SSLCiphertext.length) is one more than the sum of
`SSLCompressed.length, CipherSpec.hash_size, and padding_length.
`
`Note: With CBC block chaining the initialization vector (IV) for the first record is provided
`by the handshake protocol. The IV for subsequent records is the last ciphertext block from the
`previous record.
`
`7.3 Change cipher spec protocol
`
`The change cipher spec protocol exists to signal transitions in ciphering strategies. The
`protocol consists of a single message, which is encrypted and compressed under the current (not
`the pending) CipherSpec. The message consists of a single byte of value 1.
`
`struct {
`enum { change_cipher_spec(1), (255) } type;
`} ChangeCipherSpec;
`
`The change cipher spec message is sent by both the client and server to notify the receiving
`party that subsequent records will be protected under the just-negotiated CipherSpec and keys.
`Reception of this message causes the receiver to copy the read pending state into the read
`current state. Separate read and write states are maintained by both the SSL client and server.
`When the client or server receives a change cipher spec message, it copies the pending read
`state into the current read state. When the client or server writes a change cipher spec
`message, it copies the pending write state into the current write state. The client sends a
`change cipher spec message following handshake key exchange and certificate verify messages (if
`any), and the server sends one after successfully processing the key exchange message it
`received from the client. An unexpected change cipher spec message should generate an
`unexpected_message alert (Section 7.4.2). When resuming a previous session, the change cipher
`spec message is sent after the hello messages.
`
`7.4 Alert protocol
`
`One of the content types supported by the SSL Record layer is the alert type. Alert messages
`convey the severity of the message and a description of the alert. Alert messages with a level
`of fatal result in the immediate termination of the connection. In this case, other connections
`corresponding to the session may continue, but the session identifier must be invalidated,
`preventing the failed session from being used to establish new connections. Like other
`messages, Alert messages are encrypted and compressed, as specified by the current connection
`
`https://web.archive.org/web/19970617034012/http://home.netscape.com/eng/ssl3/3-SPEC.HTM#1
`
`10/24
`
`

`

`7/10/24, 11:29 AM
`state.
`
`SSL 3.0 Specification
`
`enum { warning(1), fatal(2), (255) } AlertLevel;
`
`enum {
`
`close_notify(0),
`unexpected_message(10),
`bad_record_mac(20),
`decompression_failure(30),
`handshake_failure(40), no_certificate(41), bad_certificate(42),
` unsupported_certificate(43), certificate_revoked(44),
` certificate_expired(45), certificate_unknown(46),
` illegal_parameter (47)
`(255)
`} AlertDescription;
`
`struct {
`AlertLevel level;
`AlertDescription description;
`} Alert;
`
`7.4.1 Closure alerts
`
`The client and the server must share knowledge that the connection is ending in order to avoid
`a truncation attack. Either party may initiate the exchange of closing messages.
`
`close_notify
`This message notifies the recipient that the sender will not send any more messages on
`this connection. The session becomes unresumable if any connection is terminated without
`proper close_notify messages with level equal to warning.
`
`7.4.2 Error alerts
`
`Error handling in the SSL Handshake protocol is very simple. When an error is detected, the
`detecting party sends a message to the other party. Upon transmission or receipt of an fatal
`alert message, both parties immediately close the connection. Servers and clients are required
`to forget any session-identifiers, keys, and secrets associated with a failed connection. The
`following error alerts are defined:
`
`unexpected_message
`An inappropriate message was received. This alert is always fatal and should never be
`observed in communication between proper implementations.
`
`bad_record_mac
`This alert is returned if a record is received with an incorrect MAC. This message is
`always fatal.
`
`decompression_failure
`The decompression function received improper input (e.g. data that would expand to
`excessive length). This message is always fatal.
`
`handshake_failure
`Reception of a handshake_failure alert message indicates that the sender was unable to
`negotiate an acceptable set of security parameters given the options available. This is a
`fatal error.
`
`no_certificate
`A no_certificate alert message may be sent in response to a certification request if no
`appropriate certificate is available.
`
`bad_certificate
`A certificate was corrupt, contained signatures that did not verify correctly, etc.
`
`unsupported_certificate
`A certificate was of an unsupported type.
`
`https://web.archive.org/web/19970617034012/http://home.netscape.com/eng/ssl3/3-SPEC.HTM#1
`
`11/24
`
`

`

`7/10/24, 11:29 AM
`certificate_revoked
`A certificate was revoked by its signer.
`
`SSL 3.0 Specification
`
`certificate_expired
`A certificate has expired or is not currently valid.
`
`certificate_unknown
`Some other (unspecified) issue arose in processing the certificate, rendering it
`unacceptable.
`
`illegal_parameter
`A field in the handshake was out of range or inconsistent with other f