📄 rfc2246.txt
字号:
Network Working Group T. Dierks
Request for Comments: 2246 Certicom
Category: Standards Track C. Allen
Certicom
January 1999
The TLS Protocol
Version 1.0
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This document specifies Version 1.0 of the Transport Layer Security
(TLS) protocol. The TLS protocol provides communications privacy over
the Internet. The protocol allows client/server applications to
communicate in a way that is designed to prevent eavesdropping,
tampering, or message forgery.
Table of Contents
1. Introduction 3
2. Goals 4
3. Goals of this document 5
4. Presentation language 5
4.1. Basic block size 6
4.2. Miscellaneous 6
4.3. Vectors 6
4.4. Numbers 7
4.5. Enumerateds 7
4.6. Constructed types 8
4.6.1. Variants 9
4.7. Cryptographic attributes 10
4.8. Constants 11
5. HMAC and the pseudorandom function 11
6. The TLS Record Protocol 13
6.1. Connection states 14
Dierks & Allen Standards Track [Page 1]
RFC 2246 The TLS Protocol Version 1.0 January 1999
6.2. Record layer 16
6.2.1. Fragmentation 16
6.2.2. Record compression and decompression 17
6.2.3. Record payload protection 18
6.2.3.1. Null or standard stream cipher 19
6.2.3.2. CBC block cipher 19
6.3. Key calculation 21
6.3.1. Export key generation example 22
7. The TLS Handshake Protocol 23
7.1. Change cipher spec protocol 24
7.2. Alert protocol 24
7.2.1. Closure alerts 25
7.2.2. Error alerts 26
7.3. Handshake Protocol overview 29
7.4. Handshake protocol 32
7.4.1. Hello messages 33
7.4.1.1. Hello request 33
7.4.1.2. Client hello 34
7.4.1.3. Server hello 36
7.4.2. Server certificate 37
7.4.3. Server key exchange message 39
7.4.4. Certificate request 41
7.4.5. Server hello done 42
7.4.6. Client certificate 43
7.4.7. Client key exchange message 43
7.4.7.1. RSA encrypted premaster secret message 44
7.4.7.2. Client Diffie-Hellman public value 45
7.4.8. Certificate verify 45
7.4.9. Finished 46
8. Cryptographic computations 47
8.1. Computing the master secret 47
8.1.1. RSA 48
8.1.2. Diffie-Hellman 48
9. Mandatory Cipher Suites 48
10. Application data protocol 48
A. Protocol constant values 49
A.1. Record layer 49
A.2. Change cipher specs message 50
A.3. Alert messages 50
A.4. Handshake protocol 51
A.4.1. Hello messages 51
A.4.2. Server authentication and key exchange messages 52
A.4.3. Client authentication and key exchange messages 53
A.4.4. Handshake finalization message 54
A.5. The CipherSuite 54
A.6. The Security Parameters 56
B. Glossary 57
C. CipherSuite definitions 61
Dierks & Allen Standards Track [Page 2]
RFC 2246 The TLS Protocol Version 1.0 January 1999
D. Implementation Notes 64
D.1. Temporary RSA keys 64
D.2. Random Number Generation and Seeding 64
D.3. Certificates and authentication 65
D.4. CipherSuites 65
E. Backward Compatibility With SSL 66
E.1. Version 2 client hello 67
E.2. Avoiding man-in-the-middle version rollback 68
F. Security analysis 69
F.1. Handshake protocol 69
F.1.1. Authentication and key exchange 69
F.1.1.1. Anonymous key exchange 69
F.1.1.2. RSA key exchange and authentication 70
F.1.1.3. Diffie-Hellman key exchange with authentication 71
F.1.2. Version rollback attacks 71
F.1.3. Detecting attacks against the handshake protocol 72
F.1.4. Resuming sessions 72
F.1.5. MD5 and SHA 72
F.2. Protecting application data 72
F.3. Final notes 73
G. Patent Statement 74
Security Considerations 75
References 75
Credits 77
Comments 78
Full Copyright Statement 80
1. Introduction
The primary goal of the TLS Protocol is to provide privacy and data
integrity between two communicating applications. The protocol is
composed of two layers: the TLS Record Protocol and the TLS Handshake
Protocol. At the lowest level, layered on top of some reliable
transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
TLS Record Protocol provides connection security that has two basic
properties:
- The connection is private. Symmetric cryptography is used for
data encryption (e.g., DES [DES], RC4 [RC4], etc.) The keys for
this symmetric encryption are generated uniquely for each
connection and are based on a secret negotiated by another
protocol (such as the TLS Handshake Protocol). The Record
Protocol can also be used without encryption.
- The connection is reliable. Message transport includes a message
integrity check using a keyed MAC. Secure hash functions (e.g.,
SHA, MD5, etc.) are used for MAC computations. The Record
Protocol can operate without a MAC, but is generally only used in
Dierks & Allen Standards Track [Page 3]
RFC 2246 The TLS Protocol Version 1.0 January 1999
this mode while another protocol is using the Record Protocol as
a transport for negotiating security parameters.
The TLS Record Protocol is used for encapsulation of various higher
level protocols. One such encapsulated protocol, the TLS Handshake
Protocol, allows the server and client to authenticate each other and
to negotiate an encryption algorithm and cryptographic keys before
the application protocol transmits or receives its first byte of
data. The TLS Handshake Protocol provides connection security that
has three basic properties:
- The peer's identity can be authenticated using asymmetric, or
public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
authentication can be made optional, but is generally required
for at least one of the peers.
- The negotiation of a shared secret is secure: the negotiated
secret is unavailable to eavesdroppers, and for any authenticated
connection the secret cannot be obtained, even by an attacker who
can place himself in the middle of the connection.
- The negotiation is reliable: no attacker can modify the
negotiation communication without being detected by the parties
to the communication.
One advantage of TLS is that it is application protocol independent.
Higher level protocols can layer on top of the TLS Protocol
transparently. The TLS standard, however, does not specify how
protocols add security with TLS; the decisions on how to initiate TLS
handshaking and how to interpret the authentication certificates
exchanged are left up to the judgment of the designers and
implementors of protocols which run on top of TLS.
2. Goals
The goals of TLS Protocol, in order of their priority, are:
1. Cryptographic security: TLS should be used to establish a secure
connection between two parties.
2. Interoperability: Independent programmers should be able to
develop applications utilizing TLS that will then be able to
successfully exchange cryptographic parameters without knowledge
of one another's code.
3. Extensibility: TLS seeks to provide a framework into which new
public key and bulk encryption methods can be incorporated as
necessary. This will also accomplish two sub-goals: to prevent
Dierks & Allen Standards Track [Page 4]
RFC 2246 The TLS Protocol Version 1.0 January 1999
the need to create a new protocol (and risking the introduction
of possible new weaknesses) and to avoid the need to implement an
entire new security library.
4. Relative efficiency: Cryptographic operations tend to be highly
CPU intensive, particularly public key operations. For this
reason, the TLS protocol has incorporated an optional session
caching scheme to reduce the number of connections that need to
be established from scratch. Additionally, care has been taken to
reduce network activity.
3. Goals of this document
This document and the TLS protocol itself are based on the SSL 3.0
Protocol Specification as published by Netscape. The differences
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
(although TLS 1.0 does incorporate a mechanism by which a TLS
implementation can back down to SSL 3.0). This document is intended
primarily for readers who will be implementing the protocol and those
doing cryptographic analysis of it. The specification has been
written with this in mind, and it is intended to reflect the needs of
those two groups. For that reason, many of the algorithm-dependent
data structures and rules are included in the body of the text (as
opposed to in an appendix), providing easier access to them.
This document is not intended to supply any details of service
definition nor interface definition, although it does cover select
areas of policy as they are required for the maintenance of solid
security.
4. Presentation language
This document deals with the formatting of data in an external
representation. The following very basic and somewhat casually
defined presentation syntax will be used. The syntax draws from
several sources in its structure. Although it resembles the
programming language "C" in its syntax and XDR [XDR] in both its
syntax and intent, it would be risky to draw too many parallels. The
purpose of this presentation language is to document TLS only, not to
have general application beyond that particular goal.
Dierks & Allen Standards Track [Page 5]
RFC 2246 The TLS Protocol Version 1.0 January 1999
4.1. Basic block size
The representation of all data items is explicitly specified. The
basic data block size is one byte (i.e. 8 bits). Multiple byte data
items are concatenations of bytes, from left to right, from top to
bottom. From the bytestream a multi-byte item (a numeric in the
example) is formed (using C notation) by:
value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
... | byte[n-1];
This byte ordering for multi-byte values is the commonplace network
byte order or big endian format.
4.2. Miscellaneous
Comments begin with "/*" and end with "*/".
Optional components are denoted by enclosing them in "[[ ]]" double
brackets.
Single byte entities containing uninterpreted data are of type
opaque.
4.3. Vectors
A vector (single dimensioned array) is a stream of homogeneous data
elements. The size of the vector may be specified at documentation
time or left unspecified until runtime. In either case the length
declares the number of bytes, not the number of elements, in the
vector. The syntax for specifying a new type T' that is a fixed
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -