< draft-ietf-tls-protocol | rfc2246.txt | |||
---|---|---|---|---|
Transport Layer Security Working Group Tim Dierks | ||||
INTERNET-DRAFT Certicom | ||||
Expires May 12, 1999 Christopher Allen | ||||
Certicom | ||||
November 12, 1998 | ||||
The TLS Protocol | Network Working Group T. Dierks | |||
Version 1.0 | Request for Comments: 2246 Certicom | |||
Category: Standards Track C. Allen | ||||
Certicom | ||||
January 1999 | ||||
<draft-ietf-tls-protocol-06.txt> | The TLS Protocol | |||
Version 1.0 | ||||
Status of this memo | Status of this Memo | |||
This document is an Internet-Draft. Internet-Drafts are working | This document specifies an Internet standards track protocol for the | |||
documents of the Internet Engineering Task Force (IETF), its areas, | Internet community, and requests discussion and suggestions for | |||
and its working groups. Note that other groups may also distribute | improvements. Please refer to the current edition of the "Internet | |||
working documents as Internet-Drafts. | Official Protocol Standards" (STD 1) for the standardization state | |||
and status of this protocol. Distribution of this memo is unlimited. | ||||
Internet-Drafts are draft documents valid for a maximum of six | Copyright Notice | |||
months and may be updated, replaced, or made obsolete by other | ||||
documents at any time. It is inappropriate to use Internet-Drafts as | ||||
reference material or to cite them other than as work in progress. | ||||
To learn the current status of any Internet-Draft, please check the | Copyright (C) The Internet Society (1999). All Rights Reserved. | |||
1id-abstracts.txt listing contained in the Internet Drafts Shadow | ||||
Directories on ftp.ietf.org (US East Coast), nic.nordu.net | ||||
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific | ||||
Rim). | ||||
Abstract | Abstract | |||
This document specifies Version 1.0 of the Transport Layer Security | This document specifies Version 1.0 of the Transport Layer Security | |||
(TLS) protocol. The TLS protocol provides communications privacy | (TLS) protocol. The TLS protocol provides communications privacy over | |||
over the Internet. The protocol allows client/server applications to | the Internet. The protocol allows client/server applications to | |||
communicate in a way that is designed to prevent eavesdropping, | communicate in a way that is designed to prevent eavesdropping, | |||
tampering, or message forgery. | tampering, or message forgery. | |||
Table of Contents | Table of Contents | |||
Status of this memo 1 | ||||
Abstract 1 | ||||
Table of Contents 2 | ||||
1. Introduction 3 | 1. Introduction 3 | |||
2. Goals 4 | 2. Goals 4 | |||
3. Goals of this document 5 | 3. Goals of this document 5 | |||
4. Presentation language 5 | 4. Presentation language 5 | |||
4.1. Basic block size 6 | 4.1. Basic block size 6 | |||
4.2. Miscellaneous 6 | 4.2. Miscellaneous 6 | |||
4.3. Vectors 6 | 4.3. Vectors 6 | |||
4.4. Numbers 7 | 4.4. Numbers 7 | |||
4.5. Enumerateds 7 | 4.5. Enumerateds 7 | |||
4.6. Constructed types 8 | 4.6. Constructed types 8 | |||
4.6.1. Variants 8 | 4.6.1. Variants 9 | |||
4.7. Cryptographic attributes 9 | 4.7. Cryptographic attributes 10 | |||
4.8. Constants 11 | 4.8. Constants 11 | |||
5. HMAC and the pseudorandom function 11 | 5. HMAC and the pseudorandom function 11 | |||
6. The TLS Record Protocol 13 | 6. The TLS Record Protocol 13 | |||
6.1. Connection states 13 | 6.1. Connection states 14 | |||
6.2. Record layer 16 | 6.2. Record layer 16 | |||
6.2.1. Fragmentation 16 | 6.2.1. Fragmentation 16 | |||
6.2.2. Record compression and decompression 17 | 6.2.2. Record compression and decompression 17 | |||
6.2.3. Record payload protection 17 | 6.2.3. Record payload protection 18 | |||
6.2.3.1. Null or standard stream cipher 18 | 6.2.3.1. Null or standard stream cipher 19 | |||
6.2.3.2. CBC block cipher 18 | 6.2.3.2. CBC block cipher 19 | |||
6.3. Key calculation 20 | 6.3. Key calculation 21 | |||
6.3.1. Export key generation example 21 | 6.3.1. Export key generation example 22 | |||
7. The TLS Handshake Protocol 22 | 7. The TLS Handshake Protocol 23 | |||
7.1. Change cipher spec protocol 22 | 7.1. Change cipher spec protocol 24 | |||
7.2. Alert protocol 23 | 7.2. Alert protocol 24 | |||
7.2.1. Closure alerts 24 | 7.2.1. Closure alerts 25 | |||
7.2.2. Error alerts 24 | 7.2.2. Error alerts 26 | |||
7.3. Handshake Protocol overview 27 | 7.3. Handshake Protocol overview 29 | |||
7.4. Handshake protocol 30 | 7.4. Handshake protocol 32 | |||
7.4.1. Hello messages 31 | 7.4.1. Hello messages 33 | |||
7.4.1.1. Hello request 31 | 7.4.1.1. Hello request 33 | |||
7.4.1.2. Client hello 31 | 7.4.1.2. Client hello 34 | |||
7.4.1.3. Server hello 34 | 7.4.1.3. Server hello 36 | |||
7.4.2. Server certificate 35 | 7.4.2. Server certificate 37 | |||
7.4.3. Server key exchange message 36 | 7.4.3. Server key exchange message 39 | |||
7.4.4. Certificate request 39 | 7.4.4. Certificate request 41 | |||
7.4.5. Server hello done 39 | 7.4.5. Server hello done 42 | |||
7.4.6. Client certificate 40 | 7.4.6. Client certificate 43 | |||
7.4.7. Client key exchange message 40 | 7.4.7. Client key exchange message 43 | |||
7.4.7.1. RSA encrypted premaster secret message 41 | 7.4.7.1. RSA encrypted premaster secret message 44 | |||
7.4.7.2. Client Diffie-Hellman public value 42 | 7.4.7.2. Client Diffie-Hellman public value 45 | |||
7.4.8. Certificate verify 42 | 7.4.8. Certificate verify 45 | |||
7.4.9. Finished 43 | 7.4.9. Finished 46 | |||
8. Cryptographic computations 44 | 8. Cryptographic computations 47 | |||
8.1. Computing the master secret 44 | 8.1. Computing the master secret 47 | |||
8.1.1. RSA 44 | 8.1.1. RSA 48 | |||
8.1.2. Diffie-Hellman 45 | 8.1.2. Diffie-Hellman 48 | |||
9. Mandatory Cipher Suites 45 | 9. Mandatory Cipher Suites 48 | |||
10. Application data protocol 45 | 10. Application data protocol 48 | |||
A. Protocol constant values 45 | A. Protocol constant values 49 | |||
A.1. Record layer 45 | A.1. Record layer 49 | |||
A.2. Change cipher specs message 46 | A.2. Change cipher specs message 50 | |||
A.3. Alert messages 46 | A.3. Alert messages 50 | |||
A.4. Handshake protocol 47 | A.4. Handshake protocol 51 | |||
A.4.1. Hello messages 48 | A.4.1. Hello messages 51 | |||
A.4.2. Server authentication and key exchange messages 48 | A.4.2. Server authentication and key exchange messages 52 | |||
A.4.3. Client authentication and key exchange messages 49 | A.4.3. Client authentication and key exchange messages 53 | |||
A.4.4. Handshake finalization message 50 | A.4.4. Handshake finalization message 54 | |||
A.5. The CipherSuite 50 | A.5. The CipherSuite 54 | |||
A.6. The Security Parameters 52 | A.6. The Security Parameters 56 | |||
B. Glossary 52 | B. Glossary 57 | |||
C. CipherSuite definitions 56 | C. CipherSuite definitions 61 | |||
D. Implementation Notes 58 | D. Implementation Notes 64 | |||
D.1. Temporary RSA keys 58 | D.1. Temporary RSA keys 64 | |||
D.2. Random Number Generation and Seeding 59 | D.2. Random Number Generation and Seeding 64 | |||
D.3. Certificates and authentication 59 | D.3. Certificates and authentication 65 | |||
D.4. CipherSuites 59 | D.4. CipherSuites 65 | |||
E. Backward Compatibility With SSL 60 | E. Backward Compatibility With SSL 66 | |||
E.1. Version 2 client hello 61 | E.1. Version 2 client hello 67 | |||
E.2. Avoiding man-in-the-middle version rollback 62 | E.2. Avoiding man-in-the-middle version rollback 68 | |||
F. Security analysis 62 | F. Security analysis 69 | |||
F.1. Handshake protocol 63 | F.1. Handshake protocol 69 | |||
F.1.1. Authentication and key exchange 63 | F.1.1. Authentication and key exchange 69 | |||
F.1.1.1. Anonymous key exchange 63 | F.1.1.1. Anonymous key exchange 69 | |||
F.1.1.2. RSA key exchange and authentication 64 | F.1.1.2. RSA key exchange and authentication 70 | |||
F.1.1.3. Diffie-Hellman key exchange with authentication 64 | F.1.1.3. Diffie-Hellman key exchange with authentication 71 | |||
F.1.2. Version rollback attacks 65 | F.1.2. Version rollback attacks 71 | |||
F.1.3. Detecting attacks against the handshake protocol 65 | F.1.3. Detecting attacks against the handshake protocol 72 | |||
F.1.4. Resuming sessions 65 | F.1.4. Resuming sessions 72 | |||
F.1.5. MD5 and SHA 66 | F.1.5. MD5 and SHA 72 | |||
F.2. Protecting application data 66 | F.2. Protecting application data 72 | |||
F.3. Final notes 66 | F.3. Final notes 73 | |||
G. Patent Statement 67 | G. Patent Statement 74 | |||
References 68 | Security Considerations 75 | |||
Credits 71 | References 75 | |||
Comments 72 | Credits 77 | |||
Comments 78 | ||||
Full Copyright Statement 80 | ||||
1. Introduction | 1. Introduction | |||
The primary goal of the TLS Protocol is to provide privacy and data | The primary goal of the TLS Protocol is to provide privacy and data | |||
integrity between two communicating applications. The protocol is | integrity between two communicating applications. The protocol is | |||
composed of two layers: the TLS Record Protocol and the TLS | composed of two layers: the TLS Record Protocol and the TLS Handshake | |||
Handshake Protocol. At the lowest level, layered on top of some | Protocol. At the lowest level, layered on top of some reliable | |||
reliable transport protocol (e.g., TCP[TCP]), is the TLS Record | transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The | |||
Protocol. The TLS Record Protocol provides connection security that | TLS Record Protocol provides connection security that has two basic | |||
has two basic properties: | properties: | |||
- The connection is private. Symmetric cryptography is used for | - The connection is private. Symmetric cryptography is used for | |||
data encryption (e.g., DES[DES], RC4[RC4], etc.) The keys for | data encryption (e.g., DES [DES], RC4 [RC4], etc.) The keys for | |||
this symmetric encryption are generated uniquely for each | this symmetric encryption are generated uniquely for each | |||
connection and are based on a secret negotiated by another | connection and are based on a secret negotiated by another | |||
protocol (such as the TLS Handshake Protocol). The Record | protocol (such as the TLS Handshake Protocol). The Record | |||
Protocol can also be used without encryption. | Protocol can also be used without encryption. | |||
- The connection is reliable. Message transport includes a message | - The connection is reliable. Message transport includes a message | |||
integrity check using a keyed MAC. Secure hash functions (e.g., | integrity check using a keyed MAC. Secure hash functions (e.g., | |||
SHA, MD5, etc.) are used for MAC computations. The Record | SHA, MD5, etc.) are used for MAC computations. The Record | |||
Protocol can operate without a MAC, but is generally only used | Protocol can operate without a MAC, but is generally only used in | |||
in this mode while another protocol is using the Record Protocol | this mode while another protocol is using the Record Protocol as | |||
as a transport for negotiating security parameters. | a transport for negotiating security parameters. | |||
The TLS Record Protocol is used for encapsulation of various higher | The TLS Record Protocol is used for encapsulation of various higher | |||
level protocols. One such encapsulated protocol, the TLS Handshake | level protocols. One such encapsulated protocol, the TLS Handshake | |||
Protocol, allows the server and client to authenticate each other | Protocol, allows the server and client to authenticate each other and | |||
and to negotiate an encryption algorithm and cryptographic keys | to negotiate an encryption algorithm and cryptographic keys before | |||
before the application protocol transmits or receives its first byte | the application protocol transmits or receives its first byte of | |||
of data. The TLS Handshake Protocol provides connection security | data. The TLS Handshake Protocol provides connection security that | |||
that has three basic properties: | has three basic properties: | |||
- The peer's identity can be authenticated using asymmetric, or | - The peer's identity can be authenticated using asymmetric, or | |||
public key, cryptography (e.g., RSA[RSA], DSS[DSS], etc.). This | public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This | |||
authentication can be made optional, but is generally required | authentication can be made optional, but is generally required | |||
for at least one of the peers. | for at least one of the peers. | |||
- The negotiation of a shared secret is secure: the negotiated | - The negotiation of a shared secret is secure: the negotiated | |||
secret is unavailable to eavesdroppers, and for any | secret is unavailable to eavesdroppers, and for any authenticated | |||
authenticated connection the secret cannot be obtained, even by | connection the secret cannot be obtained, even by an attacker who | |||
an attacker who can place himself in the middle of the | can place himself in the middle of the connection. | |||
connection. | ||||
- The negotiation is reliable: no attacker can modify the | - The negotiation is reliable: no attacker can modify the | |||
negotiation communication without being detected by the parties | negotiation communication without being detected by the parties | |||
to the communication. | to the communication. | |||
One advantage of TLS is that it is application protocol independent. | One advantage of TLS is that it is application protocol independent. | |||
Higher level protocols can layer on top of the TLS Protocol | Higher level protocols can layer on top of the TLS Protocol | |||
transparently. The TLS standard, however, does not specify how | transparently. The TLS standard, however, does not specify how | |||
protocols add security with TLS; the decisions on how to initiate | protocols add security with TLS; the decisions on how to initiate TLS | |||
TLS handshaking and how to interpret the authentication certificates | handshaking and how to interpret the authentication certificates | |||
exchanged are left up to the judgment of the designers and | exchanged are left up to the judgment of the designers and | |||
implementors of protocols which run on top of TLS. | implementors of protocols which run on top of TLS. | |||
2. Goals | 2. Goals | |||
The goals of TLS Protocol, in order of their priority, are: | The goals of TLS Protocol, in order of their priority, are: | |||
1. Cryptographic security: TLS should be used to establish a secure | 1. Cryptographic security: TLS should be used to establish a secure | |||
connection between two parties. | connection between two parties. | |||
2. Interoperability: Independent programmers should be able to | 2. Interoperability: Independent programmers should be able to | |||
develop applications utilizing TLS that will then be able to | develop applications utilizing TLS that will then be able to | |||
successfully exchange cryptographic parameters without knowledge | successfully exchange cryptographic parameters without knowledge | |||
of one another's code. | of one another's code. | |||
3. Extensibility: TLS seeks to provide a framework into which new | 3. Extensibility: TLS seeks to provide a framework into which new | |||
public key and bulk encryption methods can be incorporated as | public key and bulk encryption methods can be incorporated as | |||
necessary. This will also accomplish two sub-goals: to prevent | necessary. This will also accomplish two sub-goals: to prevent | |||
the need to create a new protocol (and risking the introduction | the need to create a new protocol (and risking the introduction | |||
of possible new weaknesses) and to avoid the need to implement | of possible new weaknesses) and to avoid the need to implement an | |||
an entire new security library. | entire new security library. | |||
4. Relative efficiency: Cryptographic operations tend to be highly | 4. Relative efficiency: Cryptographic operations tend to be highly | |||
CPU intensive, particularly public key operations. For this | CPU intensive, particularly public key operations. For this | |||
reason, the TLS protocol has incorporated an optional session | reason, the TLS protocol has incorporated an optional session | |||
caching scheme to reduce the number of connections that need to | caching scheme to reduce the number of connections that need to | |||
be established from scratch. Additionally, care has been taken | be established from scratch. Additionally, care has been taken to | |||
to reduce network activity. | reduce network activity. | |||
3. Goals of this document | 3. Goals of this document | |||
This document and the TLS protocol itself are based on the SSL 3.0 | This document and the TLS protocol itself are based on the SSL 3.0 | |||
Protocol Specification as published by Netscape. The differences | Protocol Specification as published by Netscape. The differences | |||
between this protocol and SSL 3.0 are not dramatic, but they are | between this protocol and SSL 3.0 are not dramatic, but they are | |||
significant enough that TLS 1.0 and SSL 3.0 do not interoperate | significant enough that TLS 1.0 and SSL 3.0 do not interoperate | |||
(although TLS 1.0 does incorporate a mechanism by which a TLS | (although TLS 1.0 does incorporate a mechanism by which a TLS | |||
implementation can back down to SSL 3.0). This document is intended | implementation can back down to SSL 3.0). This document is intended | |||
primarily for readers who will be implementing the protocol and | primarily for readers who will be implementing the protocol and those | |||
those doing cryptographic analysis of it. The specification has been | doing cryptographic analysis of it. The specification has been | |||
written with this in mind, and it is intended to reflect the needs | written with this in mind, and it is intended to reflect the needs of | |||
of those two groups. For that reason, many of the | those two groups. For that reason, many of the algorithm-dependent | |||
algorithm-dependent data structures and rules are included in the | data structures and rules are included in the body of the text (as | |||
body of the text (as opposed to in an appendix), providing easier | opposed to in an appendix), providing easier access to them. | |||
access to them. | ||||
This document is not intended to supply any details of service | This document is not intended to supply any details of service | |||
definition nor interface definition, although it does cover select | definition nor interface definition, although it does cover select | |||
areas of policy as they are required for the maintenance of solid | areas of policy as they are required for the maintenance of solid | |||
security. | security. | |||
4. Presentation language | 4. Presentation language | |||
This document deals with the formatting of data in an external | This document deals with the formatting of data in an external | |||
representation. The following very basic and somewhat casually | representation. The following very basic and somewhat casually | |||
defined presentation syntax will be used. The syntax draws from | defined presentation syntax will be used. The syntax draws from | |||
several sources in its structure. Although it resembles the | several sources in its structure. Although it resembles the | |||
programming language "C" in its syntax and XDR [XDR] in both its | programming language "C" in its syntax and XDR [XDR] in both its | |||
syntax and intent, it would be risky to draw too many parallels. The | syntax and intent, it would be risky to draw too many parallels. The | |||
purpose of this presentation language is to document TLS only, not | purpose of this presentation language is to document TLS only, not to | |||
to have general application beyond that particular goal. | have general application beyond that particular goal. | |||
4.1. Basic block size | 4.1. Basic block size | |||
The representation of all data items is explicitly specified. The | The representation of all data items is explicitly specified. The | |||
basic data block size is one byte (i.e. 8 bits). Multiple byte data | 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 | items are concatenations of bytes, from left to right, from top to | |||
bottom. From the bytestream a multi-byte item (a numeric in the | bottom. From the bytestream a multi-byte item (a numeric in the | |||
example) is formed (using C notation) by: | example) is formed (using C notation) by: | |||
value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | | value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | | |||
skipping to change at page 6, line 40 ¶ | skipping to change at page 6, line 40 ¶ | |||
A vector (single dimensioned array) is a stream of homogeneous data | A vector (single dimensioned array) is a stream of homogeneous data | |||
elements. The size of the vector may be specified at documentation | elements. The size of the vector may be specified at documentation | |||
time or left unspecified until runtime. In either case the length | time or left unspecified until runtime. In either case the length | |||
declares the number of bytes, not the number of elements, in the | 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 | vector. The syntax for specifying a new type T' that is a fixed | |||
length vector of type T is | length vector of type T is | |||
T T'[n]; | T T'[n]; | |||
Here T' occupies n bytes in the data stream, where n is a multiple | Here T' occupies n bytes in the data stream, where n is a multiple of | |||
of the size of T. The length of the vector is not included in the | the size of T. The length of the vector is not included in the | |||
encoded stream. | encoded stream. | |||
In the following example, Datum is defined to be three consecutive | In the following example, Datum is defined to be three consecutive | |||
bytes that the protocol does not interpret, while Data is three | bytes that the protocol does not interpret, while Data is three | |||
consecutive Datum, consuming a total of nine bytes. | consecutive Datum, consuming a total of nine bytes. | |||
opaque Datum[3]; /* three uninterpreted bytes */ | opaque Datum[3]; /* three uninterpreted bytes */ | |||
Datum Data[9]; /* 3 consecutive 3 byte vectors */ | Datum Data[9]; /* 3 consecutive 3 byte vectors */ | |||
Variable length vectors are defined by specifying a subrange of | Variable length vectors are defined by specifying a subrange of legal | |||
legal lengths, inclusively, using the notation <floor..ceiling>. | lengths, inclusively, using the notation <floor..ceiling>. When | |||
When encoded, the actual length precedes the vector's contents in | encoded, the actual length precedes the vector's contents in the byte | |||
the byte stream. The length will be in the form of a number | stream. The length will be in the form of a number consuming as many | |||
consuming as many bytes as required to hold the vector's specified | bytes as required to hold the vector's specified maximum (ceiling) | |||
maximum (ceiling) length. A variable length vector with an actual | length. A variable length vector with an actual length field of zero | |||
length field of zero is referred to as an empty vector. | is referred to as an empty vector. | |||
T T'<floor..ceiling>; | T T'<floor..ceiling>; | |||
In the following example, mandatory is a vector that must contain | 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 | between 300 and 400 bytes of type opaque. It can never be empty. The | |||
actual length field consumes two bytes, a uint16, sufficient to | actual length field consumes two bytes, a uint16, sufficient to | |||
represent the value 400 (see Section 4.4). On the other hand, longer | 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 | can represent up to 800 bytes of data, or 400 uint16 elements, and it | |||
it may be empty. Its encoding will include a two byte actual length | may be empty. Its encoding will include a two byte actual length | |||
field prepended to the vector. The length of an encoded vector must | field prepended to the vector. The length of an encoded vector must | |||
be an even multiple of the length of a single element (for example, | be an even multiple of the length of a single element (for example, a | |||
a 17 byte vector of uint16 would be illegal). | 17 byte vector of uint16 would be illegal). | |||
opaque mandatory<300..400>; | opaque mandatory<300..400>; | |||
/* length field is 2 bytes, cannot be empty */ | /* length field is 2 bytes, cannot be empty */ | |||
uint16 longer<0..800>; | uint16 longer<0..800>; | |||
/* zero to 400 16-bit unsigned integers */ | /* zero to 400 16-bit unsigned integers */ | |||
4.4. Numbers | 4.4. Numbers | |||
The basic numeric data type is an unsigned byte (uint8). All larger | The basic numeric data type is an unsigned byte (uint8). All larger | |||
numeric data types are formed from fixed length series of bytes | numeric data types are formed from fixed length series of bytes | |||
skipping to change at page 7, line 44 ¶ | skipping to change at page 7, line 51 ¶ | |||
All values, here and elsewhere in the specification, are stored in | All values, here and elsewhere in the specification, are stored in | |||
"network" or "big-endian" order; the uint32 represented by the hex | "network" or "big-endian" order; the uint32 represented by the hex | |||
bytes 01 02 03 04 is equivalent to the decimal value 16909060. | bytes 01 02 03 04 is equivalent to the decimal value 16909060. | |||
4.5. Enumerateds | 4.5. Enumerateds | |||
An additional sparse data type is available called enum. A field of | An additional sparse data type is available called enum. A field of | |||
type enum can only assume the values declared in the definition. | type enum can only assume the values declared in the definition. | |||
Each definition is a different type. Only enumerateds of the same | Each definition is a different type. Only enumerateds of the same | |||
type may be assigned or compared. Every element of an enumerated | type may be assigned or compared. Every element of an enumerated must | |||
must be assigned a value, as demonstrated in the following example. | be assigned a value, as demonstrated in the following example. Since | |||
Since the elements of the enumerated are not ordered, they can be | the elements of the enumerated are not ordered, they can be assigned | |||
assigned any unique value, in any order. | any unique value, in any order. | |||
enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te; | enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te; | |||
Enumerateds occupy as much space in the byte stream as would its | Enumerateds occupy as much space in the byte stream as would its | |||
maximal defined ordinal value. The following definition would cause | maximal defined ordinal value. The following definition would cause | |||
one byte to be used to carry fields of type Color. | one byte to be used to carry fields of type Color. | |||
enum { red(3), blue(5), white(7) } Color; | enum { red(3), blue(5), white(7) } Color; | |||
One may optionally specify a value without its associated tag to | One may optionally specify a value without its associated tag to | |||
force the width definition without defining a superfluous element. | force the width definition without defining a superfluous element. | |||
In the following example, Taste will consume two bytes in the data | In the following example, Taste will consume two bytes in the data | |||
stream but can only assume the values 1, 2 or 4. | stream but can only assume the values 1, 2 or 4. | |||
enum { sweet(1), sour(2), bitter(4), (32000) } Taste; | enum { sweet(1), sour(2), bitter(4), (32000) } Taste; | |||
The names of the elements of an enumeration are scoped within the | The names of the elements of an enumeration are scoped within the | |||
defined type. In the first example, a fully qualified reference to | defined type. In the first example, a fully qualified reference to | |||
the second element of the enumeration would be Color.blue. Such | the second element of the enumeration would be Color.blue. Such | |||
qualification is not required if the target of the assignment is | qualification is not required if the target of the assignment is well | |||
well specified. | specified. | |||
Color color = Color.blue; /* overspecified, legal */ | Color color = Color.blue; /* overspecified, legal */ | |||
Color color = blue; /* correct, type implicit */ | Color color = blue; /* correct, type implicit */ | |||
For enumerateds that are never converted to external representation, | For enumerateds that are never converted to external representation, | |||
the numerical information may be omitted. | the numerical information may be omitted. | |||
enum { low, medium, high } Amount; | enum { low, medium, high } Amount; | |||
4.6. Constructed types | 4.6. Constructed types | |||
skipping to change at page 8, line 42 ¶ | skipping to change at page 9, line 6 ¶ | |||
syntax for definition is much like that of C. | syntax for definition is much like that of C. | |||
struct { | struct { | |||
T1 f1; | T1 f1; | |||
T2 f2; | T2 f2; | |||
... | ... | |||
Tn fn; | Tn fn; | |||
} [[T]]; | } [[T]]; | |||
The fields within a structure may be qualified using the type's name | The fields within a structure may be qualified using the type's name | |||
using a syntax much like that available for enumerateds. For | using a syntax much like that available for enumerateds. For example, | |||
example, T.f2 refers to the second field of the previous | T.f2 refers to the second field of the previous declaration. | |||
declaration. Structure definitions may be embedded. | Structure definitions may be embedded. | |||
4.6.1. Variants | 4.6.1. Variants | |||
Defined structures may have variants based on some knowledge that is | Defined structures may have variants based on some knowledge that is | |||
available within the environment. The selector must be an enumerated | available within the environment. The selector must be an enumerated | |||
type that defines the possible variants the structure defines. There | type that defines the possible variants the structure defines. There | |||
must be a case arm for every element of the enumeration declared in | 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 | the select. The body of the variant structure may be given a label | |||
for reference. The mechanism by which the variant is selected at | for reference. The mechanism by which the variant is selected at | |||
runtime is not prescribed by the presentation language. | runtime is not prescribed by the presentation language. | |||
skipping to change at page 9, line 51 ¶ | skipping to change at page 10, line 16 ¶ | |||
is a narrowed type of a VariantRecord containing a variant_body of | is a narrowed type of a VariantRecord containing a variant_body of | |||
type V2. | type V2. | |||
4.7. Cryptographic attributes | 4.7. Cryptographic attributes | |||
The four cryptographic operations digital signing, stream cipher | The four cryptographic operations digital signing, stream cipher | |||
encryption, block cipher encryption, and public key encryption are | encryption, block cipher encryption, and public key encryption are | |||
designated digitally-signed, stream-ciphered, block-ciphered, and | designated digitally-signed, stream-ciphered, block-ciphered, and | |||
public-key-encrypted, respectively. A field's cryptographic | public-key-encrypted, respectively. A field's cryptographic | |||
processing is specified by prepending an appropriate key word | processing is specified by prepending an appropriate key word | |||
designation before the field's type specification. Cryptographic | designation before the field's type specification. Cryptographic keys | |||
keys are implied by the current session state (see Section 6.1). | are implied by the current session state (see Section 6.1). | |||
In digital signing, one-way hash functions are used as input for a | In digital signing, one-way hash functions are used as input for a | |||
signing algorithm. A digitally-signed element is encoded as an | signing algorithm. A digitally-signed element is encoded as an opaque | |||
opaque vector <0..2^16-1>, where the length is specified by the | vector <0..2^16-1>, where the length is specified by the signing | |||
signing algorithm and key. | algorithm and key. | |||
In RSA signing, a 36-byte structure of two hashes (one SHA and one | In RSA signing, a 36-byte structure of two hashes (one SHA and one | |||
MD5) is signed (encrypted with the private key). It is encoded with | MD5) is signed (encrypted with the private key). It is encoded with | |||
PKCS #1 block type 0 or type 1 as described in [PKCS1]. | PKCS #1 block type 0 or type 1 as described in [PKCS1]. | |||
In DSS, the 20 bytes of the SHA hash are run directly through the | In DSS, the 20 bytes of the SHA hash are run directly through the | |||
Digital Signing Algorithm with no additional hashing. This produces | Digital Signing Algorithm with no additional hashing. This produces | |||
two values, r and s. The DSS signature is an opaque vector, as | two values, r and s. The DSS signature is an opaque vector, as above, | |||
above, the contents of which are the DER encoding of: | the contents of which are the DER encoding of: | |||
Dss-Sig-Value ::= SEQUENCE { | Dss-Sig-Value ::= SEQUENCE { | |||
r INTEGER, | r INTEGER, | |||
s INTEGER | s INTEGER | |||
} | } | |||
In stream cipher encryption, the plaintext is exclusive-ORed with an | In stream cipher encryption, the plaintext is exclusive-ORed with an | |||
identical amount of output generated from a cryptographically-secure | identical amount of output generated from a cryptographically-secure | |||
keyed pseudorandom number generator. | keyed pseudorandom number generator. | |||
skipping to change at page 10, line 50 ¶ | skipping to change at page 11, line 20 ¶ | |||
stream-ciphered struct { | stream-ciphered struct { | |||
uint8 field1; | uint8 field1; | |||
uint8 field2; | uint8 field2; | |||
digitally-signed opaque hash[20]; | digitally-signed opaque hash[20]; | |||
} UserType; | } UserType; | |||
The contents of hash are used as input for the signing algorithm, | The contents of hash are used as input for the signing algorithm, | |||
then the entire structure is encrypted with a stream cipher. The | then the entire structure is encrypted with a stream cipher. The | |||
length of this structure, in bytes would be equal to 2 bytes for | length of this structure, in bytes would be equal to 2 bytes for | |||
field1 and field2, plus two bytes for the length of the signature, | field1 and field2, plus two bytes for the length of the signature, | |||
plus the length of the output of the signing algorithm. This is | plus the length of the output of the signing algorithm. This is known | |||
known due to the fact that the algorithm and key used for the | due to the fact that the algorithm and key used for the signing are | |||
signing are known prior to encoding or decoding this structure. | known prior to encoding or decoding this structure. | |||
4.8. Constants | 4.8. Constants | |||
Typed constants can be defined for purposes of specification by | Typed constants can be defined for purposes of specification by | |||
declaring a symbol of the desired type and assigning values to it. | declaring a symbol of the desired type and assigning values to it. | |||
Under-specified types (opaque, variable length vectors, and | Under-specified types (opaque, variable length vectors, and | |||
structures that contain opaque) cannot be assigned values. No fields | structures that contain opaque) cannot be assigned values. No fields | |||
of a multi-element structure or vector may be elided. | of a multi-element structure or vector may be elided. | |||
For example, | For example, | |||
struct { | struct { | |||
uint8 f1; | uint8 f1; | |||
uint8 f2; | uint8 f2; | |||
} Example1; | } Example1; | |||
Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */ | Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */ | |||
5. HMAC and the pseudorandom function | 5. HMAC and the pseudorandom function | |||
A number of operations in the TLS record and handshake layer | A number of operations in the TLS record and handshake layer required | |||
required a keyed MAC; this is a secure digest of some data protected | a keyed MAC; this is a secure digest of some data protected by a | |||
by a secret. Forging the MAC is infeasible without knowledge of the | secret. Forging the MAC is infeasible without knowledge of the MAC | |||
MAC secret. The construction we use for this operation is known as | secret. The construction we use for this operation is known as HMAC, | |||
HMAC, described in [HMAC]. | described in [HMAC]. | |||
HMAC can be used with a variety of different hash algorithms. TLS | HMAC can be used with a variety of different hash algorithms. TLS | |||
uses it in the handshake with two different algorithms: MD5 and | uses it in the handshake with two different algorithms: MD5 and SHA- | |||
SHA-1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret, | 1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret, | |||
data). Additional hash algorithms can be defined by cipher suites | data). Additional hash algorithms can be defined by cipher suites and | |||
and used to protect record data, but MD5 and SHA-1 are hard coded | used to protect record data, but MD5 and SHA-1 are hard coded into | |||
into the description of the handshaking for this version of the | the description of the handshaking for this version of the protocol. | |||
protocol. | ||||
In addition, a construction is required to do expansion of secrets | In addition, a construction is required to do expansion of secrets | |||
into blocks of data for the purposes of key generation or | into blocks of data for the purposes of key generation or validation. | |||
validation. This pseudo-random function (PRF) takes as input a | This pseudo-random function (PRF) takes as input a secret, a seed, | |||
secret, a seed, and an identifying label and produces an output of | and an identifying label and produces an output of arbitrary length. | |||
arbitrary length. | ||||
In order to make the PRF as secure as possible, it uses two hash | In order to make the PRF as secure as possible, it uses two hash | |||
algorithms in a way which should guarantee its security if either | algorithms in a way which should guarantee its security if either | |||
algorithm remains secure. | algorithm remains secure. | |||
First, we define a data expansion function, P_hash(secret, data) | First, we define a data expansion function, P_hash(secret, data) | |||
which uses a single hash function to expand a secret and seed into | which uses a single hash function to expand a secret and seed into an | |||
an arbitrary quantity of output: | arbitrary quantity of output: | |||
P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + | P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + | |||
HMAC_hash(secret, A(2) + seed) + | HMAC_hash(secret, A(2) + seed) + | |||
HMAC_hash(secret, A(3) + seed) + ... | HMAC_hash(secret, A(3) + seed) + ... | |||
Where + indicates concatenation. | Where + indicates concatenation. | |||
A() is defined as: | A() is defined as: | |||
A(0) = seed | A(0) = seed | |||
A(i) = HMAC_hash(secret, A(i-1)) | A(i) = HMAC_hash(secret, A(i-1)) | |||
skipping to change at page 12, line 25 ¶ | skipping to change at page 12, line 45 ¶ | |||
of the final iteration would then be discarded, leaving 64 bytes of | of the final iteration would then be discarded, leaving 64 bytes of | |||
output data. | output data. | |||
TLS's PRF is created by splitting the secret into two halves and | TLS's PRF is created by splitting the secret into two halves and | |||
using one half to generate data with P_MD5 and the other half to | using one half to generate data with P_MD5 and the other half to | |||
generate data with P_SHA-1, then exclusive-or'ing the outputs of | generate data with P_SHA-1, then exclusive-or'ing the outputs of | |||
these two expansion functions together. | these two expansion functions together. | |||
S1 and S2 are the two halves of the secret and each is the same | S1 and S2 are the two halves of the secret and each is the same | |||
length. S1 is taken from the first half of the secret, S2 from the | length. S1 is taken from the first half of the secret, S2 from the | |||
second half. Their length is created by rounding up the length of | second half. Their length is created by rounding up the length of the | |||
the overall secret divided by two; thus, if the original secret is | overall secret divided by two; thus, if the original secret is an odd | |||
an odd number of bytes long, the last byte of S1 will be the same as | number of bytes long, the last byte of S1 will be the same as the | |||
the first byte of S2. | first byte of S2. | |||
L_S = length in bytes of secret; | L_S = length in bytes of secret; | |||
L_S1 = L_S2 = ceil(L_S / 2); | L_S1 = L_S2 = ceil(L_S / 2); | |||
The secret is partitioned into two halves (with the possibility of | The secret is partitioned into two halves (with the possibility of | |||
one shared byte) as described above, S1 taking the first L_S1 bytes | one shared byte) as described above, S1 taking the first L_S1 bytes | |||
and S2 the last L_S2 bytes. | and S2 the last L_S2 bytes. | |||
The PRF is then defined as the result of mixing the two pseudorandom | The PRF is then defined as the result of mixing the two pseudorandom | |||
streams by exclusive-or'ing them together. | streams by exclusive-or'ing them together. | |||
PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR | PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR | |||
P_SHA-1(S2, label + seed); | P_SHA-1(S2, label + seed); | |||
The label is an ASCII string. It should be included in the exact | The label is an ASCII string. It should be included in the exact form | |||
form it is given without a length byte or trailing null character. | it is given without a length byte or trailing null character. For | |||
For example, the label "slithy toves" would be processed by hashing | example, the label "slithy toves" would be processed by hashing the | |||
the following bytes: | following bytes: | |||
73 6C 69 74 68 79 20 74 6F 76 65 73 | 73 6C 69 74 68 79 20 74 6F 76 65 73 | |||
Note that because MD5 produces 16 byte outputs and SHA-1 produces 20 | Note that because MD5 produces 16 byte outputs and SHA-1 produces 20 | |||
byte outputs, the boundaries of their internal iterations will not | byte outputs, the boundaries of their internal iterations will not be | |||
be aligned; to generate a 80 byte output will involve P_MD5 being | aligned; to generate a 80 byte output will involve P_MD5 being | |||
iterated through A(5), while P_SHA-1 will only iterate through A(4). | iterated through A(5), while P_SHA-1 will only iterate through A(4). | |||
6. The TLS Record Protocol | 6. The TLS Record Protocol | |||
The TLS Record Protocol is a layered protocol. At each layer, | The TLS Record Protocol is a layered protocol. At each layer, | |||
messages may include fields for length, description, and content. | messages may include fields for length, description, and content. | |||
The Record Protocol takes messages to be transmitted, fragments the | The Record Protocol takes messages to be transmitted, fragments the | |||
data into manageable blocks, optionally compresses the data, applies | data into manageable blocks, optionally compresses the data, applies | |||
a MAC, encrypts, and transmits the result. Received data is | a MAC, encrypts, and transmits the result. Received data is | |||
decrypted, verified, decompressed, and reassembled, then delivered | decrypted, verified, decompressed, and reassembled, then delivered to | |||
to higher level clients. | higher level clients. | |||
Four record protocol clients are described in this document: the | Four record protocol clients are described in this document: the | |||
handshake protocol, the alert protocol, the change cipher spec | handshake protocol, the alert protocol, the change cipher spec | |||
protocol, and the application data protocol. In order to allow | protocol, and the application data protocol. In order to allow | |||
extension of the TLS protocol, additional record types can be | extension of the TLS protocol, additional record types can be | |||
supported by the record protocol. Any new record types should | supported by the record protocol. Any new record types should | |||
allocate type values immediately beyond the ContentType values for | allocate type values immediately beyond the ContentType values for | |||
the four record types described here (see Appendix A.2). If a TLS | the four record types described here (see Appendix A.2). If a TLS | |||
implementation receives a record type it does not understand, it | implementation receives a record type it does not understand, it | |||
should just ignore it. Any protocol designed for use over TLS must | should just ignore it. Any protocol designed for use over TLS must be | |||
be carefully designed to deal with all possible attacks against it. | carefully designed to deal with all possible attacks against it. | |||
Note that because the type and length of a record are not protected | Note that because the type and length of a record are not protected | |||
by encryption, care should be take to minimize the value of traffic | by encryption, care should be take to minimize the value of traffic | |||
analysis of these values. | analysis of these values. | |||
6.1. Connection states | 6.1. Connection states | |||
A TLS connection state is the operating environment of the TLS | A TLS connection state is the operating environment of the TLS Record | |||
Record Protocol. It specifies a compression algorithm, encryption | Protocol. It specifies a compression algorithm, encryption algorithm, | |||
algorithm, and MAC algorithm. In addition, the parameters for these | and MAC algorithm. In addition, the parameters for these algorithms | |||
algorithms are known: the MAC secret and the bulk encryption keys | are known: the MAC secret and the bulk encryption keys and IVs for | |||
and IVs for the connection in both the read and the write | the connection in both the read and the write directions. Logically, | |||
directions. Logically, there are always four connection states | there are always four connection states outstanding: the current read | |||
outstanding: the current read and write states, and the pending read | and write states, and the pending read and write states. All records | |||
and write states. All records are processed under the current read | are processed under the current read and write states. The security | |||
and write states. The security parameters for the pending states can | parameters for the pending states can be set by the TLS Handshake | |||
be set by the TLS Handshake Protocol, and the Handshake Protocol can | Protocol, and the Handshake Protocol can selectively make either of | |||
selectively make either of the pending states current, in which case | the pending states current, in which case the appropriate current | |||
the appropriate current state is disposed of and replaced with the | state is disposed of and replaced with the pending state; the pending | |||
pending state; the pending state is then reinitialized to an empty | state is then reinitialized to an empty state. It is illegal to make | |||
state. It is illegal to make a state which has not been initialized | a state which has not been initialized with security parameters a | |||
with security parameters a current state. The initial current state | current state. The initial current state always specifies that no | |||
always specifies that no encryption, compression, or MAC will be | encryption, compression, or MAC will be used. | |||
used. | ||||
The security parameters for a TLS Connection read and write state | The security parameters for a TLS Connection read and write state are | |||
are set by providing the following values: | set by providing the following values: | |||
connection end | connection end | |||
Whether this entity is considered the "client" or the "server" | Whether this entity is considered the "client" or the "server" in | |||
in this connection. | this connection. | |||
bulk encryption algorithm | bulk encryption algorithm | |||
An algorithm to be used for bulk encryption. This specification | An algorithm to be used for bulk encryption. This specification | |||
includes the key size of this algorithm, how much of that key is | includes the key size of this algorithm, how much of that key is | |||
secret, whether it is a block or stream cipher, the block size | secret, whether it is a block or stream cipher, the block size of | |||
of the cipher (if appropriate), and whether it is considered an | the cipher (if appropriate), and whether it is considered an | |||
"export" cipher. | "export" cipher. | |||
MAC algorithm | MAC algorithm | |||
An algorithm to be used for message authentication. This | An algorithm to be used for message authentication. This | |||
specification includes the size of the hash which is returned by | specification includes the size of the hash which is returned by | |||
the MAC algorithm. | the MAC algorithm. | |||
compression algorithm | compression algorithm | |||
An algorithm to be used for data compression. This specification | An algorithm to be used for data compression. This specification | |||
must include all information the algorithm requires to do | must include all information the algorithm requires to do | |||
skipping to change at page 15, line 20 ¶ | skipping to change at page 15, line 50 ¶ | |||
The record layer will use the security parameters to generate the | The record layer will use the security parameters to generate the | |||
following six items: | following six items: | |||
client write MAC secret | client write MAC secret | |||
server write MAC secret | server write MAC secret | |||
client write key | client write key | |||
server write key | server write key | |||
client write IV (for block ciphers only) | client write IV (for block ciphers only) | |||
server write IV (for block ciphers only) | server write IV (for block ciphers only) | |||
The client write parameters are used by the server when receiving | The client write parameters are used by the server when receiving and | |||
and processing records and vice-versa. The algorithm used for | processing records and vice-versa. The algorithm used for generating | |||
generating these items from the security parameters is described in | these items from the security parameters is described in section 6.3. | |||
section 6.3. | ||||
Once the security parameters have been set and the keys have been | Once the security parameters have been set and the keys have been | |||
generated, the connection states can be instantiated by making them | generated, the connection states can be instantiated by making them | |||
the current states. These current states must be updated for each | the current states. These current states must be updated for each | |||
record processed. Each connection state includes the following | record processed. Each connection state includes the following | |||
elements: | elements: | |||
compression state | compression state | |||
The current state of the compression algorithm. | The current state of the compression algorithm. | |||
cipher state | cipher state | |||
The current state of the encryption algorithm. This will consist | The current state of the encryption algorithm. This will consist | |||
of the scheduled key for that connection. In addition, for block | of the scheduled key for that connection. In addition, for block | |||
ciphers running in CBC mode (the only mode specified for TLS), | ciphers running in CBC mode (the only mode specified for TLS), | |||
this will initially contain the IV for that connection state and | this will initially contain the IV for that connection state and | |||
be updated to contain the ciphertext of the last block encrypted | be updated to contain the ciphertext of the last block encrypted | |||
or decrypted as records are processed. For stream ciphers, this | or decrypted as records are processed. For stream ciphers, this | |||
will contain whatever the necessary state information is to | will contain whatever the necessary state information is to allow | |||
allow the stream to continue to encrypt or decrypt data. | the stream to continue to encrypt or decrypt data. | |||
MAC secret | MAC secret | |||
The MAC secret for this connection as generated above. | The MAC secret for this connection as generated above. | |||
sequence number | sequence number | |||
Each connection state contains a sequence number, which is | Each connection state contains a sequence number, which is | |||
maintained separately for read and write states. The sequence | maintained separately for read and write states. The sequence | |||
number must be set to zero whenever a connection state is made | number must be set to zero whenever a connection state is made | |||
the active state. Sequence numbers are of type uint64 and may | the active state. Sequence numbers are of type uint64 and may not | |||
not exceed 2^64-1. A sequence number is incremented after each | exceed 2^64-1. A sequence number is incremented after each | |||
record: specifically, the first record which is transmitted | record: specifically, the first record which is transmitted under | |||
under a particular connection state should use sequence number | a particular connection state should use sequence number 0. | |||
0. | ||||
6.2. Record layer | 6.2. Record layer | |||
The TLS Record Layer receives uninterpreted data from higher layers | The TLS Record Layer receives uninterpreted data from higher layers | |||
in non-empty blocks of arbitrary size. | in non-empty blocks of arbitrary size. | |||
6.2.1. Fragmentation | 6.2.1. Fragmentation | |||
The record layer fragments information blocks into TLSPlaintext | The record layer fragments information blocks into TLSPlaintext | |||
records carrying data in chunks of 2^14 bytes or less. Client | records carrying data in chunks of 2^14 bytes or less. Client message | |||
message boundaries are not preserved in the record layer (i.e., | boundaries are not preserved in the record layer (i.e., multiple | |||
multiple client messages of the same ContentType may be coalesced | client messages of the same ContentType may be coalesced into a | |||
into a single TLSPlaintext record, or a single message may be | single TLSPlaintext record, or a single message may be fragmented | |||
fragmented across several records). | across several records). | |||
struct { | struct { | |||
uint8 major, minor; | uint8 major, minor; | |||
} ProtocolVersion; | } ProtocolVersion; | |||
enum { | enum { | |||
change_cipher_spec(20), alert(21), handshake(22), | change_cipher_spec(20), alert(21), handshake(22), | |||
application_data(23), (255) | application_data(23), (255) | |||
} ContentType; | } ContentType; | |||
struct { | struct { | |||
ContentType type; | ContentType type; | |||
ProtocolVersion version; | ProtocolVersion version; | |||
uint16 length; | uint16 length; | |||
opaque fragment[TLSPlaintext.length]; | opaque fragment[TLSPlaintext.length]; | |||
skipping to change at page 17, line 7 ¶ | skipping to change at page 17, line 41 ¶ | |||
The application data. This data is transparent and treated as an | The application data. This data is transparent and treated as an | |||
independent block to be dealt with by the higher level protocol | independent block to be dealt with by the higher level protocol | |||
specified by the type field. | specified by the type field. | |||
Note: Data of different TLS Record layer content types may be | Note: Data of different TLS Record layer content types may be | |||
interleaved. Application data is generally of lower precedence | interleaved. Application data is generally of lower precedence | |||
for transmission than other content types. | for transmission than other content types. | |||
6.2.2. Record compression and decompression | 6.2.2. Record compression and decompression | |||
All records are compressed using the compression algorithm defined | All records are compressed using the compression algorithm defined in | |||
in the current session state. There is always an active compression | the current session state. There is always an active compression | |||
algorithm; however, initially it is defined as | algorithm; however, initially it is defined as | |||
CompressionMethod.null. The compression algorithm translates a | CompressionMethod.null. The compression algorithm translates a | |||
TLSPlaintext structure into a TLSCompressed structure. Compression | TLSPlaintext structure into a TLSCompressed structure. Compression | |||
functions are initialized with default state information whenever a | functions are initialized with default state information whenever a | |||
connection state is made active. | connection state is made active. | |||
Compression must be lossless and may not increase the content length | Compression must be lossless and may not increase the content length | |||
by more than 1024 bytes. If the decompression function encounters a | by more than 1024 bytes. If the decompression function encounters a | |||
TLSCompressed.fragment that would decompress to a length in excess | TLSCompressed.fragment that would decompress to a length in excess of | |||
of 2^14 bytes, it should report a fatal decompression failure error. | 2^14 bytes, it should report a fatal decompression failure error. | |||
struct { | struct { | |||
ContentType type; /* same as TLSPlaintext.type */ | ContentType type; /* same as TLSPlaintext.type */ | |||
ProtocolVersion version;/* same as TLSPlaintext.version */ | ProtocolVersion version;/* same as TLSPlaintext.version */ | |||
uint16 length; | uint16 length; | |||
opaque fragment[TLSCompressed.length]; | opaque fragment[TLSCompressed.length]; | |||
} TLSCompressed; | } TLSCompressed; | |||
length | length | |||
The length (in bytes) of the following TLSCompressed.fragment. | The length (in bytes) of the following TLSCompressed.fragment. | |||
skipping to change at page 18, line 45 ¶ | skipping to change at page 19, line 39 ¶ | |||
where "+" denotes concatenation. | where "+" denotes concatenation. | |||
seq_num | seq_num | |||
The sequence number for this record. | The sequence number for this record. | |||
hash | hash | |||
The hashing algorithm specified by | The hashing algorithm specified by | |||
SecurityParameters.mac_algorithm. | SecurityParameters.mac_algorithm. | |||
Note that the MAC is computed before encryption. The stream cipher | Note that the MAC is computed before encryption. The stream cipher | |||
encrypts the entire block, including the MAC. For stream ciphers | encrypts the entire block, including the MAC. For stream ciphers that | |||
that do not use a synchronization vector (such as RC4), the stream | do not use a synchronization vector (such as RC4), the stream cipher | |||
cipher state from the end of one record is simply used on the | state from the end of one record is simply used on the subsequent | |||
subsequent packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, | packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption | |||
encryption consists of the identity operation (i.e., the data is not | consists of the identity operation (i.e., the data is not encrypted | |||
encrypted and the MAC size is zero implying that no MAC is used). | and the MAC size is zero implying that no MAC is used). | |||
TLSCiphertext.length is TLSCompressed.length plus | TLSCiphertext.length is TLSCompressed.length plus | |||
CipherSpec.hash_size. | CipherSpec.hash_size. | |||
6.2.3.2. CBC block cipher | 6.2.3.2. CBC block cipher | |||
For block ciphers (such as RC2 or DES), the encryption and MAC | For block ciphers (such as RC2 or DES), the encryption and MAC | |||
functions convert TLSCompressed.fragment structures to and from | functions convert TLSCompressed.fragment structures to and from block | |||
block TLSCiphertext.fragment structures. | TLSCiphertext.fragment structures. | |||
block-ciphered struct { | block-ciphered struct { | |||
opaque content[TLSCompressed.length]; | opaque content[TLSCompressed.length]; | |||
opaque MAC[CipherSpec.hash_size]; | opaque MAC[CipherSpec.hash_size]; | |||
uint8 padding[GenericBlockCipher.padding_length]; | uint8 padding[GenericBlockCipher.padding_length]; | |||
uint8 padding_length; | uint8 padding_length; | |||
} GenericBlockCipher; | } GenericBlockCipher; | |||
The MAC is generated as described in Section 6.2.3.1. | The MAC is generated as described in Section 6.2.3.1. | |||
padding | padding | |||
Padding that is added to force the length of the plaintext to be | Padding that is added to force the length of the plaintext to be | |||
an integral multiple of the block cipher's block length. The | an integral multiple of the block cipher's block length. The | |||
padding may be any length up to 255 bytes long, as long as it | padding may be any length up to 255 bytes long, as long as it | |||
results in the TLSCiphertext.length being an integral multiple | results in the TLSCiphertext.length being an integral multiple of | |||
of the block length. Lengths longer than necessary might be | the block length. Lengths longer than necessary might be | |||
desirable to frustrate attacks on a protocol based on analysis | desirable to frustrate attacks on a protocol based on analysis of | |||
of the lengths of exchanged messages. Each uint8 in the padding | the lengths of exchanged messages. Each uint8 in the padding data | |||
data vector must be filled with the padding length value. | vector must be filled with the padding length value. | |||
padding_length | padding_length | |||
The padding length should be such that the total size of the | The padding length should be such that the total size of the | |||
GenericBlockCipher structure is a multiple of the cipher's block | GenericBlockCipher structure is a multiple of the cipher's block | |||
length. Legal values range from zero to 255, inclusive. This | length. Legal values range from zero to 255, inclusive. This | |||
length specifies the length of the padding field exclusive of | length specifies the length of the padding field exclusive of the | |||
the padding_length field itself. | padding_length field itself. | |||
The encrypted data length (TLSCiphertext.length) is one more than | The encrypted data length (TLSCiphertext.length) is one more than the | |||
the sum of TLSCompressed.length, CipherSpec.hash_size, and | sum of TLSCompressed.length, CipherSpec.hash_size, and | |||
padding_length. | padding_length. | |||
Example: If the block length is 8 bytes, the content length | Example: If the block length is 8 bytes, the content length | |||
(TLSCompressed.length) is 61 bytes, and the MAC length is 20 | (TLSCompressed.length) is 61 bytes, and the MAC length is 20 | |||
bytes, the length before padding is 82 bytes. Thus, the | bytes, the length before padding is 82 bytes. Thus, the | |||
padding length modulo 8 must be equal to 6 in order to make | padding length modulo 8 must be equal to 6 in order to make | |||
the total length an even multiple of 8 bytes (the block | the total length an even multiple of 8 bytes (the block | |||
length). The padding length can be 6, 14, 22, and so on, | length). The padding length can be 6, 14, 22, and so on, | |||
through 254. If the padding length were the minimum necessary, | through 254. If the padding length were the minimum necessary, | |||
6, the padding would be 6 bytes, each containing the value 6. | 6, the padding would be 6 bytes, each containing the value 6. | |||
Thus, the last 8 octets of the GenericBlockCipher before block | Thus, the last 8 octets of the GenericBlockCipher before block | |||
encryption would be xx 06 06 06 06 06 06 06, where xx is the | encryption would be xx 06 06 06 06 06 06 06, where xx is the | |||
last octet of the MAC. | last octet of the MAC. | |||
Note: With block ciphers in CBC mode (Cipher Block Chaining) the | Note: With block ciphers in CBC mode (Cipher Block Chaining) the | |||
initialization vector (IV) for the first record is generated | initialization vector (IV) for the first record is generated with | |||
with the other keys and secrets when the security parameters are | the other keys and secrets when the security parameters are set. | |||
set. The IV for subsequent records is the last ciphertext block | The IV for subsequent records is the last ciphertext block from | |||
from the previous record. | the previous record. | |||
6.3. Key calculation | 6.3. Key calculation | |||
The Record Protocol requires an algorithm to generate keys, IVs, and | The Record Protocol requires an algorithm to generate keys, IVs, and | |||
MAC secrets from the security parameters provided by the handshake | MAC secrets from the security parameters provided by the handshake | |||
protocol. | protocol. | |||
The master secret is hashed into a sequence of secure bytes, which | The master secret is hashed into a sequence of secure bytes, which | |||
are assigned to the MAC secrets, keys, and non-export IVs required | are assigned to the MAC secrets, keys, and non-export IVs required by | |||
by the current connection state (see Appendix A.6). CipherSpecs | the current connection state (see Appendix A.6). CipherSpecs require | |||
require a client write MAC secret, a server write MAC secret, a | a client write MAC secret, a server write MAC secret, a client write | |||
client write key, a server write key, a client write IV, and a | key, a server write key, a client write IV, and a server write IV, | |||
server write IV, which are generated from the master secret in that | which are generated from the master secret in that order. Unused | |||
order. Unused values are empty. | values are empty. | |||
When generating keys and MAC secrets, the master secret is used as | When generating keys and MAC secrets, the master secret is used as an | |||
an entropy source, and the random values provide unencrypted salt | entropy source, and the random values provide unencrypted salt | |||
material and IVs for exportable ciphers. | material and IVs for exportable ciphers. | |||
To generate the key material, compute | To generate the key material, compute | |||
key_block = PRF(SecurityParameters.master_secret, | key_block = PRF(SecurityParameters.master_secret, | |||
"key expansion", | "key expansion", | |||
SecurityParameters.server_random + | SecurityParameters.server_random + | |||
SecurityParameters.client_random); | SecurityParameters.client_random); | |||
until enough output has been generated. Then the key_block is | until enough output has been generated. Then the key_block is | |||
partitioned as follows: | partitioned as follows: | |||
client_write_MAC_secret[SecurityParameters.hash_size] | client_write_MAC_secret[SecurityParameters.hash_size] | |||
server_write_MAC_secret[SecurityParameters.hash_size] | server_write_MAC_secret[SecurityParameters.hash_size] | |||
client_write_key[SecurityParameters.key_material] | client_write_key[SecurityParameters.key_material_length] | |||
server_write_key[SecurityParameters.key_material] | server_write_key[SecurityParameters.key_material_length] | |||
client_write_IV[SecurityParameters.IV_size] | client_write_IV[SecurityParameters.IV_size] | |||
server_write_IV[SecurityParameters.IV_size] | server_write_IV[SecurityParameters.IV_size] | |||
The client_write_IV and server_write_IV are only generated for | The client_write_IV and server_write_IV are only generated for non- | |||
non-export block ciphers. For exportable block ciphers, the | export block ciphers. For exportable block ciphers, the | |||
initialization vectors are generated later, as described below. Any | initialization vectors are generated later, as described below. Any | |||
extra key_block material is discarded. | extra key_block material is discarded. | |||
Implementation note: | Implementation note: | |||
The cipher spec which is defined in this document which requires | The cipher spec which is defined in this document which requires | |||
the most material is 3DES_EDE_CBC_SHA: it requires 2 x 24 byte | the most material is 3DES_EDE_CBC_SHA: it requires 2 x 24 byte | |||
keys, 2 x 20 byte MAC secrets, and 2 x 8 byte IVs, for a total | keys, 2 x 20 byte MAC secrets, and 2 x 8 byte IVs, for a total of | |||
of 104 bytes of key material. | 104 bytes of key material. | |||
Exportable encryption algorithms (for which CipherSpec.is_exportable | Exportable encryption algorithms (for which CipherSpec.is_exportable | |||
is true) require additional processing as follows to derive their | is true) require additional processing as follows to derive their | |||
final write keys: | final write keys: | |||
final_client_write_key = | final_client_write_key = | |||
PRF(SecurityParameters.client_write_key, | PRF(SecurityParameters.client_write_key, | |||
"client write key", | "client write key", | |||
SecurityParameters.client_random + | SecurityParameters.client_random + | |||
SecurityParameters.server_random); | SecurityParameters.server_random); | |||
final_server_write_key = | final_server_write_key = | |||
PRF(SecurityParameters.server_write_key, | PRF(SecurityParameters.server_write_key, | |||
"server write key", | "server write key", | |||
SecurityParameters.client_random + | SecurityParameters.client_random + | |||
SecurityParameters.server_random); | SecurityParameters.server_random); | |||
Exportable encryption algorithms derive their IVs solely from the | Exportable encryption algorithms derive their IVs solely from the | |||
random values from the hello messages: | random values from the hello messages: | |||
iv_block = PRF("", "IV block", SecurityParameters.client_random | iv_block = PRF("", "IV block", SecurityParameters.client_random + | |||
+ | ||||
SecurityParameters.server_random); | SecurityParameters.server_random); | |||
The iv_block is partitioned into two initialization vectors as the | The iv_block is partitioned into two initialization vectors as the | |||
key_block was above: | key_block was above: | |||
client_write_IV[SecurityParameters.IV_size] | client_write_IV[SecurityParameters.IV_size] | |||
server_write_IV[SecurityParameters.IV_size] | server_write_IV[SecurityParameters.IV_size] | |||
Note that the PRF is used without a secret in this case: this just | Note that the PRF is used without a secret in this case: this just | |||
means that the secret has a length of zero bytes and contributes | means that the secret has a length of zero bytes and contributes | |||
skipping to change at page 22, line 12 ¶ | skipping to change at page 23, line 20 ¶ | |||
client_random + | client_random + | |||
server_random)[0..15] | server_random)[0..15] | |||
iv_block = PRF("", "IV block", client_random + | iv_block = PRF("", "IV block", client_random + | |||
server_random)[0..15] | server_random)[0..15] | |||
client_write_IV = iv_block[0..7] | client_write_IV = iv_block[0..7] | |||
server_write_IV = iv_block[8..15] | server_write_IV = iv_block[8..15] | |||
7. The TLS Handshake Protocol | 7. The TLS Handshake Protocol | |||
The TLS Handshake Protocol consists of a suite of three | The TLS Handshake Protocol consists of a suite of three sub-protocols | |||
sub-protocols which are used to allow peers to agree upon security | which are used to allow peers to agree upon security parameters for | |||
parameters for the record layer, authenticate themselves, | the record layer, authenticate themselves, instantiate negotiated | |||
instantiate negotiated security parameters, and report error | security parameters, and report error conditions to each other. | |||
conditions to each other. | ||||
The Handshake Protocol is responsible for negotiating a session, | The Handshake Protocol is responsible for negotiating a session, | |||
which consists of the following items: | which consists of the following items: | |||
session identifier | session identifier | |||
An arbitrary byte sequence chosen by the server to identify an | An arbitrary byte sequence chosen by the server to identify an | |||
active or resumable session state. | active or resumable session state. | |||
peer certificate | peer certificate | |||
X509v3[X509] certificate of the peer. This element of the state | X509v3 [X509] certificate of the peer. This element of the state | |||
may be null. | may be null. | |||
compression method | compression method | |||
The algorithm used to compress data prior to encryption. | The algorithm used to compress data prior to encryption. | |||
cipher spec | cipher spec | |||
Specifies the bulk data encryption algorithm (such as null, DES, | Specifies the bulk data encryption algorithm (such as null, DES, | |||
etc.) and a MAC algorithm (such as MD5 or SHA). It also defines | etc.) and a MAC algorithm (such as MD5 or SHA). It also defines | |||
cryptographic attributes such as the hash_size. (See Appendix | cryptographic attributes such as the hash_size. (See Appendix A.6 | |||
A.6 for formal definition) | for formal definition) | |||
master secret | master secret | |||
48-byte secret shared between the client and server. | 48-byte secret shared between the client and server. | |||
is resumable | is resumable | |||
A flag indicating whether the session can be used to initiate | A flag indicating whether the session can be used to initiate new | |||
new connections. | connections. | |||
These items are then used to create security parameters for use by | These items are then used to create security parameters for use by | |||
the Record Layer when protecting application data. Many connections | the Record Layer when protecting application data. Many connections | |||
can be instantiated using the same session through the resumption | can be instantiated using the same session through the resumption | |||
feature of the TLS Handshake Protocol. | feature of the TLS Handshake Protocol. | |||
7.1. Change cipher spec protocol | 7.1. Change cipher spec protocol | |||
The change cipher spec protocol exists to signal transitions in | The change cipher spec protocol exists to signal transitions in | |||
ciphering strategies. The protocol consists of a single message, | ciphering strategies. The protocol consists of a single message, | |||
which is encrypted and compressed under the current (not the | which is encrypted and compressed under the current (not the pending) | |||
pending) connection state. The message consists of a single byte of | connection state. The message consists of a single byte of value 1. | |||
value 1. | ||||
struct { | struct { | |||
enum { change_cipher_spec(1), (255) } type; | enum { change_cipher_spec(1), (255) } type; | |||
} ChangeCipherSpec; | } ChangeCipherSpec; | |||
The change cipher spec message is sent by both the client and server | The change cipher spec message is sent by both the client and server | |||
to notify the receiving party that subsequent records will be | to notify the receiving party that subsequent records will be | |||
protected under the newly negotiated CipherSpec and keys. Reception | protected under the newly negotiated CipherSpec and keys. Reception | |||
of this message causes the receiver to instruct the Record Layer to | of this message causes the receiver to instruct the Record Layer to | |||
immediately copy the read pending state into the read current state. | immediately copy the read pending state into the read current state. | |||
skipping to change at page 23, line 25 ¶ | skipping to change at page 24, line 37 ¶ | |||
the record layer to make the write pending state the write active | the record layer to make the write pending state the write active | |||
state. (See section 6.1.) The change cipher spec message is sent | state. (See section 6.1.) The change cipher spec message is sent | |||
during the handshake after the security parameters have been agreed | during the handshake after the security parameters have been agreed | |||
upon, but before the verifying finished message is sent (see section | upon, but before the verifying finished message is sent (see section | |||
7.4.9). | 7.4.9). | |||
7.2. Alert protocol | 7.2. Alert protocol | |||
One of the content types supported by the TLS Record layer is the | One of the content types supported by the TLS Record layer is the | |||
alert type. Alert messages convey the severity of the message and a | alert type. Alert messages convey the severity of the message and a | |||
description of the alert. Alert messages with a level of fatal | description of the alert. Alert messages with a level of fatal result | |||
result in the immediate termination of the connection. In this case, | in the immediate termination of the connection. In this case, other | |||
other connections corresponding to the session may continue, but the | connections corresponding to the session may continue, but the | |||
session identifier must be invalidated, preventing the failed | session identifier must be invalidated, preventing the failed session | |||
session from being used to establish new connections. Like other | from being used to establish new connections. Like other messages, | |||
messages, alert messages are encrypted and compressed, as specified | alert messages are encrypted and compressed, as specified by the | |||
by the current connection state. | current connection state. | |||
enum { warning(1), fatal(2), (255) } AlertLevel; | enum { warning(1), fatal(2), (255) } AlertLevel; | |||
enum { | enum { | |||
close_notify(0), | close_notify(0), | |||
unexpected_message(10), | unexpected_message(10), | |||
bad_record_mac(20), | bad_record_mac(20), | |||
decryption_failed(21), | decryption_failed(21), | |||
record_overflow(22), | record_overflow(22), | |||
decompression_failure(30), | decompression_failure(30), | |||
skipping to change at page 24, line 16 ¶ | skipping to change at page 25, line 32 ¶ | |||
(255) | (255) | |||
} AlertDescription; | } AlertDescription; | |||
struct { | struct { | |||
AlertLevel level; | AlertLevel level; | |||
AlertDescription description; | AlertDescription description; | |||
} Alert; | } Alert; | |||
7.2.1. Closure alerts | 7.2.1. Closure alerts | |||
The client and the server must share knowledge that the connection | The client and the server must share knowledge that the connection is | |||
is ending in order to avoid a truncation attack. Either party may | ending in order to avoid a truncation attack. Either party may | |||
initiate the exchange of closing messages. | initiate the exchange of closing messages. | |||
close_notify | close_notify | |||
This message notifies the recipient that the sender will not | This message notifies the recipient that the sender will not send | |||
send any more messages on this connection. The session becomes | any more messages on this connection. The session becomes | |||
unresumable if any connection is terminated without proper | unresumable if any connection is terminated without proper | |||
close_notify messages with level equal to warning. | close_notify messages with level equal to warning. | |||
Either party may initiate a close by sending a close_notify alert. | Either party may initiate a close by sending a close_notify alert. | |||
Any data received after a closure alert is ignored. | Any data received after a closure alert is ignored. | |||
Each party is required to send a close_notify alert before closing | Each party is required to send a close_notify alert before closing | |||
the write side of the connection. It is required that the other | the write side of the connection. It is required that the other party | |||
party respond with a close_notify alert of its own and close down | respond with a close_notify alert of its own and close down the | |||
the connection immediately, discarding any pending writes. It is not | connection immediately, discarding any pending writes. It is not | |||
required for the initiator of the close to wait for the responding | required for the initiator of the close to wait for the responding | |||
close_notify alert before closing the read side of the connection. | close_notify alert before closing the read side of the connection. | |||
If the application protocol using TLS provides that any data may be | If the application protocol using TLS provides that any data may be | |||
carried over the underlying transport after the TLS connection is | carried over the underlying transport after the TLS connection is | |||
closed, the TLS implementation must receive the responding | closed, the TLS implementation must receive the responding | |||
close_notify alert before indicating to the application layer that | close_notify alert before indicating to the application layer that | |||
the TLS connection has ended. If the application protocol will not | the TLS connection has ended. If the application protocol will not | |||
transfer any additional data, but will only close the underlying | transfer any additional data, but will only close the underlying | |||
transport connection, then the implementation may choose to close | transport connection, then the implementation may choose to close the | |||
the transport without waiting for the responding close_notify. No | transport without waiting for the responding close_notify. No part of | |||
part of this standard should be taken to dictate the manner in which | this standard should be taken to dictate the manner in which a usage | |||
a usage profile for TLS manages its data transport, including when | profile for TLS manages its data transport, including when | |||
connections are opened or closed. | connections are opened or closed. | |||
NB: It is assumed that closing a connection reliably delivers | NB: It is assumed that closing a connection reliably delivers | |||
pending data before destroying the transport. | pending data before destroying the transport. | |||
7.2.2. Error alerts | 7.2.2. Error alerts | |||
Error handling in the TLS Handshake protocol is very simple. When an | Error handling in the TLS Handshake protocol is very simple. When an | |||
error is detected, the detecting party sends a message to the other | error is detected, the detecting party sends a message to the other | |||
party. Upon transmission or receipt of an fatal alert message, both | party. Upon transmission or receipt of an fatal alert message, both | |||
parties immediately close the connection. Servers and clients are | parties immediately close the connection. Servers and clients are | |||
required to forget any session-identifiers, keys, and secrets | required to forget any session-identifiers, keys, and secrets | |||
associated with a failed connection. The following error alerts are | associated with a failed connection. The following error alerts are | |||
defined: | defined: | |||
unexpected_message | unexpected_message | |||
An inappropriate message was received. This alert is always | An inappropriate message was received. This alert is always fatal | |||
fatal and should never be observed in communication between | and should never be observed in communication between proper | |||
proper implementations. | implementations. | |||
bad_record_mac | bad_record_mac | |||
This alert is returned if a record is received with an incorrect | This alert is returned if a record is received with an incorrect | |||
MAC. This message is always fatal. | MAC. This message is always fatal. | |||
decryption_failed | decryption_failed | |||
A TLSCiphertext decrypted in an invalid way: either it wasn`t an | A TLSCiphertext decrypted in an invalid way: either it wasn`t an | |||
even multiple of the block length or its padding values, when | even multiple of the block length or its padding values, when | |||
checked, weren`t correct. This message is always fatal. | checked, weren`t correct. This message is always fatal. | |||
skipping to change at page 25, line 34 ¶ | skipping to change at page 27, line 6 ¶ | |||
A TLSCiphertext record was received which had a length more than | A TLSCiphertext record was received which had a length more than | |||
2^14+2048 bytes, or a record decrypted to a TLSCompressed record | 2^14+2048 bytes, or a record decrypted to a TLSCompressed record | |||
with more than 2^14+1024 bytes. This message is always fatal. | with more than 2^14+1024 bytes. This message is always fatal. | |||
decompression_failure | decompression_failure | |||
The decompression function received improper input (e.g. data | The decompression function received improper input (e.g. data | |||
that would expand to excessive length). This message is always | that would expand to excessive length). This message is always | |||
fatal. | fatal. | |||
handshake_failure | handshake_failure | |||
Reception of a handshake_failure alert message indicates that | Reception of a handshake_failure alert message indicates that the | |||
the sender was unable to negotiate an acceptable set of security | sender was unable to negotiate an acceptable set of security | |||
parameters given the options available. This is a fatal error. | parameters given the options available. This is a fatal error. | |||
bad_certificate | bad_certificate | |||
A certificate was corrupt, contained signatures that did not | A certificate was corrupt, contained signatures that did not | |||
verify correctly, etc. | verify correctly, etc. | |||
unsupported_certificate | unsupported_certificate | |||
A certificate was of an unsupported type. | A certificate was of an unsupported type. | |||
certificate_revoked | certificate_revoked | |||
skipping to change at page 26, line 11 ¶ | skipping to change at page 27, line 33 ¶ | |||
certificate_unknown | certificate_unknown | |||
Some other (unspecified) issue arose in processing the | Some other (unspecified) issue arose in processing the | |||
certificate, rendering it unacceptable. | certificate, rendering it unacceptable. | |||
illegal_parameter | illegal_parameter | |||
A field in the handshake was out of range or inconsistent with | A field in the handshake was out of range or inconsistent with | |||
other fields. This is always fatal. | other fields. This is always fatal. | |||
unknown_ca | unknown_ca | |||
A valid certificate chain or partial chain was received, but the | A valid certificate chain or partial chain was received, but the | |||
certificate was not accepted because the CA certificate could | certificate was not accepted because the CA certificate could not | |||
not be located or couldn`t be matched with a known, trusted CA. | be located or couldn`t be matched with a known, trusted CA. This | |||
This message is always fatal. | message is always fatal. | |||
access_denied | access_denied | |||
A valid certificate was received, but when access control was | A valid certificate was received, but when access control was | |||
applied, the sender decided not to proceed with negotiation. | applied, the sender decided not to proceed with negotiation. | |||
This message is always fatal. | This message is always fatal. | |||
decode_error | decode_error | |||
A message could not be decoded because some field was out of the | A message could not be decoded because some field was out of the | |||
specified range or the length of the message was incorrect. This | specified range or the length of the message was incorrect. This | |||
message is always fatal. | message is always fatal. | |||
skipping to change at page 26, line 45 ¶ | skipping to change at page 28, line 20 ¶ | |||
protocol_version | protocol_version | |||
The protocol version the client has attempted to negotiate is | The protocol version the client has attempted to negotiate is | |||
recognized, but not supported. (For example, old protocol | recognized, but not supported. (For example, old protocol | |||
versions might be avoided for security reasons). This message is | versions might be avoided for security reasons). This message is | |||
always fatal. | always fatal. | |||
insufficient_security | insufficient_security | |||
Returned instead of handshake_failure when a negotiation has | Returned instead of handshake_failure when a negotiation has | |||
failed specifically because the server requires ciphers more | failed specifically because the server requires ciphers more | |||
secure than those supported by the client. This message is | secure than those supported by the client. This message is always | |||
always fatal. | fatal. | |||
internal_error | internal_error | |||
An internal error unrelated to the peer or the correctness of | An internal error unrelated to the peer or the correctness of the | |||
the protocol makes it impossible to continue (such as a memory | protocol makes it impossible to continue (such as a memory | |||
allocation failure). This message is always fatal. | allocation failure). This message is always fatal. | |||
user_canceled | user_canceled | |||
This handshake is being canceled for some reason unrelated to a | This handshake is being canceled for some reason unrelated to a | |||
protocol failure. If the user cancels an operation after the | protocol failure. If the user cancels an operation after the | |||
handshake is complete, just closing the connection by sending a | handshake is complete, just closing the connection by sending a | |||
close_notify is more appropriate. This alert should be followed | close_notify is more appropriate. This alert should be followed | |||
by a close_notify. This message is generally a warning. | by a close_notify. This message is generally a warning. | |||
no_renegotiation | no_renegotiation | |||
Sent by the client in response to a hello request or by the | Sent by the client in response to a hello request or by the | |||
server in response to a client hello after initial handshaking. | server in response to a client hello after initial handshaking. | |||
Either of these would normally lead to renegotiation; when that | Either of these would normally lead to renegotiation; when that | |||
is not appropriate, the recipient should respond with this | is not appropriate, the recipient should respond with this alert; | |||
alert; at that point, the original requester can decide whether | at that point, the original requester can decide whether to | |||
to proceed with the connection. One case where this would be | proceed with the connection. One case where this would be | |||
appropriate would be where a server has spawned a process to | appropriate would be where a server has spawned a process to | |||
satisfy a request; the process might receive security parameters | satisfy a request; the process might receive security parameters | |||
(key length, authentication, etc.) at startup and it might be | (key length, authentication, etc.) at startup and it might be | |||
difficult to communicate changes to these parameters after that | difficult to communicate changes to these parameters after that | |||
point. This message is always a warning. | point. This message is always a warning. | |||
For all errors where an alert level is not explicitly specified, the | For all errors where an alert level is not explicitly specified, the | |||
sending party may determine at its discretion whether this is a | sending party may determine at its discretion whether this is a fatal | |||
fatal error or not; if an alert with a level of warning is received, | error or not; if an alert with a level of warning is received, the | |||
the receiving party may decide at its discretion whether to treat | receiving party may decide at its discretion whether to treat this as | |||
this as a fatal error or not. However, all messages which are | a fatal error or not. However, all messages which are transmitted | |||
transmitted with a level of fatal must be treated as fatal messages. | with a level of fatal must be treated as fatal messages. | |||
7.3. Handshake Protocol overview | 7.3. Handshake Protocol overview | |||
The cryptographic parameters of the session state are produced by | The cryptographic parameters of the session state are produced by the | |||
the TLS Handshake Protocol, which operates on top of the TLS Record | TLS Handshake Protocol, which operates on top of the TLS Record | |||
Layer. When a TLS client and server first start communicating, they | Layer. When a TLS client and server first start communicating, they | |||
agree on a protocol version, select cryptographic algorithms, | agree on a protocol version, select cryptographic algorithms, | |||
optionally authenticate each other, and use public-key encryption | optionally authenticate each other, and use public-key encryption | |||
techniques to generate shared secrets. | techniques to generate shared secrets. | |||
The TLS Handshake Protocol involves the following steps: | The TLS Handshake Protocol involves the following steps: | |||
- Exchange hello messages to agree on algorithms, exchange random | - Exchange hello messages to agree on algorithms, exchange random | |||
values, and check for session resumption. | values, and check for session resumption. | |||
skipping to change at page 28, line 12 ¶ | skipping to change at page 29, line 44 ¶ | |||
calculated the same security parameters and that the handshake | calculated the same security parameters and that the handshake | |||
occurred without tampering by an attacker. | occurred without tampering by an attacker. | |||
Note that higher layers should not be overly reliant on TLS always | Note that higher layers should not be overly reliant on TLS always | |||
negotiating the strongest possible connection between two peers: | negotiating the strongest possible connection between two peers: | |||
there are a number of ways a man in the middle attacker can attempt | there are a number of ways a man in the middle attacker can attempt | |||
to make two entities drop down to the least secure method they | to make two entities drop down to the least secure method they | |||
support. The protocol has been designed to minimize this risk, but | support. The protocol has been designed to minimize this risk, but | |||
there are still attacks available: for example, an attacker could | there are still attacks available: for example, an attacker could | |||
block access to the port a secure service runs on, or attempt to get | block access to the port a secure service runs on, or attempt to get | |||
the peers to negotiate an unauthenticated connection. The | the peers to negotiate an unauthenticated connection. The fundamental | |||
fundamental rule is that higher levels must be cognizant of what | rule is that higher levels must be cognizant of what their security | |||
their security requirements are and never transmit information over | requirements are and never transmit information over a channel less | |||
a channel less secure than what they require. The TLS protocol is | secure than what they require. The TLS protocol is secure, in that | |||
secure, in that any cipher suite offers its promised level of | any cipher suite offers its promised level of security: if you | |||
security: if you negotiate 3DES with a 1024 bit RSA key exchange | negotiate 3DES with a 1024 bit RSA key exchange with a host whose | |||
with a host whose certificate you have verified, you can expect to | certificate you have verified, you can expect to be that secure. | |||
be that secure. However, you should never send data over a link | ||||
encrypted with 40 bit security unless you feel that data is worth no | However, you should never send data over a link encrypted with 40 bit | |||
more than the effort required to break that encryption. | security unless you feel that data is worth no more than the effort | |||
required to break that encryption. | ||||
These goals are achieved by the handshake protocol, which can be | These goals are achieved by the handshake protocol, which can be | |||
summarized as follows: The client sends a client hello message to | summarized as follows: The client sends a client hello message to | |||
which the server must respond with a server hello message, or else a | which the server must respond with a server hello message, or else a | |||
fatal error will occur and the connection will fail. The client | fatal error will occur and the connection will fail. The client hello | |||
hello and server hello are used to establish security enhancement | and server hello are used to establish security enhancement | |||
capabilities between client and server. The client hello and server | capabilities between client and server. The client hello and server | |||
hello establish the following attributes: Protocol Version, Session | hello establish the following attributes: Protocol Version, Session | |||
ID, Cipher Suite, and Compression Method. Additionally, two random | ID, Cipher Suite, and Compression Method. Additionally, two random | |||
values are generated and exchanged: ClientHello.random and | values are generated and exchanged: ClientHello.random and | |||
ServerHello.random. | ServerHello.random. | |||
The actual key exchange uses up to four messages: the server | The actual key exchange uses up to four messages: the server | |||
certificate, the server key exchange, the client certificate, and | certificate, the server key exchange, the client certificate, and the | |||
the client key exchange. New key exchange methods can be created by | client key exchange. New key exchange methods can be created by | |||
specifying a format for these messages and defining the use of the | specifying a format for these messages and defining the use of the | |||
messages to allow the client and server to agree upon a shared | messages to allow the client and server to agree upon a shared | |||
secret. This secret should be quite long; currently defined key | secret. This secret should be quite long; currently defined key | |||
exchange methods exchange secrets which range from 48 to 128 bytes | exchange methods exchange secrets which range from 48 to 128 bytes in | |||
in length. | length. | |||
Following the hello messages, the server will send its certificate, | Following the hello messages, the server will send its certificate, | |||
if it is to be authenticated. Additionally, a server key exchange | 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 | 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 | certificate, or if its certificate is for signing only). If the | |||
server is authenticated, it may request a certificate from the | server is authenticated, it may request a certificate from the | |||
client, if that is appropriate to the cipher suite selected. Now the | client, if that is appropriate to the cipher suite selected. Now the | |||
server will send the server hello done message, indicating that the | server will send the server hello done message, indicating that the | |||
hello-message phase of the handshake is complete. The server will | hello-message phase of the handshake is complete. The server will | |||
then wait for a client response. If the server has sent a | then wait for a client response. If the server has sent a certificate | |||
certificate request message, the client must send the certificate | request message, the client must send the certificate message. The | |||
message. The client key exchange message is now sent, and the | client key exchange message is now sent, and the content of that | |||
content of that message will depend on the public key algorithm | message will depend on the public key algorithm selected between the | |||
selected between the client hello and the server hello. If the | client hello and the server hello. If the client has sent a | |||
client has sent a certificate with signing ability, a | certificate with signing ability, a digitally-signed certificate | |||
digitally-signed certificate verify message is sent to explicitly | verify message is sent to explicitly verify the certificate. | |||
verify the certificate. | ||||
At this point, a change cipher spec message is sent by the client, | At this point, a change cipher spec message is sent by the client, | |||
and the client copies the pending Cipher Spec into the current | and the client copies the pending Cipher Spec into the current Cipher | |||
Cipher Spec. The client then immediately sends the finished message | Spec. The client then immediately sends the finished message under | |||
under the new algorithms, keys, and secrets. In response, the server | the new algorithms, keys, and secrets. In response, the server will | |||
will send its own change cipher spec message, transfer the pending | send its own change cipher spec message, transfer the pending to the | |||
to the current Cipher Spec, and send its finished message under the | current Cipher Spec, and send its finished message under the new | |||
new Cipher Spec. At this point, the handshake is complete and the | Cipher Spec. At this point, the handshake is complete and the client | |||
client and server may begin to exchange application layer data. (See | and server may begin to exchange application layer data. (See flow | |||
flow chart below.) | chart below.) | |||
Client Server | Client Server | |||
ClientHello --------> | ClientHello --------> | |||
ServerHello | ServerHello | |||
Certificate* | Certificate* | |||
ServerKeyExchange* | ServerKeyExchange* | |||
CertificateRequest* | CertificateRequest* | |||
<-------- ServerHelloDone | <-------- ServerHelloDone | |||
Certificate* | Certificate* | |||
skipping to change at page 29, line 39 ¶ | skipping to change at page 31, line 30 ¶ | |||
Finished --------> | Finished --------> | |||
[ChangeCipherSpec] | [ChangeCipherSpec] | |||
<-------- Finished | <-------- Finished | |||
Application Data <-------> Application Data | Application Data <-------> Application Data | |||
Fig. 1 - Message flow for a full handshake | Fig. 1 - Message flow for a full handshake | |||
* Indicates optional or situation-dependent messages that are not | * Indicates optional or situation-dependent messages that are not | |||
always sent. | always sent. | |||
Note: To help avoid pipeline stalls, ChangeCipherSpec is an | Note: To help avoid pipeline stalls, ChangeCipherSpec is an | |||
independent TLS Protocol content type, and is not actually a TLS | independent TLS Protocol content type, and is not actually a TLS | |||
handshake message. | handshake message. | |||
When the client and server decide to resume a previous session or | When the client and server decide to resume a previous session or | |||
duplicate an existing session (instead of negotiating new security | duplicate an existing session (instead of negotiating new security | |||
parameters) the message flow is as follows: | parameters) the message flow is as follows: | |||
The client sends a ClientHello using the Session ID of the session | The client sends a ClientHello using the Session ID of the session to | |||
to be resumed. The server then checks its session cache for a match. | be resumed. The server then checks its session cache for a match. If | |||
If a match is found, and the server is willing to re-establish the | a match is found, and the server is willing to re-establish the | |||
connection under the specified session state, it will send a | connection under the specified session state, it will send a | |||
ServerHello with the same Session ID value. At this point, both | ServerHello with the same Session ID value. At this point, both | |||
client and server must send change cipher spec messages and proceed | client and server must send change cipher spec messages and proceed | |||
directly to finished messages. Once the re-establishment is | directly to finished messages. Once the re-establishment is complete, | |||
complete, the client and server may begin to exchange application | the client and server may begin to exchange application layer data. | |||
layer data. (See flow chart below.) If a Session ID match is not | (See flow chart below.) If a Session ID match is not found, the | |||
found, the server generates a new session ID and the TLS client and | server generates a new session ID and the TLS client and server | |||
server perform a full handshake. | perform a full handshake. | |||
Client Server | Client Server | |||
ClientHello --------> | ClientHello --------> | |||
ServerHello | ServerHello | |||
[ChangeCipherSpec] | [ChangeCipherSpec] | |||
<-------- Finished | <-------- Finished | |||
[ChangeCipherSpec] | [ChangeCipherSpec] | |||
Finished --------> | Finished --------> | |||
Application Data <-------> Application Data | Application Data <-------> Application Data | |||
Fig. 2 - Message flow for an abbreviated handshake | Fig. 2 - Message flow for an abbreviated handshake | |||
The contents and significance of each message will be presented in | The contents and significance of each message will be presented in | |||
detail in the following sections. | detail in the following sections. | |||
7.4. Handshake protocol | 7.4. Handshake protocol | |||
The TLS Handshake Protocol is one of the defined higher level | The TLS Handshake Protocol is one of the defined higher level clients | |||
clients of the TLS Record Protocol. This protocol is used to | of the TLS Record Protocol. This protocol is used to negotiate the | |||
negotiate the secure attributes of a session. Handshake messages are | secure attributes of a session. Handshake messages are supplied to | |||
supplied to the TLS Record Layer, where they are encapsulated within | the TLS Record Layer, where they are encapsulated within one or more | |||
one or more TLSPlaintext structures, which are processed and | TLSPlaintext structures, which are processed and transmitted as | |||
transmitted as specified by the current active session state. | specified by the current active session state. | |||
enum { | enum { | |||
hello_request(0), client_hello(1), server_hello(2), | hello_request(0), client_hello(1), server_hello(2), | |||
certificate(11), server_key_exchange (12), | certificate(11), server_key_exchange (12), | |||
certificate_request(13), server_hello_done(14), | certificate_request(13), server_hello_done(14), | |||
certificate_verify(15), client_key_exchange(16), | certificate_verify(15), client_key_exchange(16), | |||
finished(20), (255) | finished(20), (255) | |||
} HandshakeType; | } HandshakeType; | |||
struct { | struct { | |||
skipping to change at page 31, line 5 ¶ | skipping to change at page 33, line 5 ¶ | |||
case certificate: Certificate; | case certificate: Certificate; | |||
case server_key_exchange: ServerKeyExchange; | case server_key_exchange: ServerKeyExchange; | |||
case certificate_request: CertificateRequest; | case certificate_request: CertificateRequest; | |||
case server_hello_done: ServerHelloDone; | case server_hello_done: ServerHelloDone; | |||
case certificate_verify: CertificateVerify; | case certificate_verify: CertificateVerify; | |||
case client_key_exchange: ClientKeyExchange; | case client_key_exchange: ClientKeyExchange; | |||
case finished: Finished; | case finished: Finished; | |||
} body; | } body; | |||
} Handshake; | } Handshake; | |||
The handshake protocol messages are presented below in the order | The handshake protocol messages are presented below in the order they | |||
they must be sent; sending handshake messages in an unexpected order | must be sent; sending handshake messages in an unexpected order | |||
results in a fatal error. Unneeded handshake messages can be | results in a fatal error. Unneeded handshake messages can be omitted, | |||
omitted, however. Note one exception to the ordering: the | however. Note one exception to the ordering: the Certificate message | |||
Certificate message is used twice in the handshake (from server to | is used twice in the handshake (from server to client, then from | |||
client, then from client to server), but described only in its first | client to server), but described only in its first position. The one | |||
position. The one message which is not bound by these ordering rules | message which is not bound by these ordering rules in the Hello | |||
in the Hello Request message, which can be sent at any time, but | Request message, which can be sent at any time, but which should be | |||
which should be ignored by the client if it arrives in the middle of | ignored by the client if it arrives in the middle of a handshake. | |||
a handshake. | ||||
7.4.1. Hello messages | 7.4.1. Hello messages | |||
The hello phase messages are used to exchange security enhancement | The hello phase messages are used to exchange security enhancement | |||
capabilities between the client and server. When a new session | capabilities between the client and server. When a new session | |||
begins, the Record Layer's connection state encryption, hash, and | begins, the Record Layer's connection state encryption, hash, and | |||
compression algorithms are initialized to null. The current | compression algorithms are initialized to null. The current | |||
connection state is used for renegotiation messages. | connection state is used for renegotiation messages. | |||
7.4.1.1. Hello request | 7.4.1.1. Hello request | |||
skipping to change at page 31, line 49 ¶ | skipping to change at page 33, line 48 ¶ | |||
than a few records are received from the client. If the server | than a few records are received from the client. If the server | |||
sends a hello request but does not receive a client hello in | sends a hello request but does not receive a client hello in | |||
response, it may close the connection with a fatal alert. | response, it may close the connection with a fatal alert. | |||
After sending a hello request, servers should not repeat the request | After sending a hello request, servers should not repeat the request | |||
until the subsequent handshake negotiation is complete. | until the subsequent handshake negotiation is complete. | |||
Structure of this message: | Structure of this message: | |||
struct { } HelloRequest; | struct { } HelloRequest; | |||
Note: This message should never be included in the message hashes | Note: This message should never be included in the message hashes which | |||
which are maintained throughout the handshake and used in the | are maintained throughout the handshake and used in the finished | |||
finished messages and the certificate verify message. | messages and the certificate verify message. | |||
7.4.1.2. Client hello | 7.4.1.2. Client hello | |||
When this message will be sent: | When this message will be sent: | |||
When a client first connects to a server it is required to send | 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 | the client hello as its first message. The client can also send a | |||
a client hello in response to a hello request or on its own | client hello in response to a hello request or on its own | |||
initiative in order to renegotiate the security parameters in an | initiative in order to renegotiate the security parameters in an | |||
existing connection. | existing connection. | |||
Structure of this message: | Structure of this message: | |||
The client hello message includes a random structure, which is | The client hello message includes a random structure, which is | |||
used later in the protocol. | used later in the protocol. | |||
struct { | struct { | |||
uint32 gmt_unix_time; | uint32 gmt_unix_time; | |||
opaque random_bytes[28]; | opaque random_bytes[28]; | |||
} Random; | } Random; | |||
gmt_unix_time | gmt_unix_time | |||
The current time and date in standard UNIX 32-bit format | The current time and date in standard UNIX 32-bit format (seconds | |||
(seconds since the midnight starting Jan 1, 1970, GMT) according | since the midnight starting Jan 1, 1970, GMT) according to the | |||
to the sender's internal clock. Clocks are not required to be | sender's internal clock. Clocks are not required to be set | |||
set correctly by the basic TLS Protocol; higher level or | correctly by the basic TLS Protocol; higher level or application | |||
application protocols may define additional requirements. | protocols may define additional requirements. | |||
random_bytes | random_bytes | |||
28 bytes generated by a secure random number generator. | 28 bytes generated by a secure random number generator. | |||
The client hello message includes a variable length session | The client hello message includes a variable length session | |||
identifier. If not empty, the value identifies a session between the | identifier. If not empty, the value identifies a session between the | |||
same client and server whose security parameters the client wishes | same client and server whose security parameters the client wishes to | |||
to reuse. The session identifier may be from an earlier connection, | reuse. The session identifier may be from an earlier connection, this | |||
this connection, or another currently active connection. The second | connection, or another currently active connection. The second option | |||
option is useful if the client only wishes to update the random | is useful if the client only wishes to update the random structures | |||
structures and derived values of a connection, while the third | and derived values of a connection, while the third option makes it | |||
option makes it possible to establish several independent secure | possible to establish several independent secure connections without | |||
connections without repeating the full handshake protocol. These | repeating the full handshake protocol. These independent connections | |||
independent connections may occur sequentially or simultaneously; a | may occur sequentially or simultaneously; a SessionID becomes valid | |||
SessionID becomes valid when the handshake negotiating it completes | when the handshake negotiating it completes with the exchange of | |||
with the exchange of Finished messages and persists until removed | Finished messages and persists until removed due to aging or because | |||
due to aging or because a fatal error was encountered on a | a fatal error was encountered on a connection associated with the | |||
connection associated with the session. The actual contents of the | session. The actual contents of the SessionID are defined by the | |||
SessionID are defined by the server. | server. | |||
opaque SessionID<0..32>; | opaque SessionID<0..32>; | |||
Warning: | Warning: | |||
Because the SessionID is transmitted without encryption or | Because the SessionID is transmitted without encryption or | |||
immediate MAC protection, servers must not place confidential | immediate MAC protection, servers must not place confidential | |||
information in session identifiers or let the contents of fake | information in session identifiers or let the contents of fake | |||
session identifiers cause any breach of security. (Note that the | session identifiers cause any breach of security. (Note that the | |||
content of the handshake as a whole, including the SessionID, is | content of the handshake as a whole, including the SessionID, is | |||
protected by the Finished messages exchanged at the end of the | protected by the Finished messages exchanged at the end of the | |||
handshake.) | handshake.) | |||
The CipherSuite list, passed from the client to the server in the | The CipherSuite list, passed from the client to the server in the | |||
client hello message, contains the combinations of cryptographic | client hello message, contains the combinations of cryptographic | |||
algorithms supported by the client in order of the client's | algorithms supported by the client in order of the client's | |||
preference (favorite choice first). Each CipherSuite defines a key | preference (favorite choice first). Each CipherSuite defines a key | |||
exchange algorithm, a bulk encryption algorithm (including secret | exchange algorithm, a bulk encryption algorithm (including secret key | |||
key length) and a MAC algorithm. The server will select a cipher | length) and a MAC algorithm. The server will select a cipher suite | |||
suite or, if no acceptable choices are presented, return a handshake | or, if no acceptable choices are presented, return a handshake | |||
failure alert and close the connection. | failure alert and close the connection. | |||
uint8 CipherSuite[2]; /* Cryptographic suite selector */ | uint8 CipherSuite[2]; /* Cryptographic suite selector */ | |||
The client hello includes a list of compression algorithms supported | The client hello includes a list of compression algorithms supported | |||
by the client, ordered according to the client's preference. | by the client, ordered according to the client's preference. | |||
enum { null(0), (255) } CompressionMethod; | enum { null(0), (255) } CompressionMethod; | |||
struct { | struct { | |||
skipping to change at page 33, line 40 ¶ | skipping to change at page 35, line 49 ¶ | |||
The version of the TLS protocol by which the client wishes to | The version of the TLS protocol by which the client wishes to | |||
communicate during this session. This should be the latest | communicate during this session. This should be the latest | |||
(highest valued) version supported by the client. For this | (highest valued) version supported by the client. For this | |||
version of the specification, the version will be 3.1 (See | version of the specification, the version will be 3.1 (See | |||
Appendix E for details about backward compatibility). | Appendix E for details about backward compatibility). | |||
random | random | |||
A client-generated random structure. | A client-generated random structure. | |||
session_id | session_id | |||
The ID of a session the client wishes to use for this | The ID of a session the client wishes to use for this connection. | |||
connection. This field should be empty if no session_id is | This field should be empty if no session_id is available or the | |||
available or the client wishes to generate new security | client wishes to generate new security parameters. | |||
parameters. | ||||
cipher_suites | cipher_suites | |||
This is a list of the cryptographic options supported by the | This is a list of the cryptographic options supported by the | |||
client, with the client's first preference first. If the | client, with the client's first preference first. If the | |||
session_id field is not empty (implying a session resumption | session_id field is not empty (implying a session resumption | |||
request) this vector must include at least the cipher_suite from | request) this vector must include at least the cipher_suite from | |||
that session. Values are defined in Appendix A.5. | that session. Values are defined in Appendix A.5. | |||
compression_methods | compression_methods | |||
This is a list of the compression methods supported by the | This is a list of the compression methods supported by the | |||
client, sorted by client preference. If the session_id field is | client, sorted by client preference. If the session_id field is | |||
not empty (implying a session resumption request) it must | not empty (implying a session resumption request) it must include | |||
include the compression_method from that session. This vector | the compression_method from that session. This vector must | |||
must contain, and all implementations must support, | contain, and all implementations must support, | |||
CompressionMethod.null. Thus, a client and server will always be | CompressionMethod.null. Thus, a client and server will always be | |||
able to agree on a compression method. | able to agree on a compression method. | |||
After sending the client hello message, the client waits for a | After sending the client hello message, the client waits for a server | |||
server hello message. Any other handshake message returned by the | hello message. Any other handshake message returned by the server | |||
server except for a hello request is treated as a fatal error. | except for a hello request is treated as a fatal error. | |||
Forward compatibility note: | Forward compatibility note: | |||
In the interests of forward compatibility, it is permitted for a | In the interests of forward compatibility, it is permitted for a | |||
client hello message to include extra data after the compression | client hello message to include extra data after the compression | |||
methods. This data must be included in the handshake hashes, but | methods. This data must be included in the handshake hashes, but | |||
must otherwise be ignored. This is the only handshake message | must otherwise be ignored. This is the only handshake message for | |||
for which this is legal; for all other messages, the amount of | which this is legal; for all other messages, the amount of data | |||
data in the message must match the description of the message | in the message must match the description of the message | |||
precisely. | precisely. | |||
7.4.1.3. Server hello | 7.4.1.3. Server hello | |||
When this message will be sent: | When this message will be sent: | |||
The server will send this message in response to a client hello | The server will send this message in response to a client hello | |||
message when it was able to find an acceptable set of | message when it was able to find an acceptable set of algorithms. | |||
algorithms. If it cannot find such a match, it will respond with | If it cannot find such a match, it will respond with a handshake | |||
a handshake failure alert. | failure alert. | |||
Structure of this message: | Structure of this message: | |||
struct { | struct { | |||
ProtocolVersion server_version; | ProtocolVersion server_version; | |||
Random random; | Random random; | |||
SessionID session_id; | SessionID session_id; | |||
CipherSuite cipher_suite; | CipherSuite cipher_suite; | |||
CompressionMethod compression_method; | CompressionMethod compression_method; | |||
} ServerHello; | } ServerHello; | |||
server_version | server_version | |||
This field will contain the lower of that suggested by the | This field will contain the lower of that suggested by the client | |||
client in the client hello and the highest supported by the | in the client hello and the highest supported by the server. For | |||
server. For this version of the specification, the version is | this version of the specification, the version is 3.1 (See | |||
3.1 (See Appendix E for details about backward compatibility). | Appendix E for details about backward compatibility). | |||
random | random | |||
This structure is generated by the server and must be different | This structure is generated by the server and must be different | |||
from (and independent of) ClientHello.random. | from (and independent of) ClientHello.random. | |||
session_id | session_id | |||
This is the identity of the session corresponding to this | This is the identity of the session corresponding to this | |||
connection. If the ClientHello.session_id was non-empty, the | connection. If the ClientHello.session_id was non-empty, the | |||
server will look in its session cache for a match. If a match is | 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 | found and the server is willing to establish the new connection | |||
using the specified session state, the server will respond with | using the specified session state, the server will respond with | |||
the same value as was supplied by the client. This indicates a | the same value as was supplied by the client. This indicates a | |||
resumed session and dictates that the parties must proceed | resumed session and dictates that the parties must proceed | |||
directly to the finished messages. Otherwise this field will | directly to the finished messages. Otherwise this field will | |||
contain a different value identifying the new session. The | contain a different value identifying the new session. The server | |||
server may return an empty session_id to indicate that the | may return an empty session_id to indicate that the session will | |||
session will not be cached and therefore cannot be resumed. If a | not be cached and therefore cannot be resumed. If a session is | |||
session is resumed, it must be resumed using the same cipher | resumed, it must be resumed using the same cipher suite it was | |||
suite it was originally negotiated with. | originally negotiated with. | |||
cipher_suite | cipher_suite | |||
The single cipher suite selected by the server from the list in | The single cipher suite selected by the server from the list in | |||
ClientHello.cipher_suites. For resumed sessions this field is | ClientHello.cipher_suites. For resumed sessions this field is the | |||
the value from the state of the session being resumed. | value from the state of the session being resumed. | |||
compression_method | compression_method | |||
The single compression algorithm selected by the server from the | The single compression algorithm selected by the server from the | |||
list in ClientHello.compression_methods. For resumed sessions | list in ClientHello.compression_methods. For resumed sessions | |||
this field is the value from the resumed session state. | this field is the value from the resumed session state. | |||
7.4.2. Server certificate | 7.4.2. Server certificate | |||
When this message will be sent: | When this message will be sent: | |||
The server must send a certificate whenever the agreed-upon key | The server must send a certificate whenever the agreed-upon key | |||
exchange method is not an anonymous one. This message will | exchange method is not an anonymous one. This message will always | |||
always immediately follow the server hello message. | immediately follow the server hello message. | |||
Meaning of this message: | Meaning of this message: | |||
The certificate type must be appropriate for the selected cipher | The certificate type must be appropriate for the selected cipher | |||
suite's key exchange algorithm, and is generally an X.509v3 | suite's key exchange algorithm, and is generally an X.509v3 | |||
certificate. It must contain a key which matches the key | certificate. It must contain a key which matches the key exchange | |||
exchange method, as follows. Unless otherwise specified, the | method, as follows. Unless otherwise specified, the signing | |||
signing algorithm for the certificate must be the same as the | algorithm for the certificate must be the same as the algorithm | |||
algorithm for the certificate key. Unless otherwise specified, | for the certificate key. Unless otherwise specified, the public | |||
the public key may be of any length. | key may be of any length. | |||
Key Exchange Algorithm Certificate Key Type | Key Exchange Algorithm Certificate Key Type | |||
RSA RSA public key; the certificate must | RSA RSA public key; the certificate must | |||
allow the key to be used for encryption. | allow the key to be used for encryption. | |||
RSA_EXPORT RSA public key of length greater than | RSA_EXPORT RSA public key of length greater than | |||
512 bits which can be used for signing, | 512 bits which can be used for signing, | |||
or a key of 512 bits or shorter which | or a key of 512 bits or shorter which | |||
can be used for either encryption or | can be used for either encryption or | |||
skipping to change at page 36, line 17 ¶ | skipping to change at page 38, line 38 ¶ | |||
DH_DSS Diffie-Hellman key. The algorithm used | DH_DSS Diffie-Hellman key. The algorithm used | |||
to sign the certificate should be DSS. | to sign the certificate should be DSS. | |||
DH_RSA Diffie-Hellman key. The algorithm used | DH_RSA Diffie-Hellman key. The algorithm used | |||
to sign the certificate should be RSA. | to sign the certificate should be RSA. | |||
All certificate profiles, key and cryptographic formats are defined | All certificate profiles, key and cryptographic formats are defined | |||
by the IETF PKIX working group [PKIX]. When a key usage extension is | by the IETF PKIX working group [PKIX]. When a key usage extension is | |||
present, the digitalSignature bit must be set for the key to be | present, the digitalSignature bit must be set for the key to be | |||
eligible for signing, as described above, and the keyEncipherment | eligible for signing, as described above, and the keyEncipherment bit | |||
bit must be present to allow encryption, as described above. The | must be present to allow encryption, as described above. The | |||
keyAgreement bit must be set on Diffie-Hellman certificates. | keyAgreement bit must be set on Diffie-Hellman certificates. | |||
As CipherSuites which specify new key exchange methods are specified | As CipherSuites which specify new key exchange methods are specified | |||
for the TLS Protocol, they will imply certificate format and the | for the TLS Protocol, they will imply certificate format and the | |||
required encoded keying information. | required encoded keying information. | |||
Structure of this message: | Structure of this message: | |||
opaque ASN.1Cert<1..2^24-1>; | opaque ASN.1Cert<1..2^24-1>; | |||
struct { | struct { | |||
skipping to change at page 39, line 18 ¶ | skipping to change at page 41, line 50 ¶ | |||
digitally-signed struct { | digitally-signed struct { | |||
opaque sha_hash[20]; | opaque sha_hash[20]; | |||
}; | }; | |||
} Signature; | } Signature; | |||
7.4.4. Certificate request | 7.4.4. Certificate request | |||
When this message will be sent: | When this message will be sent: | |||
A non-anonymous server can optionally request a certificate from | A non-anonymous server can optionally request a certificate from | |||
the client, if appropriate for the selected cipher suite. This | the client, if appropriate for the selected cipher suite. This | |||
message, if sent, will immediately follow the Server Key | message, if sent, will immediately follow the Server Key Exchange | |||
Exchange message (if it is sent; otherwise, the Server | message (if it is sent; otherwise, the Server Certificate | |||
Certificate message). | message). | |||
Structure of this message: | Structure of this message: | |||
enum { | enum { | |||
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), | rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), | |||
(255) | (255) | |||
} ClientCertificateType; | } ClientCertificateType; | |||
opaque DistinguishedName<1..2^16-1>; | opaque DistinguishedName<1..2^16-1>; | |||
struct { | struct { | |||
ClientCertificateType certificate_types<1..2^8-1>; | ClientCertificateType certificate_types<1..2^8-1>; | |||
DistinguishedName certificate_authorities<3..2^16-1>; | DistinguishedName certificate_authorities<3..2^16-1>; | |||
} CertificateRequest; | } CertificateRequest; | |||
certificate_types | certificate_types | |||
This field is a list of the types of certificates requested, | This field is a list of the types of certificates requested, | |||
sorted in order of the server's preference. | sorted in order of the server's preference. | |||
certificate_authorities | certificate_authorities | |||
A list of the distinguished names of acceptable certificate | A list of the distinguished names of acceptable certificate | |||
authorities. These distinguished names may specify a desired | authorities. These distinguished names may specify a desired | |||
distinguished name for a root CA or for a subordinate CA; | distinguished name for a root CA or for a subordinate CA; | |||
thus, this message can be used both to describe known roots | thus, this message can be used both to describe known roots | |||
and a desired authorization space. | and a desired authorization space. | |||
Note: DistinguishedName is derived from [X509]. | Note: DistinguishedName is derived from [X509]. | |||
skipping to change at page 40, line 42 ¶ | skipping to change at page 43, line 29 ¶ | |||
Diffie-Hellman group and generator encoded in the client's | Diffie-Hellman group and generator encoded in the client's | |||
certificate must match the server specified Diffie-Hellman | certificate must match the server specified Diffie-Hellman | |||
parameters if the client's parameters are to be used for the key | parameters if the client's parameters are to be used for the key | |||
exchange. | exchange. | |||
7.4.7. Client key exchange message | 7.4.7. Client key exchange message | |||
When this message will be sent: | When this message will be sent: | |||
This message is always sent by the client. It will immediately | This message is always sent by the client. It will immediately | |||
follow the client certificate message, if it is sent. Otherwise | follow the client certificate message, if it is sent. Otherwise | |||
it will be the first message sent by the client after it | it will be the first message sent by the client after it receives | |||
receives the server hello done message. | the server hello done message. | |||
Meaning of this message: | Meaning of this message: | |||
With this message, the premaster secret is set, either though | With this message, the premaster secret is set, either though | |||
direct transmission of the RSA-encrypted secret, or by the | direct transmission of the RSA-encrypted secret, or by the | |||
transmission of Diffie-Hellman parameters which will allow each | transmission of Diffie-Hellman parameters which will allow each | |||
side to agree upon the same premaster secret. When the key | side to agree upon the same premaster secret. When the key | |||
exchange method is DH_RSA or DH_DSS, client certification has | exchange method is DH_RSA or DH_DSS, client certification has | |||
been requested, and the client was able to respond with a | been requested, and the client was able to respond with a | |||
certificate which contained a Diffie-Hellman public key whose | certificate which contained a Diffie-Hellman public key whose | |||
parameters (group and generator) matched those specified by the | parameters (group and generator) matched those specified by the | |||
skipping to change at page 41, line 14 ¶ | skipping to change at page 44, line 4 ¶ | |||
Structure of this message: | Structure of this message: | |||
The choice of messages depends on which key exchange method has | The choice of messages depends on which key exchange method has | |||
been selected. See Section 7.4.3 for the KeyExchangeAlgorithm | been selected. See Section 7.4.3 for the KeyExchangeAlgorithm | |||
definition. | definition. | |||
struct { | struct { | |||
select (KeyExchangeAlgorithm) { | select (KeyExchangeAlgorithm) { | |||
case rsa: EncryptedPreMasterSecret; | case rsa: EncryptedPreMasterSecret; | |||
case diffie_hellman: ClientDiffieHellmanPublic; | case diffie_hellman: ClientDiffieHellmanPublic; | |||
} exchange_keys; | } exchange_keys; | |||
} ClientKeyExchange; | } ClientKeyExchange; | |||
7.4.7.1. RSA encrypted premaster secret message | 7.4.7.1. RSA encrypted premaster secret message | |||
Meaning of this message: | Meaning of this message: | |||
If RSA is being used for key agreement and authentication, the | If RSA is being used for key agreement and authentication, the | |||
client generates a 48-byte premaster secret, encrypts it using | client generates a 48-byte premaster secret, encrypts it using | |||
the public key from the server's certificate or the temporary | the public key from the server's certificate or the temporary RSA | |||
RSA key provided in a server key exchange message, and sends the | key provided in a server key exchange message, and sends the | |||
result in an encrypted premaster secret message. This structure | result in an encrypted premaster secret message. This structure | |||
is a variant of the client key exchange message, not a message | is a variant of the client key exchange message, not a message in | |||
in itself. | itself. | |||
Structure of this message: | Structure of this message: | |||
struct { | struct { | |||
ProtocolVersion client_version; | ProtocolVersion client_version; | |||
opaque random[46]; | opaque random[46]; | |||
} PreMasterSecret; | } PreMasterSecret; | |||
client_version | client_version | |||
The latest (newest) version supported by the client. This is | The latest (newest) version supported by the client. This is | |||
used to detect version roll-back attacks. Upon receiving the | used to detect version roll-back attacks. Upon receiving the | |||
skipping to change at page 42, line 6 ¶ | skipping to change at page 44, line 47 ¶ | |||
} EncryptedPreMasterSecret; | } EncryptedPreMasterSecret; | |||
Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used | Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used | |||
to attack a TLS server which is using PKCS#1 encoded RSA. The | to attack a TLS server which is using PKCS#1 encoded RSA. The | |||
attack takes advantage of the fact that by failing in different | attack takes advantage of the fact that by failing in different | |||
ways, a TLS server can be coerced into revealing whether a | ways, a TLS server can be coerced into revealing whether a | |||
particular message, when decrypted, is properly PKCS#1 formatted | particular message, when decrypted, is properly PKCS#1 formatted | |||
or not. | or not. | |||
The best way to avoid vulnerability to this attack is to treat | The best way to avoid vulnerability to this attack is to treat | |||
incorrectly formatted messages in a manner indistinguishable | incorrectly formatted messages in a manner indistinguishable from | |||
from correctly formatted RSA blocks. Thus, when it receives an | correctly formatted RSA blocks. Thus, when it receives an | |||
incorrectly formatted RSA block, a server should generate a | incorrectly formatted RSA block, a server should generate a | |||
random 48-byte value and proceed using it as the premaster | random 48-byte value and proceed using it as the premaster | |||
secret. Thus, the server will act identically whether the | secret. Thus, the server will act identically whether the | |||
received RSA block is correctly encoded or not. | received RSA block is correctly encoded or not. | |||
pre_master_secret | pre_master_secret | |||
This random value is generated by the client and is used to | This random value is generated by the client and is used to | |||
generate the master secret, as specified in Section 8.1. | generate the master secret, as specified in Section 8.1. | |||
7.4.7.2. Client Diffie-Hellman public value | 7.4.7.2. Client Diffie-Hellman public value | |||
skipping to change at page 42, line 51 ¶ | skipping to change at page 45, line 43 ¶ | |||
case explicit: opaque dh_Yc<1..2^16-1>; | case explicit: opaque dh_Yc<1..2^16-1>; | |||
} dh_public; | } dh_public; | |||
} ClientDiffieHellmanPublic; | } ClientDiffieHellmanPublic; | |||
dh_Yc | dh_Yc | |||
The client's Diffie-Hellman public value (Yc). | The client's Diffie-Hellman public value (Yc). | |||
7.4.8. Certificate verify | 7.4.8. Certificate verify | |||
When this message will be sent: | When this message will be sent: | |||
This message is used to provide explicit verification of a | This message is used to provide explicit verification of a client | |||
client certificate. This message is only sent following a client | certificate. This message is only sent following a client | |||
certificate that has signing capability (i.e. all certificates | certificate that has signing capability (i.e. all certificates | |||
except those containing fixed Diffie-Hellman parameters). When | except those containing fixed Diffie-Hellman parameters). When | |||
sent, it will immediately follow the client key exchange | sent, it will immediately follow the client key exchange message. | |||
message. | ||||
Structure of this message: | Structure of this message: | |||
struct { | struct { | |||
Signature signature; | Signature signature; | |||
} CertificateVerify; | } CertificateVerify; | |||
The Signature type is defined in 7.4.3. | ||||
The Signature type is defined in 6.4.3. | ||||
CertificateVerify.signature.md5_hash | CertificateVerify.signature.md5_hash | |||
MD5(handshake_messages); | MD5(handshake_messages); | |||
Certificate.signature.sha_hash | Certificate.signature.sha_hash | |||
SHA(handshake_messages); | SHA(handshake_messages); | |||
Here handshake_messages refers to all handshake messages sent or | Here handshake_messages refers to all handshake messages sent or | |||
received starting at client hello up to but not including this | received starting at client hello up to but not including this | |||
message, including the type and length fields of the handshake | message, including the type and length fields of the handshake | |||
skipping to change at page 43, line 34 ¶ | skipping to change at page 46, line 28 ¶ | |||
7.4.9. Finished | 7.4.9. Finished | |||
When this message will be sent: | When this message will be sent: | |||
A finished message is always sent immediately after a change | A finished message is always sent immediately after a change | |||
cipher spec message to verify that the key exchange and | cipher spec message to verify that the key exchange and | |||
authentication processes were successful. It is essential that a | authentication processes were successful. It is essential that a | |||
change cipher spec message be received between the other | change cipher spec message be received between the other | |||
handshake messages and the Finished message. | handshake messages and the Finished message. | |||
Meaning of this message: | Meaning of this message: | |||
The finished message is the first protected with the | The finished message is the first protected with the just- | |||
just-negotiated algorithms, keys, and secrets. Recipients of | negotiated algorithms, keys, and secrets. Recipients of finished | |||
finished messages must verify that the contents are correct. | messages must verify that the contents are correct. Once a side | |||
Once a side has sent its Finished message and received and | has sent its Finished message and received and validated the | |||
validated the Finished message from its peer, it may begin to | Finished message from its peer, it may begin to send and receive | |||
send and receive application data over the connection. | application data over the connection. | |||
struct { | struct { | |||
opaque verify_data[12]; | opaque verify_data[12]; | |||
} Finished; | } Finished; | |||
verify_data | verify_data | |||
PRF(master_secret, finished_label, MD5(handshake_messages) + | PRF(master_secret, finished_label, MD5(handshake_messages) + | |||
SHA-1(handshake_messages)) [0..11]; | SHA-1(handshake_messages)) [0..11]; | |||
finished_label | finished_label | |||
skipping to change at page 44, line 5 ¶ | skipping to change at page 47, line 4 ¶ | |||
finished_label | finished_label | |||
For Finished messages sent by the client, the string "client | For Finished messages sent by the client, the string "client | |||
finished". For Finished messages sent by the server, the | finished". For Finished messages sent by the server, the | |||
string "server finished". | string "server finished". | |||
handshake_messages | handshake_messages | |||
All of the data from all handshake messages up to but not | All of the data from all handshake messages up to but not | |||
including this message. This is only data visible at the | including this message. This is only data visible at the | |||
handshake layer and does not include record layer headers. | handshake layer and does not include record layer headers. | |||
This is the concatenation of all the Handshake structures as | This is the concatenation of all the Handshake structures as | |||
defined in 7.4 exchanged thus far. | defined in 7.4 exchanged thus far. | |||
It is a fatal error if a finished message is not preceded by a | It is a fatal error if a finished message is not preceded by a change | |||
change cipher spec message at the appropriate point in the | cipher spec message at the appropriate point in the handshake. | |||
handshake. | ||||
The hash contained in finished messages sent by the server | The hash contained in finished messages sent by the server | |||
incorporate Sender.server; those sent by the client incorporate | incorporate Sender.server; those sent by the client incorporate | |||
Sender.client. The value handshake_messages includes all handshake | Sender.client. The value handshake_messages includes all handshake | |||
messages starting at client hello up to, but not including, this | messages starting at client hello up to, but not including, this | |||
finished message. This may be different from handshake_messages in | finished message. This may be different from handshake_messages in | |||
Section 7.4.8 because it would include the certificate verify | Section 7.4.8 because it would include the certificate verify message | |||
message (if sent). Also, the handshake_messages for the finished | (if sent). Also, the handshake_messages for the finished message sent | |||
message sent by the client will be different from that for the | by the client will be different from that for the finished message | |||
finished message sent by the server, because the one which is sent | sent by the server, because the one which is sent second will include | |||
second will include the prior one. | the prior one. | |||
Note: Change cipher spec messages, alerts and any other record types | Note: Change cipher spec messages, alerts and any other record types | |||
are not handshake messages and are not included in the hash | are not handshake messages and are not included in the hash | |||
computations. Also, Hello Request messages are omitted from | computations. Also, Hello Request messages are omitted from | |||
handshake hashes. | handshake hashes. | |||
8. Cryptographic computations | 8. Cryptographic computations | |||
In order to begin connection protection, the TLS Record Protocol | In order to begin connection protection, the TLS Record Protocol | |||
requires specification of a suite of algorithms, a master secret, | requires specification of a suite of algorithms, a master secret, and | |||
and the client and server random values. The authentication, | the client and server random values. The authentication, encryption, | |||
encryption, and MAC algorithms are determined by the cipher_suite | and MAC algorithms are determined by the cipher_suite selected by the | |||
selected by the server and revealed in the server hello message. The | server and revealed in the server hello message. The compression | |||
compression algorithm is negotiated in the hello messages, and the | algorithm is negotiated in the hello messages, and the random values | |||
random values are exchanged in the hello messages. All that remains | are exchanged in the hello messages. All that remains is to calculate | |||
is to calculate the master secret. | the master secret. | |||
8.1. Computing the master secret | 8.1. Computing the master secret | |||
For all key exchange methods, the same algorithm is used to convert | For all key exchange methods, the same algorithm is used to convert | |||
the pre_master_secret into the master_secret. The pre_master_secret | the pre_master_secret into the master_secret. The pre_master_secret | |||
should be deleted from memory once the master_secret has been | should be deleted from memory once the master_secret has been | |||
computed. | computed. | |||
master_secret = PRF(pre_master_secret, "master secret", | master_secret = PRF(pre_master_secret, "master secret", | |||
ClientHello.random + ServerHello.random) | ClientHello.random + ServerHello.random) | |||
[0..47]; | [0..47]; | |||
The master secret is always exactly 48 bytes in length. The length | The master secret is always exactly 48 bytes in length. The length of | |||
of the premaster secret will vary depending on key exchange method. | the premaster secret will vary depending on key exchange method. | |||
8.1.1. RSA | 8.1.1. RSA | |||
When RSA is used for server authentication and key exchange, a | When RSA is used for server authentication and key exchange, a 48- | |||
48-byte pre_master_secret is generated by the client, encrypted | byte pre_master_secret is generated by the client, encrypted under | |||
under the server's public key, and sent to the server. The server | the server's public key, and sent to the server. The server uses its | |||
uses its private key to decrypt the pre_master_secret. Both parties | private key to decrypt the pre_master_secret. Both parties then | |||
then convert the pre_master_secret into the master_secret, as | convert the pre_master_secret into the master_secret, as specified | |||
specified above. | above. | |||
RSA digital signatures are performed using PKCS #1 [PKCS1] block | RSA digital signatures are performed using PKCS #1 [PKCS1] block type | |||
type 1. RSA public key encryption is performed using PKCS #1 block | 1. RSA public key encryption is performed using PKCS #1 block type 2. | |||
type 2. | ||||
8.1.2. Diffie-Hellman | 8.1.2. Diffie-Hellman | |||
A conventional Diffie-Hellman computation is performed. The | A conventional Diffie-Hellman computation is performed. The | |||
negotiated key (Z) is used as the pre_master_secret, and is | negotiated key (Z) is used as the pre_master_secret, and is converted | |||
converted into the master_secret, as specified above. | into the master_secret, as specified above. | |||
Note: Diffie-Hellman parameters are specified by the server, and may | Note: Diffie-Hellman parameters are specified by the server, and may | |||
be either ephemeral or contained within the server's | be either ephemeral or contained within the server's certificate. | |||
certificate. | ||||
9. Mandatory Cipher Suites | 9. Mandatory Cipher Suites | |||
In the absence of an application profile standard specifying | In the absence of an application profile standard specifying | |||
otherwise, a TLS compliant application MUST implement the cipher | otherwise, a TLS compliant application MUST implement the cipher | |||
suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. | suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. | |||
10. Application data protocol | 10. Application data protocol | |||
Application data messages are carried by the Record Layer and are | Application data messages are carried by the Record Layer and are | |||
skipping to change at page 50, line 35 ¶ | skipping to change at page 54, line 23 ¶ | |||
struct { | struct { | |||
opaque verify_data[12]; | opaque verify_data[12]; | |||
} Finished; | } Finished; | |||
A.5. The CipherSuite | A.5. The CipherSuite | |||
The following values define the CipherSuite codes used in the client | The following values define the CipherSuite codes used in the client | |||
hello and server hello messages. | hello and server hello messages. | |||
A CipherSuite defines a cipher specification supported in TLS | A CipherSuite defines a cipher specification supported in TLS Version | |||
Version 1.0. | 1.0. | |||
TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a | TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a | |||
TLS connection during the first handshake on that channel, but must | TLS connection during the first handshake on that channel, but must | |||
not be negotiated, as it provides no more protection than an | not be negotiated, as it provides no more protection than an | |||
unsecured connection. | unsecured connection. | |||
CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 }; | CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 }; | |||
The following CipherSuite definitions require that the server | The following CipherSuite definitions require that the server provide | |||
provide an RSA certificate that can be used for key exchange. The | an RSA certificate that can be used for key exchange. The server may | |||
server may request either an RSA or a DSS signature-capable | request either an RSA or a DSS signature-capable certificate in the | |||
certificate in the certificate request message. | certificate request message. | |||
CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; | CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; | |||
CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }; | CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }; | |||
CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; | CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; | |||
CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; | CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; | |||
CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; | CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; | |||
CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; | CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; | |||
CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; | CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; | |||
CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; | CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; | |||
CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; | CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; | |||
CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; | CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; | |||
The following CipherSuite definitions are used for | The following CipherSuite definitions are used for server- | |||
server-authenticated (and optionally client-authenticated) | authenticated (and optionally client-authenticated) Diffie-Hellman. | |||
Diffie-Hellman. DH denotes cipher suites in which the server's | DH denotes cipher suites in which the server's certificate contains | |||
certificate contains the Diffie-Hellman parameters signed by the | the Diffie-Hellman parameters signed by the certificate authority | |||
certificate authority (CA). DHE denotes ephemeral Diffie-Hellman, | (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman | |||
where the Diffie-Hellman parameters are signed by a DSS or RSA | parameters are signed by a DSS or RSA certificate, which has been | |||
certificate, which has been signed by the CA. The signing algorithm | signed by the CA. The signing algorithm used is specified after the | |||
used is specified after the DH or DHE parameter. The server can | DH or DHE parameter. The server can request an RSA or DSS signature- | |||
request an RSA or DSS signature-capable certificate from the client | capable certificate from the client for client authentication or it | |||
for client authentication or it may request a Diffie-Hellman | may request a Diffie-Hellman certificate. Any Diffie-Hellman | |||
certificate. Any Diffie-Hellman certificate provided by the client | certificate provided by the client must use the parameters (group and | |||
must use the parameters (group and generator) described by the | generator) described by the server. | |||
server. | ||||
CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; | CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; | |||
CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }; | CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }; | |||
CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; | CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; | |||
CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; | CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; | |||
CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }; | CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }; | |||
CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; | CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; | |||
CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; | CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; | |||
CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }; | CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }; | |||
CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; | CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; | |||
CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; | CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; | |||
CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; | CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; | |||
CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; | CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; | |||
The following cipher suites are used for completely anonymous | The following cipher suites are used for completely anonymous | |||
Diffie-Hellman communications in which neither party is | Diffie-Hellman communications in which neither party is | |||
authenticated. Note that this mode is vulnerable to | authenticated. Note that this mode is vulnerable to man-in-the-middle | |||
man-in-the-middle attacks and is therefore deprecated. | attacks and is therefore deprecated. | |||
CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; | CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; | |||
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; | CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; | |||
CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; | CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; | |||
CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; | CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; | |||
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; | CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; | |||
Note: All cipher suites whose first byte is 0xFF are considered | Note: All cipher suites whose first byte is 0xFF are considered | |||
private and can be used for defining local/experimental | private and can be used for defining local/experimental | |||
algorithms. Interoperability of such types is a local matter. | algorithms. Interoperability of such types is a local matter. | |||
Note: Additional cipher suites can be registered by publishing an RFC | Note: Additional cipher suites can be registered by publishing an RFC | |||
which specifies the cipher suites, including the necessary TLS | which specifies the cipher suites, including the necessary TLS | |||
protocol information, including message encoding, premaster | protocol information, including message encoding, premaster | |||
secret derivation, symmetric encryption and MAC calculation and | secret derivation, symmetric encryption and MAC calculation and | |||
appropriate reference information for the algorithms involved. | appropriate reference information for the algorithms involved. | |||
The RFC editor's office may, at its discretion, choose to | The RFC editor's office may, at its discretion, choose to publish | |||
publish specifications for cipher suites which are not | specifications for cipher suites which are not completely | |||
completely described (e.g., for classified algorithms) if it | described (e.g., for classified algorithms) if it finds the | |||
finds the specification to be of technical interest and | specification to be of technical interest and completely | |||
completely specified. | specified. | |||
Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are | Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are | |||
reserved to avoid collision with Fortezza-based cipher suites in | reserved to avoid collision with Fortezza-based cipher suites in | |||
SSL 3. | SSL 3. | |||
A.6. The Security Parameters | A.6. The Security Parameters | |||
These security parameters are determined by the TLS Handshake | These security parameters are determined by the TLS Handshake | |||
Protocol and provided as parameters to the TLS Record Layer in order | Protocol and provided as parameters to the TLS Record Layer in order | |||
to initialize a connection state. SecurityParameters includes: | to initialize a connection state. SecurityParameters includes: | |||
skipping to change at page 53, line 17 ¶ | skipping to change at page 57, line 24 ¶ | |||
authentication | authentication | |||
Authentication is the ability of one entity to determine the | Authentication is the ability of one entity to determine the | |||
identity of another entity. | identity of another entity. | |||
block cipher | block cipher | |||
A block cipher is an algorithm that operates on plaintext in | A block cipher is an algorithm that operates on plaintext in | |||
groups of bits, called blocks. 64 bits is a common block size. | groups of bits, called blocks. 64 bits is a common block size. | |||
bulk cipher | bulk cipher | |||
A symmetric encryption algorithm used to encrypt large | A symmetric encryption algorithm used to encrypt large quantities | |||
quantities of data. | of data. | |||
cipher block chaining (CBC) | cipher block chaining (CBC) | |||
CBC is a mode in which every plaintext block encrypted with a | CBC is a mode in which every plaintext block encrypted with a | |||
block cipher is first exclusive-ORed with the previous | block cipher is first exclusive-ORed with the previous ciphertext | |||
ciphertext block (or, in the case of the first block, with the | block (or, in the case of the first block, with the | |||
initialization vector). For decryption, every block is first | initialization vector). For decryption, every block is first | |||
decrypted, then exclusive-ORed with the previous ciphertext | decrypted, then exclusive-ORed with the previous ciphertext block | |||
block (or IV). | (or IV). | |||
certificate | certificate | |||
As part of the X.509 protocol (a.k.a. ISO Authentication | As part of the X.509 protocol (a.k.a. ISO Authentication | |||
framework), certificates are assigned by a trusted Certificate | framework), certificates are assigned by a trusted Certificate | |||
Authority and provide a strong binding between a party's | Authority and provide a strong binding between a party's identity | |||
identity or some other attributes and its public key. | or some other attributes and its public key. | |||
client | client | |||
The application entity that initiates a TLS connection to a | The application entity that initiates a TLS connection to a | |||
server. This may or may not imply that the client initiated the | server. This may or may not imply that the client initiated the | |||
underlying transport connection. The primary operational | underlying transport connection. The primary operational | |||
difference between the server and client is that the server is | difference between the server and client is that the server is | |||
generally authenticated, while the client is only optionally | generally authenticated, while the client is only optionally | |||
authenticated. | authenticated. | |||
client write key | client write key | |||
skipping to change at page 54, line 5 ¶ | skipping to change at page 58, line 18 ¶ | |||
connection | connection | |||
A connection is a transport (in the OSI layering model | A connection is a transport (in the OSI layering model | |||
definition) that provides a suitable type of service. For TLS, | definition) that provides a suitable type of service. For TLS, | |||
such connections are peer to peer relationships. The connections | such connections are peer to peer relationships. The connections | |||
are transient. Every connection is associated with one session. | are transient. Every connection is associated with one session. | |||
Data Encryption Standard | Data Encryption Standard | |||
DES is a very widely used symmetric encryption algorithm. DES is | DES is a very widely used symmetric encryption algorithm. DES is | |||
a block cipher with a 56 bit key and an 8 byte block size. Note | a block cipher with a 56 bit key and an 8 byte block size. Note | |||
that in TLS, for key generation purposes, DES is treated as | that in TLS, for key generation purposes, DES is treated as | |||
having an 8 byte key length (64 bits), but it still only | having an 8 byte key length (64 bits), but it still only provides | |||
provides 56 bits of protection. (The low bit of each key byte is | 56 bits of protection. (The low bit of each key byte is presumed | |||
presumed to be set to produce odd parity in that key byte.) DES | to be set to produce odd parity in that key byte.) DES can also | |||
can also be operated in a mode where three independent keys and | be operated in a mode where three independent keys and three | |||
three encryptions are used for each block of data; this uses 168 | encryptions are used for each block of data; this uses 168 bits | |||
bits of key (24 bytes in the TLS key generation method) and | of key (24 bytes in the TLS key generation method) and provides | |||
provides the equivalent of 112 bits of security. [DES], [3DES] | the equivalent of 112 bits of security. [DES], [3DES] | |||
Digital Signature Standard (DSS) | Digital Signature Standard (DSS) | |||
A standard for digital signing, including the Digital Signing | A standard for digital signing, including the Digital Signing | |||
Algorithm, approved by the National Institute of Standards and | Algorithm, approved by the National Institute of Standards and | |||
Technology, defined in NIST FIPS PUB 186, "Digital Signature | Technology, defined in NIST FIPS PUB 186, "Digital Signature | |||
Standard," published May, 1994 by the U.S. Dept. of Commerce. | Standard," published May, 1994 by the U.S. Dept. of Commerce. | |||
[DSS] | [DSS] | |||
digital signatures | digital signatures | |||
Digital signatures utilize public key cryptography and one-way | Digital signatures utilize public key cryptography and one-way | |||
hash functions to produce a signature of the data that can be | hash functions to produce a signature of the data that can be | |||
authenticated, and is difficult to forge or repudiate. | authenticated, and is difficult to forge or repudiate. | |||
handshake | handshake | |||
An initial negotiation between client and server that | An initial negotiation between client and server that establishes | |||
establishes the parameters of their transactions. | the parameters of their transactions. | |||
Initialization Vector (IV) | Initialization Vector (IV) | |||
When a block cipher is used in CBC mode, the initialization | When a block cipher is used in CBC mode, the initialization | |||
vector is exclusive-ORed with the first plaintext block prior to | vector is exclusive-ORed with the first plaintext block prior to | |||
encryption. | encryption. | |||
IDEA | IDEA | |||
A 64-bit block cipher designed by Xuejia Lai and James Massey. | A 64-bit block cipher designed by Xuejia Lai and James Massey. | |||
[IDEA] | [IDEA] | |||
skipping to change at page 54, line 54 ¶ | skipping to change at page 59, line 21 ¶ | |||
master secret | master secret | |||
Secure secret data used for generating encryption keys, MAC | Secure secret data used for generating encryption keys, MAC | |||
secrets, and IVs. | secrets, and IVs. | |||
MD5 | MD5 | |||
MD5 is a secure hashing function that converts an arbitrarily | MD5 is a secure hashing function that converts an arbitrarily | |||
long data stream into a digest of fixed size (16 bytes). [MD5] | long data stream into a digest of fixed size (16 bytes). [MD5] | |||
public key cryptography | public key cryptography | |||
A class of cryptographic techniques employing two-key ciphers. | A class of cryptographic techniques employing two-key ciphers. | |||
Messages encrypted with the public key can only be decrypted | Messages encrypted with the public key can only be decrypted with | |||
with the associated private key. Conversely, messages signed | the associated private key. Conversely, messages signed with the | |||
with the private key can be verified with the public key. | private key can be verified with the public key. | |||
one-way hash function | one-way hash function | |||
A one-way transformation that converts an arbitrary amount of | A one-way transformation that converts an arbitrary amount of | |||
data into a fixed-length hash. It is computationally hard to | data into a fixed-length hash. It is computationally hard to | |||
reverse the transformation or to find collisions. MD5 and SHA | reverse the transformation or to find collisions. MD5 and SHA are | |||
are examples of one-way hash functions. | examples of one-way hash functions. | |||
RC2 | RC2 | |||
A block cipher developed by Ron Rivest at RSA Data Security, | A block cipher developed by Ron Rivest at RSA Data Security, Inc. | |||
Inc. [RSADSI] described in [RC2]. | [RSADSI] described in [RC2]. | |||
RC4 | RC4 | |||
A stream cipher licensed by RSA Data Security [RSADSI]. A | A stream cipher licensed by RSA Data Security [RSADSI]. A | |||
compatible cipher is described in [RC4]. | compatible cipher is described in [RC4]. | |||
RSA | RSA | |||
A very widely used public-key algorithm that can be used for | A very widely used public-key algorithm that can be used for | |||
either encryption or digital signing. [RSA] | either encryption or digital signing. [RSA] | |||
salt | salt | |||
Non-secret random data used to make export encryption keys | Non-secret random data used to make export encryption keys resist | |||
resist precomputation attacks. | precomputation attacks. | |||
server | server | |||
The server is the application entity that responds to requests | The server is the application entity that responds to requests | |||
for connections from clients. See also under client. | for connections from clients. See also under client. | |||
session | session | |||
A TLS session is an association between a client and a server. | A TLS session is an association between a client and a server. | |||
Sessions are created by the handshake protocol. Sessions define | Sessions are created by the handshake protocol. Sessions define a | |||
a set of cryptographic security parameters, which can be shared | set of cryptographic security parameters, which can be shared | |||
among multiple connections. Sessions are used to avoid the | among multiple connections. Sessions are used to avoid the | |||
expensive negotiation of new security parameters for each | expensive negotiation of new security parameters for each | |||
connection. | connection. | |||
session identifier | session identifier | |||
A session identifier is a value generated by a server that | A session identifier is a value generated by a server that | |||
identifies a particular session. | identifies a particular session. | |||
server write key | server write key | |||
The key used to encrypt data written by the server. | The key used to encrypt data written by the server. | |||
skipping to change at page 58, line 25 ¶ | skipping to change at page 64, line 5 ¶ | |||
The amount of data a block cipher enciphers in one chunk; a | The amount of data a block cipher enciphers in one chunk; a | |||
block cipher running in CBC mode can only encrypt an even | block cipher running in CBC mode can only encrypt an even | |||
multiple of its block size. | multiple of its block size. | |||
Hash Hash Padding | Hash Hash Padding | |||
function Size Size | function Size Size | |||
NULL 0 0 | NULL 0 0 | |||
MD5 16 48 | MD5 16 48 | |||
SHA 20 40 | SHA 20 40 | |||
Appendix D | ||||
D. Implementation Notes | D. Implementation Notes | |||
The TLS protocol cannot prevent many common security mistakes. This | The TLS protocol cannot prevent many common security mistakes. This | |||
section provides several recommendations to assist implementors. | section provides several recommendations to assist implementors. | |||
D.1. Temporary RSA keys | D.1. Temporary RSA keys | |||
US Export restrictions limit RSA keys used for encryption to 512 | 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 | bits, but do not place any limit on lengths of RSA keys used for | |||
signing operations. Certificates often need to be larger than 512 | signing operations. Certificates often need to be larger than 512 | |||
bits, since 512-bit RSA keys are not secure enough for high-value | bits, since 512-bit RSA keys are not secure enough for high-value | |||
transactions or for applications requiring long-term security. Some | transactions or for applications requiring long-term security. Some | |||
certificates are also designated signing-only, in which case they | certificates are also designated signing-only, in which case they | |||
cannot be used for key exchange. | cannot be used for key exchange. | |||
When the public key in the certificate cannot be used for | When the public key in the certificate cannot be used for encryption, | |||
encryption, the server signs a temporary RSA key, which is then | the server signs a temporary RSA key, which is then exchanged. In | |||
exchanged. In exportable applications, the temporary RSA key should | exportable applications, the temporary RSA key should be the maximum | |||
be the maximum allowable length (i.e., 512 bits). Because 512-bit | allowable length (i.e., 512 bits). Because 512-bit RSA keys are | |||
RSA keys are relatively insecure, they should be changed often. For | relatively insecure, they should be changed often. For typical | |||
typical electronic commerce applications, it is suggested that keys | electronic commerce applications, it is suggested that keys be | |||
be changed daily or every 500 transactions, and more often if | changed daily or every 500 transactions, and more often if possible. | |||
possible. Note that while it is acceptable to use the same temporary | Note that while it is acceptable to use the same temporary key for | |||
key for multiple transactions, it must be signed each time it is | multiple transactions, it must be signed each time it is used. | |||
used. | ||||
RSA key generation is a time-consuming process. In many cases, a | RSA key generation is a time-consuming process. In many cases, a | |||
low-priority process can be assigned the task of key generation. | low-priority process can be assigned the task of key generation. | |||
Whenever a new key is completed, the existing temporary key can be | Whenever a new key is completed, the existing temporary key can be | |||
replaced with the new one. | replaced with the new one. | |||
D.2. Random Number Generation and Seeding | D.2. Random Number Generation and Seeding | |||
TLS requires a cryptographically-secure pseudorandom number | TLS requires a cryptographically-secure pseudorandom number generator | |||
generator (PRNG). Care must be taken in designing and seeding PRNGs. | (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs | |||
PRNGs based on secure hash operations, most notably MD5 and/or SHA, | based on secure hash operations, most notably MD5 and/or SHA, are | |||
are acceptable, but cannot provide more security than the size of | acceptable, but cannot provide more security than the size of the | |||
the random number generator state. (For example, MD5-based PRNGs | random number generator state. (For example, MD5-based PRNGs usually | |||
usually provide 128 bits of state.) | provide 128 bits of state.) | |||
To estimate the amount of seed material being produced, add the | To estimate the amount of seed material being produced, add the | |||
number of bits of unpredictable information in each seed byte. For | number of bits of unpredictable information in each seed byte. For | |||
example, keystroke timing values taken from a PC compatible's 18.2 | example, keystroke timing values taken from a PC compatible's 18.2 Hz | |||
Hz timer provide 1 or 2 secure bits each, even though the total size | timer provide 1 or 2 secure bits each, even though the total size of | |||
of the counter value is 16 bits or more. To seed a 128-bit PRNG, one | the counter value is 16 bits or more. To seed a 128-bit PRNG, one | |||
would thus require approximately 100 such timer values. | would thus require approximately 100 such timer values. | |||
Warning: The seeding functions in RSAREF and versions of BSAFE prior to | Warning: The seeding functions in RSAREF and versions of BSAFE prior to | |||
3.0 are order-independent. For example, if 1000 seed bits are | 3.0 are order-independent. For example, if 1000 seed bits are | |||
supplied, one at a time, in 1000 separate calls to the seed | supplied, one at a time, in 1000 separate calls to the seed | |||
function, the PRNG will end up in a state which depends only | function, the PRNG will end up in a state which depends only | |||
on the number of 0 or 1 seed bits in the seed data (i.e., | on the number of 0 or 1 seed bits in the seed data (i.e., | |||
there are 1001 possible final states). Applications using | there are 1001 possible final states). Applications using | |||
BSAFE or RSAREF must take extra care to ensure proper seeding. | BSAFE or RSAREF must take extra care to ensure proper seeding. | |||
This may be accomplished by accumulating seed bits into a | This may be accomplished by accumulating seed bits into a | |||
buffer and processing them all at once or by processing an | buffer and processing them all at once or by processing an | |||
incrementing counter with every seed bit; either method will | incrementing counter with every seed bit; either method will | |||
reintroduce order dependence into the seeding process. | reintroduce order dependence into the seeding process. | |||
D.3. Certificates and authentication | D.3. Certificates and authentication | |||
Implementations are responsible for verifying the integrity of | Implementations are responsible for verifying the integrity of | |||
certificates and should generally support certificate revocation | certificates and should generally support certificate revocation | |||
messages. Certificates should always be verified to ensure proper | messages. Certificates should always be verified to ensure proper | |||
signing by a trusted Certificate Authority (CA). The selection and | signing by a trusted Certificate Authority (CA). The selection and | |||
addition of trusted CAs should be done very carefully. Users should | addition of trusted CAs should be done very carefully. Users should | |||
be able to view information about the certificate and root CA. | be able to view information about the certificate and root CA. | |||
D.4. CipherSuites | D.4. CipherSuites | |||
TLS supports a range of key sizes and security levels, including | TLS supports a range of key sizes and security levels, including some | |||
some which provide no or minimal security. A proper implementation | which provide no or minimal security. A proper implementation will | |||
will probably not support many cipher suites. For example, 40-bit | probably not support many cipher suites. For example, 40-bit | |||
encryption is easily broken, so implementations requiring strong | encryption is easily broken, so implementations requiring strong | |||
security should not allow 40-bit keys. Similarly, anonymous | security should not allow 40-bit keys. Similarly, anonymous Diffie- | |||
Diffie-Hellman is strongly discouraged because it cannot prevent | Hellman is strongly discouraged because it cannot prevent man-in- | |||
man-in-the-middle attacks. Applications should also enforce minimum | the-middle attacks. Applications should also enforce minimum and | |||
and maximum key sizes. For example, certificate chains containing | maximum key sizes. For example, certificate chains containing 512-bit | |||
512-bit RSA keys or signatures are not appropriate for high-security | RSA keys or signatures are not appropriate for high-security | |||
applications. | applications. | |||
E. Backward Compatibility With SSL | E. Backward Compatibility With SSL | |||
For historical reasons and in order to avoid a profligate | For historical reasons and in order to avoid a profligate consumption | |||
consumption of reserved port numbers, application protocols which | of reserved port numbers, application protocols which are secured by | |||
are secured by TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share | TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same | |||
the same connection port: for example, the https protocol (HTTP | connection port: for example, the https protocol (HTTP secured by SSL | |||
secured by SSL or TLS) uses port 443 regardless of which security | or TLS) uses port 443 regardless of which security protocol it is | |||
protocol it is using. Thus, some mechanism must be determined to | using. Thus, some mechanism must be determined to distinguish and | |||
distinguish and negotiate among the various protocols. | negotiate among the various protocols. | |||
TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both | TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both | |||
is easy. TLS clients who wish to negotiate with SSL 3.0 servers | is easy. TLS clients who wish to negotiate with SSL 3.0 servers | |||
should send client hello messages using the SSL 3.0 record format | should send client hello messages using the SSL 3.0 record format and | |||
and client hello structure, sending {3, 1} for the version field to | client hello structure, sending {3, 1} for the version field to note | |||
note that they support TLS 1.0. If the server supports only SSL 3.0, | that they support TLS 1.0. If the server supports only SSL 3.0, it | |||
it will respond with an SSL 3.0 server hello; if it supports TLS, | will respond with an SSL 3.0 server hello; if it supports TLS, with a | |||
with a TLS server hello. The negotiation then proceeds as | TLS server hello. The negotiation then proceeds as appropriate for | |||
appropriate for the negotiated protocol. | the negotiated protocol. | |||
Similarly, a TLS server which wishes to interoperate with SSL 3.0 | Similarly, a TLS server which wishes to interoperate with SSL 3.0 | |||
clients should accept SSL 3.0 client hello messages and respond with | clients should accept SSL 3.0 client hello messages and respond with | |||
an SSL 3.0 server hello if an SSL 3.0 client hello is received which | an SSL 3.0 server hello if an SSL 3.0 client hello is received which | |||
has a version field of {3, 0}, denoting that this client does not | has a version field of {3, 0}, denoting that this client does not | |||
support TLS. | support TLS. | |||
Whenever a client already knows the highest protocol known to a | Whenever a client already knows the highest protocol known to a | |||
server (for example, when resuming a session), it should initiate | server (for example, when resuming a session), it should initiate the | |||
the connection in that native protocol. | connection in that native protocol. | |||
TLS 1.0 clients that support SSL Version 2.0 servers must send SSL | TLS 1.0 clients that support SSL Version 2.0 servers must send SSL | |||
Version 2.0 client hello messages [SSL2]. TLS servers should accept | Version 2.0 client hello messages [SSL2]. TLS servers should accept | |||
either client hello format if they wish to support SSL 2.0 clients | either client hello format if they wish to support SSL 2.0 clients on | |||
on the same connection port. The only deviations from the Version | the same connection port. The only deviations from the Version 2.0 | |||
2.0 specification are the ability to specify a version with a value | specification are the ability to specify a version with a value of | |||
of three and the support for more ciphering types in the CipherSpec. | three and the support for more ciphering types in the CipherSpec. | |||
Warning: The ability to send Version 2.0 client hello messages will be | Warning: The ability to send Version 2.0 client hello messages will be | |||
phased out with all due haste. Implementors should make every | phased out with all due haste. Implementors should make every | |||
effort to move forward as quickly as possible. Version 3.0 | effort to move forward as quickly as possible. Version 3.0 | |||
provides better mechanisms for moving to newer versions. | provides better mechanisms for moving to newer versions. | |||
The following cipher specifications are carryovers from SSL Version | The following cipher specifications are carryovers from SSL Version | |||
2.0. These are assumed to use RSA for key exchange and | 2.0. These are assumed to use RSA for key exchange and | |||
authentication. | authentication. | |||
V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 }; | V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 }; | |||
V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 }; | V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 }; | |||
V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 }; | V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 }; | |||
V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 | V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 | |||
= { 0x04,0x00,0x80 }; | = { 0x04,0x00,0x80 }; | |||
skipping to change at page 62, line 16 ¶ | skipping to change at page 68, line 25 ¶ | |||
This is a list of all CipherSpecs the client is willing and able | 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 | to use. There must be at least one CipherSpec acceptable to the | |||
server. | server. | |||
session_id | session_id | |||
If this field's length is not zero, it will contain the | If this field's length is not zero, it will contain the | |||
identification for a session that the client wishes to resume. | identification for a session that the client wishes to resume. | |||
challenge | challenge | |||
The client challenge to the server for the server to identify | The client challenge to the server for the server to identify | |||
itself is a (nearly) arbitrary length random. The TLS server | itself is a (nearly) arbitrary length random. The TLS server will | |||
will right justify the challenge data to become the | right justify the challenge data to become the ClientHello.random | |||
ClientHello.random data (padded with leading zeroes, if | data (padded with leading zeroes, if necessary), as specified in | |||
necessary), as specified in this protocol specification. If the | this protocol specification. If the length of the challenge is | |||
length of the challenge is greater than 32 bytes, only the last | greater than 32 bytes, only the last 32 bytes are used. It is | |||
32 bytes are used. It is legitimate (but not necessary) for a V3 | legitimate (but not necessary) for a V3 server to reject a V2 | |||
server to reject a V2 ClientHello that has fewer than 16 bytes | ClientHello that has fewer than 16 bytes of challenge data. | |||
of challenge data. | ||||
Note: Requests to resume a TLS session should use a TLS client hello. | Note: Requests to resume a TLS session should use a TLS client hello. | |||
E.2. Avoiding man-in-the-middle version rollback | E.2. Avoiding man-in-the-middle version rollback | |||
When TLS clients fall back to Version 2.0 compatibility mode, they | When TLS clients fall back to Version 2.0 compatibility mode, they | |||
should use special PKCS #1 block formatting. This is done so that | should use special PKCS #1 block formatting. This is done so that TLS | |||
TLS servers will reject Version 2.0 sessions with TLS-capable | servers will reject Version 2.0 sessions with TLS-capable clients. | |||
clients. | ||||
When TLS clients are in Version 2.0 compatibility mode, they set the | When TLS clients are in Version 2.0 compatibility mode, they set the | |||
right-hand (least-significant) 8 random bytes of the PKCS padding | right-hand (least-significant) 8 random bytes of the PKCS padding | |||
(not including the terminal null of the padding) for the RSA | (not including the terminal null of the padding) for the RSA | |||
encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY | encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY | |||
to 0x03 (the other padding bytes are random). After decrypting the | to 0x03 (the other padding bytes are random). After decrypting the | |||
ENCRYPTED-KEY-DATA field, servers that support TLS should issue an | ENCRYPTED-KEY-DATA field, servers that support TLS should issue an | |||
error if these eight padding bytes are 0x03. Version 2.0 servers | error if these eight padding bytes are 0x03. Version 2.0 servers | |||
receiving blocks padded in this manner will proceed normally. | receiving blocks padded in this manner will proceed normally. | |||
Appendix F | ||||
F. Security analysis | F. Security analysis | |||
The TLS protocol is designed to establish a secure connection | The TLS protocol is designed to establish a secure connection between | |||
between a client and a server communicating over an insecure | a client and a server communicating over an insecure channel. This | |||
channel. This document makes several traditional assumptions, | document makes several traditional assumptions, including that | |||
including that attackers have substantial computational resources | attackers have substantial computational resources and cannot obtain | |||
and cannot obtain secret information from sources outside the | secret information from sources outside the protocol. Attackers are | |||
protocol. Attackers are assumed to have the ability to capture, | assumed to have the ability to capture, modify, delete, replay, and | |||
modify, delete, replay, and otherwise tamper with messages sent over | otherwise tamper with messages sent over the communication channel. | |||
the communication channel. This appendix outlines how TLS has been | This appendix outlines how TLS has been designed to resist a variety | |||
designed to resist a variety of attacks. | of attacks. | |||
F.1. Handshake protocol | F.1. Handshake protocol | |||
The handshake protocol is responsible for selecting a CipherSpec and | The handshake protocol is responsible for selecting a CipherSpec and | |||
generating a Master Secret, which together comprise the primary | generating a Master Secret, which together comprise the primary | |||
cryptographic parameters associated with a secure session. The | cryptographic parameters associated with a secure session. The | |||
handshake protocol can also optionally authenticate parties who have | handshake protocol can also optionally authenticate parties who have | |||
certificates signed by a trusted certificate authority. | certificates signed by a trusted certificate authority. | |||
F.1.1. Authentication and key exchange | F.1.1. Authentication and key exchange | |||
TLS supports three authentication modes: authentication of both | TLS supports three authentication modes: authentication of both | |||
parties, server authentication with an unauthenticated client, and | parties, server authentication with an unauthenticated client, and | |||
total anonymity. Whenever the server is authenticated, the channel | total anonymity. Whenever the server is authenticated, the channel is | |||
is secure against man-in-the-middle attacks, but completely | secure against man-in-the-middle attacks, but completely anonymous | |||
anonymous sessions are inherently vulnerable to such attacks. | sessions are inherently vulnerable to such attacks. Anonymous | |||
Anonymous servers cannot authenticate clients. If the server is | servers cannot authenticate clients. If the server is authenticated, | |||
authenticated, its certificate message must provide a valid | its certificate message must provide a valid certificate chain | |||
certificate chain leading to an acceptable certificate authority. | leading to an acceptable certificate authority. Similarly, | |||
Similarly, authenticated clients must supply an acceptable | authenticated clients must supply an acceptable certificate to the | |||
certificate to the server. Each party is responsible for verifying | server. Each party is responsible for verifying that the other's | |||
that the other's certificate is valid and has not expired or been | certificate is valid and has not expired or been revoked. | |||
revoked. | ||||
The general goal of the key exchange process is to create a | The general goal of the key exchange process is to create a | |||
pre_master_secret known to the communicating parties and not to | pre_master_secret known to the communicating parties and not to | |||
attackers. The pre_master_secret will be used to generate the | attackers. The pre_master_secret will be used to generate the | |||
master_secret (see Section 8.1). The master_secret is required to | master_secret (see Section 8.1). The master_secret is required to | |||
generate the certificate verify and finished messages, encryption | generate the certificate verify and finished messages, encryption | |||
keys, and MAC secrets (see Sections 7.4.8, 7.4.9 and 6.3). By | keys, and MAC secrets (see Sections 7.4.8, 7.4.9 and 6.3). By sending | |||
sending a correct finished message, parties thus prove that they | a correct finished message, parties thus prove that they know the | |||
know the correct pre_master_secret. | correct pre_master_secret. | |||
F.1.1.1. Anonymous key exchange | F.1.1.1. Anonymous key exchange | |||
Completely anonymous sessions can be established using RSA or | Completely anonymous sessions can be established using RSA or | |||
Diffie-Hellman for key exchange. With anonymous RSA, the client | Diffie-Hellman for key exchange. With anonymous RSA, the client | |||
encrypts a pre_master_secret with the server's uncertified public | encrypts a pre_master_secret with the server's uncertified public key | |||
key extracted from the server key exchange message. The result is | extracted from the server key exchange message. The result is sent in | |||
sent in a client key exchange message. Since eavesdroppers do not | a client key exchange message. Since eavesdroppers do not know the | |||
know the server's private key, it will be infeasible for them to | server's private key, it will be infeasible for them to decode the | |||
decode the pre_master_secret. (Note that no anonymous RSA Cipher | pre_master_secret. (Note that no anonymous RSA Cipher Suites are | |||
Suites are defined in this document). | defined in this document). | |||
With Diffie-Hellman, the server's public parameters are contained in | With Diffie-Hellman, the server's public parameters are contained in | |||
the server key exchange message and the client's are sent in the | the server key exchange message and the client's are sent in the | |||
client key exchange message. Eavesdroppers who do not know the | client key exchange message. Eavesdroppers who do not know the | |||
private values should not be able to find the Diffie-Hellman result | private values should not be able to find the Diffie-Hellman result | |||
(i.e. the pre_master_secret). | (i.e. the pre_master_secret). | |||
Warning: Completely anonymous connections only provide protection | Warning: Completely anonymous connections only provide protection | |||
against passive eavesdropping. Unless an independent | against passive eavesdropping. Unless an independent tamper- | |||
tamper-proof channel is used to verify that the finished | proof channel is used to verify that the finished messages | |||
messages were not replaced by an attacker, server | were not replaced by an attacker, server authentication is | |||
authentication is required in environments where active | required in environments where active man-in-the-middle | |||
man-in-the-middle attacks are a concern. | attacks are a concern. | |||
F.1.1.2. RSA key exchange and authentication | F.1.1.2. RSA key exchange and authentication | |||
With RSA, key exchange and server authentication are combined. The | With RSA, key exchange and server authentication are combined. The | |||
public key may be either contained in the server's certificate or | public key may be either contained in the server's certificate or may | |||
may be a temporary RSA key sent in a server key exchange message. | be a temporary RSA key sent in a server key exchange message. When | |||
When temporary RSA keys are used, they are signed by the server's | temporary RSA keys are used, they are signed by the server's RSA or | |||
RSA or DSS certificate. The signature includes the current | DSS certificate. The signature includes the current | |||
ClientHello.random, so old signatures and temporary keys cannot be | ClientHello.random, so old signatures and temporary keys cannot be | |||
replayed. Servers may use a single temporary RSA key for multiple | replayed. Servers may use a single temporary RSA key for multiple | |||
negotiation sessions. | negotiation sessions. | |||
Note: The temporary RSA key option is useful if servers need large | Note: The temporary RSA key option is useful if servers need large | |||
certificates but must comply with government-imposed size limits | certificates but must comply with government-imposed size limits | |||
on keys used for key exchange. | on keys used for key exchange. | |||
After verifying the server's certificate, the client encrypts a | After verifying the server's certificate, the client encrypts a | |||
pre_master_secret with the server's public key. By successfully | pre_master_secret with the server's public key. By successfully | |||
skipping to change at page 65, line 6 ¶ | skipping to change at page 71, line 27 ¶ | |||
parameters, its certificate contains the information required to | parameters, its certificate contains the information required to | |||
complete the key exchange. Note that in this case the client and | complete the key exchange. Note that in this case the client and | |||
server will generate the same Diffie-Hellman result (i.e., | server will generate the same Diffie-Hellman result (i.e., | |||
pre_master_secret) every time they communicate. To prevent the | pre_master_secret) every time they communicate. To prevent the | |||
pre_master_secret from staying in memory any longer than necessary, | pre_master_secret from staying in memory any longer than necessary, | |||
it should be converted into the master_secret as soon as possible. | it should be converted into the master_secret as soon as possible. | |||
Client Diffie-Hellman parameters must be compatible with those | Client Diffie-Hellman parameters must be compatible with those | |||
supplied by the server for the key exchange to work. | supplied by the server for the key exchange to work. | |||
If the client has a standard DSS or RSA certificate or is | If the client has a standard DSS or RSA certificate or is | |||
unauthenticated, it sends a set of temporary parameters to the | unauthenticated, it sends a set of temporary parameters to the server | |||
server in the client key exchange message, then optionally uses a | in the client key exchange message, then optionally uses a | |||
certificate verify message to authenticate itself. | certificate verify message to authenticate itself. | |||
F.1.2. Version rollback attacks | F.1.2. Version rollback attacks | |||
Because TLS includes substantial improvements over SSL Version 2.0, | Because TLS includes substantial improvements over SSL Version 2.0, | |||
attackers may try to make TLS-capable clients and servers fall back | attackers may try to make TLS-capable clients and servers fall back | |||
to Version 2.0. This attack can occur if (and only if) two | to Version 2.0. This attack can occur if (and only if) two TLS- | |||
TLS-capable parties use an SSL 2.0 handshake. | capable parties use an SSL 2.0 handshake. | |||
Although the solution using non-random PKCS #1 block type 2 message | Although the solution using non-random PKCS #1 block type 2 message | |||
padding is inelegant, it provides a reasonably secure way for | padding is inelegant, it provides a reasonably secure way for Version | |||
Version 3.0 servers to detect the attack. This solution is not | 3.0 servers to detect the attack. This solution is not secure against | |||
secure against attackers who can brute force the key and substitute | attackers who can brute force the key and substitute a new | |||
a new ENCRYPTED-KEY-DATA message containing the same key (but with | ENCRYPTED-KEY-DATA message containing the same key (but with normal | |||
normal padding) before the application specified wait threshold has | padding) before the application specified wait threshold has expired. | |||
expired. Parties concerned about attacks of this scale should not be | Parties concerned about attacks of this scale should not be using | |||
using 40-bit encryption keys anyway. Altering the padding of the | 40-bit encryption keys anyway. Altering the padding of the least- | |||
least-significant 8 bytes of the PKCS padding does not impact | significant 8 bytes of the PKCS padding does not impact security for | |||
security for the size of the signed hashes and RSA key lengths used | the size of the signed hashes and RSA key lengths used in the | |||
in the protocol, since this is essentially equivalent to increasing | protocol, since this is essentially equivalent to increasing the | |||
the input block size by 8 bytes. | input block size by 8 bytes. | |||
F.1.3. Detecting attacks against the handshake protocol | F.1.3. Detecting attacks against the handshake protocol | |||
An attacker might try to influence the handshake exchange to make | An attacker might try to influence the handshake exchange to make the | |||
the parties select different encryption algorithms than they would | parties select different encryption algorithms than they would | |||
normally choose. Because many implementations will support 40-bit | normally choose. Because many implementations will support 40-bit | |||
exportable encryption and some may even support null encryption or | exportable encryption and some may even support null encryption or | |||
MAC algorithms, this attack is of particular concern. | MAC algorithms, this attack is of particular concern. | |||
For this attack, an attacker must actively change one or more | For this attack, an attacker must actively change one or more | |||
handshake messages. If this occurs, the client and server will | handshake messages. If this occurs, the client and server will | |||
compute different values for the handshake message hashes. As a | compute different values for the handshake message hashes. As a | |||
result, the parties will not accept each others' finished messages. | result, the parties will not accept each others' finished messages. | |||
Without the master_secret, the attacker cannot repair the finished | Without the master_secret, the attacker cannot repair the finished | |||
messages, so the attack will be discovered. | messages, so the attack will be discovered. | |||
F.1.4. Resuming sessions | F.1.4. Resuming sessions | |||
When a connection is established by resuming a session, new | When a connection is established by resuming a session, new | |||
ClientHello.random and ServerHello.random values are hashed with the | ClientHello.random and ServerHello.random values are hashed with the | |||
session's master_secret. Provided that the master_secret has not | session's master_secret. Provided that the master_secret has not been | |||
been compromised and that the secure hash operations used to produce | compromised and that the secure hash operations used to produce the | |||
the encryption keys and MAC secrets are secure, the connection | encryption keys and MAC secrets are secure, the connection should be | |||
should be secure and effectively independent from previous | secure and effectively independent from previous connections. | |||
connections. Attackers cannot use known encryption keys or MAC | Attackers cannot use known encryption keys or MAC secrets to | |||
secrets to compromise the master_secret without breaking the secure | compromise the master_secret without breaking the secure hash | |||
hash operations (which use both SHA and MD5). | operations (which use both SHA and MD5). | |||
Sessions cannot be resumed unless both the client and server agree. | Sessions cannot be resumed unless both the client and server agree. | |||
If either party suspects that the session may have been compromised, | If either party suspects that the session may have been compromised, | |||
or that certificates may have expired or been revoked, it should | or that certificates may have expired or been revoked, it should | |||
force a full handshake. An upper limit of 24 hours is suggested for | force a full handshake. An upper limit of 24 hours is suggested for | |||
session ID lifetimes, since an attacker who obtains a master_secret | session ID lifetimes, since an attacker who obtains a master_secret | |||
may be able to impersonate the compromised party until the | may be able to impersonate the compromised party until the | |||
corresponding session ID is retired. Applications that may be run in | corresponding session ID is retired. Applications that may be run in | |||
relatively insecure environments should not write session IDs to | relatively insecure environments should not write session IDs to | |||
stable storage. | stable storage. | |||
F.1.5. MD5 and SHA | F.1.5. MD5 and SHA | |||
TLS uses hash functions very conservatively. Where possible, both | TLS uses hash functions very conservatively. Where possible, both MD5 | |||
MD5 and SHA are used in tandem to ensure that non-catastrophic flaws | and SHA are used in tandem to ensure that non-catastrophic flaws in | |||
in one algorithm will not break the overall protocol. | one algorithm will not break the overall protocol. | |||
F.2. Protecting application data | F.2. Protecting application data | |||
The master_secret is hashed with the ClientHello.random and | The master_secret is hashed with the ClientHello.random and | |||
ServerHello.random to produce unique data encryption keys and MAC | ServerHello.random to produce unique data encryption keys and MAC | |||
secrets for each connection. | secrets for each connection. | |||
Outgoing data is protected with a MAC before transmission. To | Outgoing data is protected with a MAC before transmission. To prevent | |||
prevent message replay or modification attacks, the MAC is computed | message replay or modification attacks, the MAC is computed from the | |||
from the MAC secret, the sequence number, the message length, the | MAC secret, the sequence number, the message length, the message | |||
message contents, and two fixed character strings. The message type | contents, and two fixed character strings. The message type field is | |||
field is necessary to ensure that messages intended for one TLS | necessary to ensure that messages intended for one TLS Record Layer | |||
Record Layer client are not redirected to another. The sequence | client are not redirected to another. The sequence number ensures | |||
number ensures that attempts to delete or reorder messages will be | that attempts to delete or reorder messages will be detected. Since | |||
detected. Since sequence numbers are 64-bits long, they should never | sequence numbers are 64-bits long, they should never overflow. | |||
overflow. Messages from one party cannot be inserted into the | Messages from one party cannot be inserted into the other's output, | |||
other's output, since they use independent MAC secrets. Similarly, | since they use independent MAC secrets. Similarly, the server-write | |||
the server-write and client-write keys are independent so stream | and client-write keys are independent so stream cipher keys are used | |||
cipher keys are used only once. | only once. | |||
If an attacker does break an encryption key, all messages encrypted | If an attacker does break an encryption key, all messages encrypted | |||
with it can be read. Similarly, compromise of a MAC key can make | with it can be read. Similarly, compromise of a MAC key can make | |||
message modification attacks possible. Because MACs are also | message modification attacks possible. Because MACs are also | |||
encrypted, message-alteration attacks generally require breaking the | encrypted, message-alteration attacks generally require breaking the | |||
encryption algorithm as well as the MAC. | encryption algorithm as well as the MAC. | |||
Note: MAC secrets may be larger than encryption keys, so messages can | Note: MAC secrets may be larger than encryption keys, so messages can | |||
remain tamper resistant even if encryption keys are broken. | remain tamper resistant even if encryption keys are broken. | |||
F.3. Final notes | F.3. Final notes | |||
For TLS to be able to provide a secure connection, both the client | For TLS to be able to provide a secure connection, both the client | |||
and server systems, keys, and applications must be secure. In | and server systems, keys, and applications must be secure. In | |||
addition, the implementation must be free of security errors. | addition, the implementation must be free of security errors. | |||
The system is only as strong as the weakest key exchange and | The system is only as strong as the weakest key exchange and | |||
authentication algorithm supported, and only trustworthy | authentication algorithm supported, and only trustworthy | |||
cryptographic functions should be used. Short public keys, 40-bit | cryptographic functions should be used. Short public keys, 40-bit | |||
bulk encryption keys, and anonymous servers should be used with | bulk encryption keys, and anonymous servers should be used with great | |||
great caution. Implementations and users must be careful when | caution. Implementations and users must be careful when deciding | |||
deciding which certificates and certificate authorities are | which certificates and certificate authorities are acceptable; a | |||
acceptable; a dishonest certificate authority can do tremendous | dishonest certificate authority can do tremendous damage. | |||
damage. | ||||
Appendix G | ||||
G. Patent Statement | G. Patent Statement | |||
Some of the cryptographic algorithms proposed for use in this | Some of the cryptographic algorithms proposed for use in this | |||
protocol have patent claims on them. In addition Netscape | protocol have patent claims on them. In addition Netscape | |||
Communications Corporation has a patent claim on the Secure Sockets | Communications Corporation has a patent claim on the Secure Sockets | |||
Layer (SSL) work that this standard is based on. The Internet | Layer (SSL) work that this standard is based on. The Internet | |||
Standards Process as defined in RFC 1310 requires a written | Standards Process as defined in RFC 2026 requests that a statement be | |||
statement from the Patent holder that a license will be made | obtained from a Patent holder indicating that a license will be made | |||
available to applicants under reasonable terms and conditions prior | available to applicants under reasonable terms and conditions. | |||
to approving a specification as a Proposed, Draft or Internet | ||||
Standard. | ||||
The Massachusetts Institute of Technology has granted RSA Data | The Massachusetts Institute of Technology has granted RSA Data | |||
Security, Inc., exclusive sub-licensing rights to the following | Security, Inc., exclusive sub-licensing rights to the following | |||
patent issued in the United States: | patent issued in the United States: | |||
Cryptographic Communications System and Method ("RSA"), No. | Cryptographic Communications System and Method ("RSA"), No. | |||
4,405,829 | 4,405,829 | |||
Netscape Communications Corporation has been issued the following | Netscape Communications Corporation has been issued the following | |||
patent in the United States: | patent in the United States: | |||
skipping to change at page 68, line 11 ¶ | skipping to change at page 74, line 48 ¶ | |||
transport protocol with security features. Netscape encourages | transport protocol with security features. Netscape encourages | |||
the royalty-free adoption and use of the SSL protocol upon the | the royalty-free adoption and use of the SSL protocol upon the | |||
following terms and conditions: | following terms and conditions: | |||
* If you already have a valid SSL Ref license today which | * If you already have a valid SSL Ref license today which | |||
includes source code from Netscape, an additional patent | includes source code from Netscape, an additional patent | |||
license under the SSL patent is not required. | license under the SSL patent is not required. | |||
* If you don't have an SSL Ref license, you may have a royalty | * If you don't have an SSL Ref license, you may have a royalty | |||
free license to build implementations covered by the SSL | free license to build implementations covered by the SSL | |||
Patent Claims or the IETF TLS specification provided that | Patent Claims or the IETF TLS specification provided that you | |||
you do not to assert any patent rights against Netscape or | do not to assert any patent rights against Netscape or other | |||
other companies for the implementation of SSL or the IETF | companies for the implementation of SSL or the IETF TLS | |||
TLS recommendation. | recommendation. | |||
What are "Patent Claims": | What are "Patent Claims": | |||
Patent claims are claims in an issued foreign or domestic patent | Patent claims are claims in an issued foreign or domestic patent | |||
that: | that: | |||
1) must be infringed in order to implement methods or build | 1) must be infringed in order to implement methods or build | |||
products according to the IETF TLS specification; or | products according to the IETF TLS specification; or | |||
2) patent claims which require the elements of the SSL patent | 2) patent claims which require the elements of the SSL patent | |||
claims and/or their equivalents to be infringed. | claims and/or their equivalents to be infringed. | |||
The Internet Society, Internet Architecture Board, Internet | The Internet Society, Internet Architecture Board, Internet | |||
Engineering Steering Group and the Corporation for National Research | Engineering Steering Group and the Corporation for National Research | |||
Initiatives take no position on the validity or scope of the patents | Initiatives take no position on the validity or scope of the patents | |||
and patent applications, nor on the appropriateness of the terms of | and patent applications, nor on the appropriateness of the terms of | |||
the assurance. The Internet Society and other groups mentioned above | the assurance. The Internet Society and other groups mentioned above | |||
have not made any determination as to any other intellectual | have not made any determination as to any other intellectual property | |||
property rights which may apply to the practice of this standard. | rights which may apply to the practice of this standard. Any further | |||
Any further consideration of these matters is the user's own | consideration of these matters is the user's own responsibility. | |||
responsibility. | ||||
Security Considerations | ||||
Security issues are discussed throughout this memo. | ||||
References | References | |||
[3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," | [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," | |||
IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41. | IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41. | |||
[BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against | [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against | |||
Protocols Based on RSA Encryption Standard PKCS #1" in Advances in | Protocols Based on RSA Encryption Standard PKCS #1" in | |||
Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: 1--12, 1998. | Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: | |||
1--12, 1998. | ||||
[DES] ANSI X3.106, "American National Standard for Information | [DES] ANSI X3.106, "American National Standard for Information | |||
Systems-Data Link Encryption," American National Standards | Systems-Data Link Encryption," American National Standards | |||
Institute, 1983. | Institute, 1983. | |||
[DH1] W. Diffie and M. E. Hellman, "New Directions in Cryptography," | [DH1] W. Diffie and M. E. Hellman, "New Directions in | |||
IEEE Transactions on Information Theory, V. IT-22, n. 6, Jun 1977, | Cryptography," IEEE Transactions on Information Theory, V. | |||
pp. 74-84. | IT-22, n. 6, Jun 1977, pp. 74-84. | |||
[DSS] NIST FIPS PUB 186, "Digital Signature Standard," National | [DSS] NIST FIPS PUB 186, "Digital Signature Standard," National | |||
Institute of Standards and Technology, U.S. Department of Commerce, | Institute of Standards and Technology, U.S. Department of | |||
May 18, 1994. | Commerce, May 18, 1994. | |||
[FTP] J. Postel and J. Reynolds, RFC 959: File Transfer Protocol, | [FTP] Postel J., and J. Reynolds, "File Transfer Protocol", STD 9, | |||
October 1985. | RFC 959, October 1985. | |||
[HTTP] T. Berners-Lee, R. Fielding, H. Frystyk, Hypertext Transfer | [HTTP] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext | |||
Protocol -- HTTP/1.0, October, 1995. | Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. | |||
[HMAC] H. Krawczyk, M. Bellare, and R. Canetti, RFC 2104, HMAC: | [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | |||
Keyed-Hashing for Message Authentication, February, 1997. | Hashing for Message Authentication," RFC 2104, February | |||
1997. | ||||
[IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH | [IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH | |||
Series in Information Processing, v. 1, Konstanz: Hartung-Gorre | Series in Information Processing, v. 1, Konstanz: Hartung- | |||
Verlag, 1992. | Gorre Verlag, 1992. | |||
[MD2] R. Rivest. RFC 1319: The MD2 Message Digest Algorithm. April | [MD2] Kaliski, B., "The MD2 Message Digest Algorithm", RFC 1319, | |||
1992. | April 1992. | |||
[MD5] R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. April | [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, | |||
1992. | April 1992. | |||
[PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard," | [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard," | |||
version 1.5, November 1993. | version 1.5, November 1993. | |||
[PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax | [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax | |||
Standard," version 1.5, November 1993. | Standard," version 1.5, November 1993. | |||
[PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax | [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax | |||
Standard," version 1.5, November 1993. | Standard," version 1.5, November 1993. | |||
[PKIX] R. Housley, W. Ford, W. Polk, D. Solo, Internet Public Key | [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet | |||
Infrastructure: Part I: X.509 Certificate and CRL Profile, | Public Key Infrastructure: Part I: X.509 Certificate and CRL | |||
<draft-ietf-pkix-ipki-part1-06.txt>, October 1997. | Profile", RFC 2459, January 1999. | |||
[RC2] R. Rivest, A Description of the RC2(r) Encryption Algorithm | [RC2] Rivest, R., "A Description of the RC2(r) Encryption | |||
<draft-rivest-rc2desc-00.txt> | Algorithm", RFC 2268, January 1998. | |||
[RC4] R. Thayer and K. Kaukonen, A Stream Cipher Encryption | [RC4] Thayer, R. and K. Kaukonen, A Stream Cipher Encryption | |||
Algorithm, <draft-kaukonen-cipher-arcfour-01.txt>, July 1997. | Algorithm, Work in Progress. | |||
[RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for | [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for | |||
Obtaining Digital Signatures and Public-Key Cryptosystems," | Obtaining Digital Signatures and Public-Key Cryptosystems," | |||
Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-126. | Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120- | |||
126. | ||||
[RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782 [SCH] B. | [RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782 | |||
Schneier. Applied Cryptography: Protocols, Algorithms, and Source | ||||
Code in C, Published by John Wiley & Sons, Inc. 1994. | ||||
[SHA] NIST FIPS PUB 180-1, "Secure Hash Standard," National | [SCH] B. Schneier. Applied Cryptography: Protocols, Algorithms, | |||
Institute of Standards and Technology, U.S. Department of Commerce, | and Source Code in C, Published by John Wiley & Sons, Inc. | |||
DRAFT, May 31, 1994. | 1994. | |||
[SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications | [SHA] NIST FIPS PUB 180-1, "Secure Hash Standard," National | |||
Corp., Feb 9, 1995. | Institute of Standards and Technology, U.S. Department of | |||
Commerce, Work in Progress, May 31, 1994. | ||||
[SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", | [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications | |||
Netscape Communications Corp., Nov 18, 1996. | Corp., Feb 9, 1995. | |||
[TCP] ISI for DARPA, RFC 793: Transport Control Protocol, September | [SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", | |||
1981. | Netscape Communications Corp., Nov 18, 1996. | |||
[TEL] J. Postel and J. Reynolds, RFC 854/5, May, 1993. | [TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, | |||
September 1981. | ||||
[X509] CCITT. Recommendation X.509: "The Directory - Authentication | [TEL] Postel J., and J. Reynolds, "Telnet Protocol | |||
Framework". 1988. | Specifications", STD 8, RFC 854, May 1993. | |||
[XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External Data | [TEL] Postel J., and J. Reynolds, "Telnet Option Specifications", | |||
Representation Standard, August 1995. | STD 8, RFC 855, May 1993. | |||
[X509] CCITT. Recommendation X.509: "The Directory - Authentication | ||||
Framework". 1988. | ||||
[XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External | ||||
Data Representation Standard, August 1995. | ||||
Credits | Credits | |||
Working Group Chair | Win Treese | |||
Open Market | ||||
Win Treese | EMail: treese@openmarket.com | |||
Open Market | ||||
treese@openmarket.com | ||||
Editors | Editors | |||
Christopher Allen Tim Dierks | Christopher Allen Tim Dierks | |||
Certicom Certicom | Certicom Certicom | |||
callen@certicom.com tdierks@certicom.com | ||||
Authors | EMail: callen@certicom.com EMail: tdierks@certicom.com | |||
Tim Dierks Philip L. Karlton | Authors' Addresses | |||
Certicom Netscape Communications | ||||
tdierks@certicom.com | ||||
Alan O. Freier Paul C. Kocher | Tim Dierks Philip L. Karlton | |||
Netscape Communications Independent Consultant | Certicom Netscape Communications | |||
freier@netscape.com pck@netcom.com | ||||
Other contributors | EMail: tdierks@certicom.com | |||
Alan O. Freier Paul C. Kocher | ||||
Netscape Communications Independent Consultant | ||||
Martin Abadi Robert Relyea | EMail: freier@netscape.com EMail: pck@netcom.com | |||
Digital Equipment Corporation Netscape Communications | ||||
ma@pa.dec.com relyea@netscape.com | ||||
Ran Canetti Jim Roskind | Other contributors | |||
IBM Watson Research Center Netscape Communications | ||||
canetti@watson.ibm.com jar@netscape.com | ||||
Taher Elgamal Micheal J. Sabin, Ph. D. | Martin Abadi Robert Relyea | |||
Securify Consulting Engineer | Digital Equipment Corporation Netscape Communications | |||
taher@pacbell.net msabin@netcom.com | ||||
Anil R. Gangolli Dan Simon | EMail: ma@pa.dec.com EMail: relyea@netscape.com | |||
Structured Arts Computing Corp. Microsoft | ||||
gangolli@structuredarts.com dansimon@microsoft.com | ||||
Kipp E.B. Hickman Tom Weinstein | Ran Canetti Jim Roskind | |||
Netscape Communications Netscape Communications | IBM Watson Research Center Netscape Communications | |||
kipp@netscape.com tomw@netscape.com | ||||
Hugo Krawczyk | EMail: canetti@watson.ibm.com EMail: jar@netscape.com | |||
IBM Watson Research Center | ||||
hugo@watson.ibm.com | Taher Elgamal Micheal J. Sabin, Ph. D. | |||
Securify Consulting Engineer | ||||
EMail: elgamal@securify.com EMail: msabin@netcom.com | ||||
Anil R. Gangolli Dan Simon | ||||
Structured Arts Computing Corp. Microsoft | ||||
EMail: gangolli@structuredarts.com EMail: dansimon@microsoft.com | ||||
Kipp E.B. Hickman Tom Weinstein | ||||
Netscape Communications Netscape Communications | ||||
EMail: kipp@netscape.com EMail: tomw@netscape.com | ||||
Hugo Krawczyk | ||||
IBM Watson Research Center | ||||
EMail: hugo@watson.ibm.com | ||||
Comments | Comments | |||
The discussion list for the IETF TLS working group is located at the | The discussion list for the IETF TLS working group is located at the | |||
e-mail address <ietf-tls@lists.consensus.com>. Information on the | e-mail address <ietf-tls@lists.consensus.com>. Information on the | |||
group and information on how to subscribe to the list is at | group and information on how to subscribe to the list is at | |||
<http://lists.consensus.com/>. | <http://lists.consensus.com/>. | |||
Archives of the list can be found at: | Archives of the list can be found at: | |||
<http://www.imc.org/ietf-tls/mail-archive/> | <http://www.imc.org/ietf-tls/mail-archive/> | |||
Full Copyright Statement | ||||
Copyright (C) The Internet Society (1999). All Rights Reserved. | ||||
This document and translations of it may be copied and furnished to | ||||
others, and derivative works that comment on or otherwise explain it | ||||
or assist in its implementation may be prepared, copied, published | ||||
and distributed, in whole or in part, without restriction of any | ||||
kind, provided that the above copyright notice and this paragraph are | ||||
included on all such copies and derivative works. However, this | ||||
document itself may not be modified in any way, such as by removing | ||||
the copyright notice or references to the Internet Society or other | ||||
Internet organizations, except as needed for the purpose of | ||||
developing Internet standards in which case the procedures for | ||||
copyrights defined in the Internet Standards process must be | ||||
followed, or as required to translate it into languages other than | ||||
English. | ||||
The limited permissions granted above are perpetual and will not be | ||||
revoked by the Internet Society or its successors or assigns. | ||||
This document and the information contained herein is provided on an | ||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | ||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | ||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | ||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | ||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
End of changes. 223 change blocks. | ||||
844 lines changed or deleted | 825 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |