diff options
Diffstat (limited to 'doc/rfc/rfc6101.txt')
| -rw-r--r-- | doc/rfc/rfc6101.txt | 3755 |
1 files changed, 3755 insertions, 0 deletions
diff --git a/doc/rfc/rfc6101.txt b/doc/rfc/rfc6101.txt new file mode 100644 index 0000000..e91d677 --- /dev/null +++ b/doc/rfc/rfc6101.txt @@ -0,0 +1,3755 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Freier +Request for Comments: 6101 P. Karlton +Category: Historic Netscape Communications +ISSN: 2070-1721 P. Kocher + Independent Consultant + August 2011 + + + The Secure Sockets Layer (SSL) Protocol Version 3.0 + +Abstract + + This document is published as a historical record of the SSL 3.0 + protocol. The original Abstract follows. + + This document specifies version 3.0 of the Secure Sockets Layer (SSL + 3.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. + +Foreword + + Although the SSL 3.0 protocol is a widely implemented protocol, a + pioneer in secure communications protocols, and the basis for + Transport Layer Security (TLS), it was never formally published by + the IETF, except in several expired Internet-Drafts. This allowed no + easy referencing to the protocol. We believe a stable reference to + the original document should exist and for that reason, this document + describes what is known as the last published version of the SSL 3.0 + protocol, that is, the November 18, 1996, version of the protocol. + + There were no changes to the original document other than trivial + editorial changes and the addition of a "Security Considerations" + section. However, portions of the original document that no longer + apply were not included. Such as the "Patent Statement" section, the + "Reserved Ports Assignment" section, and the cipher-suite registrator + note in the "The CipherSuite" section. The "US export rules" + discussed in the document do not apply today but are kept intact to + provide context for decisions taken in protocol design. The "Goals + of This Document" section indicates the goals for adopters of SSL + 3.0, not goals of the IETF. + + The authors and editors were retained as in the original document. + The editor of this document is Nikos Mavrogiannopoulos + (nikos.mavrogiannopoulos@esat.kuleuven.be). The editor would like to + thank Dan Harkins, Linda Dunbar, Sean Turner, and Geoffrey Keating + for reviewing this document and providing helpful comments. + + + +Freier, et al. Historic [Page 1] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for the historical record. + + This document defines a Historic Document for the Internet community. + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6101. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + +Freier, et al. Historic [Page 2] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +Table of Contents + + 1. Introduction ....................................................5 + 2. Goals ...........................................................5 + 3. Goals of This Document ..........................................6 + 4. Presentation Language ...........................................6 + 4.1. Basic Block Size ...........................................7 + 4.2. Miscellaneous ..............................................7 + 4.3. Vectors ....................................................7 + 4.4. Numbers ....................................................8 + 4.5. Enumerateds ................................................8 + 4.6. Constructed Types ..........................................9 + 4.6.1. Variants ...........................................10 + 4.7. Cryptographic Attributes ..................................11 + 4.8. Constants .................................................12 + 5. SSL Protocol ...................................................12 + 5.1. Session and Connection States .............................12 + 5.2. Record Layer ..............................................14 + 5.2.1. Fragmentation ......................................14 + 5.2.2. Record Compression and Decompression ...............15 + 5.2.3. Record Payload Protection and the CipherSpec .......16 + 5.3. Change Cipher Spec Protocol ...............................18 + 5.4. Alert Protocol ............................................18 + 5.4.1. Closure Alerts .....................................19 + 5.4.2. Error Alerts .......................................20 + 5.5. Handshake Protocol Overview ...............................21 + 5.6. Handshake Protocol ........................................23 + 5.6.1. Hello messages .....................................24 + 5.6.2. Server Certificate .................................28 + 5.6.3. Server Key Exchange Message ........................28 + 5.6.4. Certificate Request ................................30 + 5.6.5. Server Hello Done ..................................31 + 5.6.6. Client Certificate .................................31 + 5.6.7. Client Key Exchange Message ........................31 + 5.6.8. Certificate Verify .................................34 + 5.6.9. Finished ...........................................35 + 5.7. Application Data Protocol .................................36 + 6. Cryptographic Computations .....................................36 + 6.1. Asymmetric Cryptographic Computations .....................36 + 6.1.1. RSA ................................................36 + 6.1.2. Diffie-Hellman .....................................37 + 6.1.3. FORTEZZA ...........................................37 + 6.2. Symmetric Cryptographic Calculations and the CipherSpec ...37 + 6.2.1. The Master Secret ..................................37 + 6.2.2. Converting the Master Secret into Keys and + MAC Secrets ........................................37 + 7. Security Considerations ........................................39 + 8. Informative References .........................................40 + + + +Freier, et al. Historic [Page 3] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + Appendix A. Protocol Constant Values ..............................42 + A.1. Record Layer ...............................................42 + A.2. Change Cipher Specs Message ................................43 + A.3. Alert Messages .............................................43 + A.4. Handshake Protocol .........................................44 + A.4.1. Hello Messages .........................................44 + A.4.2. Server Authentication and Key Exchange Messages ........45 + A.5. Client Authentication and Key Exchange Messages ............46 + A.5.1. Handshake Finalization Message .........................47 + A.6. The CipherSuite ............................................47 + A.7. The CipherSpec .............................................49 + Appendix B. Glossary ..............................................50 + Appendix C. CipherSuite Definitions ...............................53 + Appendix D. Implementation Notes ..................................56 + D.1. Temporary RSA Keys .........................................56 + D.2. Random Number Generation and Seeding .......................56 + D.3. Certificates and Authentication ............................57 + D.4. CipherSuites ...............................................57 + D.5. FORTEZZA ...................................................57 + D.5.1. Notes on Use of FORTEZZA Hardware ......................57 + D.5.2. FORTEZZA Cipher Suites .................................58 + D.5.3. FORTEZZA Session Resumption ............................58 + Appendix E. Version 2.0 Backward Compatibility ....................59 + E.1. Version 2 Client Hello .....................................59 + E.2. Avoiding Man-in-the-Middle Version Rollback ..............61 + Appendix F. Security Analysis .....................................61 + F.1. Handshake Protocol .........................................61 + F.1.1. Authentication and Key Exchange ........................61 + F.1.2. Version Rollback Attacks ...............................64 + F.1.3. Detecting Attacks against the Handshake Protocol .......64 + F.1.4. Resuming Sessions ......................................65 + F.1.5. MD5 and SHA ............................................65 + F.2. Protecting Application Data ................................65 + F.3. Final Notes ................................................66 + Appendix G. Acknowledgements ......................................66 + G.1. Other Contributors .........................................66 + G.2. Early Reviewers ............................................67 + + + + + + + + + + + + + + +Freier, et al. Historic [Page 4] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +1. 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 [RFC0793]), 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: + + o 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], 3DES [3DES], RC4 [SCH]). + + o The peer's identity can be authenticated using asymmetric, or + public key, cryptography (e.g., RSA [RSA], DSS [DSS]). + + o The connection is reliable. Message transport includes a message + integrity check using a keyed Message Authentication Code (MAC) + [RFC2104]. Secure hash functions (e.g., SHA, MD5) are used for + MAC computations. + +2. Goals + + The goals of SSL protocol version 3.0, in order of their priority, + are: + + 1. Cryptographic security + + SSL should be used to establish a secure connection between + two parties. + + 2. Interoperability + + 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. + + + + + + + +Freier, et al. Historic [Page 5] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + 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. + +3. 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 or interface definition, although it does cover select + areas of policy as they are required for the maintenance of solid + security. + +4. 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 External Data + Representation (XDR) [RFC1832] in both its syntax and intent, it + + + + +Freier, et al. Historic [Page 6] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + 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. + +4.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 byte stream, 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. + +4.2. Miscellaneous + + Comments begin with "/*" and end with "*/". Optional components are + denoted by enclosing them in "[[ ]]" double brackets. Single-byte + entities containing uninterpreted data are of type opaque. + +4.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. + + opaque Datum[3]; /* three uninterpreted bytes */ + Datum Data[9]; /* 3 consecutive 3 byte vectors */ + + + + + + +Freier, et al. Historic [Page 7] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + Variable-length vectors are defined by specifying a subrange of legal + lengths, inclusively, using the notation <floor..ceiling>. 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'<floor..ceiling>; + + 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 4.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. + + opaque mandatory<300..400>; + /* length field is 2 bytes, cannot be empty */ + uint16 longer<0..800>; + /* zero to 400 16-bit unsigned integers */ + +4.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 4.1 and are also unsigned. The + following numeric types are predefined. + + uint8 uint16[2]; + uint8 uint24[3]; + uint8 uint32[4]; + uint8 uint64[8]; + +4.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. + + enum { e1(v1), e2(v2), ... , en(vn), [[(n)]] } Te; + + + + + +Freier, et al. Historic [Page 8] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + 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; + + Optionally, one may 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. + + Color color = Color.blue; /* overspecified, legal */ + Color color = blue; /* correct, type implicit */ + + For enumerateds that are never converted to external representation, + the numerical information may be omitted. + + enum { low, medium, high } Amount; + +4.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. + + + + + + + +Freier, et al. Historic [Page 9] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +4.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; + 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 { + select (VariantTag) { /* value of selector is implicit */ + case apple: V1; /* VariantBody, tag = apple */ + case orange: V2; /* VariantBody, tag = orange */ + } variant_body; /* optional label on variant */ + } VariantRecord; + + + + + + + + + + +Freier, et al. Historic [Page 10] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + Variant structures may be qualified (narrowed) by specifying a value + for the selector prior to the type. For example, an + + orange VariantRecord + + is a narrowed type of a VariantRecord containing a variant_body of + type V2. + +4.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 5.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 Signature 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: + + stream-ciphered struct { + uint8 field1; + uint8 field2; + digitally-signed opaque hash[20]; + } UserType; + + The contents of hash are used as input for the signing algorithm, + then the entire structure is encrypted with a stream cipher. + + + + +Freier, et al. Historic [Page 11] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +4.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};/* assigns f1 = 1, f2 = 4 */ + +5. SSL Protocol + + 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. + +5.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 5.3), and they 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. + + + + + + + +Freier, et al. Historic [Page 12] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + 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: 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 Cipher Block Chaining + (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. + + + + + + + + +Freier, et al. Historic [Page 13] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + 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 2^64-1. + +5.2. Record Layer + + The SSL record layer receives uninterpreted data from higher layers + in non-empty blocks of arbitrary size. + +5.2.1. Fragmentation + + The record layer fragments information blocks into SSLPlaintext + records of 2^14 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. + + version: The version of protocol being employed. This document + describes SSL version 3.0 (see Appendix A.1). + + length: The length (in bytes) of the following + SSLPlaintext.fragment. The length should not exceed 2^14. + + 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. + + + + + +Freier, et al. Historic [Page 14] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + 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. + +5.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 5.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 + 2^14 bytes, it should issue a fatal decompression_failure alert + (Section 5.4.2). + + struct { + ContentType type; /* same as SSLPlaintext.type */ + ProtocolVersion version;/* same as SSLPlaintext.version */ + uint16 length; + opaque fragment[SSLCompressed.length]; + } SSLCompressed; + + length: The length (in bytes) of the following + SSLCompressed.fragment. The length should not exceed 2^14 + 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. + + + + + + + + + +Freier, et al. Historic [Page 15] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +5.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 + that 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 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 2^14 + 2048. + + fragment: The encrypted form of SSLCompressed.fragment, including + the MAC. + +5.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; + + + + +Freier, et al. Historic [Page 16] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + The MAC is generated as: + + hash(MAC_write_secret + pad_2 + + hash(MAC_write_secret + pad_1 + seq_num + + SSLCompressed.type + SSLCompressed.length + + SSLCompressed.fragment)); + + where "+" denotes concatenation. + + pad_1: The character 0x36 repeated 48 times for MD5 or 40 times for + SHA. + + pad_2: The character 0x5c repeated 48 times for MD5 or 40 times for + SHA. + + seq_num: The sequence number for this message. + + hash: 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 + encrypted and the MAC size is zero implying that no MAC is used). + SSLCiphertext.length is SSLCompressed.length plus + CipherSpec.hash_size. + +5.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 5.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. + + + + + +Freier, et al. Historic [Page 17] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + 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, 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. + +5.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. 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 5.4.2). When resuming a previous + session, the change cipher spec message is sent after the hello + messages. + +5.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 state. + + + +Freier, et al. Historic [Page 18] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + 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; + +5.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. + + Either party may initiate a close by sending a close_notify alert. + Any data received after a closure alert is ignored. + + Each party is required to send a close_notify alert before closing + the write side of the connection. It is required that the other + party respond with a close_notify alert of its own and close down the + connection immediately, discarding any pending writes. It is not + required for the initiator of the close to wait for the responding + close_notify alert before closing the read side of the connection. + + NB: It is assumed that closing a connection reliably delivers pending + data before destroying the transport. + + + + + +Freier, et al. Historic [Page 19] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +5.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 a 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. + + certificate_revoked: A certificate was revoked by its signer. + + 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 fields. This is always fatal. + + + + + + +Freier, et al. Historic [Page 20] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +5.5. Handshake Protocol Overview + + The cryptographic parameters of the session state are produced by the + SSL handshake protocol, which operates on top of the SSL record + layer. When an SSL client and server first start communicating, they + agree on a protocol version, select cryptographic algorithms, + optionally authenticate each other, and use public key encryption + techniques to generate shared secrets. These processes are performed + in the handshake protocol, which can be summarized as follows: the + client sends a client hello message to which the server must respond + with a server hello message, or else a fatal error will occur and the + connection will fail. The client hello and server hello are used to + establish security enhancement capabilities between client and + server. The client hello and server hello establish the following + attributes: Protocol Version, Session ID, Cipher Suite, and + Compression Method. Additionally, two random values are generated + and exchanged: ClientHello.random and ServerHello.random. + + Following the hello messages, the server will send its certificate, + if it is to be authenticated. Additionally, a server key exchange + message may be sent, if it is required (e.g., if their server has no + certificate, or if its certificate is for signing only). If the + server is authenticated, it may request a certificate from the + client, if that is appropriate to the cipher suite selected. Now the + server will send the server hello done message, indicating that the + hello-message phase of the handshake is complete. The server will + then wait for a client response. If the server has sent a + certificate request message, the client must send either the + certificate message or a no_certificate alert. The client key + exchange message is now sent, and the content of that message will + depend on the public key algorithm selected between the client hello + and the server hello. If the client has sent a certificate with + signing ability, a digitally-signed certificate verify message is + sent to explicitly verify the certificate. + + At this point, a change cipher spec message is sent by the client, + and the client copies the pending CipherSpec into the current + CipherSpec. The client then immediately sends the finished message + under the new algorithms, keys, and secrets. In response, the server + will send its own change cipher spec message, transfer the pending to + the current CipherSpec, and send its finished message under the new + CipherSpec. At this point, the handshake is complete and the client + and server may begin to exchange application layer data. (See flow + chart below.) + + + + + + + +Freier, et al. Historic [Page 21] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + Client Server + + ClientHello --------> + ServerHello + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished --------> + [ChangeCipherSpec] + <-------- Finished + Application Data <-------> Application Data + + * Indicates optional or situation-dependent messages that are not + always sent. + + Note: To help avoid pipeline stalls, ChangeCipherSpec is an + independent SSL protocol content type, and is not actually an SSL + handshake message. + + When the client and server decide to resume a previous session or + duplicate an existing session (instead of negotiating new security + parameters) the message flow is as follows: + + The client sends a ClientHello using the session ID of the session to + be resumed. The server then checks its session cache for a match. + If a match is found, and the server is willing to re-establish the + connection under the specified session state, it will send a + ServerHello with the same session ID value. At this point, both + client and server must send change cipher spec messages and proceed + directly to finished messages. Once the re-establishment is + complete, the client and server may begin to exchange application + layer data. (See flow chart below.) If a session ID match is not + found, the server generates a new session ID and the SSL client and + server perform a full handshake. + + + + + + + + + + + + +Freier, et al. Historic [Page 22] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + Client Server + + ClientHello --------> + ServerHello + [change cipher spec] + <-------- Finished + change cipher spec + Finished --------> + Application Data <-------> Application Data + + + The contents and significance of each message will be presented in + detail in the following sections. + +5.6. Handshake Protocol + + The SSL handshake protocol is one of the defined higher level clients + of the SSL record protocol. This protocol is used to negotiate the + secure attributes of a session. Handshake messages are supplied to + the SSL record layer, where they are encapsulated within one or more + SSLPlaintext structures, which are processed and transmitted as + specified by the current active session state. + + enum { + hello_request(0), client_hello(1), server_hello(2), + certificate(11), server_key_exchange (12), + certificate_request(13), server_hello_done(14), + certificate_verify(15), client_key_exchange(16), + finished(20), (255) + } HandshakeType; + + struct { + HandshakeType msg_type; /* handshake type */ + uint24 length; /* bytes in message */ + select (HandshakeType) { + case hello_request: HelloRequest; + case client_hello: ClientHello; + case server_hello: ServerHello; + case certificate: Certificate; + case server_key_exchange: ServerKeyExchange; + case certificate_request: CertificateRequest; + case server_hello_done: ServerHelloDone; + case certificate_verify: CertificateVerify; + case client_key_exchange: ClientKeyExchange; + case finished: Finished; + } body; + } Handshake; + + + + +Freier, et al. Historic [Page 23] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + The handshake protocol messages are presented in the order they must + be sent; sending handshake messages in an unexpected order results in + a fatal error. + +5.6.1. Hello messages + + The hello phase messages are used to exchange security enhancement + capabilities between the client and server. When a new session + begins, the CipherSpec encryption, hash, and compression algorithms + are initialized to null. The current CipherSpec is used for + renegotiation messages. + +5.6.1.1. Hello Request + + The hello request message may be sent by the server at any time, but + will be ignored by the client if the handshake protocol is already + underway. It is a simple notification that the client should begin + the negotiation process anew by sending a client hello message when + convenient. + + Note: Since handshake messages are intended to have transmission + precedence over application data, it is expected that the negotiation + begin in no more than one or two times the transmission time of a + maximum-length application data message. + + After sending a hello request, servers should not repeat the request + until the subsequent handshake negotiation is complete. A client + that receives a hello request while in a handshake negotiation state + should simply ignore the message. + + The structure of a hello request message is as follows: + + struct { } HelloRequest; + +5.6.1.2. Client Hello + + When a client first connects to a server it is required to send the + client hello as its first message. The client can also send a client + hello in response to a hello request or on its own initiative in + order to renegotiate the security parameters in an existing + connection. The client hello message includes a random structure, + which is used later in the protocol. + + + + + + + + + +Freier, et al. Historic [Page 24] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + struct { + uint32 gmt_unix_time; + opaque random_bytes[28]; + } Random; + + gmt_unix_time: The current time and date in standard UNIX 32-bit + format according to the sender's internal clock. Clocks are not + required to be set correctly by the basic SSL protocol; higher + level or application protocols may define additional requirements. + + random_bytes: 28 bytes generated by a secure random number + generator. + + The client hello message includes a variable-length session + identifier. If not empty, the value identifies a session between the + same client and server whose security parameters the client wishes to + reuse. The session identifier may be from an earlier connection, + this connection, or another currently active connection. The second + option is useful if the client only wishes to update the random + structures and derived values of a connection, while the third option + makes it possible to establish several simultaneous independent + secure connections without repeating the full handshake protocol. + The actual contents of the SessionID are defined by the server. + + opaque SessionID<0..32>; + + Warning: Servers must not place confidential information in session + identifiers or let the contents of fake session identifiers cause any + breach of security. + + The CipherSuite list, passed from the client to the server in the + client hello message, contains the combinations of cryptographic + algorithms supported by the client in order of the client's + preference (first choice first). Each CipherSuite defines both a key + exchange algorithm and a CipherSpec. The server will select a cipher + suite or, if no acceptable choices are presented, return a handshake + failure alert and close the connection. + + uint8 CipherSuite[2]; /* Cryptographic suite selector */ + + The client hello includes a list of compression algorithms supported + by the client, ordered according to the client's preference. If the + server supports none of those specified by the client, the session + must fail. + + enum { null(0), (255) } CompressionMethod; + + Issue: Which compression methods to support is under investigation. + + + +Freier, et al. Historic [Page 25] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + The structure of the client hello is as follows. + + struct { + ProtocolVersion client_version; + Random random; + SessionID session_id; + CipherSuite cipher_suites<2..2^16-1>; + CompressionMethod compression_methods<1..2^8-1>; + } ClientHello; + + client_version: The version of the SSL protocol by which the client + wishes to communicate during this session. This should be the + most recent (highest valued) version supported by the client. For + this version of the specification, the version will be 3.0 (see + Appendix E for details about backward compatibility). + + random: A client-generated random structure. + + session_id: The ID of a session the client wishes to use for this + connection. This field should be empty if no session_id is + available or the client wishes to generate new security + parameters. + + cipher_suites: This is a list of the cryptographic options supported + by the client, sorted with the client's first preference first. + If the session_id field is not empty (implying a session + resumption request), this vector must include at least the + cipher_suite from that session. Values are defined in + Appendix A.6. + + compression_methods: This is a list of the compression methods + supported by the client, sorted by client preference. If the + session_id field is not empty (implying a session resumption + request), this vector must include at least the compression_method + from that session. All implementations must support + CompressionMethod.null. + + After sending the client hello message, the client waits for a server + hello message. Any other handshake message returned by the server + except for a hello request is treated as a fatal error. + + Implementation note: Application data may not be sent before a + finished message has been sent. Transmitted application data is + known to be insecure until a valid finished message has been + received. This absolute restriction is relaxed if there is a + current, non-null encryption on this connection. + + + + + +Freier, et al. Historic [Page 26] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + Forward compatibility note: In the interests of forward + compatibility, it is permitted for a client hello message to include + extra data after the compression methods. This data must be included + in the handshake hashes, but must otherwise be ignored. + +5.6.1.3. Server Hello + + The server processes the client hello message and responds with + either a handshake_failure alert or server hello message. + + struct { + ProtocolVersion server_version; + Random random; + SessionID session_id; + CipherSuite cipher_suite; + CompressionMethod compression_method; + } ServerHello; + + + server_version: This field will contain the lower of that suggested + by the client in the client hello and the highest supported by the + server. For this version of the specification, the version will + be 3.0 (see Appendix E for details about backward compatibility). + + random: This structure is generated by the server and must be + different from (and independent of) ClientHello.random. + + session_id: This is the identity of the session corresponding to + this connection. If the ClientHello.session_id was non-empty, the + server will look in its session cache for a match. If a match is + found and the server is willing to establish the new connection + using the specified session state, the server will respond with + the same value as was supplied by the client. This indicates a + resumed session and dictates that the parties must proceed + directly to the finished messages. Otherwise, this field will + contain a different value identifying the new session. The server + may return an empty session_id to indicate that the session will + not be cached and therefore cannot be resumed. + + cipher_suite: The single cipher suite selected by the server from + the list in ClientHello.cipher_suites. For resumed sessions, this + field is the value from the state of the session being resumed. + + compression_method: The single compression algorithm selected by the + server from the list in ClientHello.compression_methods. For + resumed sessions, this field is the value from the resumed session + state. + + + + +Freier, et al. Historic [Page 27] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +5.6.2. Server Certificate + + If the server is to be authenticated (which is generally the case), + the server sends its certificate immediately following the server + hello message. The certificate type must be appropriate for the + selected cipher suite's key exchange algorithm, and is generally an + X.509.v3 certificate (or a modified X.509 certificate in the case of + FORTEZZA(tm) [FOR]). The same message type will be used for the + client's response to a certificate request message. + + opaque ASN.1Cert<1..2^24-1>; + struct { + ASN.1Cert certificate_list<1..2^24-1>; + } Certificate; + + certificate_list: This is a sequence (chain) of X.509.v3 + certificates, ordered with the sender's certificate first followed + by any certificate authority certificates proceeding sequentially + upward. + + Note: PKCS #7 [PKCS7] is not used as the format for the certificate + vector because PKCS #6 [PKCS6] extended certificates are not used. + Also, PKCS #7 defines a Set rather than a Sequence, making the task + of parsing the list more difficult. + +5.6.3. Server Key Exchange Message + + The server key exchange message is sent by the server if it has no + certificate, has a certificate only used for signing (e.g., DSS [DSS] + certificates, signing-only RSA [RSA] certificates), or FORTEZZA KEA + key exchange is used. This message is not used if the server + certificate contains Diffie-Hellman [DH1] parameters. + + Note: According to current US export law, RSA moduli larger than 512 + bits may not be used for key exchange in software exported from the + US. With this message, larger RSA keys may be used as signature-only + certificates to sign temporary shorter RSA keys for key exchange. + + enum { rsa, diffie_hellman, fortezza_kea } + KeyExchangeAlgorithm; + + struct { + opaque rsa_modulus<1..2^16-1>; + opaque rsa_exponent<1..2^16-1>; + } ServerRSAParams; + + + + + + +Freier, et al. Historic [Page 28] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + rsa_modulus: The modulus of the server's temporary RSA key. + + rsa_exponent: The public exponent of the server's temporary RSA key. + + struct { + opaque dh_p<1..2^16-1>; + opaque dh_g<1..2^16-1>; + opaque dh_Ys<1..2^16-1>; + } ServerDHParams; /* Ephemeral DH parameters */ + + dh_p: The prime modulus used for the Diffie-Hellman operation. + + dh_g: The generator used for the Diffie-Hellman operation. + + dh_Ys: The server's Diffie-Hellman public value (gX mod p). + + struct { + opaque r_s [128]; + } ServerFortezzaParams; + + r_s: Server random number for FORTEZZA KEA (Key Exchange Algorithm). + + struct { + select (KeyExchangeAlgorithm) { + case diffie_hellman: + ServerDHParams params; + Signature signed_params; + case rsa: + ServerRSAParams params; + Signature signed_params; + case fortezza_kea: + ServerFortezzaParams params; + }; + } ServerKeyExchange; + + params: The server's key exchange parameters. + + signed_params: A hash of the corresponding params value, with the + signature appropriate to that hash applied. + + md5_hash: MD5(ClientHello.random + ServerHello.random + + ServerParams); + + + + + + + + + +Freier, et al. Historic [Page 29] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + sha_hash: SHA(ClientHello.random + ServerHello.random + + ServerParams); + + enum { anonymous, rsa, dsa } SignatureAlgorithm; + + digitally-signed struct { + select(SignatureAlgorithm) { + case anonymous: struct { }; + case rsa: + opaque md5_hash[16]; + opaque sha_hash[20]; + case dsa: + opaque sha_hash[20]; + }; + } Signature; + +5.6.4. Certificate Request + + A non-anonymous server can optionally request a certificate from the + client, if appropriate for the selected cipher suite. + + enum { + rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), + rsa_ephemeral_dh(5), dss_ephemeral_dh(6), fortezza_kea(20), + (255) + } ClientCertificateType; + + opaque DistinguishedName<1..2^16-1>; + + struct { + ClientCertificateType certificate_types<1..2^8-1>; + DistinguishedName certificate_authorities<3..2^16-1>; + } CertificateRequest; + + certificate_types: This field is a list of the types of certificates + requested, sorted in order of the server's preference. + + certificate_authorities: A list of the distinguished names of + acceptable certificate authorities. + + Note: DistinguishedName is derived from [X509]. + + Note: It is a fatal handshake_failure alert for an anonymous server + to request client identification. + + + + + + + +Freier, et al. Historic [Page 30] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +5.6.5. Server Hello Done + + The server hello done message is sent by the server to indicate the + end of the server hello and associated messages. After sending this + message, the server will wait for a client response. + + struct { } ServerHelloDone; + + Upon receipt of the server hello done message the client should + verify that the server provided a valid certificate if required and + check that the server hello parameters are acceptable. + +5.6.6. Client Certificate + + This is the first message the client can send after receiving a + server hello done message. This message is only sent if the server + requests a certificate. If no suitable certificate is available, the + client should send a no_certificate alert instead. This alert is + only a warning; however, the server may respond with a fatal + handshake failure alert if client authentication is required. Client + certificates are sent using the certificate defined in Section 5.6.2. + + Note: Client Diffie-Hellman certificates must match the server + specified Diffie-Hellman parameters. + +5.6.7. Client Key Exchange Message + + The choice of messages depends on which public key algorithm(s) has + (have) been selected. See Section 5.6.3 for the KeyExchangeAlgorithm + definition. + + struct { + select (KeyExchangeAlgorithm) { + case rsa: EncryptedPreMasterSecret; + case diffie_hellman: ClientDiffieHellmanPublic; + case fortezza_kea: FortezzaKeys; + } exchange_keys; + } ClientKeyExchange; + + The information to select the appropriate record structure is in the + pending session state (see Section 5.1). + + + + + + + + + + +Freier, et al. Historic [Page 31] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +5.6.7.1. RSA Encrypted Premaster Secret Message + + If RSA is being used for key agreement and authentication, the client + generates a 48-byte premaster secret, encrypts it under the public + key from the server's certificate or temporary RSA key from a server + key exchange message, and sends the result in an encrypted premaster + secret message. + + struct { + ProtocolVersion client_version; + opaque random[46]; + } PreMasterSecret; + + client_version: The latest (newest) version supported by the client. + This is used to detect version roll-back attacks. + + random: 46 securely-generated random bytes. + + struct { + public-key-encrypted PreMasterSecret pre_master_secret; + } EncryptedPreMasterSecret; + + pre_master_secret: This random value is generated by the client and + is used to generate the master secret, as specified in + Section 6.1. + +5.6.7.2. FORTEZZA Key Exchange Message + + Under FORTEZZA, the client derives a token encryption key (TEK) using + the FORTEZZA Key Exchange Algorithm (KEA). The client's KEA + calculation uses the public key in the server's certificate along + with private parameters in the client's token. The client sends + public parameters needed for the server to generate the TEK, using + its own private parameters. The client generates session keys, wraps + them using the TEK, and sends the results to the server. The client + generates IVs for the session keys and TEK and sends them also. The + client generates a random 48-byte premaster secret, encrypts it using + the TEK, and sends the result: + + + + + + + + + + + + + +Freier, et al. Historic [Page 32] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + struct { + opaque y_c<0..128>; + opaque r_c[128]; + opaque y_signature[40]; + opaque wrapped_client_write_key[12]; + opaque wrapped_server_write_key[12]; + opaque client_write_iv[24]; + opaque server_write_iv[24]; + opaque master_secret_iv[24]; + block-ciphered opaque encrypted_pre_master_secret[48]; + } FortezzaKeys; + + + y_signature: y_signature is the signature of the KEA public key, + signed with the client's DSS private key. + + y_c: The client's Yc value (public key) for the KEA calculation. If + the client has sent a certificate, and its KEA public key is + suitable, this value must be empty since the certificate already + contains this value. If the client sent a certificate without a + suitable public key, y_c is used and y_signature is the KEA public + key signed with the client's DSS private key. For this value to + be used, it must be between 64 and 128 bytes. + + r_c: The client's Rc value for the KEA calculation. + + wrapped_client_write_key: This is the client's write key, wrapped by + the TEK. + + wrapped_server_write_key: This is the server's write key, wrapped by + the TEK. + + client_write_iv: The IV for the client write key. + + server_write_iv: The IV for the server write key. + + master_secret_iv: This is the IV for the TEK used to encrypt the + premaster secret. + + pre_master_secret: A random value, generated by the client and used + to generate the master secret, as specified in Section 6.1. In + the above structure, it is encrypted using the TEK. + + + + + + + + + +Freier, et al. Historic [Page 33] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +5.6.7.3. Client Diffie-Hellman Public Value + + This structure conveys the client's Diffie-Hellman public value (Yc) + if it was not already included in the client's certificate. The + encoding used for Yc is determined by the enumerated + PublicValueEncoding. + + enum { implicit, explicit } PublicValueEncoding; + + implicit: If the client certificate already contains the public + value, then it is implicit and Yc does not need to be sent again. + + explicit: Yc needs to be sent. + + struct { + select (PublicValueEncoding) { + case implicit: struct { }; + case explicit: opaque dh_Yc<1..2^16-1>; + } dh_public; + } ClientDiffieHellmanPublic; + + dh_Yc: The client's Diffie-Hellman public value (Yc). + +5.6.8. Certificate Verify + + This message is used to provide explicit verification of a client + certificate. This message is only sent following any client + certificate that has signing capability (i.e., all certificates + except those containing fixed Diffie-Hellman parameters). + + struct { + Signature signature; + } CertificateVerify; + + CertificateVerify.signature.md5_hash + MD5(master_secret + pad_2 + + MD5(handshake_messages + master_secret + pad_1)); + Certificate.signature.sha_hash + SHA(master_secret + pad_2 + + SHA(handshake_messages + master_secret + pad_1)); + + pad_1: This is identical to the pad_1 defined in Section 5.2.3.1. + + pad_2: This is identical to the pad_2 defined in Section 5.2.3.1. + + Here, handshake_messages refers to all handshake messages starting at + client hello up to but not including this message. + + + + +Freier, et al. Historic [Page 34] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +5.6.9. Finished + + A finished message is always sent immediately after a change cipher + spec message to verify that the key exchange and authentication + processes were successful. The finished message is the first + protected with the just-negotiated algorithms, keys, and secrets. No + acknowledgment of the finished message is required; parties may begin + sending encrypted data immediately after sending the finished + message. Recipients of finished messages must verify that the + contents are correct. + + enum { client(0x434C4E54), server(0x53525652) } Sender; + + struct { + opaque md5_hash[16]; + opaque sha_hash[20]; + } Finished; + + md5_hash: MD5(master_secret + pad2 + MD5(handshake_messages + Sender + + master_secret + pad1)); + + sha_hash: SHA(master_secret + pad2 + SHA(handshake_messages + Sender + + master_secret + pad1)); + + handshake_messages: All of the data from all handshake messages up + to but not including this message. This is only data visible at + the handshake layer and does not include record layer headers. + + It is a fatal error if a finished message is not preceeded by a + change cipher spec message at the appropriate point in the handshake. + + The hash contained in finished messages sent by the server + incorporate Sender.server; those sent by the client incorporate + Sender.client. The value handshake_messages includes all handshake + messages starting at client hello up to but not including this + finished message. This may be different from handshake_messages in + Section 5.6.8 because it would include the certificate verify message + (if sent). + + Note: Change cipher spec messages are not handshake messages and are + not included in the hash computations. + + + + + + + + + + +Freier, et al. Historic [Page 35] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +5.7. Application Data Protocol + + Application data messages are carried by the record layer and are + fragmented, compressed, and encrypted based on the current connection + state. The messages are treated as transparent data to the record + layer. + +6. Cryptographic Computations + + The key exchange, authentication, encryption, and MAC algorithms are + determined by the cipher_suite selected by the server and revealed in + the server hello message. + +6.1. Asymmetric Cryptographic Computations + + The asymmetric algorithms are used in the handshake protocol to + authenticate parties and to generate shared keys and secrets. + + For Diffie-Hellman, RSA, and FORTEZZA, the same algorithm is used to + convert the pre_master_secret into the master_secret. The + pre_master_secret should be deleted from memory once the + master_secret has been computed. + + master_secret = + MD5(pre_master_secret + SHA('A' + pre_master_secret + + ClientHello.random + ServerHello.random)) + + MD5(pre_master_secret + SHA('BB' + pre_master_secret + + ClientHello.random + ServerHello.random)) + + MD5(pre_master_secret + SHA('CCC' + pre_master_secret + + ClientHello.random + ServerHello.random)); + +6.1.1. RSA + + When RSA is used for server authentication and key exchange, a 48- + byte pre_master_secret is generated by the client, encrypted under + the server's public key, and sent to the server. The server uses its + private key to decrypt the pre_master_secret. Both parties then + convert the pre_master_secret into the master_secret, as specified + above. + + RSA digital signatures are performed using PKCS #1 [PKCS1] block + type 1. RSA public key encryption is performed using PKCS #1 block + type 2. + + + + + + + + +Freier, et al. Historic [Page 36] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +6.1.2. Diffie-Hellman + + A conventional Diffie-Hellman computation is performed. The + negotiated key (Z) is used as the pre_master_secret, and is converted + into the master_secret, as specified above. + + Note: Diffie-Hellman parameters are specified by the server, and may + be either ephemeral or contained within the server's certificate. + +6.1.3. FORTEZZA + + A random 48-byte pre_master_secret is sent encrypted under the TEK + and its IV. The server decrypts the pre_master_secret and converts + it into a master_secret, as specified above. Bulk cipher keys and + IVs for encryption are generated by the client's token and exchanged + in the key exchange message; the master_secret is only used for MAC + computations. + +6.2. Symmetric Cryptographic Calculations and the CipherSpec + + The technique used to encrypt and verify the integrity of SSL records + is specified by the currently active CipherSpec. A typical example + would be to encrypt data using DES and generate authentication codes + using MD5. The encryption and MAC algorithms are set to + SSL_NULL_WITH_NULL_NULL at the beginning of the SSL handshake + protocol, indicating that no message authentication or encryption is + performed. The handshake protocol is used to negotiate a more secure + CipherSpec and to generate cryptographic keys. + +6.2.1. The Master Secret + + Before secure encryption or integrity verification can be performed + on records, the client and server need to generate shared secret + information known only to themselves. This value is a 48-byte + quantity called the master secret. The master secret is used to + generate keys and secrets for encryption and MAC computations. Some + algorithms, such as FORTEZZA, may have their own procedure for + generating encryption keys (the master secret is used only for MAC + computations in FORTEZZA). + +6.2.2. Converting the Master Secret into Keys and MAC Secrets + + The master secret is hashed into a sequence of secure bytes, which + are assigned to the MAC secrets, keys, and non-export IVs required by + the current CipherSpec (see Appendix A.7). CipherSpecs require a + client write MAC secret, a server write MAC secret, a client write + key, a server write key, a client write IV, and a server write IV, + which are generated from the master secret in that order. Unused + + + +Freier, et al. Historic [Page 37] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + values, such as FORTEZZA keys communicated in the KeyExchange + message, are empty. The following inputs are available to the key + definition process: + + opaque MasterSecret[48] + ClientHello.random + ServerHello.random + + When generating keys and MAC secrets, the master secret is used as an + entropy source, and the random values provide unencrypted salt + material and IVs for exportable ciphers. + + To generate the key material, compute + + key_block = + MD5(master_secret + SHA(`A' + master_secret + + ServerHello.random + + ClientHello.random)) + + MD5(master_secret + SHA(`BB' + master_secret + + ServerHello.random + + ClientHello.random)) + + MD5(master_secret + SHA(`CCC' + master_secret + + ServerHello.random + + ClientHello.random)) + [...]; + + until enough output has been generated. Then, the key_block is + partitioned as follows. + + client_write_MAC_secret[CipherSpec.hash_size] + server_write_MAC_secret[CipherSpec.hash_size] + client_write_key[CipherSpec.key_material] + server_write_key[CipherSpec.key_material] + client_write_IV[CipherSpec.IV_size] /* non-export ciphers */ + server_write_IV[CipherSpec.IV_size] /* non-export ciphers */ + + Any extra key_block material is discarded. + + Exportable encryption algorithms (for which CipherSpec.is_exportable + is true) require additional processing as follows to derive their + final write keys: + + final_client_write_key = MD5(client_write_key + + ClientHello.random + + ServerHello.random); + final_server_write_key = MD5(server_write_key + + ServerHello.random + + ClientHello.random); + + + + +Freier, et al. Historic [Page 38] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + Exportable encryption algorithms derive their IVs from the random + messages: + + client_write_IV = MD5(ClientHello.random + ServerHello.random); + server_write_IV = MD5(ServerHello.random + ClientHello.random); + + MD5 outputs are trimmed to the appropriate size by discarding the + least-significant bytes. + +6.2.2.1. Export Key Generation Example + + SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for + each of the two encryption keys and 16 bytes for each of the MAC + keys, for a total of 42 bytes of key material. MD5 produces 16 bytes + of output per call, so three calls to MD5 are required. The MD5 + outputs are concatenated into a 48-byte key_block with the first MD5 + call providing bytes zero through 15, the second providing bytes 16 + through 31, etc. The key_block is partitioned, and the write keys + are salted because this is an exportable encryption algorithm. + + client_write_MAC_secret = key_block[0..15] + server_write_MAC_secret = key_block[16..31] + client_write_key = key_block[32..36] + server_write_key = key_block[37..41] + final_client_write_key = MD5(client_write_key + + ClientHello.random + + ServerHello.random)[0..15]; + final_server_write_key = MD5(server_write_key + + ServerHello.random + + ClientHello.random)[0..15]; + client_write_IV = MD5(ClientHello.random + + ServerHello.random)[0..7]; + server_write_IV = MD5(ServerHello.random + + ClientHello.random)[0..7]; + +7. Security Considerations + + See Appendix F. + + + + + + + + + + + + + +Freier, et al. Historic [Page 39] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +8. Informative References + + [DH1] Diffie, W. and M. Hellman, "New Directions in + Cryptography", IEEE Transactions on Information Theory V. + IT-22, n. 6, pp. 74-84, June 1977. + + [SSL-2] Hickman, K., "The SSL Protocol", February 1995. + + [3DES] Tuchman, W., "Hellman Presents No Shortcut Solutions To + DES", IEEE Spectrum, v. 16, n. 7, pp 40-41, July 1979. + + [DES] ANSI X3.106, "American National Standard for Information + Systems-Data Link Encryption", American National + Standards Institute, 1983. + + [DSS] NIST FIPS PUB 186, "Digital Signature Standard", National + Institute of Standards and Technology U.S. Department of + Commerce, May 1994. + + [FOR] NSA X22, "FORTEZZA: Application Implementers Guide", + Document # PD4002103-1.01, April 1995. + + [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", + STD 9, RFC 959, October 1985. + + [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext + Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. + + [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol + Specification", STD 8, RFC 854, May 1983. + + [RFC1832] Srinivasan, R., "XDR: External Data Representation + Standard", RFC 1832, August 1995. + + + + + + + + + +Freier, et al. Historic [Page 40] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, + February 1997. + + [IDEA] Lai, X., "On the Design and Security of Block Ciphers", + ETH Series in Information Processing, v. 1, Konstanz: + Hartung-Gorre Verlag, 1992. + + [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard + version 1.5", November 1993. + + [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate + Syntax Standard version 1.5", November 1993. + + [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message + Syntax Standard version 1.5", November 1993. + + [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for + Obtaining Digital Signatures and Public-Key + Cryptosystems", Communications of the ACM v. 21, n. 2 pp. + 120-126., February 1978. + + [SCH] Schneier, B., "Applied Cryptography: Protocols, + Algorithms, and Source Code in C", John Wiley & Sons, + 1994. + + [SHA] NIST FIPS PUB 180-1, "Secure Hash Standard", May 1994. + + National Institute of Standards and Technology, U.S. + Department of Commerce, DRAFT + + [X509] CCITT, "The Directory - Authentication Framework", + Recommendation X.509 , 1988. + + [RSADSI] RSA Data Security, Inc., "Unpublished works". + + + + + + + + + + + + + + + + +Freier, et al. Historic [Page 41] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +Appendix A. Protocol Constant Values + + This section describes protocol types and constants. + +A.1. Record Layer + + struct { + uint8 major, minor; + } ProtocolVersion; + + ProtocolVersion version = { 3,0 }; + + 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; + + struct { + ContentType type; + ProtocolVersion version; + uint16 length; + opaque fragment[SSLCompressed.length]; + } SSLCompressed; + + struct { + ContentType type; + ProtocolVersion version; + uint16 length; + select (CipherSpec.cipher_type) { + case stream: GenericStreamCipher; + case block: GenericBlockCipher; + } fragment; + } SSLCiphertext; + + stream-ciphered struct { + opaque content[SSLCompressed.length]; + opaque MAC[CipherSpec.hash_size]; + } GenericStreamCipher; + + block-ciphered struct { + opaque content[SSLCompressed.length]; + + + +Freier, et al. Historic [Page 42] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + opaque MAC[CipherSpec.hash_size]; + uint8 padding[GenericBlockCipher.padding_length]; + uint8 padding_length; + } GenericBlockCipher; + +A.2. Change Cipher Specs Message + + struct { + enum { change_cipher_spec(1), (255) } type; + } ChangeCipherSpec; + +A.3. Alert Messages + + 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; + + + + + + + + + + + + + + + + +Freier, et al. Historic [Page 43] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +A.4. Handshake Protocol + + enum { + hello_request(0), client_hello(1), server_hello(2), + certificate(11), server_key_exchange (12), + certificate_request(13), server_done(14), + certificate_verify(15), client_key_exchange(16), + finished(20), (255) + } HandshakeType; + + struct { + HandshakeType msg_type; + uint24 length; + select (HandshakeType) { + case hello_request: HelloRequest; + case client_hello: ClientHello; + case server_hello: ServerHello; + case certificate: Certificate; + case server_key_exchange: ServerKeyExchange; + case certificate_request: CertificateRequest; + case server_done: ServerHelloDone; + case certificate_verify: CertificateVerify; + case client_key_exchange: ClientKeyExchange; + case finished: Finished; + } body; + } Handshake; + +A.4.1. Hello Messages + + struct { } HelloRequest; + + struct { + uint32 gmt_unix_time; + opaque random_bytes[28]; + } Random; + + opaque SessionID<0..32>; + + uint8 CipherSuite[2]; + + enum { null(0), (255) } CompressionMethod; + + struct { + ProtocolVersion client_version; + Random random; + SessionID session_id; + CipherSuite cipher_suites<0..2^16-1>; + CompressionMethod compression_methods<0..2^8-1>; + + + +Freier, et al. Historic [Page 44] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + } ClientHello; + + struct { + ProtocolVersion server_version; + Random random; + SessionID session_id; + CipherSuite cipher_suite; + CompressionMethod compression_method; + } ServerHello; + +A.4.2. Server Authentication and Key Exchange Messages + + opaque ASN.1Cert<2^24-1>; + + struct { + ASN.1Cert certificate_list<1..2^24-1>; + } Certificate; + + enum { rsa, diffie_hellman, fortezza_kea } KeyExchangeAlgorithm; + + struct { + opaque RSA_modulus<1..2^16-1>; + opaque RSA_exponent<1..2^16-1>; + } ServerRSAParams; + + struct { + opaque DH_p<1..2^16-1>; + opaque DH_g<1..2^16-1>; + opaque DH_Ys<1..2^16-1>; + } ServerDHParams; + + struct { + opaque r_s [128] + } ServerFortezzaParams + + struct { + select (KeyExchangeAlgorithm) { + case diffie_hellman: + ServerDHParams params; + Signature signed_params; + case rsa: + ServerRSAParams params; + Signature signed_params; + case fortezza_kea: + ServerFortezzaParams params; + }; + } ServerKeyExchange; + + + + +Freier, et al. Historic [Page 45] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + enum { anonymous, rsa, dsa } SignatureAlgorithm; + + digitally-signed struct { + select(SignatureAlgorithm) { + case anonymous: struct { }; + case rsa: + opaque md5_hash[16]; + opaque sha_hash[20]; + case dsa: + opaque sha_hash[20]; + }; + } Signature; + + + enum { + RSA_sign(1), DSS_sign(2), RSA_fixed_DH(3), + DSS_fixed_DH(4), RSA_ephemeral_DH(5), DSS_ephemeral_DH(6), + FORTEZZA_MISSI(20), (255) + } CertificateType; + + opaque DistinguishedName<1..2^16-1>; + + struct { + CertificateType certificate_types<1..2^8-1>; + DistinguishedName certificate_authorities<3..2^16-1>; + } CertificateRequest; + + struct { } ServerHelloDone; + +A.5. Client Authentication and Key Exchange Messages + + struct { + select (KeyExchangeAlgorithm) { + case rsa: EncryptedPreMasterSecret; + case diffie_hellman: DiffieHellmanClientPublicValue; + case fortezza_kea: FortezzaKeys; + } exchange_keys; + } ClientKeyExchange; + + struct { + ProtocolVersion client_version; + opaque random[46]; + } PreMasterSecret; + + struct { + public-key-encrypted PreMasterSecret pre_master_secret; + } EncryptedPreMasterSecret; + + + + +Freier, et al. Historic [Page 46] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + struct { + opaque y_c<0..128>; + opaque r_c[128]; + opaque y_signature[40]; + opaque wrapped_client_write_key[12]; + opaque wrapped_server_write_key[12]; + opaque client_write_iv[24]; + opaque server_write_iv[24]; + opaque master_secret_iv[24]; + opaque encrypted_preMasterSecret[48]; + } FortezzaKeys; + + enum { implicit, explicit } PublicValueEncoding; + + struct { + select (PublicValueEncoding) { + case implicit: struct {}; + case explicit: opaque DH_Yc<1..2^16-1>; + } dh_public; + } ClientDiffieHellmanPublic; + + struct { + Signature signature; + } CertificateVerify; + +A.5.1. Handshake Finalization Message + + struct { + opaque md5_hash[16]; + opaque sha_hash[20]; + } Finished; + +A.6. The CipherSuite + + The following values define the CipherSuite codes used in the client + hello and server hello messages. + + A CipherSuite defines a cipher specifications supported in SSL + version 3.0. + + CipherSuite SSL_NULL_WITH_NULL_NULL = { 0x00,0x00 }; + + The following CipherSuite definitions require that the server provide + an RSA certificate that can be used for key exchange. The server may + request either an RSA or a DSS signature-capable certificate in the + certificate request message. + + + + + +Freier, et al. Historic [Page 47] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + CipherSuite SSL_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; + CipherSuite SSL_RSA_WITH_NULL_SHA = { 0x00,0x02 }; + CipherSuite SSL_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; + CipherSuite SSL_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; + CipherSuite SSL_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; + CipherSuite SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; + CipherSuite SSL_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; + CipherSuite SSL_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; + CipherSuite SSL_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; + CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; + + The following CipherSuite definitions are used for server- + authenticated (and optionally client-authenticated) Diffie-Hellman. + DH denotes cipher suites in which the server's certificate contains + the Diffie-Hellman parameters signed by the certificate authority + (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman + parameters are signed by a DSS or RSA certificate, which has been + signed by the CA. The signing algorithm used is specified after the + DH or DHE parameter. In all cases, the client must have the same + type of certificate, and must use the Diffie-Hellman parameters + chosen by the server. + + CipherSuite SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; + CipherSuite SSL_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }; + CipherSuite SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; + CipherSuite SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; + CipherSuite SSL_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }; + CipherSuite SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; + CipherSuite SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; + CipherSuite SSL_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }; + CipherSuite SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; + CipherSuite SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; + CipherSuite SSL_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; + CipherSuite SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; + + The following cipher suites are used for completely anonymous Diffie- + Hellman communications in which neither party is authenticated. Note + that this mode is vulnerable to man-in-the-middle attacks and is + therefore strongly discouraged. + + CipherSuite SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; + CipherSuite SSL_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; + CipherSuite SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; + CipherSuite SSL_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; + CipherSuite SSL_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; + + + + + + +Freier, et al. Historic [Page 48] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + The final cipher suites are for the FORTEZZA token. + + CipherSuite SSL_FORTEZZA_KEA_WITH_NULL_SHA = { 0X00,0X1C }; + CipherSuite SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA = { 0x00,0x1D }; + CipherSuite SSL_FORTEZZA_KEA_WITH_RC4_128_SHA = { 0x00,0x1E }; + + Note: All cipher suites whose first byte is 0xFF are considered + private and can be used for defining local/experimental algorithms. + Interoperability of such types is a local matter. + +A.7. The CipherSpec + + A cipher suite identifies a CipherSpec. These structures are part of + the SSL session state. The CipherSpec includes: + + enum { stream, block } CipherType; + + enum { true, false } IsExportable; + + enum { null, rc4, rc2, des, 3des, des40, fortezza } + BulkCipherAlgorithm; + + enum { null, md5, sha } MACAlgorithm; + + struct { + BulkCipherAlgorithm bulk_cipher_algorithm; + MACAlgorithm mac_algorithm; + CipherType cipher_type; + IsExportable is_exportable + uint8 hash_size; + uint8 key_material; + uint8 IV_size; + } CipherSpec; + + + + + + + + + + + + + + + + + + +Freier, et al. Historic [Page 49] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +Appendix B. Glossary + + application protocol: An application protocol is a protocol that + normally layers directly on top of the transport layer (e.g., + TCP/IP [RFC0793]/[RFC0791]). Examples include HTTP [RFC1945], + TELNET [RFC0959], FTP [RFC0854], and SMTP. + + asymmetric cipher: See public key cryptography. + + authentication: Authentication is the ability of one entity to + determine the identity of another entity. + + block cipher: A block cipher is an algorithm that operates on + plaintext in groups of bits, called blocks. 64 bits is a typical + block size. + + bulk cipher: A symmetric encryption algorithm used to encrypt large + quantities of data. + + cipher block chaining (CBC) mode: CBC is a mode in which every + plaintext block encrypted with the block cipher is first + exclusive-ORed with the previous ciphertext block (or, in the case + of the first block, with the initialization vector). + + certificate: As part of the X.509 protocol (a.k.a. ISO + Authentication framework), certificates are assigned by a trusted + certificate authority and provide verification of a party's + identity and may also supply its public key. + + client: The application entity that initiates a connection to a + server. + + client write key: The key used to encrypt data written by the + client. + + client write MAC secret: The secret data used to authenticate data + written by the client. + + connection: A connection is a transport (in the OSI layering model + definition) that provides a suitable type of service. For SSL, + such connections are peer-to-peer relationships. The connections + are transient. Every connection is associated with one session. + + Data Encryption Standard (DES): DES is a very widely used symmetric + encryption algorithm. DES is a block cipher [DES] [3DES]. + + + + + + +Freier, et al. Historic [Page 50] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + Digital Signature Standard: (DSS) A standard for digital signing, + including the Digital Signature Algorithm, approved by the + National Institute of Standards and Technology, defined in NIST + FIPS PUB 186, "Digital Signature Standard," published May, 1994 by + the U.S. Dept. of Commerce. + + digital signatures: Digital signatures utilize public key + cryptography and one-way hash functions to produce a signature of + the data that can be authenticated, and is difficult to forge or + repudiate. + + FORTEZZA: A PCMCIA card that provides both encryption and digital + signing. + + handshake: An initial negotiation between client and server that + establishes the parameters of their transactions. + + Initialization Vector (IV): When a block cipher is used in CBC mode, + the initialization vector is exclusive-ORed with the first + plaintext block prior to encryption. + + IDEA: A 64-bit block cipher designed by Xuejia Lai and James Massey + [IDEA]. + + Message Authentication Code (MAC): A Message Authentication Code is + a one-way hash computed from a message and some secret data. Its + purpose is to detect if the message has been altered. + + master secret: Secure secret data used for generating encryption + keys, MAC secrets, and IVs. + + MD5: MD5 [RFC1321] is a secure hashing function that converts an + arbitrarily long data stream into a digest of fixed size. + + public key cryptography: A class of cryptographic techniques + employing two-key ciphers. Messages encrypted with the public key + can only be decrypted with the associated private key. + Conversely, messages signed with the private key can be verified + with the public key. + + one-way hash function: A one-way transformation that converts an + arbitrary amount of data into a fixed-length hash. It is + computationally hard to reverse the transformation or to find + collisions. MD5 and SHA are examples of one-way hash functions. + + + + + + + +Freier, et al. Historic [Page 51] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + RC2, RC4: Proprietary bulk ciphers from RSA Data Security, Inc. + (There is no good reference to these as they are unpublished + works; however, see [RSADSI]). RC2 is a block cipher and RC4 is a + stream cipher. + + RSA: A very widely used public key algorithm that can be used for + either encryption or digital signing. + + salt: Non-secret random data used to make export encryption keys + resist precomputation attacks. + + 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: An SSL session is an association between a client and a + server. Sessions are created by the handshake protocol. Sessions + define a set of cryptographic security parameters, which can be + shared among multiple connections. Sessions are used to avoid the + expensive negotiation of new security parameters for each + connection. + + session identifier: A session identifier is a value generated by a + server that identifies a particular session. + + server write key: The key used to encrypt data written by the + server. + + server write MAC secret: The secret data used to authenticate data + written by the server. + + SHA: The Secure Hash Algorithm is defined in FIPS PUB 180-1. It + produces a 20-byte output [SHA]. + + stream cipher: An encryption algorithm that converts a key into a + cryptographically strong keystream, which is then exclusive-ORed + with the plaintext. + + symmetric cipher: See bulk cipher. + + + + + + + + + + + + +Freier, et al. Historic [Page 52] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +Appendix C. CipherSuite Definitions + +CipherSuite Is Key Cipher Hash + Exportable Exchange + +SSL_NULL_WITH_NULL_NULL * NULL NULL NULL +SSL_RSA_WITH_NULL_MD5 * RSA NULL MD5 +SSL_RSA_WITH_NULL_SHA * RSA NULL SHA +SSL_RSA_EXPORT_WITH_RC4_40_MD5 * RSA_EXPORT RC4_40 MD5 +SSL_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 +SSL_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA +SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 * RSA_EXPORT RC2_CBC_40 MD5 +SSL_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA +SSL_RSA_EXPORT_WITH_DES40_CBC_SHA * RSA_EXPORT DES40_CBC SHA +SSL_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA +SSL_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA +SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA * DH_DSS_EXPORT DES40_CBC SHA +SSL_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA +SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA +SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA * DH_RSA_EXPORT DES40_CBC SHA +SSL_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA +SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA +SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC SHA +SSL_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA +SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA +SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC SHA +SSL_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA +SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA +SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 * DH_anon_EXPORT RC4_40 MD5 +SSL_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 +SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA DH_anon DES40_CBC SHA +SSL_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA +SSL_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA +SSL_FORTEZZA_KEA_WITH_NULL_SHA FORTEZZA_KEA NULL SHA +SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA FORTEZZA_KEA FORTEZZA_CBC SHA +SSL_FORTEZZA_KEA_WITH_RC4_128_SHA FORTEZZA_KEA RC4_128 SHA + + + + + + + + + + + + + + + +Freier, et al. Historic [Page 53] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + +----------------+------------------------------+-------------------+ + | Key Exchange | Description | Key Size Limit | + | Algorithm | | | + +----------------+------------------------------+-------------------+ + | DHE_DSS | Ephemeral DH with DSS | None | + | | signatures | | + | DHE_DSS_EXPORT | Ephemeral DH with DSS | DH = 512 bits | + | | signatures | | + | DHE_RSA | Ephemeral DH with RSA | None | + | | signatures | | + | DHE_RSA_EXPORT | Ephemeral DH with RSA | DH = 512 bits, | + | | signatures | RSA = none | + | DH_anon | Anonymous DH, no signatures | None | + | DH_anon_EXPORT | Anonymous DH, no signatures | DH = 512 bits | + | DH_DSS | DH with DSS-based | None | + | | certificates | | + | DH_DSS_EXPORT | DH with DSS-based | DH = 512 bits | + | | certificates | | + | DH_RSA | DH with RSA-based | None | + | | certificates | | + | DH_RSA_EXPORT | DH with RSA-based | DH = 512 bits, | + | | certificates | RSA = none | + | FORTEZZA_KEA | FORTEZZA KEA. Details | N/A | + | | unpublished | | + | NULL | No key exchange | N/A | + | RSA | RSA key exchange | None | + | RSA_EXPORT | RSA key exchange | RSA = 512 bits | + +----------------+------------------------------+-------------------+ + + Table 1 + + Key size limit: The key size limit gives the size of the largest + public key that can be legally used for encryption in cipher + suites that are exportable. + + + + + + + + + + + + + + + + + +Freier, et al. Historic [Page 54] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + +--------------+--------+-----+-------+-------+-------+------+------+ + | Cipher | Cipher | IsE | Key | Exp. | Effec | IV | Bloc | + | | Type | xpo | Mater | Key | tive | Size | k | + | | | rta | ial | Mater | Key | | Size | + | | | ble | | ial | Bits | | | + +--------------+--------+-----+-------+-------+-------+------+------+ + | NULL | Stream | * | 0 | 0 | 0 | 0 | N/A | + | FORTEZZA_CBC | Block | | NA | 12 | 96 | 20 | 8 | + | | | | (**) | (**) | (**) | (**) | | + | IDEA_CBC | Block | | 16 | 16 | 128 | 8 | 8 | + | RC2_CBC_40 | Block | * | 5 | 16 | 40 | 8 | 8 | + | RC4_40 | Stream | * | 5 | 16 | 40 | 0 | N/A | + | RC4_128 | Stream | | 16 | 16 | 128 | 0 | N/A | + | DES40_CBC | Block | * | 5 | 8 | 40 | 8 | 8 | + | DES_CBC | Block | | 8 | 8 | 56 | 8 | 8 | + | 3DES_EDE_CBC | Block | | 24 | 24 | 168 | 8 | 8 | + +--------------+--------+-----+-------+-------+-------+------+------+ + + * Indicates IsExportable is true. + ** FORTEZZA uses its own key and IV generation algorithms. + + Table 2 + + Key Material: The number of bytes from the key_block that are used + for generating the write keys. + + Expanded Key Material: The number of bytes actually fed into the + encryption algorithm. + + Effective Key Bits: How much entropy material is in the key material + being fed into the encryption routines. + + +---------------+-----------+--------------+ + | Hash Function | Hash Size | Padding Size | + +---------------+-----------+--------------+ + | NULL | 0 | 0 | + | MD5 | 16 | 48 | + | SHA | 20 | 40 | + +---------------+-----------+--------------+ + + Table 3 + + + + + + + + + + +Freier, et al. Historic [Page 55] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +Appendix D. Implementation Notes + + The SSL protocol cannot prevent many common security mistakes. This + section provides several recommendations to assist implementers. + +D.1. Temporary RSA Keys + + US export restrictions limit RSA keys used for encryption to 512 + bits, but do not place any limit on lengths of RSA keys used for + signing operations. Certificates often need to be larger than 512 + bits, since 512-bit RSA keys are not secure enough for high-value + transactions or for applications requiring long-term security. Some + certificates are also designated signing-only, in which case they + cannot be used for key exchange. + + When the public key in the certificate cannot be used for encryption, + the server signs a temporary RSA key, which is then exchanged. In + exportable applications, the temporary RSA key should be the maximum + allowable length (i.e., 512 bits). Because 512-bit RSA keys are + relatively insecure, they should be changed often. For typical + electronic commerce applications, it is suggested that keys be + changed daily or every 500 transactions, and more often if possible. + Note that while it is acceptable to use the same temporary key for + multiple transactions, it must be signed each time it is used. + + RSA key generation is a time-consuming process. In many cases, a + low-priority process can be assigned the task of key generation. + Whenever a new key is completed, the existing temporary key can be + replaced with the new one. + +D.2. Random Number Generation and Seeding + + SSL requires a cryptographically secure pseudorandom number generator + (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs + based on secure hash operations, most notably MD5 and/or SHA, are + acceptable, but cannot provide more security than the size of the + random number generator state. (For example, MD5-based PRNGs usually + provide 128 bits of state.) + + To estimate the amount of seed material being produced, add the + number of bits of unpredictable information in each seed byte. For + example, keystroke timing values taken from a PC-compatible's 18.2 Hz + timer provide 1 or 2 secure bits each, even though the total size of + the counter value is 16 bits or more. To seed a 128-bit PRNG, one + would thus require approximately 100 such timer values. + + + + + + +Freier, et al. Historic [Page 56] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + Note: The seeding functions in RSAREF and versions of BSAFE prior to + 3.0 are order independent. For example, if 1000 seed bits are + supplied, one at a time, in 1000 separate calls to the seed function, + the PRNG will end up in a state that depends only on the number of 0 + or 1 seed bits in the seed data (i.e., there are 1001 possible final + states). Applications using BSAFE or RSAREF must take extra care to + ensure proper seeding. + +D.3. Certificates and Authentication + + Implementations are responsible for verifying the integrity of + certificates and should generally support certificate revocation + messages. Certificates should always be verified to ensure proper + signing by a trusted certificate authority (CA). The selection and + addition of trusted CAs should be done very carefully. Users should + be able to view information about the certificate and root CA. + +D.4. CipherSuites + + SSL supports a range of key sizes and security levels, including some + that provide no or minimal security. A proper implementation will + probably not support many cipher suites. For example, 40-bit + encryption is easily broken, so implementations requiring strong + security should not allow 40-bit keys. Similarly, anonymous Diffie- + Hellman is strongly discouraged because it cannot prevent man-in-the- + middle attacks. Applications should also enforce minimum and maximum + key sizes. For example, certificate chains containing 512-bit RSA + keys or signatures are not appropriate for high-security + applications. + +D.5. FORTEZZA + + This section describes implementation details for cipher suites that + make use of the FORTEZZA hardware encryption system. + +D.5.1. Notes on Use of FORTEZZA Hardware + + A complete explanation of all issues regarding the use of FORTEZZA + hardware is outside the scope of this document. However, there are a + few special requirements of SSL that deserve mention. + + Because SSL is a full duplex protocol, two crypto states must be + maintained, one for reading and one for writing. There are also a + number of circumstances that can result in the crypto state in the + FORTEZZA card being lost. For these reasons, it's recommended that + the current crypto state be saved after processing a record, and + loaded before processing the next. + + + + +Freier, et al. Historic [Page 57] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + After the client generates the TEK, it also generates two message + encryption keys (MEKs), one for reading and one for writing. After + generating each of these keys, the client must generate a + corresponding IV and then save the crypto state. The client also + uses the TEK to generate an IV and encrypt the premaster secret. All + three IVs are sent to the server, along with the wrapped keys and the + encrypted premaster secret in the client key exchange message. At + this point, the TEK is no longer needed, and may be discarded. + + On the server side, the server uses the master IV and the TEK to + decrypt the premaster secret. It also loads the wrapped MEKs into + the card. The server loads both IVs to verify that the IVs match the + keys. However, since the card is unable to encrypt after loading an + IV, the server must generate a new IV for the server write key. This + IV is discarded. + + When encrypting the first encrypted record (and only that record), + the server adds 8 bytes of random data to the beginning of the + fragment. These 8 bytes are discarded by the client after + decryption. The purpose of this is to synchronize the state on the + client and server resulting from the different IVs. + +D.5.2. FORTEZZA Cipher Suites + + 5) FORTEZZA_NULL_WITH_NULL_SHA: Uses the full FORTEZZA key exchange, + including sending server and client write keys and IVs. + +D.5.3. FORTEZZA Session Resumption + + There are two possibilities for FORTEZZA session restart: 1) Never + restart a FORTEZZA session. 2) Restart a session with the previously + negotiated keys and IVs. + + Never restarting a FORTEZZA session: + + Clients who never restart FORTEZZA sessions should never send session + IDs that were previously used in a FORTEZZA session as part of the + ClientHello. Servers who never restart FORTEZZA sessions should + never send a previous session id on the ServerHello if the negotiated + session is FORTEZZA. + + Restart a session: + + You cannot restart FORTEZZA on a session that has never done a + complete FORTEZZA key exchange (that is, you cannot restart FORTEZZA + if the session was an RSA/RC4 session renegotiated for FORTEZZA). If + you wish to restart a FORTEZZA session, you must save the MEKs and + + + + +Freier, et al. Historic [Page 58] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + IVs from the initial key exchange for this session and reuse them for + any new connections on that session. This is not recommended, but it + is possible. + +Appendix E. Version 2.0 Backward Compatibility + + Version 3.0 clients that support version 2.0 servers must send + version 2.0 client hello messages [SSL-2]. Version 3.0 servers + should accept either client hello format. The only deviations from + the version 2.0 specification are the ability to specify a version + with a value of three and the support for more ciphering types in the + CipherSpec. + + Warning: The ability to send version 2.0 client hello messages will + be phased out with all due haste. Implementers should make every + effort to move forward as quickly as possible. Version 3.0 provides + better mechanisms for transitioning to newer versions. + + The following cipher specifications are carryovers from SSL version + 2.0. These are assumed to use RSA for key exchange and + authentication. + + V2CipherSpec SSL_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 }; + V2CipherSpec SSL_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 }; + V2CipherSpec SSL_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 }; + V2CipherSpec SSL_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 + = { 0x04,0x00,0x80 }; + V2CipherSpec SSL_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 }; + V2CipherSpec SSL_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 }; + V2CipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 }; + + Cipher specifications introduced in version 3.0 can be included in + version 2.0 client hello messages using the syntax below. Any + V2CipherSpec element with its first byte equal to zero will be + ignored by version 2.0 servers. Clients sending any of the above + V2CipherSpecs should also include the version 3.0 equivalent (see + Appendix A.6): + + V2CipherSpec (see Version 3.0 name) = { 0x00, CipherSuite }; + +E.1. Version 2 Client Hello + + The version 2.0 client hello message is presented below using this + document's presentation model. The true definition is still assumed + to be the SSL version 2.0 specification. + + + + + + +Freier, et al. Historic [Page 59] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + uint8 V2CipherSpec[3]; + + struct { + unit8 msg_type; + Version version; + uint16 cipher_spec_length; + uint16 session_id_length; + uint16 challenge_length; + V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length]; + opaque session_id[V2ClientHello.session_id_length]; + Random challenge; + } V2ClientHello; + + session msg_type: This field, in conjunction with the version field, + identifies a version 2 client hello message. The value should + equal one (1). + + version: The highest version of the protocol supported by the client + (equals ProtocolVersion.version; see Appendix A.1). + + cipher_spec_length: This field is the total length of the field + cipher_specs. It cannot be zero and must be a multiple of the + V2CipherSpec length (3). + + session_id_length: This field must have a value of either zero or + 16. If zero, the client is creating a new session. If 16, the + session_id field will contain the 16 bytes of session + identification. + + challenge_length: The length in bytes of the client's challenge to + the server to authenticate itself. This value must be 32. + + cipher_specs: This is a list of all CipherSpecs the client is + willing and able to use. There must be at least one CipherSpec + acceptable to the server. + + session_id: If this field's length is not zero, it will contain the + identification for a session that the client wishes to resume. + + challenge: The client's challenge to the server for the server to + identify itself is a (nearly) arbitrary length random. The + version 3.0 server will right justify the challenge data to become + the ClientHello.random data (padded with leading zeroes, if + necessary), as specified in this version 3.0 protocol. If the + length of the challenge is greater than 32 bytes, then only the + last 32 bytes are used. It is legitimate (but not necessary) for + a V3 server to reject a V2 ClientHello that has fewer than 16 + bytes of challenge data. + + + +Freier, et al. Historic [Page 60] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + Note: Requests to resume an SSL 3.0 session should use an SSL 3.0 + client hello. + +E.2. Avoiding Man-in-the-Middle Version Rollback + + When SSL version 3.0 clients fall back to version 2.0 compatibility + mode, they use special PKCS #1 block formatting. This is done so + that version 3.0 servers will reject version 2.0 sessions with + version 3.0-capable clients. + + When version 3.0 clients are in version 2.0 compatibility mode, they + set the right-hand (least-significant) 8 random bytes of the PKCS + padding (not including the terminal null of the padding) for the RSA + encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY + to 0x03 (the other padding bytes are random). After decrypting the + ENCRYPTED-KEY-DATA field, servers that support SSL 3.0 should issue + an error if these eight padding bytes are 0x03. Version 2.0 servers + receiving blocks padded in this manner will proceed normally. + +Appendix F. Security Analysis + + The SSL protocol is designed to establish a secure connection between + a client and a server communicating over an insecure channel. This + document makes several traditional assumptions, including that + attackers have substantial computational resources and cannot obtain + secret information from sources outside the protocol. Attackers are + assumed to have the ability to capture, modify, delete, replay, and + otherwise tamper with messages sent over the communication channel. + This appendix outlines how SSL has been designed to resist a variety + of attacks. + +F.1. Handshake Protocol + + The handshake protocol is responsible for selecting a CipherSpec and + generating a MasterSecret, which together comprise the primary + cryptographic parameters associated with a secure session. The + handshake protocol can also optionally authenticate parties who have + certificates signed by a trusted certificate authority. + +F.1.1. Authentication and Key Exchange + + SSL supports three authentication modes: authentication of both + parties, server authentication with an unauthenticated client, and + total anonymity. Whenever the server is authenticated, the channel + should be secure against man-in-the-middle attacks, but completely + anonymous sessions are inherently vulnerable to such attacks. + + + + + +Freier, et al. Historic [Page 61] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + Anonymous servers cannot authenticate clients, since the client + signature in the certificate verify message may require a server + certificate to bind the signature to a particular server. If the + server is authenticated, its certificate message must provide a valid + certificate chain leading to an acceptable certificate authority. + Similarly, authenticated clients must supply an acceptable + certificate to the server. Each party is responsible for verifying + that the other's certificate is valid and has not expired or been + revoked. + + The general goal of the key exchange process is to create a + pre_master_secret known to the communicating parties and not to + attackers. The pre_master_secret will be used to generate the + master_secret (see Section 6.1). The master_secret is required to + generate the finished messages, encryption keys, and MAC secrets (see + Sections 5.6.9 and 6.2.2). By sending a correct finished message, + parties thus prove that they know the correct pre_master_secret. + +F.1.1.1. Anonymous Key Exchange + + Completely anonymous sessions can be established using RSA, Diffie- + Hellman, or FORTEZZA for key exchange. With anonymous RSA, the + client encrypts a pre_master_secret with the server's uncertified + public key extracted from the server key exchange message. The + result is sent in a client key exchange message. Since eavesdroppers + do not know the server's private key, it will be infeasible for them + to decode the pre_master_secret. + + With Diffie-Hellman or FORTEZZA, the server's public parameters are + contained in the server key exchange message and the client's are + sent in the client key exchange message. Eavesdroppers who do not + know the private values should not be able to find the Diffie-Hellman + result (i.e., the pre_master_secret) or the FORTEZZA token encryption + key (TEK). + + Warning: Completely anonymous connections only provide protection + against passive eavesdropping. Unless an independent tamper-proof + channel is used to verify that the finished messages were not + replaced by an attacker, server authentication is required in + environments where active man-in-the-middle attacks are a concern. + +F.1.1.2. RSA Key Exchange and Authentication + + With RSA, key exchange and server authentication are combined. The + public key either may be contained in the server's certificate or may + be a temporary RSA key sent in a server key exchange message. When + temporary RSA keys are used, they are signed by the server's RSA or + DSS certificate. The signature includes the current + + + +Freier, et al. Historic [Page 62] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + ClientHello.random, so old signatures and temporary keys cannot be + replayed. Servers may use a single temporary RSA key for multiple + negotiation sessions. + + Note: The temporary RSA key option is useful if servers need large + certificates but must comply with government-imposed size limits on + keys used for key exchange. + + After verifying the server's certificate, the client encrypts a + pre_master_secret with the server's public key. By successfully + decoding the pre_master_secret and producing a correct finished + message, the server demonstrates that it knows the private key + corresponding to the server certificate. + + When RSA is used for key exchange, clients are authenticated using + the certificate verify message (see Section 5.6.8). The client signs + a value derived from the master_secret and all preceding handshake + messages. These handshake messages include the server certificate, + which binds the signature to the server, and ServerHello.random, + which binds the signature to the current handshake process. + +F.1.1.3. Diffie-Hellman Key Exchange with Authentication + + When Diffie-Hellman key exchange is used, the server either can + supply a certificate containing fixed Diffie-Hellman parameters or + can use the server key exchange message to send a set of temporary + Diffie-Hellman parameters signed with a DSS or RSA certificate. + Temporary parameters are hashed with the hello.random values before + signing to ensure that attackers do not replay old parameters. In + either case, the client can verify the certificate or signature to + ensure that the parameters belong to the server. + + If the client has a certificate containing fixed Diffie-Hellman + parameters, its certificate contains the information required to + complete the key exchange. Note that in this case, the client and + server will generate the same Diffie-Hellman result (i.e., + pre_master_secret) every time they communicate. To prevent the + pre_master_secret from staying in memory any longer than necessary, + it should be converted into the master_secret as soon as possible. + Client Diffie-Hellman parameters must be compatible with those + supplied by the server for the key exchange to work. + + If the client has a standard DSS or RSA certificate or is + unauthenticated, it sends a set of temporary parameters to the server + in the client key exchange message, then optionally uses a + certificate verify message to authenticate itself. + + + + + +Freier, et al. Historic [Page 63] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +F.1.1.4. FORTEZZA + + FORTEZZA's design is classified, but at the protocol level it is + similar to Diffie-Hellman with fixed public values contained in + certificates. The result of the key exchange process is the token + encryption key (TEK), which is used to wrap data encryption keys, + client write key, server write key, and master secret encryption key. + The data encryption keys are not derived from the pre_master_secret + because unwrapped keys are not accessible outside the token. The + encrypted pre_master_secret is sent to the server in a client key + exchange message. + +F.1.2. Version Rollback Attacks + + Because SSL version 3.0 includes substantial improvements over SSL + version 2.0, attackers may try to make version 3.0-capable clients + and servers fall back to version 2.0. This attack is occurring if + (and only if) two version 3.0-capable parties use an SSL 2.0 + handshake. + + Although the solution using non-random PKCS #1 block type 2 message + padding is inelegant, it provides a reasonably secure way for version + 3.0 servers to detect the attack. This solution is not secure + against attackers who can brute force the key and substitute a new + ENCRYPTED-KEY-DATA message containing the same key (but with normal + padding) before the application specified wait threshold has expired. + Parties concerned about attacks of this scale should not be using 40- + bit encryption keys anyway. Altering the padding of the least + significant 8 bytes of the PKCS padding does not impact security, + since this is essentially equivalent to increasing the input block + size by 8 bytes. + +F.1.3. Detecting Attacks against the Handshake Protocol + + An attacker might try to influence the handshake exchange to make the + parties select different encryption algorithms than they would + normally choose. Because many implementations will support 40-bit + exportable encryption and some may even support null encryption or + MAC algorithms, this attack is of particular concern. + + For this attack, an attacker must actively change one or more + handshake messages. If this occurs, the client and server will + compute different values for the handshake message hashes. As a + result, the parties will not accept each other's finished messages. + Without the master_secret, the attacker cannot repair the finished + messages, so the attack will be discovered. + + + + + +Freier, et al. Historic [Page 64] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +F.1.4. Resuming Sessions + + When a connection is established by resuming a session, new + ClientHello.random and ServerHello.random values are hashed with the + session's master_secret. Provided that the master_secret has not + been compromised and that the secure hash operations used to produce + the encryption keys and MAC secrets are secure, the connection should + be secure and effectively independent from previous connections. + Attackers cannot use known encryption keys or MAC secrets to + compromise the master_secret without breaking the secure hash + operations (which use both SHA and MD5). + + Sessions cannot be resumed unless both the client and server agree. + If either party suspects that the session may have been compromised, + or that certificates may have expired or been revoked, it should + force a full handshake. An upper limit of 24 hours is suggested for + session ID lifetimes, since an attacker who obtains a master_secret + may be able to impersonate the compromised party until the + corresponding session ID is retired. Applications that may be run in + relatively insecure environments should not write session IDs to + stable storage. + +F.1.5. MD5 and SHA + + SSL uses hash functions very conservatively. Where possible, both + MD5 and SHA are used in tandem to ensure that non-catastrophic flaws + in one algorithm will not break the overall protocol. + +F.2. Protecting Application Data + + The master_secret is hashed with the ClientHello.random and + ServerHello.random to produce unique data encryption keys and MAC + secrets for each connection. FORTEZZA encryption keys are generated + by the token, and are not derived from the master_secret. + + Outgoing data is protected with a MAC before transmission. To + prevent message replay or modification attacks, the MAC is computed + from the MAC secret, the sequence number, the message length, the + message contents, and two fixed-character strings. The message type + field is necessary to ensure that messages intended for one SSL + record layer client are not redirected to another. The sequence + number ensures that attempts to delete or reorder messages will be + detected. Since sequence numbers are 64 bits long, they should never + overflow. Messages from one party cannot be inserted into the + other's output, since they use independent MAC secrets. Similarly, + the server-write and client-write keys are independent so stream + cipher keys are used only once. + + + + +Freier, et al. Historic [Page 65] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + + If an attacker does break an encryption key, all messages encrypted + with it can be read. Similarly, compromise of a MAC key can make + message modification attacks possible. Because MACs are also + encrypted, message-alteration attacks generally require breaking the + encryption algorithm as well as the MAC. + + Note: MAC secrets may be larger than encryption keys, so messages can + remain tamper resistant even if encryption keys are broken. + +F.3. Final Notes + + For SSL to be able to provide a secure connection, both the client + and server systems, keys, and applications must be secure. In + addition, the implementation must be free of security errors. + + The system is only as strong as the weakest key exchange and + authentication algorithm supported, and only trustworthy + cryptographic functions should be used. Short public keys, 40-bit + bulk encryption keys, and anonymous servers should be used with great + caution. Implementations and users must be careful when deciding + which certificates and certificate authorities are acceptable; a + dishonest certificate authority can do tremendous damage. + +Appendix G. Acknowledgements + +G.1. Other Contributors + + Martin Abadi Robert Relyea + Digital Equipment Corporation Netscape Communications + ma@pa.dec.com relyea@netscape.com + + Taher Elgamal Jim Roskind + Netscape Communications Netscape Communications + elgamal@netscape.com jar@netscape.com + + Anil Gangolli Micheal J. Sabin, Ph.D. + Netscape Communications Consulting Engineer + gangolli@netscape.com msabin@netcom.com + + Kipp E.B. Hickman Tom Weinstein + Netscape Communications Netscape Communications + kipp@netscape.com tomw@netscape.com + + + + + + + + + +Freier, et al. Historic [Page 66] + +RFC 6101 The SSL Protocol Version 3.0 August 2011 + + +G.2. Early Reviewers + + Robert Baldwin Clyde Monma + RSA Data Security, Inc. Bellcore + baldwin@rsa.com clyde@bellcore.com + + George Cox Eric Murray + Intel Corporation ericm@lne.com + cox@ibeam.jf.intel.com + + Cheri Dowell Avi Rubin + Sun Microsystems Bellcore + cheri@eng.sun.com rubin@bellcore.com + + Stuart Haber Don Stephenson + Bellcore Sun Microsystems + stuart@bellcore.com don.stephenson@eng.sun.com + + Burt Kaliski Joe Tardo + RSA Data Security, Inc. General Magic + burt@rsa.com tardo@genmagic.com + +Authors' Addresses + + Alan O. Freier + Netscape Communications + + + Philip Karlton + Netscape Communications + + + Paul C. Kocher + Independent Consultant + + + + + + + + + + + + + + + + + +Freier, et al. Historic [Page 67] + |