RFC2246 日本語訳
2246 The TLS Protocol Version 1.0. T. Dierks, C. Allen. January 1999. (Format: TXT=170401 bytes) (Obsoleted by RFC4346) (Updated by RFC3546) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group T. Dierks
Request for Comments: 2246 Certicom
Category: Standards Track C. Allen
Certicom
January 1999
Dierksがコメントのために要求するワーキンググループT.をネットワークでつないでください: 2246年のCerticomカテゴリ: 標準化過程C.アレンCerticom1999年1月
The TLS Protocol
Version 1.0
TLSプロトコルバージョン1.0
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(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.
このドキュメントはTransport Layer Security(TLS)プロトコルのバージョン1.0を指定します。 TLSプロトコルはコミュニケーションインターネット上のプライバシーを提供します。 プロトコルで、クライアント/サーバ・アプリケーションは盗み聞くのを防ぐように設計されている道、改ざん、またはメッセージ偽造で伝えます。
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
1. 序論3 2。 目標4 3。 この目標は5 4を記録します。 プレゼンテーション言語5 4.1。 基本的なブロック・サイズ6 4.2。 その他6の4.3。 ベクトル6 4.4。 No.7 4.5。 列挙品目7 4.6。 タイプ8 4.6に、.1を構成しました。 異形9 4.7。 暗号の属性10 4.8。 定数11 5。 HMACと擬似ランダム機能11 6。 TLSはプロトコル13 6.1を記録します。 接続州14
Dierks & Allen Standards Track [Page 1] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[1ページ]RFC2246TLSプロトコルバージョン1999年1月1日
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
6.2. .1に層16の6.2を記録してください。 断片化、16 6.2 .2。 .3に圧縮と減圧17 6.2を記録してください。 .1にペイロード保護18 6.2.3を記録してください。 ヌルか規格が暗号19 6.2に.2に.3を流します。 CBCは暗号19 6.3を妨げます。 計算21 6.3に.1を合わせてください。 キー生成が例22の7であるとエクスポートしてください。 TLS握手プロトコル23 7.1。 暗号仕様プロトコル24 7.2を変えてください。 プロトコル24 7.2に、.1を警告します。 閉鎖は7.2に.2に25を警告します。 誤りは7.3に26を警告します。 握手プロトコル概要29 7.4。 握手プロトコル32 7.4.1。 こんにちは、メッセージ、33 7.4 .1 .1。 33を要求してください。こんにちは、7.4 .1 .2。 クライアント、こんにちは、34 7.4 .1 .3。 サーバ、こんにちは、36 7.4 .2。 サーバ証明書37 7.4.3。 サーバ主要な交換メッセージ39 7.4.4。 証明書要求41 7.4.5。 サーバ、こんにちは、7.4に.6に42をします。 クライアント証明書43 7.4.7。 クライアント主要な交換メッセージ43 7.4.7.1。 RSAは前マスター秘密の通信44 7.4に.2に.7を暗号化しました。 クライアントディフィー-ヘルマンの公共の価値45の7.4.8。 証明書は7.4に.9に45について確かめます。 終わりました。46 8。 暗号の計算47 8.1。 .1にマスター秘密の47 8.1を計算します。 RSA、48 8.1 .2。 ディフィー-ヘルマン48、9 義務的な暗号スイート48 10。 アプリケーションデータは48のA.プロトコル恒常価値49A.1について議定書の中で述べます。 層49のA.2を記録してください。 暗号眼鏡メッセージ50A.3を変えてください。 警告メッセージ50A.4。 握手プロトコル51A.4.1。 こんにちは、メッセージ51A.4.2。 サーバー証明とキーはメッセージ52A.4.3を交換します。 クライアント認証とキーはメッセージ53A.4.4を交換します。 握手決定メッセージ54A.5。 CipherSuite54A.6。 Security Parameters56B.Glossary57C.CipherSuite定義61
Dierks & Allen Standards Track [Page 2] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[2ページ]RFC2246TLSプロトコルバージョン1999年1月1日
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
D.実装注意64D.1。 一時的なRSAキー64D.2。 乱数発生と種子64D.3。 証明書と認証65D.4。 SSL66E.1とのCipherSuites65のE.の後方の互換性。 バージョン2クライアント、こんにちは、67E.2。 中央の男性バージョンロールバック68F.Security分析69F.1を避けます。 握手プロトコル69F.1.1。 認証とキーは69F.1.1.1を交換します。 匿名の主要な交換69F.1.1.2。 RSAの主要な交換と認証70F.1.1.3。 認証71F.1.2とのディフィー-ヘルマンの主要な交換。 バージョンロールバックは71F.1.3を攻撃します。 握手に対して攻撃を検出して、72F.1.4について議定書の中で述べてください。 セッション72F.1.5を再開します。 MD5とSHA72F.2。 アプリケーションデータ72F.3を保護します。 最後通達73G.Patent Statement74Security Considerations75References75Credits77Comments78Full Copyright Statement80
1. Introduction
1. 序論
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:
TLSプロトコルのプライマリ目標は2の間のアプリケーションを伝えるプライバシーとデータ保全を提供することです。 プロトコルは2つの層で構成されます: TLSはプロトコルとTLS握手プロトコルを記録します。 何らかの信頼できるトランスポート・プロトコル(例えば、TCP[TCP])の上で層にされる中で最も低いレベルに、TLS Recordプロトコルがあります。 TLS Recordプロトコルは2個の基礎特性を持っているセキュリティを接続に提供します:
- 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.
- 接続は個人的です。 左右対称の暗号はデータ暗号化(例えば、DES[DES]、RC4[RC4]など)に使用されます。 この左右対称の暗号化のためのキーは、各接続のために唯一生成されて、別のプロトコル(TLS Handshakeプロトコルなどの)によって交渉された秘密に基づいています。 また、暗号化なしでRecordプロトコルを使用できます。
- 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
- 接続は頼もしいです。 メッセージ転送は、合わせられたMACを使用することでメッセージの保全チェックを含んでいます。 安全なハッシュ関数(例えば、SHA、MD5など)はMAC計算に使用されます。 MACなしで操作できますが、一般に、プロトコルが使用されるだけであるRecord
Dierks & Allen Standards Track [Page 3] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[3ページ]RFC2246TLSプロトコルバージョン1999年1月1日
this mode while another protocol is using the Record Protocol as
a transport for negotiating security parameters.
このモードは、セキュリティパラメタを交渉するのに別のプロトコルである間、輸送としてRecordプロトコルを使用しています。
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:
TLS Recordプロトコルは様々なより高い平らなプロトコルのカプセル化に使用されます。 そのようなプロトコルのカプセル化された1つ(TLS Handshakeプロトコル)は、互いを認証して、アプリケーション・プロトコルがデータの最初のバイトを伝えるか、または受ける前に暗号化アルゴリズムと暗号化キーを交渉するためにサーバとクライアントを許容します。 TLS Handshakeプロトコルは3個の基礎特性を持っているセキュリティを接続に提供します:
- 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.
- 同輩のアイデンティティが認証された使用非対称である場合がある、公開鍵、暗号(例えば、RSA[RSA]、DSS[DSS]など) この認証が、任意に作ることができますが、一般に、少なくとも同輩のひとりに必要です。
- 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.
TLSの1つの利点はそれがアプリケーション・プロトコル独立者であるということです。 より高い平らなプロトコルはTLSプロトコルの上で透過的に層にされることができます。 しかしながら、TLS規格はプロトコルがTLSと共にセキュリティをどう加えるかを指定しません。 どのようにTLSハンドシェイクに着手するか、そして、どのように証明書が交換した認証を解釈するかに関する決定はTLSの上で稼働するプロトコルのデザイナーと作成者の判断に任せられます。
2. Goals
2. 目標
The goals of TLS Protocol, in order of their priority, are:
彼らの優先権の順に、TLSプロトコルの目標は以下の通りです。
1. Cryptographic security: TLS should be used to establish a secure
connection between two parties.
1. 暗号のセキュリティ: TLSは、2回のパーティーの間の安全な接続を証明するのに使用されるべきです。
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.
2. 相互運用性: 独立しているプログラマはその時お互いのコードに関する知識なしで暗号のパラメタを首尾よく交換できるTLSを利用するアプリケーションを開発できるべきです。
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
3. 伸展性: TLSはどの新しい公開鍵にフレームワークを提供しようとするか、そして、必要に応じて大量の暗号化メソッドは取り入れることができます。 また、これは2つのサブ目標を達成するでしょう: 防ぎます。
Dierks & Allen Standards Track [Page 4] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[4ページ]RFC2246TLSプロトコルバージョン1999年1月1日
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.
4. 相対的効率: 暗号の操作は、CPU非常に徹底的である傾向があって、特に公開鍵は操作です。 この理由で、TLSプロトコルは最初から設立される必要があるポートの数を減少させるために体系をキャッシュする任意のセッションを取り入れました。 さらに、ネットワーク活動を抑えるために、注意しました。
3. Goals of this document
3. このドキュメントの目標
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.
このドキュメントとTLSプロトコル自体はNetscapeによって発行されるようにSSL3.0プロトコルSpecificationに基づいています。 このプロトコルとSSL3.0の違いは劇的ではありませんが、それらはTLS1.0とSSL3.0が共同利用しないほど(TLS1.0はTLS実装がSSL3.0に譲歩できるメカニズムを組み込みますが)重要です。 このドキュメントは主としてプロトコルを実装する読者とそれの暗号の分析をするもののために意図します。 仕様は念頭にこれで書かれています、そして、それらの2つのグループの必要性を反映することを意図します。 その理由で、アルゴリズム依存するデータ構造と規則の多くがテキスト(コネと対照的に付録)のボディーに含まれています、それらへの、より簡単なアクセスを提供して。
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
4. プレゼンテーション言語
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.
このドキュメントは外部の表現における、データの形式に対処します。 以下の非常に基本的で何気なくいくらか定義されたプレゼンテーション構文は使用されるでしょう。 構文は構造にいくつかのソースから描かれます。 構文と意図の両方でその構文とXDRのプログラミング言語「C」[XDR]に類似していますが、あまりに多くの平行線を描くのは危険でしょう。 その特定の目標を超えて一般的適用を持たないように、ドキュメントTLSだけにはこのプレゼンテーション言語の目的があります。
Dierks & Allen Standards Track [Page 5] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[5ページ]RFC2246TLSプロトコルバージョン1999年1月1日
4.1. Basic block size
4.1. 基本的なブロック・サイズ
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:
すべてのデータ項目の表現は明らかに指定されます。 基礎データブロック・サイズは1バイト(すなわち、8ビット)です。 左から右までデータ項目は先端から下部への複数のバイト、バイトの連結です。 bytestreamから、マルチバイト項目(例の数値)は以下によって形成されます(C記法を使用します)。
value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
... | byte[n-1];
値は(バイト[0]<<8*(n-1))と等しいです。| (バイト[1]<<8*(n-2)) | ... | バイト[n-1]。
This byte ordering for multi-byte values is the commonplace network byte order or big endian format.
マルチバイト値のためのこのバイト順は、平凡なネットワークバイトオーダーかビッグエンディアン形式です。
4.2. Miscellaneous
4.2. その他
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
4.3. ベクトル
A vector (single dimensioned array) is a stream of homogeneous data elements. The size of the vector may be specified at documentation time or left unspecified until runtime. In either case the length declares the number of bytes, not the number of elements, in the vector. The syntax for specifying a new type T' that is a fixed length vector of type T is
ベクトル(ただ一つのdimensionedアレイ)は均質のデータ要素の流れです。 ベクトルのサイズは、ドキュメンテーション時に指定されるか、またはランタイムまで不特定のままにされるかもしれません。 どちらの場合ではも、長さはベクトルにおける、要素の数ではなく、バイト数を宣言します。 タイプTの固定長ベクトルである'新しいタイプTを指定するための構文'はそうです。
T T'[n];
T T'[n]'。
Here T' occupies n bytes in the data stream, where n is a multiple of the size of T. The length of the vector is not included in the encoded stream.
'ここで、T'はデータ・ストリームにnバイト従事していて、nがどこのT. ベクトルの長さのサイズの倍数であるかはコード化された流れで含まれていません。
In the following example, Datum is defined to be three consecutive bytes that the protocol does not interpret, while Data is three consecutive Datum, consuming a total of nine bytes.
以下の例では、Datumはプロトコルが解釈しない連続した3バイトになるように定義されます、Dataが3の連続したDatumですが、合計9バイトを消費して。
opaque Datum[3]; /* three uninterpreted bytes */
Datum Data[9]; /* 3 consecutive 3 byte vectors */
Datum[3]について不透明にしてください。 非解釈された/*3バイト*/データのData[9]。 3バイトの連続した/*3つのベクトル*/
Dierks & Allen Standards Track [Page 6] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[6ページ]RFC2246TLSプロトコルバージョン1999年1月1日
Variable length vectors are defined by specifying a subrange of legal lengths, inclusively, using the notation <floor..ceiling>. When encoded, the actual length precedes the vector's contents in the byte stream. The length will be in the form of a number consuming as many bytes as required to hold the vector's specified maximum (ceiling) length. A variable length vector with an actual length field of zero is referred to as an empty vector.
可変長ベクトルは、記法<床を使用することで包括的に法的な長さのサブレンジを指定することによって、定義されます。天井>。 コード化されると、実際の長さはバイト・ストリームでベクトルのコンテンツに先行します。 長さが、ベクトルの指定された最大の(天井)の長さを保持するために必要に応じて同じくらい多くのバイトを消費しながら、数の形にあるでしょう。 ゼロの実際の長さの分野に従った可変長ベクトルは空のベクトルと呼ばれます。
T T'<floor..ceiling>;
T T'<床'。天井>。
In the following example, mandatory is a vector that must contain between 300 and 400 bytes of type opaque. It can never be empty. The actual length field consumes two bytes, a uint16, sufficient to represent the value 400 (see Section 4.4). On the other hand, longer can represent up to 800 bytes of data, or 400 uint16 elements, and it may be empty. Its encoding will include a two byte actual length field prepended to the vector. The length of an encoded vector must be an even multiple of the length of a single element (for example, a 17 byte vector of uint16 would be illegal).
以下の例では、義務的であるのは、300〜400バイトのタイプ不透明なものを含まなければならないベクトルです。 それは空であるはずがありません。 実際の長さの分野は2バイト、値400を表すことができるくらいのuint16を消費します(セクション4.4を見てください)。 他方ではと、より長い間、最大800バイトのデータ、または400のuint16要素を表すことができて、それは空であるかもしれません。 コード化はベクトルにprependedされた2バイトの実際の長さの分野を含むでしょう。 コード化されたベクトルの長さはただ一つの要素の長さの同等の倍数であるに違いありません(例えば、uint16の17バイトのベクトルは不法でしょう)。
opaque mandatory<300..400>;
/* length field is 2 bytes, cannot be empty */
uint16 longer<0..800>;
/* zero to 400 16-bit unsigned integers */
義務的な<300について不透明にしてください。400>。 空の*/uint16が、より長い<0であったかもしれないなら、/*長さの分野は2バイトです。800>。 ゼロ〜/*400の16ビットの符号のない整数*/
4.4. Numbers
4.4. 数
The basic numeric data type is an unsigned byte (uint8). All larger numeric data types are formed from fixed length series of bytes concatenated as described in Section 4.1 and are also unsigned. The following numeric types are predefined.
基本の数値データ型は無記名のバイト(uint8)です。 すべての、より大きい数値データ型も、セクション4.1で説明されるように連結されたバイトの固定長シリーズから形成されて、また、無記名です。 以下の数値型は事前に定義されます。
uint8 uint16[2];
uint8 uint24[3];
uint8 uint32[4];
uint8 uint64[8];
uint8 uint16[2]。 uint8 uint24[3]。 uint8 uint32[4]。 uint8 uint64[8]。
All values, here and elsewhere in the specification, are stored in "network" or "big-endian" order; the uint32 represented by the hex bytes 01 02 03 04 is equivalent to the decimal value 16909060.
すべての値が「ネットワーク」か「ビッグエンディアン」オーダーに仕様のこことほかの場所に格納されます。 十六進法バイト01 02 03 04によって表されたuint32はデシマル値16909060に同等です。
4.5. Enumerateds
4.5. 列挙品目
An additional sparse data type is available called enum. A field of type enum can only assume the values declared in the definition. Each definition is a different type. Only enumerateds of the same type may be assigned or compared. Every element of an enumerated must
追加まばらなデータ型は利用可能な呼ばれたenumです。 タイプenumの分野は定義で宣言された値を仮定できるだけです。 各定義は異なったタイプです。 同じタイプの列挙品目だけを割り当てられてもよいか、または比較してもよいです。 列挙された必須のあらゆる要素
Dierks & Allen Standards Track [Page 7] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[7ページ]RFC2246TLSプロトコルバージョン1999年1月1日
be assigned a value, as demonstrated in the following example. Since the elements of the enumerated are not ordered, they can be assigned any unique value, in any order.
値は以下の例に示されるように割り当てられてください。 列挙の要素が注文されないので、どんなオーダーでもどんなユニークな値もそれらに割り当てることができます。
enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
enum、e1(v1)、e2(v2)、…、en(vn)、[(n)]]、Te。
Enumerateds occupy as much space in the byte stream as would its maximal defined ordinal value. The following definition would cause one byte to be used to carry fields of type Color.
列挙品目は最大限度の定義された序数の値であるだろうことのようにバイト・ストリームで同じくらい多くのスペースを占めます。 以下の定義で、タイプColorの野原を運ぶのに1バイトを使用するでしょう。
enum { red(3), blue(5), white(7) } Color;
enum、赤(3)、青(5)、白(7)は着色します。
One may optionally specify a value without its associated tag to force the width definition without defining a superfluous element. In the following example, Taste will consume two bytes in the data stream but can only assume the values 1, 2 or 4.
余計な要素を定義しないで幅の定義を強制するために関連タグなしで値を任意に指定するかもしれません。 以下の例では、Tasteは、データ・ストリームで2バイトを消費しますが、値が1、2または4であると仮定できるだけです。
enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
enum、甘い(1)、酸(2)、苦い(4)、(32000)は味がします。
The names of the elements of an enumeration are scoped within the defined type. In the first example, a fully qualified reference to the second element of the enumeration would be Color.blue. Such qualification is not required if the target of the assignment is well specified.
列挙の要素の名前は定義されたタイプの中で見られます。 最初の例では、列挙の2番目の要素の完全に適切な参照はColor.blueでしょう。 課題の目標がよく指定されるなら、そのような資格は必要ではありません。
Color color = Color.blue; /* overspecified, legal */
Color color = blue; /* correct, type implicit */
色の色はColor.blueと等しいです。 /*過剰指定されて、法的な*/色の色は青と等しいです。 /*正しくて、暗黙の*/をタイプしてください。
For enumerateds that are never converted to external representation, the numerical information may be omitted.
外部の表現に決して変換されない列挙品目において、数字の情報は省略されるかもしれません。
enum { low, medium, high } Amount;
enumの低くて、中型の、そして、高い量。
4.6. Constructed types
4.6. 組み立てられたタイプ
Structure types may be constructed from primitive types for convenience. Each specification declares a new, unique type. The syntax for definition is much like that of C.
構造タイプは便宜のためのプリミティブ型から構成されるかもしれません。 各仕様は新しくて、ユニークなタイプを宣言します。 定義のための構文はCのものに似ています。
struct {
T1 f1;
T2 f2;
...
Tn fn;
} [[T]];
struct、T1 f1;、T2 f2;、Tn fn;、[[T]]。
Dierks & Allen Standards Track [Page 8] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[8ページ]RFC2246TLSプロトコルバージョン1999年1月1日
The fields within a structure may be qualified using the type's name using a syntax much like that available for enumerateds. For example, T.f2 refers to the second field of the previous declaration. Structure definitions may be embedded.
列挙品目にそんなに利用可能であるように構文を使用することでタイプの名前を使用することで構造の中の野原は資格があるかもしれません。 例えば、T.f2は前の宣言の2番目の野原について言及します。 構造定義は埋め込まれるかもしれません。
4.6.1. Variants
4.6.1. 異形
Defined structures may have variants based on some knowledge that is available within the environment. The selector must be an enumerated type that defines the possible variants the structure defines. There must be a case arm for every element of the enumeration declared in the select. The body of the variant structure may be given a label for reference. The mechanism by which the variant is selected at runtime is not prescribed by the presentation language.
定義された構造で、異形は何らかの環境の中で利用可能な知識に基づいているかもしれません。 セレクタは構造が定義する可能な異形を定義する列挙型であるに違いありません。 選ぶところで宣言された列挙のあらゆる要素のためのケースアームがあるに違いありません。 参照のために異形構造のボディーにラベルを与えるかもしれません。 異形がランタイムのときに選択されるメカニズムはプレゼンテーション言語によって定められません。
struct {
T1 f1;
T2 f2;
....
Tn fn;
select (E) {
case e1: Te1;
case e2: Te2;
....
case en: Ten;
} [[fv]];
} [[Tv]];
T1 f1; T2 f2; Tn fn; (E)を選択してください。struct、e1をケースに入れてください: Te1、e2をケースに入れてください: Te2、アンをケースに入れてください: 10[[fv]];、[[Tv]]。
For example:
例えば:
enum { apple, orange } VariantTag;
struct {
uint16 number;
opaque string<0..10>; /* variable length */
} V1;
struct {
uint32 number;
opaque string[10]; /* fixed length */
} V2;
struct {
select (VariantTag) { /* value of selector is implicit */
case apple: V1; /* VariantBody, tag = apple */
case orange: V2; /* VariantBody, tag = orange */
} variant_body; /* optional label on variant */
} VariantRecord;
りんご、オレンジをenumする、VariantTag。 structの*uint16番号; 不透明なストリング<0..10>;/可変な長さ*/V1。 struct uint32番号; 不透明なストリング[10];/*固定長*/V2。 struct、(VariantTag)を選択してください、セレクタの/*値は内在している*/ケースりんごです: V1; タグ=りんご*/ケースオレンジ: /*VariantBody、V2; /*VariantBody、=オレンジ*/にタグ付けをしてください、異形_ボディー; 異形*/の/*任意のラベル、VariantRecord。
Variant structures may be qualified (narrowed) by specifying a value for the selector prior to the type. For example, a
タイプの前でセレクタに値を指定することによって、異形構造は資格があるかもしれません(狭くされます)。 例えば、a
Dierks & Allen Standards Track [Page 9] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[9ページ]RFC2246TLSプロトコルバージョン1999年1月1日
orange VariantRecord
オレンジのVariantRecord
is a narrowed type of a VariantRecord containing a variant_body of type V2.
VariantRecordの狭くされたタイプはタイプV2の異形_ボディーを含んでいますか?
4.7. Cryptographic attributes
4.7. 暗号の属性
The four cryptographic operations digital signing, stream cipher encryption, block cipher encryption, and public key encryption are designated digitally-signed, stream-ciphered, block-ciphered, and public-key-encrypted, respectively. A field's cryptographic processing is specified by prepending an appropriate key word designation before the field's type specification. Cryptographic keys are implied by the current session state (see Section 6.1).
公開鍵暗号化がデジタル調印、ストリーム暗号暗号化が妨げる4つの暗号の操作が暗号化を解いて、デジタルにサインされて、流れで解かれた状態で指定されて、ブロックで解かれて、公開カギによってコード化されている、それぞれ。 フィールドの暗号の処理は、フィールドのタイプ仕様の前に適切なキーワード名称をprependingすることによって、指定されます。 暗号化キーは現在のセッション州によって含意されます(セクション6.1を見てください)。
In digital signing, one-way hash functions are used as input for a signing algorithm. A digitally-signed element is encoded as an opaque vector <0..2^16-1>, where the length is specified by the signing algorithm and key.
デジタル調印片道ハッシュ関数は調印アルゴリズムのために入力されるように使用されています。 デジタルにサインされた要素は不透明なベクトル<0としてコード化されます。2^16-1 >。(そこでは、長さが調印アルゴリズムとキーによって指定されます)。
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 PKCS #1 block type 0 or type 1 as described in [PKCS1].
RSA調印に、2の構造が論じ尽くす36バイト(1SHAと1MD5)はサインされます(秘密鍵で、コード化されます)。 それは[PKCS1]で説明されるようにPKCS#1ゴシック体0かタイプ1でコード化されます。
In DSS, the 20 bytes of the SHA hash are run directly through the Digital Signing Algorithm with no additional hashing. This produces two values, r and s. The DSS signature is an opaque vector, as above, the contents of which are the DER encoding of:
DSSでは、SHA細切れ肉料理の20バイトは追加論じ尽くすことのないDigital Signing Algorithm直接を通した走行です。 これは2つの値、r、およびsを生産します。 DSS署名は上の不透明なベクトルです。それの内容は以下のDERコード化です。
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
以下をDss-Sig評価してください:= 系列r整数、s整数
In stream cipher encryption, the plaintext is exclusive-ORed with an identical amount of output generated from a cryptographically-secure keyed pseudorandom number generator.
ストリーム暗号暗号化では、平文は同じ量の出力が暗号で安全な合わせられた擬似ランダム数のジェネレータから発生している排他的なORedです。
In block cipher encryption, every block of plaintext encrypts to a block of ciphertext. All block cipher encryption is done in CBC (Cipher Block Chaining) mode, and all items which are block-ciphered will be an exact multiple of the cipher block length.
暗号暗号化、あらゆるブロックの平文が1ブロックの暗号文にコード化するブロックで。 CBC(暗号Block Chaining)モードですべてのブロック暗号暗号化をします、そして、すべてのブロックによって解かれた項目が暗号ブロック長の正確な倍数になるでしょう。
In public key encryption, a public key algorithm is used to encrypt data in such a way that it can be decrypted only with the matching private key. A public-key-encrypted element is encoded as an opaque vector <0..2^16-1>, where the length is specified by the signing algorithm and key.
公開鍵暗号化では、公開鍵アルゴリズムは、単に合っている秘密鍵でそれを解読することができるような方法でデータをコード化するのに使用されます。 公開カギでコード化された要素は不透明なベクトル<0としてコード化されます。2^16-1 >。(そこでは、長さが調印アルゴリズムとキーによって指定されます)。
Dierks & Allen Standards Track [Page 10] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[10ページ]RFC2246TLSプロトコルバージョン1999年1月1日
An RSA encrypted value is encoded with PKCS #1 block type 2 as described in [PKCS1].
RSAは値をコード化しました。PKCS#1ゴシック体2で、[PKCS1]で説明されるように、コード化されます。
In the following example:
以下の例で:
stream-ciphered struct {
uint8 field1;
uint8 field2;
digitally-signed opaque hash[20];
} UserType;
流れで解かれたstruct uint8 field1; uint8 field2; 不透明な細切れ肉料理[20]にデジタルにサインする;UserType。
The contents of hash are used as input for the signing algorithm, then the entire structure is encrypted with a stream cipher. The 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, plus the length of the output of the signing algorithm. This is known due to the fact that the algorithm and key used for the signing are known prior to encoding or decoding this structure.
細切れ肉料理の内容が調印アルゴリズムのために入力されるように使用されている、そして、全体の構造はストリーム暗号でコード化されます。 この構造の長さ、バイトで、field1とfield2のための2バイト、および署名の長さ、および調印アルゴリズムの出力の長さのための2バイトへの同輩はいるでしょう。 これは調印に、中古のアルゴリズムとキーがこの構造をコード化するか、または解読しながら知られている事実のため知られています。
4.8. Constants
4.8. 定数
Typed constants can be defined for purposes of specification by declaring a symbol of the desired type and assigning values to it. Under-specified types (opaque, variable length vectors, and structures that contain opaque) cannot be assigned values. No fields of a multi-element structure or vector may be elided.
仕様の目的のために必要なタイプのシンボルを宣言して、値をそれに割り当てることによって、タイプされた定数を定義できます。 下の指定されたタイプ(不明瞭で、可変な長さのベクトル、および不透明なものを含む構造)は割り当てられた値であるはずがありません。 マルチ要素構造かベクトルの分野は全く削除されないかもしれません。
For example,
例えば
struct {
uint8 f1;
uint8 f2;
} Example1;
struct uint8 f1; uint8 f2;Example1。
Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */
1、Example1 ex1=4。 /*はf1=1を割り当てて、f2は4*/と等しいです。
5. HMAC and the pseudorandom function
5. HMACと擬似ランダム機能
A number of operations in the TLS record and handshake layer required a keyed MAC; this is a secure digest of some data protected by a secret. Forging the MAC is infeasible without knowledge of the MAC secret. The construction we use for this operation is known as HMAC, described in [HMAC].
TLS記録と握手層における多くの操作が合わせられたMACを必要としました。 これは秘密によって保護されたいくつかのデータの安全なダイジェストです。 MACを鍛造するのはMAC秘密に関する知識なしで実行不可能です。 私たちがこの操作に使用する工事は[HMAC]で説明されたHMACとして知られています。
HMAC can be used with a variety of different hash algorithms. TLS uses it in the handshake with two different algorithms: MD5 and SHA- 1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,
さまざまな異なった細切れ肉料理アルゴリズムでHMACを使用できます。TLSは握手に2つの異なったアルゴリズムでそれを使用します: MD5、SHA1、HMAC_MD5としてのこれら(秘密、データ)を指示して、およびHMAC_SHA、(秘密です。
Dierks & Allen Standards Track [Page 11] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[11ページ]RFC2246TLSプロトコルバージョン1999年1月1日
data). Additional hash algorithms can be defined by cipher suites and used to protect record data, but MD5 and SHA-1 are hard coded into the description of the handshaking for this version of the protocol.
データ) 追加細切れ肉料理アルゴリズムを暗号スイートで定義して、記録的なデータを保護するのに使用できますが、MD5とSHA-1はプロトコルのこのバージョンのためにハンドシェイクの記述にコード化されていた状態で固いです。
In addition, a construction is required to do expansion of secrets into blocks of data for the purposes of key generation or validation. This pseudo-random function (PRF) takes as input a secret, a seed, and an identifying label and produces an output of arbitrary length.
さらに、工事が、キー生成か合法化の目的のためのブロックのデータに秘密の拡大を翻訳するのに必要です。 (PRF)が取るこの擬似ランダム機能は、秘密、種子、および特定ラベルを入力して、任意の長さの出力を起こします。
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 algorithm remains secure.
PRFをできるだけ安全にするように、それはどちらのアルゴリズムも安全なままで残っているならセキュリティを保証するべきである方法で2つの細切れ肉料理アルゴリズムを使用します。
First, we define a data expansion function, P_hash(secret, data) which uses a single hash function to expand a secret and seed into an arbitrary quantity of output:
まず最初に、私たちはデータ展開機能、任意の量の出力に秘密と種子を広げるのにただ一つのハッシュ関数を使用するP_細切れ肉料理(秘密、データ)を定義します:
P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
HMAC_hash(secret, A(2) + seed) +
HMAC_hash(secret, A(3) + seed) + ...
P_はHMAC_細切れ肉料理(秘密、A(1)+種子)+HMAC_細切れ肉料理(秘密、A(2)+種子)+HMAC_細切れ肉料理(秘密、A(3)+種子)(秘密、種子)=+を論じ尽くします…
Where + indicates concatenation.
+が連結を示すところ。
A() is defined as:
A(0) = seed
A(i) = HMAC_hash(secret, A(i-1))
A()は以下と定義されます。 種子A(0)=A(i)はHMAC_細切れ肉料理と等しいです。(秘密、(i-1))
P_hash can be iterated as many times as is necessary to produce the required quantity of data. For example, if P_SHA-1 was being used to create 64 bytes of data, it would have to be iterated 4 times (through A(4)), creating 80 bytes of output data; the last 16 bytes of the final iteration would then be discarded, leaving 64 bytes of output data.
何回もそのままで必要な量のデータを作り出すのに必要な状態でP_細切れ肉料理を繰り返すことができます。 例えば、P_SHA-1が64バイトのデータを作成するのに使用されているなら、それが4回繰り返されなければならない、(80バイトの出力データを作成するA(4))を通して。 そして、64バイトの出力をデータに残して、最終的な繰り返しのベスト16バイトは捨てられるでしょう。
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 generate data with P_SHA-1, then exclusive-or'ing the outputs of these two expansion functions together.
TLSのPRFはP_MD5ともう片方の半分で秘密を2つの半分に分けて、データを発生させるのに半分を使用することによって、作成されて、P_SHA-1と共にデータを発生させて、次に、exclusive-or'ingは一緒にこれらの2つの拡大機能の出力です。
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 second half. Their length is created by rounding up the length of the overall secret divided by two; thus, if the original secret is an odd number of bytes long, the last byte of S1 will be the same as the first byte of S2.
S1とS2は半分の2つの秘密です、そして、それぞれが同じ長さです。 後半からの秘密の前半、S2からS1を取ります。 それらの長さは総合的な秘密の長さが2で分割した一斉逮捕で作成されます。 したがって、オリジナルの秘密がバイト長の奇数であるなら、S1の最後のバイトはS2の最初のバイトと同じになるでしょう。
L_S = length in bytes of secret;
L_S1 = L_S2 = ceil(L_S / 2);
L_Sはバイトの秘密の長さと等しいです。 L_S1はL_S2=ceil(L_S/2)と等しいです。
Dierks & Allen Standards Track [Page 12] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[12ページ]RFC2246TLSプロトコルバージョン1999年1月1日
The secret is partitioned into two halves (with the possibility of one shared byte) as described above, S1 taking the first L_S1 bytes and S2 the last L_S2 bytes.
秘密は上で説明されるように2つの半分(共有された1バイトの可能性がある)に仕切られます、S1が最初のL_S1バイトと最後のS2L_S2に何バイトも取って。
The PRF is then defined as the result of mixing the two pseudorandom streams by exclusive-or'ing them together.
PRFはそうであり、混合するという結果と定義されて、次に、2擬似ランダムはexclusive-or'ingでそれらを一緒に流します。
PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
P_SHA-1(S2, label + seed);
PRF(秘密、ラベルに種を蒔く)はP_MD5(S1、ラベルするか、または種を蒔く)XOR P_SHA-1と等しいです(S2、ラベルするか、または種を蒔いてください)。
The label is an ASCII string. It should be included in the exact form it is given without a length byte or trailing null character. For example, the label "slithy toves" would be processed by hashing the following bytes:
ラベルはASCIIストリングです。 それは長さのバイトも引きずっているヌル文字なしで与えられている正確なフォームに含まれるべきです。 例えば、ラベル"slithy toves"は以下のバイトを論じ尽くすことによって、処理されるでしょう:
73 6C 69 74 68 79 20 74 6F 76 65 73
73 6C69 74 68 79 20 74 6F76 65 73
Note that because MD5 produces 16 byte outputs and SHA-1 produces 20 byte outputs, the boundaries of their internal iterations will not be 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).
MD5が16バイトの出力を起こして、SHA-1が20バイトの出力を起こすので彼らの内部の繰り返しの境界が並べられないことに注意してください。 出力がかかわる80バイトを発生させるには、P_MD5がA(5)を通して繰り返されて、SHA-1がA(4)を通して繰り返すだけであるP_をゆったり過ごしてください。
6. The TLS Record Protocol
6. TLSはプロトコルを記録します。
The TLS Record Protocol is a layered protocol. At each layer, messages may include fields for length, description, and content. The Record Protocol takes messages to be transmitted, fragments the data into manageable blocks, optionally compresses the data, applies a MAC, encrypts, and transmits the result. Received data is decrypted, verified, decompressed, and reassembled, then delivered to higher level clients.
TLS Recordプロトコルは層にされたプロトコルです。 各層では、メッセージは長さ、記述、および内容のための分野を含むかもしれません。 Recordプロトコルは、結果を伝えられるために伝言を受け取て、処理しやすいブロックにデータを断片化して、任意にデータを圧縮して、MACを当てはまって、暗号化して、伝えます。 受信データは、解読されて、確かめられて、減圧されて、組み立て直されて、クライアントはその時、より高いレベルに配送しました。
Four record protocol clients are described in this document: the handshake protocol, the alert protocol, the change cipher spec protocol, and the application data protocol. In order to allow extension of the TLS protocol, additional record types can be supported by the record protocol. Any new record types should allocate type values immediately beyond the ContentType values for the four record types described here (see Appendix A.2). If a TLS implementation receives a record type it does not understand, it should just ignore it. Any protocol designed for use over TLS must be carefully designed to deal with all possible attacks against it. 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 analysis of these values.
4人の記録的なプロトコルクライアントが本書では説明されます: 握手プロトコル、注意深いプロトコル、変化暗号仕様プロトコル、およびアプリケーションデータは議定書を作ります。 TLSプロトコルの拡大を許すために、記録的なプロトコルは追加レコード種類をサポートすることができます。 どんな新しいレコード種類もここで説明された4つのレコード種類のために値をタイプにContentType値すぐを超えたところまで割り当てるべきです(Appendix A.2を見てください)。 TLS実装がレコード種類を受け取るなら、分からないで、ただそれを無視するべきです。 それに対してすべての可能な攻撃に対処するように入念にTLSの上の使用のために設計されたどんなプロトコルも設計しなければなりません。 記録のタイプと長さが暗号化で保護されないので注意がこれらの値のトラヒック分析の値を最小にするためには撮影であるべきであることに注意してください。
Dierks & Allen Standards Track [Page 13] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[13ページ]RFC2246TLSプロトコルバージョン1999年1月1日
6.1. Connection states
6.1. 接続州
A TLS connection state is the operating environment of the TLS Record Protocol. It specifies a compression algorithm, encryption algorithm, and MAC algorithm. In addition, the parameters for these algorithms are known: the MAC secret and the bulk encryption keys and IVs for the connection in both the read and the write directions. Logically, there are always four connection states outstanding: the current read and write states, and the pending read and write states. All records are processed under the current read and write states. The security parameters for the pending states can be set by the TLS Handshake Protocol, and the Handshake Protocol can selectively make either of the pending states current, in which case the appropriate current state is disposed of and replaced with the pending state; the pending state is then reinitialized to an empty state. It is illegal to make a state which has not been initialized with security parameters a current state. The initial current state always specifies that no encryption, compression, or MAC will be used.
TLS接続状態はTLS Recordプロトコルの操作環境です。 それは圧縮アルゴリズム、暗号化アルゴリズム、およびMACアルゴリズムを指定します。 さらに、これらのアルゴリズムのためのパラメタは知られています: そして、両方の読書における接続のための大量の暗号化のMAC秘密、キー、およびIVs、方向を書いてください。 論理的に、未払いの4つの接続州がいつもあります: 電流は、読まれた州、および未定を読み書きして、州に書きます。 すべての記録が、読まれた電流の下で処理されて、州に書きます。 TLS Handshakeプロトコルで未定の州のためのセキュリティパラメタを設定できて、Handshakeプロトコルで未定の州のどちらかが選択的に現在になる場合があって、その場合、処分して、適切な現状を未定の状態に取り替えます。 そして、未定の状態は人影のない状態に再初期化されます。 セキュリティパラメタで初期化されていない状態を現状にするのは不法です。 初速度電流州は、いつもどんな暗号化、圧縮も、またはMACも使用されないと指定します。
The security parameters for a TLS Connection read and write state are set by providing the following values:
TLS Connectionのためのパラメタが以下の値を提供することによって設定されると状態に読み込んで、書くセキュリティ:
connection end
Whether this entity is considered the "client" or the "server" in
this connection.
この実体が「クライアントかサーバ」であるとついては、考えられる接続終わりのWhether。
bulk encryption algorithm
An algorithm to be used for bulk encryption. This specification
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 of
the cipher (if appropriate), and whether it is considered an
"export" cipher.
暗号化アルゴリズムAnアルゴリズムを膨らませて、大量の暗号化に使用されてください。 この仕様はこのアルゴリズムの主要なサイズを含んでいます、そのキーの多くがどう秘密であるか、それがブロックストリーム暗号、暗号(適切であるなら)のブロック・サイズであり、「輸出」暗号であると考えられるか否かに関係なく。
MAC algorithm
An algorithm to be used for message authentication. This
specification includes the size of the hash which is returned by
the MAC algorithm.
通報認証に使用されるべきMACアルゴリズムAnアルゴリズム。 この仕様はMACアルゴリズムで返されるハッシュのサイズを含んでいます。
compression algorithm
An algorithm to be used for data compression. This specification
must include all information the algorithm requires to do
compression.
データ圧縮に使用されるべき圧縮アルゴリズムAnアルゴリズム。 この仕様はアルゴリズムが圧縮するのを必要とするすべての情報を含まなければなりません。
master secret
A 48 byte secret shared between the two peers in the connection.
接続における2人の同輩の間で共有された秘密のA48バイト秘密をマスタリングしてください。
client random
A 32 byte value provided by the client.
クライアントによって提供されたクライアントのAの32バイトの無作為の価値。
Dierks & Allen Standards Track [Page 14] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[14ページ]RFC2246TLSプロトコルバージョン1999年1月1日
server random
A 32 byte value provided by the server.
サーバによって提供されたサーバのAの32バイトの無作為の価値。
These parameters are defined in the presentation language as:
これらのパラメタはプレゼンテーション言語で以下と定義されます。
enum { server, client } ConnectionEnd;
サーバ、クライアントをenumする、ConnectionEnd。
enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm;
ヌル、rc4、rc2、des、3des、des40をenumする、BulkCipherAlgorithm。
enum { stream, block } CipherType;
ストリーム、ブロックをenumする、CipherType。
enum { true, false } IsExportable;
enumの本当の、そして、偽のIsExportable。
enum { null, md5, sha } MACAlgorithm;
ヌル、md5がshaするenum、MACAlgorithm。
enum { null(0), (255) } CompressionMethod;
ヌル(0)、(255)をenumする、CompressionMethod。
/* The algorithms specified in CompressionMethod,
BulkCipherAlgorithm, and MACAlgorithm may be added to. */
/*CompressionMethodで指定されたアルゴリズム、BulkCipherAlgorithm、およびMACAlgorithmに追加されるかもしれません。 */
struct {
ConnectionEnd entity;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 key_size;
uint8 key_material_length;
IsExportable is_exportable;
MACAlgorithm mac_algorithm;
uint8 hash_size;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
struct ConnectionEnd実体; CipherTypeは_タイプを解きます; uint8の主要な_サイズ; uint8の主要な_の材料_長さ; IsExportableが輸出向きの_であるというMACAlgorithm mac_アルゴリズム; uint8ハッシュ_サイズ; CompressionMethod圧縮_アルゴリズム; 不透明なものが_秘密の[48]_無作為の; 不透明なクライアント_無作為の[32];不明瞭なサーバ[32]をマスタリングするBulkCipherAlgorithm大量_暗号_アルゴリズム;SecurityParameters。
The record layer will use the security parameters to generate the following six items:
記録的な層は以下の6つの項目を生成するのにセキュリティパラメタを使用するでしょう:
client write MAC secret
server write MAC secret
client write key
server write key
client write IV (for block ciphers only)
server write IV (for block ciphers only)
クライアントは主要なクライアントがIVを書くと秘密のサーバが、秘密のクライアントが書くと主要なサーバに書くMACに書くIV(ブロック暗号だけのための)サーバを書くMACに書きます。(ブロック暗号だけのための)
The client write parameters are used by the server when receiving and processing records and vice-versa. The algorithm used for generating these items from the security parameters is described in section 6.3.
クライアントは記録を受け取って、処理するとき、パラメタがサーバによって使用されて、逆もまた同様ですと書きます。 セキュリティパラメタからこれらの項目を生成するのに使用されるアルゴリズムはセクション6.3で説明されます。
Dierks & Allen Standards Track [Page 15] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[15ページ]RFC2246TLSプロトコルバージョン1999年1月1日
Once the security parameters have been set and the keys have been generated, the connection states can be instantiated by making them the current states. These current states must be updated for each record processed. Each connection state includes the following elements:
いったんセキュリティパラメタが設定されて、キーが生成されると、それらを現状にすることによって、接続州を例示できます。 処理された各記録のためにこれらの現状をアップデートしなければなりません。 それぞれの接続州は以下の要素を含めます:
compression state
The current state of the compression algorithm.
圧縮は圧縮アルゴリズムの現状を述べます。
cipher state
The current state of the encryption algorithm. This will consist
of the scheduled key for that connection. In addition, for block
ciphers running in CBC mode (the only mode specified for TLS),
this will initially contain the IV for that connection state and
be updated to contain the ciphertext of the last block encrypted
or decrypted as records are processed. For stream ciphers, this
will contain whatever the necessary state information is to allow
the stream to continue to encrypt or decrypt data.
暗号は暗号化アルゴリズムの現状を述べます。 これはその接続のための予定されているキーから成るでしょう。 さらに、CBCモード(TLSに指定された唯一のモード)へ駆け込むブロック暗号において、これを初めは、その接続状態へのIVを含んで、記録が処理されるので、暗号化されるか、または解読された最後のブロックの暗号文を含むようにアップデートするでしょう。 ストリーム暗号のために、これはストリームがデータを暗号化するか、または解読するために必要な州の情報で続けることになっていることができることなら何でも含むでしょう。
MAC secret
The MAC secret for this connection as generated above.
MAC秘密、上で生成されるこの接続へのMAC秘密。
sequence number
Each connection state contains a sequence number, which is
maintained separately for read and write states. The sequence
number must be set to zero whenever a connection state is made
the active state. Sequence numbers are of type uint64 and may not
exceed 2^64-1. A sequence number is incremented after each
record: specifically, the first record which is transmitted under
a particular connection state should use sequence number 0.
状態が別々に維持される一連番号を含む一連番号Each接続は州を読み書きします。 接続状態が作られているときはいつも、ゼロに一連番号を設定しなければなりません。活動的な状態。 一連番号は、タイプuint64にはあって、2^64-1を超えないかもしれません。 一連番号は各記録の後に増加されます: 明確に、特定の接続状態の下で伝えられる最初の記録は一連番号0を使用するべきです。
6.2. Record layer
6.2. 層を記録してください。
The TLS Record Layer receives uninterpreted data from higher layers in non-empty blocks of arbitrary size.
TLS Record Layerは、より高い層から非空きブロックの任意のサイズで非解釈されたデータを受け取ります。
6.2.1. Fragmentation
6.2.1. 断片化
The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType may be coalesced into a single TLSPlaintext record, or a single message may be fragmented across several records).
記録的な層は2^の塊におけるデータを14バイト以下運ぶTLSPlaintext記録に情報ブロックを断片化します。 クライアントメッセージ限界は記録的な層の中に保持されません(すなわち、同じContentTypeに関する複数のクライアントメッセージがただ一つのTLSPlaintext記録と合体するかもしれませんか、またはただ一つのメッセージはいくつかの記録の向こう側に断片化されるかもしれません)。
struct {
uint8 major, minor;
} ProtocolVersion;
struct、uint8少佐、未成年者;、ProtocolVersion。
Dierks & Allen Standards Track [Page 16] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[16ページ]RFC2246TLSプロトコルバージョン1999年1月1日
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;
enumに_暗号_仕様(20)、警戒(21)、握手(22)、アプリケーション_データ(23)、(255)を変えてください、ContentType。
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
struct ContentTypeタイプ; ProtocolVersionバージョン; uint16の長さ; 不明瞭な断片[TLSPlaintext.length];TLSPlaintext。
type
The higher level protocol used to process the enclosed fragment.
同封の断片を処理するのに使用されるより高い平らなプロトコルをタイプしてください。
version
The version of the protocol being employed. This document
describes TLS Version 1.0, which uses the version { 3, 1 }. The
version value 3.1 is historical: TLS version 1.0 is a minor
modification to the SSL 3.0 protocol, which bears the version
value 3.0. (See Appendix A.1).
バージョン、使われるプロトコルのバージョン。 このドキュメントはTLSバージョン1.0について説明して、どれがバージョンを使用するか。3、1。 バージョン値3.1は歴史的です: TLSバージョン1.0はSSL3.0プロトコルへの小さい方の変更です。(それは、バージョン値3.0に堪えます)。 (付録A.1を見ます。)
length
The length (in bytes) of the following TLSPlaintext.fragment.
The length should not exceed 2^14.
長さ、以下のTLSPlaintext.fragmentの長さ(バイトによる)。 長さは2^14を超えるべきではありません。
fragment
The application data. This data is transparent and treated as an
independent block to be dealt with by the higher level protocol
specified by the type field.
アプリケーションデータを断片化してください。 このデータは、透明であり、タイプ分野によって指定されたより高い平らなプロトコルによって対処されるために独立しているブロックとして扱われます。
Note: Data of different TLS Record layer content types may be
interleaved. Application data is generally of lower precedence
for transmission than other content types.
以下に注意してください。 異なったTLS Record層のcontent typeに関するデータははさみ込まれるかもしれません。 一般に、アプリケーションデータはトランスミッションのために他のcontent typeより下側に上位です。
6.2.2. Record compression and decompression
6.2.2. 圧縮と減圧を記録してください。
All records are compressed using the compression algorithm defined in the current session state. There is always an active compression algorithm; however, initially it is defined as CompressionMethod.null. The compression algorithm translates a TLSPlaintext structure into a TLSCompressed structure. Compression functions are initialized with default state information whenever a connection state is made active.
すべての記録が、現在のセッション状態で定義された圧縮アルゴリズムを使用することで圧縮されます。 アクティブな圧縮アルゴリズムがいつもあります。 しかしながら、初めは、それはCompressionMethod.nullと定義されます。 圧縮アルゴリズムはTLSPlaintext構造をTLSCompressed構造に移します。 接続状態をアクティブにするときはいつも、圧縮機能はデフォルト州の情報で初期化されます。
Dierks & Allen Standards Track [Page 17] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[17ページ]RFC2246TLSプロトコルバージョン1999年1月1日
Compression must be lossless and may not increase the content length by more than 1024 bytes. If the decompression function encounters a TLSCompressed.fragment that would decompress to a length in excess of 2^14 bytes, it should report a fatal decompression failure error.
圧縮は、losslessでなければならなく、コンテンツの長さを1024バイト以上増強しないかもしれません。 減圧機能が2以上^を長さに14バイト減圧するTLSCompressed.fragmentに遭遇するなら、それは致命的な減圧失敗誤りを報告するべきです。
struct {
ContentType type; /* same as TLSPlaintext.type */
ProtocolVersion version;/* same as TLSPlaintext.version */
uint16 length;
opaque fragment[TLSCompressed.length];
} TLSCompressed;
struct ContentTypeタイプ; TLSPlaintext.type*/ProtocolVersionバージョン; TLSPlaintext.version*/uint16の長さと同じ/*;が断片[TLSCompressed.length]について不透明にするのと同じ/*;TLSCompressed。
length
The length (in bytes) of the following TLSCompressed.fragment.
The length should not exceed 2^14 + 1024.
長さ、以下のTLSCompressed.fragmentの長さ(バイトによる)。 長さは2^14+1024を超えるべきではありません。
fragment
The compressed form of TLSPlaintext.fragment.
TLSPlaintext.fragmentの圧縮形を断片化してください。
Note: A CompressionMethod.null operation is an identity operation; no
fields are altered.
以下に注意してください。 CompressionMethod.null操作は一致演算です。 分野は全く変更されません。
Implementation note:
Decompression functions are responsible for ensuring that
messages cannot cause internal buffer overflows.
実装注意: メッセージが内部のバッファオーバーフローを引き起こさない場合があるのを確実にするのに減圧機能は原因となります。
6.2.3. Record payload protection
6.2.3. ペイロード保護を記録してください。
The encryption and MAC functions translate a TLSCompressed structure into a TLSCiphertext. The decryption functions reverse the process. The MAC of the record also includes a sequence number so that missing, extra or repeated messages are detectable.
暗号化とMAC機能はTLSCompressed構造をTLSCiphertextに翻訳します。 復号化機能はプロセスを逆にします。 また、記録のMACが一連番号を含んでいるので、なくなったか、付加的であるか繰り返されたメッセージは検出可能です。
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
} fragment;
} TLSCiphertext;
struct ContentTypeタイプ; ProtocolVersionバージョン; uint16の長さ; ケースストリーム: GenericStreamCipherケースブロック: (GenericBlockCipher)が断片化する選んだ(CipherSpec.cipher_タイプ);TLSCiphertext。
type
The type field is identical to TLSCompressed.type.
タイプがさばくタイプはTLSCompressed.typeと同じです。
version
The version field is identical to TLSCompressed.version.
バージョンがさばくバージョンはTLSCompressed.versionと同じです。
Dierks & Allen Standards Track [Page 18] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[18ページ]RFC2246TLSプロトコルバージョン1999年1月1日
length
The length (in bytes) of the following TLSCiphertext.fragment.
The length may not exceed 2^14 + 2048.
長さ、以下のTLSCiphertext.fragmentの長さ(バイトによる)。 長さは2^14+2048を超えないかもしれません。
fragment
The encrypted form of TLSCompressed.fragment, with the MAC.
MACと共にTLSCompressed.fragmentの暗号化されたフォームを断片化してください。
6.2.3.1. Null or standard stream cipher
6.2.3.1. ヌルの、または、標準のストリーム暗号
Stream ciphers (including BulkCipherAlgorithm.null - see Appendix A.6) convert TLSCompressed.fragment structures to and from stream TLSCiphertext.fragment structures.
ストリーム暗号(BulkCipherAlgorithm.nullを含んでいます--Appendix A.6を見る)は構造とストリームTLSCiphertext.fragment構造からTLSCompressed.fragment構造を変換します。
stream-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
} GenericStreamCipher;
ストリームで解かれたstruct不透明なもの満足している[TLSCompressed.length]; 不透明なMAC[CipherSpec.hash_サイズ];GenericStreamCipher。
The MAC is generated as:
MACは以下として生成されます。
HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.length +
TLSCompressed.fragment));
HMAC_ハッシュ(seq_num+TLSCompressed.type+TLSCompressed.version+TLSCompressed.length+TLSCompressed.fragment、MAC_は_秘密を書きます)。
where "+" denotes concatenation.
「+」が連結を指示するところ。
seq_num
The sequence number for this record.
これのための一連番号が記録するseq_num。
hash
The hashing algorithm specified by
SecurityParameters.mac_algorithm.
SecurityParameters.mac_アルゴリズムで指定された論じ尽くすアルゴリズムを論じ尽くしてください。
Note that the MAC is computed before encryption. The stream cipher encrypts the entire block, including the MAC. For stream ciphers that do not use a synchronization vector (such as RC4), the stream cipher state from the end of one record is simply used on the subsequent packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption consists of the identity operation (i.e., the data is not encrypted and the MAC size is zero implying that no MAC is used). TLSCiphertext.length is TLSCompressed.length plus CipherSpec.hash_size.
MACが暗号化の前に計算されることに注意してください。 ストリーム暗号はMACを含む全体のブロックを暗号化します。 同期ベクトル(RC4などの)を使用しないストリーム暗号のために、1つの記録の終わりからのストリーム暗号状態はその後のパケットの上で単に使用されます。 CipherSuiteがTLS_NULL_WITH_NULL_NULLであるなら、暗号化は一致演算から成ります(すなわち、データが暗号化されていません、そして、MACサイズはどんなMACも使用されていないのを含意しないことです)。 TLSCiphertext.lengthはTLSCompressed.lengthとCipherSpec.hash_サイズです。
6.2.3.2. CBC block cipher
6.2.3.2. CBCブロック暗号
For block ciphers (such as RC2 or DES), the encryption and MAC functions convert TLSCompressed.fragment structures to and from block TLSCiphertext.fragment structures.
ブロック暗号(RC2かDESなどの)のために、暗号化とMAC機能は構造とブロックTLSCiphertext.fragment構造からTLSCompressed.fragment構造を変換します。
Dierks & Allen Standards Track [Page 19] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[19ページ]RFC2246TLSプロトコルバージョン1999年1月1日
block-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
ブロックで解かれたstruct不透明なもの満足している[TLSCompressed.length]; 不透明なMAC[CipherSpec.hash_サイズ]; [GenericBlockCipher.padding_長さ]を水増しするuint8; _長さを水増しするuint8;GenericBlockCipher。
The MAC is generated as described in Section 6.2.3.1.
MACはセクション6.2.3で.1に説明されるように発生しています。
padding
Padding that is added to force the length of the plaintext to be
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
results in the TLSCiphertext.length being an integral multiple of
the block length. Lengths longer than necessary might be
desirable to frustrate attacks on a protocol based on analysis of
the lengths of exchanged messages. Each uint8 in the padding data
vector must be filled with the padding length value.
平文の長さがブロック暗号のブロック長の不可欠の倍数であることを強制するために加えられるPaddingを水増しします。 詰め物は長さ最大255バイトのどんな長さであるかもしれません、ブロック長の不可欠の倍数であるTLSCiphertext.lengthをもたらす限り。 必要とするより長い長さは交換されたメッセージの長さの分析に基づくプロトコルに対する攻撃をだめにするのにおいて望ましいかもしれません。 詰め物長さの価値で詰め物データベクトルにおける各uint8を満たさなければなりません。
padding_length
The padding length should be such that the total size of the
GenericBlockCipher structure is a multiple of the cipher's block
length. Legal values range from zero to 255, inclusive. This
length specifies the length of the padding field exclusive of the
padding_length field itself.
_長さを水増しして、詰め物の長さがそのようなものであるべきであるので、GenericBlockCipher構造の総サイズは暗号のブロック長の倍数です。 正当な値はゼロ〜255まで包括的に及びます。 この長さは詰め物_長さの分野自体を除いて詰め物分野の長さを指定します。
The encrypted data length (TLSCiphertext.length) is one more than the sum of TLSCompressed.length, CipherSpec.hash_size, and padding_length.
The encrypted data length (TLSCiphertext.length) is one more than the sum of TLSCompressed.length, CipherSpec.hash_size, and padding_length.
Example: If the block length is 8 bytes, the content length
(TLSCompressed.length) is 61 bytes, and the MAC length is 20
bytes, the length before padding is 82 bytes. Thus, the
padding length modulo 8 must be equal to 6 in order to make
the total length an even multiple of 8 bytes (the block
length). The padding length can be 6, 14, 22, and so on,
through 254. If the padding length were the minimum necessary,
6, the padding would be 6 bytes, each containing the value 6.
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
last octet of the MAC.
Example: If the block length is 8 bytes, the content length (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes, the length before padding is 82 bytes. Thus, the padding length modulo 8 must be equal to 6 in order to make the total length an even multiple of 8 bytes (the block length). The padding length can be 6, 14, 22, and so on, through 254. If the padding length were the minimum necessary, 6, the padding would be 6 bytes, each containing the value 6. 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 last octet of the MAC.
Note: With block ciphers in CBC mode (Cipher Block Chaining) the
initialization vector (IV) for the first record is generated with
the other keys and secrets when the security parameters are set.
The IV for subsequent records is the last ciphertext block from
the previous record.
Note: With block ciphers in CBC mode (Cipher Block Chaining) the initialization vector (IV) for the first record is generated with the other keys and secrets when the security parameters are set. The IV for subsequent records is the last ciphertext block from the previous record.
Dierks & Allen Standards Track [Page 20] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 20] RFC 2246 The TLS Protocol Version 1.0 January 1999
6.3. Key calculation
6.3. Key calculation
The Record Protocol requires an algorithm to generate keys, IVs, and MAC secrets from the security parameters provided by the handshake protocol.
The Record Protocol requires an algorithm to generate keys, IVs, and MAC secrets from the security parameters provided by the handshake protocol.
The master secret is hashed into a sequence of secure bytes, which are assigned to the MAC secrets, keys, and non-export IVs required by the current connection state (see Appendix A.6). CipherSpecs require a client write MAC secret, a server write MAC secret, a client write key, a server write key, a client write IV, and a server write IV, which are generated from the master secret in that order. Unused values are empty.
The master secret is hashed into a sequence of secure bytes, which are assigned to the MAC secrets, keys, and non-export IVs required by the current connection state (see Appendix A.6). CipherSpecs require a client write MAC secret, a server write MAC secret, a client write key, a server write key, a client write IV, and a server write IV, which are generated from the master secret in that order. Unused values are empty.
When generating keys and MAC secrets, the master secret is used as an entropy source, and the random values provide unencrypted salt material and IVs for exportable ciphers.
When generating keys and MAC secrets, the master secret is used as an entropy source, and the random values provide unencrypted salt material and IVs for exportable ciphers.
To generate the key material, compute
To generate the key material, compute
key_block = PRF(SecurityParameters.master_secret,
"key expansion",
SecurityParameters.server_random +
SecurityParameters.client_random);
key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random);
until enough output has been generated. Then the key_block is partitioned as follows:
until enough output has been generated. Then the key_block is partitioned as follows:
client_write_MAC_secret[SecurityParameters.hash_size]
server_write_MAC_secret[SecurityParameters.hash_size]
client_write_key[SecurityParameters.key_material_length]
server_write_key[SecurityParameters.key_material_length]
client_write_IV[SecurityParameters.IV_size]
server_write_IV[SecurityParameters.IV_size]
client_write_MAC_secret[SecurityParameters.hash_size] server_write_MAC_secret[SecurityParameters.hash_size] client_write_key[SecurityParameters.key_material_length] server_write_key[SecurityParameters.key_material_length] client_write_IV[SecurityParameters.IV_size] server_write_IV[SecurityParameters.IV_size]
The client_write_IV and server_write_IV are only generated for non- export block ciphers. For exportable block ciphers, the initialization vectors are generated later, as described below. Any extra key_block material is discarded.
The client_write_IV and server_write_IV are only generated for non- export block ciphers. For exportable block ciphers, the initialization vectors are generated later, as described below. Any extra key_block material is discarded.
Implementation note:
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
keys, 2 x 20 byte MAC secrets, and 2 x 8 byte IVs, for a total of
104 bytes of key material.
Implementation note: 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 keys, 2 x 20 byte MAC secrets, and 2 x 8 byte IVs, for a total of 104 bytes of key material.
Dierks & Allen Standards Track [Page 21] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 21] RFC 2246 The TLS Protocol Version 1.0 January 1999
Exportable encryption algorithms (for which CipherSpec.is_exportable is true) require additional processing as follows to derive their final write keys:
Exportable encryption algorithms (for which CipherSpec.is_exportable is true) require additional processing as follows to derive their final write keys:
final_client_write_key =
PRF(SecurityParameters.client_write_key,
"client write key",
SecurityParameters.client_random +
SecurityParameters.server_random);
final_server_write_key =
PRF(SecurityParameters.server_write_key,
"server write key",
SecurityParameters.client_random +
SecurityParameters.server_random);
final_client_write_key = PRF(SecurityParameters.client_write_key, "client write key", SecurityParameters.client_random + SecurityParameters.server_random); final_server_write_key = PRF(SecurityParameters.server_write_key, "server write key", SecurityParameters.client_random + SecurityParameters.server_random);
Exportable encryption algorithms derive their IVs solely from the random values from the hello messages:
Exportable encryption algorithms derive their IVs solely from the random values from the hello messages:
iv_block = PRF("", "IV block", SecurityParameters.client_random +
SecurityParameters.server_random);
iv_block = PRF("", "IV block", SecurityParameters.client_random + SecurityParameters.server_random);
The iv_block is partitioned into two initialization vectors as the key_block was above:
The iv_block is partitioned into two initialization vectors as the key_block was above:
client_write_IV[SecurityParameters.IV_size]
server_write_IV[SecurityParameters.IV_size]
client_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 means that the secret has a length of zero bytes and contributes nothing to the hashing in the PRF.
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 nothing to the hashing in the PRF.
6.3.1. Export key generation example
6.3.1. Export key generation example
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for each of the two encryption keys and 16 bytes for each of the MAC keys, for a total of 42 bytes of key material. The PRF output is stored in the key_block. The key_block is partitioned, and the write keys are salted because this is an exportable encryption algorithm.
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for each of the two encryption keys and 16 bytes for each of the MAC keys, for a total of 42 bytes of key material. The PRF output is stored in the key_block. The key_block is partitioned, and the write keys are salted because this is an exportable encryption algorithm.
key_block = PRF(master_secret,
"key expansion",
server_random +
client_random)[0..41]
client_write_MAC_secret = key_block[0..15]
server_write_MAC_secret = key_block[16..31]
client_write_key = key_block[32..36]
server_write_key = key_block[37..41]
key_block = PRF(master_secret, "key expansion", server_random + client_random)[0..41] client_write_MAC_secret = key_block[0..15] server_write_MAC_secret = key_block[16..31] client_write_key = key_block[32..36] server_write_key = key_block[37..41]
Dierks & Allen Standards Track [Page 22] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 22] RFC 2246 The TLS Protocol Version 1.0 January 1999
final_client_write_key = PRF(client_write_key,
"client write key",
client_random +
server_random)[0..15]
final_server_write_key = PRF(server_write_key,
"server write key",
client_random +
server_random)[0..15]
final_client_write_key = PRF(client_write_key, "client write key", client_random + server_random)[0..15] final_server_write_key = PRF(server_write_key, "server write key", client_random + server_random)[0..15]
iv_block = PRF("", "IV block", client_random +
server_random)[0..15]
client_write_IV = iv_block[0..7]
server_write_IV = iv_block[8..15]
iv_block = PRF("", "IV block", client_random + server_random)[0..15] client_write_IV = iv_block[0..7] 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 sub-protocols which are used to allow peers to agree upon security parameters for the record layer, authenticate themselves, instantiate negotiated security parameters, and report error conditions to each other.
The TLS Handshake Protocol consists of a suite of three sub-protocols which are used to allow peers to agree upon security parameters for the record layer, authenticate themselves, instantiate negotiated security parameters, and report error conditions to each other.
The Handshake Protocol is responsible for negotiating a session, which consists of the following items:
The Handshake Protocol is responsible for negotiating a session, which consists of the following items:
session identifier
An arbitrary byte sequence chosen by the server to identify an
active or resumable session state.
session identifier An arbitrary byte sequence chosen by the server to identify an active or resumable session state.
peer certificate
X509v3 [X509] certificate of the peer. This element of the state
may be null.
peer certificate X509v3 [X509] certificate of the peer. This element of the state may be null.
compression method
The algorithm used to compress data prior to encryption.
compression method The algorithm used to compress data prior to encryption.
cipher spec
Specifies the bulk data encryption algorithm (such as null, DES,
etc.) and a MAC algorithm (such as MD5 or SHA). It also defines
cryptographic attributes such as the hash_size. (See Appendix A.6
for formal definition)
cipher spec Specifies the bulk data encryption algorithm (such as null, DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also defines cryptographic attributes such as the hash_size. (See Appendix A.6 for formal definition)
master secret
48-byte secret shared between the client and server.
master secret 48-byte secret shared between the client and server.
is resumable
A flag indicating whether the session can be used to initiate new
connections.
is resumable A flag indicating whether the session can be used to initiate new connections.
Dierks & Allen Standards Track [Page 23] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 23] RFC 2246 The TLS Protocol Version 1.0 January 1999
These items are then used to create security parameters for use by the Record Layer when protecting application data. Many connections can be instantiated using the same session through the resumption feature of the TLS Handshake Protocol.
These items are then used to create security parameters for use by the Record Layer when protecting application data. Many connections can be instantiated using the same session through the resumption 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 ciphering strategies. The protocol consists of a single message, which is encrypted and compressed under the current (not the pending) connection state. The message consists of a single byte of value 1.
The change cipher spec protocol exists to signal transitions in ciphering strategies. The protocol consists of a single message, which is encrypted and compressed under the current (not the pending) connection state. The message consists of a single byte of value 1.
struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
struct { enum { change_cipher_spec(1), (255) } type; } ChangeCipherSpec;
The change cipher spec message is sent by both the client and server to notify the receiving party that subsequent records will be protected under the newly negotiated CipherSpec and keys. Reception of this message causes the receiver to instruct the Record Layer to immediately copy the read pending state into the read current state. Immediately after sending this message, the sender should instruct the record layer to make the write pending state the write active state. (See section 6.1.) The change cipher spec message is sent during the handshake after the security parameters have been agreed upon, but before the verifying finished message is sent (see section 7.4.9).
The change cipher spec message is sent by both the client and server to notify the receiving party that subsequent records will be protected under the newly negotiated CipherSpec and keys. Reception of this message causes the receiver to instruct the Record Layer to immediately copy the read pending state into the read current state. Immediately after sending this message, the sender should instruct the record layer to make the write pending state the write active state. (See section 6.1.) The change cipher spec message is sent during the handshake after the security parameters have been agreed upon, but before the verifying finished message is sent (see section 7.4.9).
7.2. Alert protocol
7.2. Alert protocol
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 description of the alert. Alert messages with a level of fatal result in the immediate termination of the connection. In this case, other connections corresponding to the session may continue, but the session identifier must be invalidated, preventing the failed session from being used to establish new connections. Like other messages, alert messages are encrypted and compressed, as specified by the current connection state.
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 description of the alert. Alert messages with a level of fatal result in the immediate termination of the connection. In this case, other connections corresponding to the session may continue, but the session identifier must be invalidated, preventing the failed session from being used to establish new connections. Like other messages, alert messages are encrypted and compressed, as specified by the current connection state.
enum { warning(1), fatal(2), (255) } AlertLevel;
enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed(21),
record_overflow(22),
enum { close_notify(0), unexpected_message(10), bad_record_mac(20), decryption_failed(21), record_overflow(22),
Dierks & Allen Standards Track [Page 24] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 24] RFC 2246 The TLS Protocol Version 1.0 January 1999
decompression_failure(30),
handshake_failure(40),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
(255)
} AlertDescription;
decompression_failure(30), handshake_failure(40), bad_certificate(42), unsupported_certificate(43), certificate_revoked(44), certificate_expired(45), certificate_unknown(46), illegal_parameter(47), unknown_ca(48), access_denied(49), decode_error(50), decrypt_error(51), export_restriction(60), protocol_version(70), insufficient_security(71), internal_error(80), user_canceled(90), no_renegotiation(100), (255) } AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
struct { AlertLevel level; AlertDescription description; } Alert;
7.2.1. Closure alerts
7.2.1. Closure alerts
The client and the server must share knowledge that the connection is ending in order to avoid a truncation attack. Either party may initiate the exchange of closing messages.
The client and the server must share knowledge that the connection is ending in order to avoid a truncation attack. Either party may initiate the exchange of closing messages.
close_notify
This message notifies the recipient that the sender will not send
any more messages on this connection. The session becomes
unresumable if any connection is terminated without proper
close_notify messages with level equal to warning.
close_notify This message notifies the recipient that the sender will not send any more messages on this connection. The session becomes unresumable if any connection is terminated without proper close_notify messages with level equal to warning.
Either party may initiate a close by sending a close_notify alert. Any data received after a closure alert is ignored.
Either party may initiate a close by sending a close_notify alert. Any data received after a closure alert is ignored.
Each party is required to send a close_notify alert before closing the write side of the connection. It is required that the other party respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes. It is not required for the initiator of the close to wait for the responding close_notify alert before closing the read side of the connection.
Each party is required to send a close_notify alert before closing the write side of the connection. It is required that the other party respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes. It is not required for the initiator of the close to wait for the responding close_notify alert before closing the read side of the connection.
Dierks & Allen Standards Track [Page 25] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 25] RFC 2246 The TLS Protocol Version 1.0 January 1999
If the application protocol using TLS provides that any data may be carried over the underlying transport after the TLS connection is closed, the TLS implementation must receive the responding close_notify alert before indicating to the application layer that the TLS connection has ended. If the application protocol will not transfer any additional data, but will only close the underlying transport connection, then the implementation may choose to close the transport without waiting for the responding close_notify. No part of this standard should be taken to dictate the manner in which a usage profile for TLS manages its data transport, including when connections are opened or closed.
If the application protocol using TLS provides that any data may be carried over the underlying transport after the TLS connection is closed, the TLS implementation must receive the responding close_notify alert before indicating to the application layer that the TLS connection has ended. If the application protocol will not transfer any additional data, but will only close the underlying transport connection, then the implementation may choose to close the transport without waiting for the responding close_notify. No part of this standard should be taken to dictate the manner in which a usage profile for TLS manages its data transport, including when connections are opened or closed.
NB: It is assumed that closing a connection reliably delivers
pending data before destroying the transport.
NB: It is assumed that closing a connection reliably delivers 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 is detected, the detecting party sends a message to the other party. Upon transmission or receipt of an fatal alert message, both parties immediately close the connection. Servers and clients are required to forget any session-identifiers, keys, and secrets associated with a failed connection. The following error alerts are defined:
Error handling in the TLS Handshake protocol is very simple. When an error is detected, the detecting party sends a message to the other party. Upon transmission or receipt of an fatal alert message, both parties immediately close the connection. Servers and clients are required to forget any session-identifiers, keys, and secrets associated with a failed connection. The following error alerts are defined:
unexpected_message
An inappropriate message was received. This alert is always fatal
and should never be observed in communication between proper
implementations.
unexpected_message An inappropriate message was received. This alert is always fatal and should never be observed in communication between proper implementations.
bad_record_mac
This alert is returned if a record is received with an incorrect
MAC. This message is always fatal.
bad_record_mac This alert is returned if a record is received with an incorrect MAC. This message is always fatal.
decryption_failed
A TLSCiphertext decrypted in an invalid way: either it wasn`t an
even multiple of the block length or its padding values, when
checked, weren`t correct. This message is always fatal.
decryption_failed A TLSCiphertext decrypted in an invalid way: either it wasn`t an even multiple of the block length or its padding values, when checked, weren`t correct. This message is always fatal.
record_overflow
A TLSCiphertext record was received which had a length more than
2^14+2048 bytes, or a record decrypted to a TLSCompressed record
with more than 2^14+1024 bytes. This message is always fatal.
record_overflow A TLSCiphertext record was received which had a length more than 2^14+2048 bytes, or a record decrypted to a TLSCompressed record with more than 2^14+1024 bytes. This message is always fatal.
decompression_failure
The decompression function received improper input (e.g. data
that would expand to excessive length). This message is always
fatal.
decompression_failure The decompression function received improper input (e.g. data that would expand to excessive length). This message is always fatal.
Dierks & Allen Standards Track [Page 26] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 26] RFC 2246 The TLS Protocol Version 1.0 January 1999
handshake_failure
Reception of a handshake_failure alert message indicates that the
sender was unable to negotiate an acceptable set of security
parameters given the options available. This is a fatal error.
handshake_failure Reception of a handshake_failure alert message indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available. This is a fatal error.
bad_certificate
A certificate was corrupt, contained signatures that did not
verify correctly, etc.
悪い_証明書A証明書はそれが正しく確かめなかった不正で、含まれた署名でしたなど。
unsupported_certificate
A certificate was of an unsupported type.
サポートされないタイプにはサポートされない_証明書A証明書がありました。
certificate_revoked
A certificate was revoked by its signer.
証明書の_の取り消されたA証明書は署名者によって取り消されました。
certificate_expired
A certificate has expired or is not currently valid.
満期のA証明書にはある証明書_は期限が切れるか、または現在、有効ではありません。
certificate_unknown
Some other (unspecified) issue arose in processing the
certificate, rendering it unacceptable.
証明書_未知のSome他の(不特定)の問題はそれを容認できなくして、証明書を処理する際に起こりました。
illegal_parameter
A field in the handshake was out of range or inconsistent with
other fields. This is always fatal.
握手における不法な_パラメタA分野は、範囲から脱していたか、または他の分野に矛盾しています。 これはいつも致命的です。
unknown_ca
A valid certificate chain or partial chain was received, but the
certificate was not accepted because the CA certificate could not
be located or couldn`t be matched with a known, trusted CA. This
message is always fatal.
未知の_ca A有効な証明書チェーンか部分的なチェーンを受け取りましたが、証明書をカリフォルニア証明書の見つけることができなかったので受け入れないことができなかったか、知られていて、信じられたカリフォルニアに合わせることができませんでした。 このメッセージはいつも致命的です。
access_denied
A valid certificate was received, but when access control was
applied, the sender decided not to proceed with negotiation.
This message is always fatal.
アクセス_は、A有効な証明書が受け取られたことを否定しましたが、アクセスコントロールが適用されたとき、送付者は、交渉を続けないと決めました。 このメッセージはいつも致命的です。
decode_error
A message could not be decoded because some field was out of the
specified range or the length of the message was incorrect. This
message is always fatal.
_何らかの分野が指定された範囲から脱していたので解読できなかったか、またはメッセージの長さが不正確であったという誤りAメッセージを解読してください。 このメッセージはいつも致命的です。
decrypt_error
A handshake cryptographic operation failed, including being
unable to correctly verify a signature, decrypt a key exchange,
or validate a finished message.
_誤りAが正しく署名について確かめることができないのを含んでいて、失敗された握手の暗号の操作であると解読するか、主要な交換を解読するか、または終わっているメッセージを有効にしてください。
Dierks & Allen Standards Track [Page 27] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[27ページ]RFC2246TLSプロトコルバージョン1999年1月1日
export_restriction
A negotiation not in compliance with export restrictions was
detected; for example, attempting to transfer a 1024 bit
ephemeral RSA key for the RSA_EXPORT handshake method. This
message is always fatal.
輸出_制限A交渉は輸出制限に従って検出されませんでした。 例えば、RSA_EXPORT握手メソッドに、主要な1024年のビットのはかないRSAを移すのを試みること。 このメッセージはいつも致命的です。
protocol_version
The protocol version the client has attempted to negotiate is
recognized, but not supported. (For example, old protocol
versions might be avoided for security reasons). This message is
always fatal.
クライアントが持っているプロトコルバージョンが交渉するのを試みたプロトコル_バージョンは、認識されますが、サポートされません。 (例えば、古いプロトコルバージョンは安全保障上の理由で避けられるかもしれません。) このメッセージはいつも致命的です。
insufficient_security
Returned instead of handshake_failure when a negotiation has
failed specifically because the server requires ciphers more
secure than those supported by the client. This message is always
fatal.
交渉であるときに、特にサーバがクライアントによってサポートされたものより安全な状態で暗号を必要とするので、握手_失敗の代わりに不十分な_セキュリティReturnedは失敗しました。 このメッセージはいつも致命的です。
internal_error
An internal error unrelated to the peer or the correctness of the
protocol makes it impossible to continue (such as a memory
allocation failure). This message is always fatal.
同輩にとって、関係ない内部の_誤りAn内部エラーかプロトコルの正当性で、それは続けているのが不可能に(メモリ割り振りの失敗などの)なります。 このメッセージはいつも致命的です。
user_canceled
This handshake is being canceled for some reason unrelated to a
protocol failure. If the user cancels an operation after the
handshake is complete, just closing the connection by sending a
close_notify is more appropriate. This alert should be followed
by a close_notify. This message is generally a warning.
ユーザの_の取り消されたThis握手はある理由でプロトコル失敗に関係ない状態で中止されています。 握手が完全になった後にユーザが操作を中止するなら、_が通知する閉鎖を送ることによって接続をただ終えるのは、より適切です。 _が通知する閉鎖はこの警戒のあとに続くべきです。 一般に、このメッセージは警告です。
no_renegotiation
Sent by the client in response to a hello request or by the
server in response to a client hello after initial handshaking.
Either of these would normally lead to renegotiation; when that
is not appropriate, the recipient should respond with this alert;
at that point, the original requester can decide whether to
proceed with the connection. One case where this would be
appropriate would be where a server has spawned a process to
satisfy a request; the process might receive security parameters
(key length, authentication, etc.) at startup and it might be
difficult to communicate changes to these parameters after that
point. This message is always a warning.
要求かクライアントに対応したサーバでこんにちは、初期のハンドシェイクの後にこんにちはに対応したクライアントによるいいえ_renegotiation Sent。 通常、これらのどちらかが再交渉に通じるでしょう。 それが適切でないときに、受取人はこの警戒で応じるべきです。 その時、オリジナルのリクエスタは、接続を続けるかどうか決めることができます。 これが適切である1つのケースがサーバが要望に応じるためにプロセスを量産したところでしょう。 プロセスは始動にセキュリティパラメタ(キー長、認証など)を受け取るかもしれません、そして、そのポイント後のこれらのパラメタへの変化を伝えるのは難しいかもしれません。 いつもこのメッセージは警告です。
For all errors where an alert level is not explicitly specified, the sending party may determine at its discretion whether this is a fatal error or not; if an alert with a level of warning is received, the
すべての誤りによって、注意深いレベルが明らかに指定されないところでは、送付パーティーは、これが致命的な誤りであるかどうかと自己判断で決心するかもしれません。 警告のレベルがある警戒が受け取られているなら
Dierks & Allen Standards Track [Page 28] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[28ページ]RFC2246TLSプロトコルバージョン1999年1月1日
receiving party may decide at its discretion whether to treat this as a fatal error or not. However, all messages which are transmitted with a level of fatal must be treated as fatal messages.
受領者は、致命的な誤りとしてこれを扱うかどうか自己判断で決めるかもしれません。 しかしながら、致命的のレベルで送られるすべてのメッセージを致命的なメッセージとして扱わなければなりません。
7.3. Handshake Protocol overview
7.3. 握手プロトコル概要
The cryptographic parameters of the session state are produced by the TLS Handshake Protocol, which operates on top of the TLS Record Layer. When a TLS client and server first start communicating, they agree on a protocol version, select cryptographic algorithms, optionally authenticate each other, and use public-key encryption techniques to generate shared secrets.
セッション状態の暗号のパラメタはTLS Handshakeプロトコルによって作り出されます。(それは、TLS Record Layerの上で作動します)。 TLSクライアントとサーバが最初に交信し始めるとき、彼らは、共有秘密キーを生成するのにプロトコルバージョンに同意して、暗号アルゴリズムを選択して、任意に互いを認証して、公開鍵暗号化のテクニックを使用します。
The TLS Handshake Protocol involves the following steps:
TLS Handshakeプロトコルは以下のステップにかかわります:
- Exchange hello messages to agree on algorithms, exchange random
values, and check for session resumption.
- 交換、こんにちは、アルゴリズムに同意して、無作為の値を交換して、セッション再開がないかどうかチェックするメッセージ。
- Exchange the necessary cryptographic parameters to allow the
client and server to agree on a premaster secret.
- クライアントとサーバが前マスター秘密に同意するのを必要な暗号のパラメタを交換して、許容してください。
- Exchange certificates and cryptographic information to allow the
client and server to authenticate themselves.
- クライアントとサーバが自分たちを認証するのを証明書と暗号の情報を交換して、許容してください。
- Generate a master secret from the premaster secret and exchanged
random values.
- 前マスター秘密と交換された無作為の値からのマスター秘密を生成してください。
- Provide security parameters to the record layer.
- セキュリティパラメタを記録的な層に供給してください。
- Allow the client and server to verify that their peer has
calculated the same security parameters and that the handshake
occurred without tampering by an attacker.
- 彼らの同輩が同じセキュリティパラメタについて計算して、握手が攻撃者でいじらないで起こったことをクライアントとサーバについて確かめさせてください。
Note that higher layers should not be overly reliant on TLS always negotiating the strongest possible connection between two peers: 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 support. The protocol has been designed to minimize this risk, but there are still attacks available: for example, an attacker could block access to the port a secure service runs on, or attempt to get the peers to negotiate an unauthenticated connection. The fundamental rule is that higher levels must be cognizant of what their security requirements are and never transmit information over a channel less secure than what they require. The TLS protocol is secure, in that any cipher suite offers its promised level of security: if you negotiate 3DES with a 1024 bit RSA key exchange with a host whose certificate you have verified, you can expect to be that secure.
より高い層がいつも2人の同輩の間の可能な限り強い接続を交渉するTLSにひどく頼るべきでないことに注意してください: 真ん中の攻撃者という男性が、最少への2実体ドロップダウンをそれらがサポートする安全なメソッドにするのを試みることができる多くの方法があります。 プロトコルはこの危険を最小にするように設計されていますが、利用可能な攻撃がまだあります: 例えば、攻撃者は、安全なサービスが走るポートへのアクセスを妨げるか、または同輩に非認証された接続を交渉させるのを試みることができました。 原理は、より高いレベルがそれらのセキュリティ要件が何であるかにおいて認識力があって、彼らが必要とすることほど安全でないチャンネルの上に情報を決して伝えてはいけないということです。 どんな暗号スイートも約束のレベルのセキュリティを提供するので、TLSプロトコルは安全です: あなたが証明書について確かめたホストと共に1024年のビットのRSAの主要な交換と3DESを交渉するなら、あなたは、そんなに安全であると予想できます。
Dierks & Allen Standards Track [Page 29] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[29ページ]RFC2246TLSプロトコルバージョン1999年1月1日
However, you should never send data over a link encrypted with 40 bit security unless you feel that data is worth no more than the effort required to break that encryption.
しかしながら、あなたはあなたが、データはその暗号化を壊すのに必要である取り組みだけの価値があると感じないなら40ビットのセキュリティで暗号化されたリンクの上にデータを決して送るべきではありません。
These goals are achieved by the handshake protocol, which can be summarized as follows: The client sends a client hello message to which the server must respond with a server hello message, or else a fatal error will occur and the connection will fail. The client hello and server hello are used to establish security enhancement capabilities between client and server. The client hello and server hello establish the following attributes: Protocol Version, Session ID, Cipher Suite, and Compression Method. Additionally, two random values are generated and exchanged: ClientHello.random and ServerHello.random.
これらの目標は握手プロトコルによって達成されます:(以下の通りプロトコルをまとめることができます)。 クライアントがクライアントを送る、こんにちは、サーバがサーバでこんにちは、致命的な誤りが望んでいるメッセージ、またはaを反応させなければならないメッセージは現れて、接続は失敗するでしょう。 クライアント、こんにちは、サーバ、こんにちは、サーバクライアントとクライアントの間のセキュリティ増進能力を証明するのに使用される、こんにちは、サーバ、こんにちは、以下の属性を確立してください: バージョン、Session ID、暗号スイート、および圧縮方法を議定書の中で述べてください。 さらに、2つの無作為の値を生成して、交換します: ClientHello.randomとServerHello.random。
The actual key exchange uses up to four messages: the server certificate, the server key exchange, the client certificate, and the client key exchange. New key exchange methods can be created by specifying a format for these messages and defining the use of the messages to allow the client and server to agree upon a shared secret. This secret should be quite long; currently defined key exchange methods exchange secrets which range from 48 to 128 bytes in length.
実際のキー交換は最大4つのメッセージを使用します: サーバ証明書、サーバの主要な交換、クライアント証明書、およびクライアントの主要な交換。 これらのメッセージに形式を指定して、クライアントとサーバが共有秘密キーに同意するのを許容するメッセージの使用を定義することによって、新しい主要な交換メソッドを作成できます。 この秘密はかなり長いはずです。 現在定義された主要な交換メソッドは48〜128バイト長さのねらいを定める秘密を交換します。
Following the hello messages, the server will send its certificate, if it is to be authenticated. Additionally, a server key exchange message may be sent, if it is required (e.g. if their server has no certificate, or if its certificate is for signing only). If the server is authenticated, it may request a certificate from the client, if that is appropriate to the cipher suite selected. Now the server will send the server hello done message, indicating that the hello-message phase of the handshake is complete. The server will then wait for a client response. If the server has sent a certificate request message, the client must send the certificate message. The client key exchange message is now sent, and the content of that message will depend on the public key algorithm selected between the client hello and the server hello. If the client has sent a certificate with signing ability, a digitally-signed certificate verify message is sent to explicitly verify the certificate.
次のこんにちは、メッセージであり、それが認証されるつもりであると、サーバは証明書を送るでしょう。 さらに、サーバの主要な交換メッセージを送るかもしれません、それが必要であるなら(例えば、それらのサーバで証明書が全くないか、または証明書が署名だけのためのものであるなら)。 サーバが認証されるなら、クライアントから証明書を要求するかもしれません、それが選択された暗号スイートに適切であるなら。 今、サーバがサーバを送る、こんにちは、それを示して、メッセージをする、こんにちは、-通信してください、握手のフェーズは完全です。 そして、サーバはクライアント応答を待っています。 サーバが証明書要求メッセージを送ったなら、クライアントは証明書メッセージを送らなければなりません。 現在、クライアントの主要な交換メッセージを送って、そのメッセージの内容がクライアントの間で選択された公開鍵アルゴリズムによる、こんにちは、サーバ、こんにちは。 クライアントが発信したなら、署名能力がある証明書、デジタルに署名している証明書はメッセージについて確かめます。明らかに、証明書について確かめさせます。
At this point, a change cipher spec message is sent by the client, and the client copies the pending Cipher Spec into the current Cipher Spec. The client then immediately sends the finished message under the new algorithms, keys, and secrets. In response, the server will send its own change cipher spec message, transfer the pending to the current Cipher Spec, and send its finished message under the new
ここに、変化暗号仕様メッセージはクライアントによって送られます、そして、クライアントは現在のCipher Specに未定のCipher Specをコピーします。 そして、クライアントはすぐに、新しいアルゴリズム、キー、および秘密の下に終わっているメッセージを送ります。 応答では、サーバは、それ自身の変化暗号仕様メッセージを送って、現在のCipher Specに未定を移して、終わっているメッセージを新しさの下に送るでしょう。
Dierks & Allen Standards Track [Page 30] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[30ページ]RFC2246TLSプロトコルバージョン1999年1月1日
Cipher Spec. At this point, the handshake is complete and the client and server may begin to exchange application layer data. (See flow chart below.)
仕様を解いてください。 ここに、握手は完了しています、そして、クライアントとサーバは応用層データを交換し始めるかもしれません。 (以下のフローチャートを見てください。)
Client Server
クライアントサーバ
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
ClientHello-------->ServerHello証明書*ServerKeyExchange*CertificateRequest*<。-------- ServerHelloDone証明書*ClientKeyExchange CertificateVerify*[ChangeCipherSpec]は終わりました。-------->[ChangeCipherSpec]<。-------- 完成アプリケーションデータ<。------->アプリケーションデータ
Fig. 1 - Message flow for a full handshake
図1--完全な握手のためのメッセージ流動
* Indicates optional or situation-dependent messages that are not always sent.
* いつも送られるというわけではない任意の、または、状況依存するメッセージを示します。
Note: To help avoid pipeline stalls, ChangeCipherSpec is an
independent TLS Protocol content type, and is not actually a TLS
handshake message.
以下に注意してください。 パイプライン売店、ChangeCipherSpecを避けるのを助けるのは、独立しているTLSプロトコルcontent typeであり、実際にTLS握手メッセージではありません。
When the client and server decide to resume a previous session or duplicate an existing session (instead of negotiating new security parameters) the message flow is as follows:
クライアントとサーバが、前のセッションを再開するか、または既存のセッションをコピーする(新しいセキュリティパラメタを交渉することの代わりに)と決めるとき、メッセージ流動は以下の通りです:
The client sends a ClientHello using the Session ID of the session to be resumed. The server then checks its session cache for a match. If a match is found, and the server is willing to re-establish the connection under the specified session state, it will send a ServerHello with the same Session ID value. At this point, both client and server must send change cipher spec messages and proceed directly to finished messages. Once the re-establishment is complete, the client and server may begin to exchange application layer data. (See flow chart below.) If a Session ID match is not found, the server generates a new session ID and the TLS client and server perform a full handshake.
クライアントは、再開されるのにセッションのSession IDを使用することでClientHelloを送ります。 そして、サーバはマッチがないかどうかセッションキャッシュをチェックします。 マッチが見つけられて、サーバが、指定されたセッション状態の下で接続を復職させても構わないと思っていると、それは同じSession ID価値があるServerHelloを送るでしょう。 ここに、クライアントとサーバの両方が、暗号仕様メッセージを変化に送って、直接終わっているメッセージに続かなければなりません。 再建がいったん完全になると、クライアントとサーバは応用層データを交換し始めるかもしれません。 (以下のフローチャートを見てください。) Session IDマッチが見つけられないなら、サーバは新しいセッションIDを生成します、そして、TLSクライアントとサーバは完全な握手を実行します。
Dierks & Allen Standards Track [Page 31] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[31ページ]RFC2246TLSプロトコルバージョン1999年1月1日
Client Server
クライアントサーバ
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
ClientHello-------->ServerHello[ChangeCipherSpec]<。-------- 終わっている[ChangeCipherSpec]は終わりました。-------->アプリケーションデータ<。------->アプリケーションデータ
Fig. 2 - Message flow for an abbreviated handshake
図2--簡略化された握手のためのメッセージ流動
The contents and significance of each message will be presented in detail in the following sections.
それぞれのメッセージのコンテンツと意味は以下のセクションに詳細に提示されるでしょう。
7.4. Handshake protocol
7.4. 握手プロトコル
The TLS Handshake Protocol is one of the defined higher level clients of the TLS Record Protocol. This protocol is used to negotiate the secure attributes of a session. Handshake messages are supplied to the TLS Record Layer, where they are encapsulated within one or more TLSPlaintext structures, which are processed and transmitted as specified by the current active session state.
TLS HandshakeプロトコルはTLS Recordプロトコルの定義されたより高い平らなクライアントのひとりです。 このプロトコルは、セッションの安全な属性を交渉するのに使用されます。 握手メッセージをTLS Record Layerに提供します。そこでは、それらが1つ以上のTLSPlaintext構造の中でカプセル化されます。現在の活動的なセッション州によって指定されるように、構造は、処理されて、伝えられます。
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255)
} HandshakeType;
enum、こんにちは、_要求(0)、クライアント_、こんにちは、(1)、サーバ_、こんにちは、(2) 証明書(11)、サーバの_の主要な_交換(12)が_要求(13)、サーバ_を証明する、こんにちは、(14)、証明書_が行われた_が(15)、クライアントの_の主要な_交換(16)、終わっている(20)、(255)について確かめる、HandshakeType。
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
} Handshake;
struct、HandshakeType msg_タイプ; /*握手タイプ*/uint24の長さ; メッセージ*/選んだ(HandshakeType)の/*バイト、_: こんにちは、_要求: こんにちは、ケースHelloRequest; _: こんにちは、ケースクライアントClientHello; ケースサーバServerHello; ケース証明書: 証明書; サーバの_の主要な_交換: ServerKeyExchangeをケースに入れます; ケース証明書_要求: CertificateRequest; _行われた_: こんにちは、ケースサーバServerHelloDone; ケース証明書_が、: CertificateVerify; クライアントの_の主要な_交換: ケースは終わりました: 終わったというClientKeyExchangeをケースに入れることを確かめる、ボディー;、握手。
Dierks & Allen Standards Track [Page 32] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[32ページ]RFC2246TLSプロトコルバージョン1999年1月1日
The handshake protocol messages are presented below in the order they must be sent; sending handshake messages in an unexpected order results in a fatal error. Unneeded handshake messages can be omitted, however. Note one exception to the ordering: the Certificate message is used twice in the handshake (from server to client, then from client to server), but described only in its first position. The one message which is not bound by these ordering rules in the Hello Request message, which can be sent at any time, but which should be ignored by the client if it arrives in the middle of a handshake.
握手プロトコルメッセージはそれらを送らなければならないオーダーに以下に提示されます。 予期していなかったオーダーにおける握手メッセージを送ると、致命的な誤りはもたらされます。 しかしながら、不要な握手メッセージを省略できます。注文への1つの例外に注意してください: Certificateメッセージは、握手(サーバからクライアントまでそして、クライアントからサーバまでの)に二度使用されますが、第1ポジションだけで説明されます。 いつでも、送ることができますが、握手の途中に到着するならクライアントによって無視されるべきであるHello Requestメッセージの規則を注文するこれらによって縛られない1つのメッセージ。
7.4.1. Hello messages
7.4.1. こんにちは、メッセージ
The hello phase messages are used to exchange security enhancement capabilities between the client and server. When a new session begins, the Record Layer's connection state encryption, hash, and compression algorithms are initialized to null. The current connection state is used for renegotiation messages.
フェーズメッセージは、クライアントとサーバの間でセキュリティ増進能力を交換するのに使用されます。こんにちは、新しいセッションが始まるとき、Record Layerの接続州の暗号化、ハッシュ、および圧縮アルゴリズムはヌルに初期化されます。 現在の接続状態は再交渉メッセージに使用されます。
7.4.1.1. Hello request
7.4.1.1. こんにちは、要求
When this message will be sent:
The hello request message may be sent by the server at any time.
このメッセージを送るとき: こんにちは、サーバはいつでも、要求メッセージを送るかもしれません。
Meaning of this message:
Hello request is a simple notification that the client should
begin the negotiation process anew by sending a client hello
message when convenient. This message will be ignored by the
client if the client is currently negotiating a session. This
message may be ignored by the client if it does not wish to
renegotiate a session, or the client may, if it wishes, respond
with a no_renegotiation alert. Since handshake messages are
intended to have transmission precedence over application data,
it is expected that the negotiation will begin before no more
than a few records are received from the client. If the server
sends a hello request but does not receive a client hello in
response, it may close the connection with a fatal alert.
このメッセージの意味: こんにちは、要求がクライアントがクライアントを送ることによって新たに交渉プロセスを開始するべきであるという簡単な通知である、こんにちは、便利であるときには、通信してください。 クライアントが現在セッションを交渉していると、このメッセージはクライアントによって無視されるでしょう。 セッションを再交渉したがっていないか、または願うならクライアントがいいえ_再交渉警戒でこたえるかもしれないなら、このメッセージはクライアントによって無視されるかもしれません。 握手メッセージにはアプリケーションデータの上のトランスミッション先行があることを意図するので、クライアントからいくつかの記録だけを受け取る前に交渉が始まると予想されます。 応答でこんにちは、サーバが要求をこんにちはに送りますが、クライアントを受けないなら、それは致命的な警戒で接続を終えるかもしれません。
After sending a hello request, servers should not repeat the request until the subsequent handshake negotiation is complete.
要求、サーバをこんにちはに送った後に、その後の握手交渉が完全になるまでの要求は繰り返されているべきではありません。
Structure of this message:
struct { } HelloRequest;
このメッセージの構造: struct、HelloRequest。
Note: This message should never be included in the message hashes which
are maintained throughout the handshake and used in the finished
messages and the certificate verify message.
以下に注意してください。 このメッセージは握手の間中維持されて、終わっているメッセージと証明書で使用されるハッシュがメッセージについて確かめるというメッセージに決して含まれるべきではありません。
Dierks & Allen Standards Track [Page 33] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[33ページ]RFC2246TLSプロトコルバージョン1999年1月1日
7.4.1.2. Client hello
7.4.1.2. クライアント、こんにちは。
When this message will be sent:
When a client first connects to a server it is required to send
the client hello as its first message. The client can also send a
client hello in response to a hello request or on its own
initiative in order to renegotiate the security parameters in an
existing connection.
このメッセージを送るとき: クライアントが最初にいつそれをサーバに接続するかが、クライアントを送るのに必要です。最初のメッセージとしてこんにちは。 また、クライアントがクライアントを送ることができる、こんにちは、要求かそれ自身のイニシアチブのこんにちはに対応して既存の接続におけるセキュリティパラメタを再交渉してください。
Structure of this message:
The client hello message includes a random structure, which is
used later in the protocol.
このメッセージの構造: こんにちは、メッセージインクルードa。クライアント、ランダム構造。(そのランダム構造は後でプロトコルに使用されます)。
struct {
uint32 gmt_unix_time;
opaque random_bytes[28];
} Random;
structにuint32 gmt_unix_時間; 不透明な無作為の_バイト[28];無作為。
gmt_unix_time
The current time and date in standard UNIX 32-bit format (seconds
since the midnight starting Jan 1, 1970, GMT) according to the
sender's internal clock. Clocks are not required to be set
correctly by the basic TLS Protocol; higher level or application
protocols may define additional requirements.
送付者の内部クロックに応じて、gmt_unix_は標準のUNIX32ビットの形式(グリニッジ標準時の1970年1月1日からの真夜中以来の秒)で現在の日時を調節します。 時計は基本的なTLSプロトコルで正しく設定されるのに必要ではありません。 より高いレベルかアプリケーション・プロトコルが追加要件を定義するかもしれません。
random_bytes
28 bytes generated by a secure random number generator.
安全な乱数発生器によって生成された28バイトの無作為の_バイト。
The client hello message includes a variable length session identifier. If not empty, the value identifies a session between the same client and server whose security parameters the client wishes to reuse. The session identifier may be from an earlier connection, this connection, or another currently active connection. The second option is useful if the client only wishes to update the random structures and derived values of a connection, while the third option makes it possible to establish several independent secure connections without repeating the full handshake protocol. These independent connections may occur sequentially or simultaneously; a SessionID becomes valid when the handshake negotiating it completes with the exchange of Finished messages and persists until removed due to aging or because a fatal error was encountered on a connection associated with the session. The actual contents of the SessionID are defined by the server.
こんにちは、メッセージインクルードa。クライアント、可変長セッション識別子。 空でないなら、値はクライアントがセキュリティパラメタを再利用したがっている同じクライアントとサーバとのセッションを特定します。 セッション識別子は以前の接続、この接続、または別の現在活発な接続から来ているかもしれません。 クライアントが接続のランダム構造と派生している値をアップデートするだけでありたいなら、2番目のオプションは役に立ちます、完全な握手プロトコルを繰り返さないでいくつかの独立している安全な接続を確立するのが3番目のオプションで可能になりますが。 これらの独立している接続は連続するか同時に、起こるかもしれません。 SessionIDはそれを交渉する握手がFinishedの交換でメッセージを完成すると有効になって、年をとったためか致命的な誤りがセッションに関連している接続のときに遭遇したので取り除くまで固執しています。 SessionIDの実際の内容はサーバによって定義されます。
opaque SessionID<0..32>;
SessionID<0について不透明にしてください。32>。
Dierks & Allen Standards Track [Page 34] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[34ページ]RFC2246TLSプロトコルバージョン1999年1月1日
Warning:
Because the SessionID is transmitted without encryption or
immediate MAC protection, servers must not place confidential
information in session identifiers or let the contents of fake
session identifiers cause any breach of security. (Note that the
content of the handshake as a whole, including the SessionID, is
protected by the Finished messages exchanged at the end of the
handshake.)
警告: SessionIDが暗号化も即座のMAC保護なしで伝えられるので、サーバで、セッション識別子の秘密情報を置いてはいけないか、にせのセッション識別子のコンテンツはセキュリティのどんな不履行も引き起こしてはいけません。 (全体でSessionIDを含む握手の内容が握手の終わりと交換されたFinishedメッセージによって保護されることに注意してください。)
The CipherSuite list, passed from the client to the server in the client hello message, contains the combinations of cryptographic algorithms supported by the client in order of the client's preference (favorite choice first). Each CipherSuite defines a key exchange algorithm, a bulk encryption algorithm (including secret key length) and a MAC algorithm. The server will select a cipher suite or, if no acceptable choices are presented, return a handshake failure alert and close the connection.
クライアントでクライアントからサーバまで渡されたCipherSuiteリスト、こんにちは、通信して、クライアントの好み(特選している1のお気に入りの番目)の順にクライアントによってサポートされた暗号アルゴリズムの組み合わせを含んでいます。 各CipherSuiteは主要な交換アルゴリズム、大量の暗号化アルゴリズム(秘密鍵の長さを含んでいる)、およびMACアルゴリズムを定義します。 どんな許容できる選択も提示されないと、サーバは、暗号スイートを選択するか、握手故障警報を返して、または接続を終えるでしょう。
uint8 CipherSuite[2]; /* Cryptographic suite selector */
uint8 CipherSuite[2]。 /*暗号のスイートセレクタ*/
The client hello includes a list of compression algorithms supported by the client, ordered according to the client's preference.
こんにちは、インクルードaが記載する圧縮アルゴリズムのクライアントは自分の好みに従って注文されたクライアントをサポートしました。
enum { null(0), (255) } CompressionMethod;
ヌル(0)、(255)をenumする、CompressionMethod。
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
struct ProtocolVersionクライアント_バージョン; _無作為の無作為; SessionIDセッション_イド;のCipherSuite暗号スイート<2..2^16-1>; _CompressionMethod圧縮メソッド<1..2^8-1>;ClientHello。
client_version
The version of the TLS protocol by which the client wishes to
communicate during this session. This should be the latest
(highest valued) version supported by the client. For this
version of the specification, the version will be 3.1 (See
Appendix E for details about backward compatibility).
TLSのバージョンが議定書を作るクライアントが今会期中に伝えたがっているクライアント_バージョン。 これが最新のものであるべきである、(高さ、評価、)、クライアントによってサポートされたバージョン。 仕様のこのバージョンのために、バージョンは3.1(後方の互換性に関する詳細に関してAppendix Eを見る)でしょう。
random
A client-generated random structure.
無作為のAはランダム構造をクライアントと同じくらい生成しました。
session_id
The ID of a session the client wishes to use for this connection.
This field should be empty if no session_id is available or the
client wishes to generate new security parameters.
クライアントがこの接続に使用したがっているセッションのセッション_イドID。 どんなセッション_イドも利用可能でないか、またはクライアントが新しいセキュリティパラメタを生成したいなら、この分野は人影がないはずです。
Dierks & Allen Standards Track [Page 35] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[35ページ]RFC2246TLSプロトコルバージョン1999年1月1日
cipher_suites
This is a list of the cryptographic options supported by the
client, with the client's first preference first. If the
session_id field is not empty (implying a session resumption
request) this vector must include at least the cipher_suite from
that session. Values are defined in Appendix A.5.
暗号_スイートThisは最初にクライアントの最優先でクライアントによってサポートされた暗号のオプションのリストです。 セッション_イド分野が人影がなくないなら(セッション再開要求を含意して)、このベクトルはそのセッションからの少なくとも暗号_スイートを含まなければなりません。 値はAppendix A.5で定義されます。
compression_methods
This is a list of the compression methods supported by the
client, sorted by client preference. If the session_id field is
not empty (implying a session resumption request) it must include
the compression_method from that session. This vector must
contain, and all implementations must support,
CompressionMethod.null. Thus, a client and server will always be
able to agree on a compression method.
圧縮_メソッドThisはクライアント好みによって割り当てられたクライアントによってサポートされた圧縮方法のリストです。 セッション_イド分野が人影がなくないなら(セッション再開要求を含意して)、それはそのセッションからの圧縮_メソッドを含まなければなりません。 このベクトルは含まなければなりません、そして、すべての実装はサポート、CompressionMethod.nullが含まなければなりません。 したがって、クライアントとサーバはいつも圧縮方法に同意できるでしょう。
After sending the client hello message, the client waits for a server hello message. Any other handshake message returned by the server except for a hello request is treated as a fatal error.
クライアントを送った後にこんにちは、メッセージ、クライアントがサーバを待つ、こんにちは、メッセージ。 こんにちは以外のサーバで返して、要求が致命的な誤りとして扱われるといういかなる他の握手メッセージ。
Forward compatibility note:
In the interests of forward compatibility, it is permitted for a
client hello message to include extra data after the compression
methods. This data must be included in the handshake hashes, but
must otherwise be ignored. This is the only handshake message for
which this is legal; for all other messages, the amount of data
in the message must match the description of the message
precisely.
互換性注意を転送してください: 下位互換のためにそれがクライアントのために受入れられる、こんにちは、圧縮方法の後に付加的なデータを含むメッセージ。 このデータを握手ハッシュに含まなければなりませんが、別の方法で無視しなければなりません。 これが法的である唯一の握手メッセージです。 他のすべてのメッセージに関しては、メッセージのデータ量は正確にメッセージの記述に合わなければなりません。
7.4.1.3. Server hello
7.4.1.3. サーバ、こんにちは。
When this message will be sent:
The server will send this message in response to a client hello
message when it was able to find an acceptable set of algorithms.
If it cannot find such a match, it will respond with a handshake
failure alert.
このメッセージを送るとき: それであるときに、メッセージは許容できるセットのアルゴリズムを見つけることができました。サーバがクライアントに対応してこのメッセージを送る、こんにちは、そのようなマッチを見つけることができないと、それは握手故障警報で応じるでしょう。
Structure of this message:
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
} ServerHello;
このメッセージの構造: struct ProtocolVersionサーバ_バージョン; 無作為の無作為; SessionIDセッション_イド; CipherSuite暗号_スイート;のCompressionMethod圧縮_メソッド;ServerHello。
Dierks & Allen Standards Track [Page 36] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[36ページ]RFC2246TLSプロトコルバージョン1999年1月1日
server_version
This field will contain the lower of that suggested by the client
in the client hello and the highest supported by the server. For
this version of the specification, the version is 3.1 (See
Appendix E for details about backward compatibility).
サーバによってサポートされて、This分野が、より低くそれを含むサーバ_バージョンは、クライアントというクライアントでこんにちはを最も高く示しました。仕様のこのバージョンのために、バージョンは3.1(後方の互換性に関する詳細に関してAppendix Eを見る)です。
random
This structure is generated by the server and must be different
from (and independent of) ClientHello.random.
無作為のThis構造がサーバによって生成されて、異なるのと(独立する)でなければならない、ClientHello.random。
session_id
This is the identity of the session corresponding to this
connection. If the ClientHello.session_id was non-empty, the
server will look in its session cache for a match. If a match is
found and the server is willing to establish the new connection
using the specified session state, the server will respond with
the same value as was supplied by the client. This indicates a
resumed session and dictates that the parties must proceed
directly to the finished messages. Otherwise this field will
contain a different value identifying the new session. The server
may return an empty session_id to indicate that the session will
not be cached and therefore cannot be resumed. If a session is
resumed, it must be resumed using the same cipher suite it was
originally negotiated with.
セッション_イドThisはこの接続において、対応するセッションのアイデンティティです。 ClientHello.session_イドが非空であったなら、サーバはマッチのためにセッションキャッシュの中を見るでしょう。 マッチが見つけられて、サーバが、指定されたセッション状態を使用することで新しい接続を確立しても構わないと思っていると、サーバはクライアントによって供給されたのと同じ値で反応するでしょう。 これは、再開しているセッションを示して、パーティーが直接終わっているメッセージに続かなければならないと決めます。 さもなければ、この分野は新しいセッションを特定する異価を含むでしょう。 サーバは、セッションをキャッシュしないで、したがって、再開できないのを示すために空のセッション_イドを返すかもしれません。 セッションが再開されるなら、それが元々交渉された同じ暗号スイートを使用することでそれを再開しなければなりません。
cipher_suite
The single cipher suite selected by the server from the list in
ClientHello.cipher_suites. For resumed sessions this field is the
value from the state of the session being resumed.
_単一の暗号スイートがサーバでClientHello.cipher_スイートのリストから選択したスイートを解いてください。 再開しているセッションのために、この分野は再開されるセッションの状態からの値です。
compression_method
The single compression algorithm selected by the server from the
list in ClientHello.compression_methods. For resumed sessions
this field is the value from the resumed session state.
ただ一つの圧縮アルゴリズムがサーバでClientHello.compression_メソッドによるリストから選択した圧縮_メソッド。 再開しているセッションのために、この分野は再開しているセッション状態からの値です。
7.4.2. Server certificate
7.4.2. サーバ証明書
When this message will be sent:
The server must send a certificate whenever the agreed-upon key
exchange method is not an anonymous one. This message will always
immediately follow the server hello message.
このメッセージを送るとき: サーバは同意している主要な交換メソッドが匿名のものでないときはいつも、証明書を送らなければなりません。 このメッセージがすぐにいつもサーバに従う、こんにちは、メッセージ。
Meaning of this message:
The certificate type must be appropriate for the selected cipher
suite's key exchange algorithm, and is generally an X.509v3
certificate. It must contain a key which matches the key exchange
method, as follows. Unless otherwise specified, the signing
このメッセージの意味: 証明書タイプは、選択された暗号スイートの主要な交換アルゴリズムに適切でなければならなく、一般に、X.509v3証明書です。 それは以下の主要な交換メソッドに合っているキーを含まなければなりません。 別の方法で指定されない場合署名
Dierks & Allen Standards Track [Page 37] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[37ページ]RFC2246TLSプロトコルバージョン1999年1月1日
algorithm for the certificate must be the same as the algorithm
for the certificate key. Unless otherwise specified, the public
key may be of any length.
証明書のためのアルゴリズムは証明書キーのためのアルゴリズムと同じであるに違いありません。 別の方法で指定されない場合、公開鍵はどんな長さのものであるかもしれません。
Key Exchange Algorithm Certificate Key Type
主要な交換アルゴリズム証明書主要なタイプ
RSA RSA public key; the certificate must
allow the key to be used for encryption.
RSA RSA公開鍵。 証明書は、キーが暗号化に使用されるのを許容しなければなりません。
RSA_EXPORT RSA public key of length greater than
512 bits which can be used for signing,
or a key of 512 bits or shorter which
can be used for either encryption or
signing.
署名に使用できる512ビット以上の長さのRSA_EXPORT RSA公開鍵、またはどちらの暗号化にも使用されるか、または署名することができる512ビット以下のキー。
DHE_DSS DSS public key.
DHE_DSS DSS公開鍵。
DHE_DSS_EXPORT DSS public key.
DHE_DSS_EXPORT DSS公開鍵。
DHE_RSA RSA public key which can be used for
signing.
署名に使用できるDHE_RSA RSA公開鍵。
DHE_RSA_EXPORT RSA public key which can be used for
signing.
署名に使用できるDHE_RSA_EXPORT RSA公開鍵。
DH_DSS Diffie-Hellman key. The algorithm used
to sign the certificate should be DSS.
DH_DSSディフィー-ヘルマンキー。 証明書に署名するのに使用されるアルゴリズムはDSSであるべきです。
DH_RSA Diffie-Hellman key. The algorithm used
to sign the certificate should be RSA.
DH_RSAディフィー-ヘルマンキー。 証明書に署名するのに使用されるアルゴリズムはRSAであるべきです。
All certificate profiles, key and cryptographic formats are defined 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 eligible for signing, as described above, and the keyEncipherment bit must be present to allow encryption, as described above. The keyAgreement bit must be set on Diffie-Hellman certificates.
すべてがプロフィールを証明して、主要で暗号の書式はIETF PKIXワーキンググループ[PKIX]によって定義されます。 主要な用法拡大が存在しているとき、上で説明されるように署名するのに、キーが適任であるようにdigitalSignatureビットを設定しなければなりません、そして、keyEnciphermentビットは暗号化を許容するために存在していなければなりません、上で説明されるように。 ディフィー-ヘルマン証明書の上にkeyAgreementビットを設定しなければなりません。
As CipherSuites which specify new key exchange methods are specified for the TLS Protocol, they will imply certificate format and the required encoded keying information.
新しい主要な交換メソッドを指定するCipherSuitesがTLSプロトコルに指定されるとき、彼らは情報を合わせながらコード化された証明書形式と必要を含意するでしょう。
Structure of this message:
opaque ASN.1Cert<1..2^24-1>;
このメッセージの構造: ASN.1Cert<1について不透明にしてください。2^24-1>。
struct {
ASN.1Cert certificate_list<0..2^24-1>;
} Certificate;
struct、ASN.1Cert証明書_リスト<0..2^24-1>; 証明書。
Dierks & Allen Standards Track [Page 38] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[38ページ]RFC2246TLSプロトコルバージョン1999年1月1日
certificate_list
This is a sequence (chain) of X.509v3 certificates. The sender's
certificate must come first in the list. Each following
certificate must directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate which specifies the
root certificate authority may optionally be omitted from the
chain, under the assumption that the remote end must already
possess it in order to validate it in any case.
証明書_リストThisはX.509v3証明書の系列(チェーン)です。 送付者の証明書はリストで一番にならなければなりません。 それぞれの次の証明書は直接それに先行するものを公認しなければなりません。 証明書合法化が、ルートキーが独自に分配されるのを必要とするので、ルート証明書権威を指定する自己署名入りの証書はチェーンから任意に省略されるかもしれません、リモートエンドがどのような場合でも、それを有効にするために既にそれを所有しなければならないという仮定で。
The same message type and structure will be used for the client's response to a certificate request message. Note that a client may send no certificates if it does not have an appropriate certificate to send in response to the server's authentication request.
同じメッセージタイプと構造は証明書要求メッセージへのクライアントの応答に使用されるでしょう。 それにサーバの認証要求に対応して送るのが適切である証明書がないならクライアントが証明書を全く送らないかもしれないことに注意してください。
Note: PKCS #7 [PKCS7] is not used as the format for the certificate
vector because PKCS #6 [PKCS6] extended certificates are not
used. Also PKCS #7 defines a SET rather than a SEQUENCE, making
the task of parsing the list more difficult.
以下に注意してください。 PKCS#6通[PKCS6]の拡張証明書が使用されていないので、PKCS#7[PKCS7]は証明書ベクトルに形式として使用されません。 また、リストを分析するタスクをより難しくして、PKCS#7はSEQUENCEよりむしろSETを定義します。
7.4.3. Server key exchange message
7.4.3. サーバの主要な交換メッセージ
When this message will be sent:
This message will be sent immediately after the server
certificate message (or the server hello message, if this is an
anonymous negotiation).
このメッセージを送るとき: サーバ証明書メッセージ直後このメッセージを送る、(サーバ、こんにちは、メッセージこれが匿名の交渉であるなら
The server key exchange message is sent by the server only when
the server certificate message (if sent) does not contain enough
data to allow the client to exchange a premaster secret. This is
true for the following key exchange methods:
サーバ証明書メッセージ(送るなら)がクライアントが前マスター秘密を交換するのを許容できるくらいのデータを含まないときだけ、サーバはサーバの主要な交換メッセージを送ります。 以下の主要な交換メソッドに、これは本当です:
RSA_EXPORT (if the public key in the server certificate is
longer than 512 bits)
DHE_DSS
DHE_DSS_EXPORT
DHE_RSA
DHE_RSA_EXPORT
DH_anon
_RSA_EXPORT(サーバ証明書の公開鍵が512ビットより長いなら)DHE_DSS DHE_DSS EXPORT DHE_RSA DHE_RSA_EXPORT DH_、やがて。
It is not legal to send the server key exchange message for the
following key exchange methods:
以下の主要な交換メソッドのためにサーバの主要な交換メッセージを送るのは法的ではありません:
RSA
RSA_EXPORT (when the public key in the server certificate is
less than or equal to 512 bits in length)
DH_DSS
DH_RSA
RSA RSA_EXPORT(サーバ証明書の公開鍵は長さが512ビット以下であるときに)DH_DSS DH_RSA
Dierks & Allen Standards Track [Page 39] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[39ページ]RFC2246TLSプロトコルバージョン1999年1月1日
Meaning of this message:
This message conveys cryptographic information to allow the
client to communicate the premaster secret: either an RSA public
key to encrypt the premaster secret with, or a Diffie-Hellman
public key with which the client can complete a key exchange
(with the result being the premaster secret.)
このメッセージの意味: このメッセージはクライアントが前マスター秘密を伝えるのを許容するために暗号の情報を伝えます: 前マスター秘密を暗号化するRSA公開鍵、またはクライアントが主要な交換を終了できるディフィー-ヘルマン公開鍵(前マスター秘密である結果の。)
As additional CipherSuites are defined for TLS which include new key exchange algorithms, the server key exchange message will be sent if and only if the certificate type associated with the key exchange algorithm does not provide enough information for the client to exchange a premaster secret.
そして、新しい主要な交換アルゴリズムを含んでいるTLSのために追加CipherSuitesを定義するときサーバの主要な交換メッセージを送る、主要な交換アルゴリズムに関連づけられた証明書タイプがクライアントが前マスター秘密を交換できるくらいの情報を提供しない場合にだけ。
Note: According to current US export law, RSA moduli larger than 512
bits may not be used for key exchange in software exported from
the US. With this message, the larger RSA keys encoded in
certificates may be used to sign temporary shorter RSA keys for
the RSA_EXPORT key exchange method.
以下に注意してください。 現在の米国輸出法によると、512ビットがソフトウェアにおける主要な交換に使用されないかもしれないより大きいRSA係数は米国からエクスポートしました。 このメッセージと共に、証明書でコード化されたより大きいRSAキーは、RSA_EXPORTの主要な交換メソッドのために一時的なより短いRSAキーに署名するのに使用されるかもしれません。
Structure of this message:
enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
このメッセージの構造: enumのrsaであって、diffie_hellmanなKeyExchangeAlgorithm。
struct {
opaque rsa_modulus<1..2^16-1>;
opaque rsa_exponent<1..2^16-1>;
} ServerRSAParams;
struct不透明なrsa_係数<1..2^16-1>; 不透明なrsa_解説者<1..2^16-1>;ServerRSAParams。
rsa_modulus
The modulus of the server's temporary RSA key.
サーバの一時的なRSAの係数が合わせるrsa_係数。
rsa_exponent
The public exponent of the server's temporary RSA key.
サーバの一時的なRSAの公共の解説者が合わせるrsa_解説者。
struct {
opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>;
} ServerDHParams; /* Ephemeral DH parameters */
struct不透明なdh_p<1..2^16-1>; 不透明なdh_g<1..2^16-1>; dh_Ys<1..2^16-1>について不透明にする;ServerDHParams。 /*はかないDHパラメタ*/
dh_p
The prime modulus used for the Diffie-Hellman operation.
主要な係数がディフィー-ヘルマンの操作に使用したdh_p。
dh_g
The generator used for the Diffie-Hellman operation.
ジェネレータがディフィー-ヘルマンの操作に使用したdh_g。
dh_Ys
The server's Diffie-Hellman public value (g^X mod p).
サーバのディフィー-ヘルマン公衆が評価するdh_Ys(g^Xモッズp)。
Dierks & Allen Standards Track [Page 40] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[40ページ]RFC2246TLSプロトコルバージョン1999年1月1日
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params;
};
} ServerKeyExchange;
struct、ケースdiffie_hellman: 署名は、_がparamsであると署名しました; rsa: ServerRSAParams paramsをケースに入れてください; 署名が、_がparamsであると署名したというServerDHParams paramsを選択してください(KeyExchangeAlgorithm);、ServerKeyExchange。
params
The server's key exchange parameters.
サーバの主要な交換パラメタをparamsします。
signed_params
For non-anonymous key exchanges, a hash of the corresponding
params value, with the signature appropriate to that hash
applied.
署名している_params For非匿名の主要な交換、そのハッシュに適切な署名がある対応するparams価値のハッシュは適用されました。
md5_hash
MD5(ClientHello.random + ServerHello.random + ServerParams);
md5_ハッシュMD5(ClientHello.random+ServerHello.random+ServerParams)。
sha_hash
SHA(ClientHello.random + ServerHello.random + ServerParams);
sha_ハッシュSHA(ClientHello.random+ServerHello.random+ServerParams)。
enum { anonymous, rsa, dsa } SignatureAlgorithm;
enumの匿名の、そして、rsaであって、dsaなSignatureAlgorithm。
select (SignatureAlgorithm)
{ case anonymous: struct { };
case rsa:
digitally-signed struct {
opaque md5_hash[16];
opaque sha_hash[20];
};
case dsa:
digitally-signed struct {
opaque sha_hash[20];
};
} Signature;
(SignatureAlgorithm)を選択してください、ケース匿名:、struct、;、rsaをケースに入れてください: デジタルに署名しているstruct不透明なmd5_ハッシュ[16]; 不透明なsha_ハッシュ[20];、dsa: デジタルに署名しているstructをケースに入れてください 不透明なsha_ハッシュ[20];、;、署名。
7.4.4. Certificate request
7.4.4. 証明書要求
When this message will be sent:
A non-anonymous server can optionally request a certificate from
the client, if appropriate for the selected cipher suite. This
message, if sent, will immediately follow the Server Key Exchange
message (if it is sent; otherwise, the Server Certificate
message).
このメッセージを送るとき: 選択された暗号スイートに適切であるなら、非匿名のサーバはクライアントから証明書を任意に要求できます。 送るとこのメッセージがすぐにServer Key Exchangeメッセージに従う、(それを送ります; さもなければ、Server Certificateが通信する、)
Dierks & Allen Standards Track [Page 41] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[41ページ]RFC2246TLSプロトコルバージョン1999年1月1日
Structure of this message:
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
(255)
} ClientCertificateType;
このメッセージの構造: rsa_サイン(1)、dss_サイン(2)、_dh(3)、_dh(4)、(255)が修理されたdss_が修理されたrsa_をenumする、ClientCertificateType。
opaque DistinguishedName<1..2^16-1>;
DistinguishedName<1について不透明にしてください。2^16-1>。
struct {
ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<3..2^16-1>;
} CertificateRequest;
struct ClientCertificateType証明書_タイプ<1..2^8-1>; DistinguishedName<3..2>証明書_当局^16-1;CertificateRequest。
certificate_types
This field is a list of the types of certificates requested,
sorted in order of the server's preference.
タイプThisがさばく証明書_はサーバの好みの順に要求されて、分類された証明書のタイプのリストです。
certificate_authorities
A list of the distinguished names of acceptable certificate
authorities. These distinguished names may specify a desired
distinguished name for a root CA or for a subordinate CA;
thus, this message can be used both to describe known roots
and a desired authorization space.
_許容できる認証局の分類名の当局Aリストを証明してください。 これらの分類名はカリフォルニアか下位のカリフォルニアとして必要な分類名を根に指定するかもしれません。 したがって、ともに知られているルーツと必要な承認スペースについて説明するのにこのメッセージを使用できます。
Note: DistinguishedName is derived from [X509].
以下に注意してください。 [X509]からDistinguishedNameを得ます。
Note: It is a fatal handshake_failure alert for an anonymous server to
request client identification.
以下に注意してください。 匿名のサーバがクライアント識別を要求するのは、致命的な握手_故障警報です。
7.4.5. Server hello done
7.4.5. サーバ、こんにちは、
When this message will be sent:
The server hello done message is sent by the server to indicate
the end of the server hello and associated messages. After
sending this message the server will wait for a client response.
このメッセージを送るとき: サーバ、こんにちは、サーバでされたメッセージを送って、サーバの終わりを示す、こんにちは、そして、関連メッセージ。 このメッセージを送った後に、サーバはクライアント応答を待っています。
Meaning of this message:
This message means that the server is done sending messages to
support the key exchange, and the client can proceed with its
phase of the key exchange.
このメッセージの意味: このメッセージは、サーバが主要な交換をサポートするメッセージを送り終わっていることを意味します、そして、クライアントは主要な交換のフェーズを続けることができます。
Upon receipt of the server hello done message the client should
verify that the server provided a valid certificate if required
and check that the server hello parameters are acceptable.
こんにちは、サーバを受け取り次第a有効な状態で提供されたサーバがそれを必要なら、証明して、チェックするというクライアントが確かめるべきであるメッセージにサーバをする、こんにちは、パラメタは許容できます。
Structure of this message:
struct { } ServerHelloDone;
このメッセージの構造: struct、ServerHelloDone。
Dierks & Allen Standards Track [Page 42] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[42ページ]RFC2246TLSプロトコルバージョン1999年1月1日
7.4.6. Client certificate
7.4.6. クライアント証明書
When this message will be sent:
This is the first message the client can send after receiving a
server hello done message. This message is only sent if the
server requests a certificate. If no suitable certificate is
available, the client should send a certificate message
containing no certificates. If client authentication is required
by the server for the handshake to continue, it may respond with
a fatal handshake failure alert. Client certificates are sent
using the Certificate structure defined in Section 7.4.2.
このメッセージを送るとき: これがサーバを受け取った後にクライアントが送ることができる最初のメッセージである、こんにちは、されたメッセージ。 サーバが証明書を要求する場合にだけ、このメッセージを送ります。 どんな適当な証明書も利用可能でないなら、クライアントは証明書を全く含まない証明書メッセージを送るべきです。 クライアント認証が握手が続くようにサーバによって必要とされるなら、それは致命的な握手故障警報で応じるかもしれません。 クライアント証明書にセクション7.4.2で定義されたCertificate構造を使用させます。
Note: When using a static Diffie-Hellman based key exchange method
(DH_DSS or DH_RSA), if client authentication is requested, the
Diffie-Hellman group and generator encoded in the client's
certificate must match the server specified Diffie-Hellman
parameters if the client's parameters are to be used for the key
exchange.
以下に注意してください。 クライアント認証が要求されるなら主要なベースの静的なディフィー-ヘルマンの交換メソッド(DH_DSSかDH_RSA)を使用するとき、クライアントの証明書でコード化されたディフィー-ヘルマングループとジェネレータはクライアントのパラメタが主要な交換に使用されることであるならサーバの指定されたディフィー-ヘルマンパラメタに合わなければなりません。
7.4.7. Client key exchange message
7.4.7. クライアントの主要な交換メッセージ
When this message will be sent:
This message is always sent by the client. It will immediately
follow the client certificate message, if it is sent. Otherwise
it will be the first message sent by the client after it receives
the server hello done message.
このメッセージを送るとき: このメッセージはいつもクライアントによって送られます。 それを送ると、それはすぐに、クライアント証明書メッセージに従うでしょう。 さもなければ、サーバを受け取った後にクライアントによって送られた最初のメッセージになる、こんにちは、されたメッセージ。
Meaning of this message:
With this message, the premaster secret is set, either though
direct transmission of the RSA-encrypted secret, or by the
transmission of Diffie-Hellman parameters which will allow each
side to agree upon the same premaster secret. When the key
exchange method is DH_RSA or DH_DSS, client certification has
been requested, and the client was able to respond with a
certificate which contained a Diffie-Hellman public key whose
parameters (group and generator) matched those specified by the
server in its certificate, this message will not contain any
data.
このメッセージの意味: このメッセージと共に、前マスター秘密が設定されるか、RSAによって暗号化された秘密の直線伝動である、またはそれぞれの側が同じ前マスター秘密に同意できるディフィー-ヘルマンパラメタの伝達であります。 主要な交換メソッドがDH_RSAかDH_DSSであり、クライアント証明が要求されて、クライアントがパラメタ(グループとジェネレータ)が証明書のサーバによって指定されたものに合っていたディフィー-ヘルマン公開鍵を含んだ証明書で応じることができたとき、このメッセージは少しのデータも含まないでしょう。
Structure of this message:
The choice of messages depends on which key exchange method has
been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
definition.
このメッセージの構造: メッセージのこの選択はどの主要な交換メソッドが選択されたか次第です。 KeyExchangeAlgorithm定義に関してセクション7.4.3を見てください。
struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
struct、(KeyExchangeAlgorithm)を選択してください、ケースrsa: EncryptedPreMasterSecret; diffie_hellmanをケースに入れてください: ClientDiffieHellmanPublic
Dierks & Allen Standards Track [Page 43] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[43ページ]RFC2246TLSプロトコルバージョン1999年1月1日
} exchange_keys;
} ClientKeyExchange;
_キーを交換してください。 } ClientKeyExchange。
7.4.7.1. RSA encrypted premaster secret message
7.4.7.1. RSAは前マスター秘密の通信を暗号化しました。
Meaning of this message:
If RSA is being used for key agreement and authentication, the
client generates a 48-byte premaster secret, encrypts it using
the public key from the server's certificate or the temporary RSA
key provided in a server key exchange message, and sends the
result in an encrypted premaster secret message. This structure
is a variant of the client key exchange message, not a message in
itself.
このメッセージの意味: RSAが主要な協定と認証に使用されているなら、クライアントは、暗号化された前マスター秘密の通信で48バイトの前マスター秘密を生成して、サーバの主要な交換メッセージに提供されたサーバの証明書か一時的なRSAキーから公開鍵を使用することでそれを暗号化して、結果を送ります。 本来この構造はメッセージではなく、クライアントの主要な交換メッセージの異形です。
Structure of this message:
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret;
このメッセージの構造: struct ProtocolVersionクライアント_バージョン; 不透明な無作為の[46];PreMasterSecret。
client_version
The latest (newest) version supported by the client. This is
used to detect version roll-back attacks. Upon receiving the
premaster secret, the server should check that this value
matches the value transmitted by the client in the client
hello message.
最新(最も新しい)のバージョンがクライアントでサポートしたクライアント_バージョン。 これは、バージョン後退復帰攻撃を検出するのに使用されます。 前マスター秘密、サーバがそうするべきである受信のときに、合わせるこれが値を評価するチェックは、クライアントというクライアントでこんにちはと伝えました。メッセージ。
random
46 securely-generated random bytes.
無作為のしっかりと発生している無作為の46バイト。
struct {
public-key-encrypted PreMasterSecret pre_master_secret;
} EncryptedPreMasterSecret;
struct、公開鍵で暗号化されたPreMasterSecret前_のマスター_秘密;、EncryptedPreMasterSecret。
Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used
to attack a TLS server which is using PKCS#1 encoded RSA. The
attack takes advantage of the fact that by failing in different
ways, a TLS server can be coerced into revealing whether a
particular message, when decrypted, is properly PKCS#1 formatted
or not.
以下に注意してください。 PKCS#1のコード化されたRSAを使用しているTLSサーバを攻撃するのにダニエルBleichenbacher[BLEI]によって発見された攻撃は使用できます。 攻撃は異なった道に失敗することによって、1がフォーマットしたPKCS#であるか否かに関係なく、解読されると特定のメッセージが適切にそうであるかどうかを明らかにするのにTLSサーバを強制できるという事実を利用します。
The best way to avoid vulnerability to this attack is to treat
incorrectly formatted messages in a manner indistinguishable from
correctly formatted RSA blocks. Thus, when it receives an
incorrectly formatted RSA block, a server should generate a
random 48-byte value and proceed using it as the premaster
secret. Thus, the server will act identically whether the
received RSA block is correctly encoded or not.
この攻撃として脆弱性を避ける最も良い方法は正しくフォーマットされたRSAブロックから区別できない方法による不当にフォーマットされたメッセージを扱うことです。 したがって、不当にフォーマットされたRSAブロックを受け取るとき、サーバは、前マスター秘密としてそれを使用することで無作為の48バイトの値を生成して、続くべきです。 したがって、受信されたRSAブロックが正しくコード化されるか否かに関係なく、サーバは同様に行動するでしょう。
Dierks & Allen Standards Track [Page 44] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[44ページ]RFC2246TLSプロトコルバージョン1999年1月1日
pre_master_secret
This random value is generated by the client and is used to
generate the master secret, as specified in Section 8.1.
前_のマスター_秘密のThis無作為の値は、クライアントによって生成されて、マスター秘密を生成するのに使用されます、セクション8.1で指定されるように。
7.4.7.2. Client Diffie-Hellman public value
7.4.7.2. クライアントのディフィー-ヘルマンの公共の価値
Meaning of this message:
This structure conveys the client's Diffie-Hellman public value
(Yc) if it was not already included in the client's certificate.
The encoding used for Yc is determined by the enumerated
PublicValueEncoding. This structure is a variant of the client
key exchange message, not a message in itself.
このメッセージの意味: それがクライアントの証明書に既に含まれなかったなら、この構造はクライアントのディフィー-ヘルマンの公共の値(Yc)を伝えます。 Ycに使用されるコード化は列挙されたPublicValueEncodingによって決定されます。 本来この構造はメッセージではなく、クライアントの主要な交換メッセージの異形です。
Structure of this message:
enum { implicit, explicit } PublicValueEncoding;
このメッセージの構造: enumの暗黙の、そして、明白なPublicValueEncoding。
implicit
If the client certificate already contains a suitable
Diffie-Hellman key, then Yc is implicit and does not need to
be sent again. In this case, the Client Key Exchange message
will be sent, but will be empty.
内在しているIf、クライアント証明書が既に適当なディフィー-ヘルマンキーを含んでいて、次に、Ycによって暗黙であり、再び送られる必要はありません。 この場合、Client Key Exchangeメッセージは、送りますが、空になるでしょう。
explicit
Yc needs to be sent.
明白なYcは、送られる必要があります。
struct {
select (PublicValueEncoding) {
case implicit: struct { };
case explicit: opaque dh_Yc<1..2^16-1>;
} dh_public;
} ClientDiffieHellmanPublic;
struct、(PublicValueEncoding)を選択してください、ケース暗黙:、struct、;、ケース明白である、: dh_Yc<1..2^16-1>について不透明にしてください;、dh_公衆;、ClientDiffieHellmanPublic。
dh_Yc
The client's Diffie-Hellman public value (Yc).
クライアントのdh_Ycのディフィー-ヘルマン公衆は(Yc)を評価します。
7.4.8. Certificate verify
7.4.8. 証明書は確かめます。
When this message will be sent:
This message is used to provide explicit verification of a client
certificate. This message is only sent following a client
certificate that has signing capability (i.e. all certificates
except those containing fixed Diffie-Hellman parameters). When
sent, it will immediately follow the client key exchange message.
このメッセージを送るとき: このメッセージは、クライアント証明書の明白な検証を提供するのに使用されます。 このメッセージを署名能力を持っているクライアント証明書(固定ディフィー-ヘルマンパラメタを含むもの以外のすなわちすべての証明書)に従わせるだけです。 送ると、それはすぐに、クライアントの主要な交換メッセージに従うでしょう。
Structure of this message:
struct {
Signature signature;
} CertificateVerify;
このメッセージの構造: struct、署名署名;、CertificateVerify。
Dierks & Allen Standards Track [Page 45] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[45ページ]RFC2246TLSプロトコルバージョン1999年1月1日
The Signature type is defined in 7.4.3.
Signatureタイプは7.4で.3に定義されます。
CertificateVerify.signature.md5_hash
MD5(handshake_messages);
CertificateVerify.signature.md5_ハッシュMD5(握手_メッセージ)。
Certificate.signature.sha_hash
SHA(handshake_messages);
Certificate.signature.sha_ハッシュSHA(握手_メッセージ)。
Here handshake_messages refers to all handshake messages sent or received starting at client hello up to but not including this message, including the type and length fields of the handshake messages. This is the concatenation of all the Handshake structures as defined in 7.4 exchanged thus far.
ここと、握手_メッセージはクライアントで包含だけでないのへのこのメッセージ、包含にこんにちは、タイプを始めて、メッセージが送ったか、または受けて、長さがさばく握手メッセージのすべての握手を呼びます。 これはこれまでのところ交換された7.4における定義されるとしてのすべてのHandshake構造の連結です。
7.4.9. Finished
7.4.9. 終わっています。
When this message will be sent:
A finished message is always sent immediately after a change
cipher spec message to verify that the key exchange and
authentication processes were successful. It is essential that a
change cipher spec message be received between the other
handshake messages and the Finished message.
このメッセージを送るとき: 主要な交換と認証過程がうまくいったことを確かめる変化暗号仕様メッセージ直後いつも終わっているメッセージを送ります。 他の握手メッセージとFinishedメッセージの間に変化暗号仕様メッセージを受け取るのは不可欠です。
Meaning of this message:
The finished message is the first protected with the just-
negotiated algorithms, keys, and secrets. Recipients of finished
messages must verify that the contents are correct. Once a side
has sent its Finished message and received and validated the
Finished message from its peer, it may begin to send and receive
application data over the connection.
このメッセージの意味: 終わっているメッセージはただ交渉されたアルゴリズム、キー、および秘密で保護された1番目です。 終わっているメッセージの受取人は、内容が正しいことを確かめなければなりません。 側が同輩からFinishedメッセージをいったんFinishedメッセージを送って、受けて、有効にすると、それは、接続の上にアプリケーションデータを送って、受け取り始めるかもしれません。
struct {
opaque verify_data[12];
} Finished;
struct、不透明なものは_データ[12]について確かめます;、終わっています。
verify_data
PRF(master_secret, finished_label, MD5(handshake_messages) +
SHA-1(handshake_messages)) [0..11];
_データPRFについて確かめてください(_が秘密の、そして、完成している_ラベル、MD5(握手_メッセージ)+SHA-1(握手_メッセージ)であるとマスタリングしてください)[0 .11]。
finished_label
For Finished messages sent by the client, the string "client
finished". For Finished messages sent by the server, the
string "server finished".
クライアントによって送られた、終わっている_ラベルFor Finishedメッセージ、「クライアントは終えた」ストリング。 サーバ、ストリングによって送られたFinishedメッセージに関しては、「サーバは完成しました」。
handshake_messages
All of the data from all handshake messages up to but not
including this message. This is only data visible at the
handshake layer and does not include record layer headers.
包含だけでないのへのこのメッセージへのすべての握手メッセージからのデータの握手_メッセージAll。 これは、握手層で目に見えるデータだけであり、記録的な層のヘッダーを含んでいません。
Dierks & Allen Standards Track [Page 46] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 46] RFC 2246 The TLS Protocol Version 1.0 January 1999
This is the concatenation of all the Handshake structures as
defined in 7.4 exchanged thus far.
This is the concatenation of all the Handshake structures as defined in 7.4 exchanged thus far.
It is a fatal error if a finished message is not preceded by a change cipher spec message at the appropriate point in the handshake.
It is a fatal error if a finished message is not preceded by a change cipher spec message at the appropriate point in the handshake.
The hash contained in finished messages sent by the server incorporate Sender.server; those sent by the client incorporate Sender.client. The value handshake_messages includes all handshake messages starting at client hello up to, but not including, this finished message. This may be different from handshake_messages in Section 7.4.8 because it would include the certificate verify message (if sent). Also, the handshake_messages for the finished message sent by the client will be different from that for the finished message sent by the server, because the one which is sent second will include the prior one.
The hash contained in finished messages sent by the server incorporate Sender.server; those sent by the client incorporate Sender.client. The value handshake_messages includes all handshake messages starting at client hello up to, but not including, this finished message. This may be different from handshake_messages in Section 7.4.8 because it would include the certificate verify message (if sent). Also, the handshake_messages for the finished message sent by the client will be different from that for the finished message sent by the server, because the one which is sent second will include the prior one.
Note: Change cipher spec messages, alerts and any other record types
are not handshake messages and are not included in the hash
computations. Also, Hello Request messages are omitted from
handshake hashes.
Note: Change cipher spec messages, alerts and any other record types are not handshake messages and are not included in the hash computations. Also, Hello Request messages are omitted from handshake hashes.
8. Cryptographic computations
8. Cryptographic computations
In order to begin connection protection, the TLS Record Protocol requires specification of a suite of algorithms, a master secret, and the client and server random values. The authentication, encryption, and MAC algorithms are determined by the cipher_suite selected by the server and revealed in the server hello message. The compression algorithm is negotiated in the hello messages, and the random values are exchanged in the hello messages. All that remains is to calculate the master secret.
In order to begin connection protection, the TLS Record Protocol requires specification of a suite of algorithms, a master secret, and the client and server random values. The authentication, encryption, and MAC algorithms are determined by the cipher_suite selected by the server and revealed in the server hello message. The compression algorithm is negotiated in the hello messages, and the random values are exchanged in the hello messages. All that remains is to calculate 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 the pre_master_secret into the master_secret. The pre_master_secret should be deleted from memory once the master_secret has been computed.
For all key exchange methods, the same algorithm is used to convert the pre_master_secret into the master_secret. The pre_master_secret should be deleted from memory once the master_secret has been computed.
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random)
[0..47];
master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47];
The master secret is always exactly 48 bytes in length. The length of the premaster secret will vary depending on key exchange method.
The master secret is always exactly 48 bytes in length. The length of the premaster secret will vary depending on key exchange method.
Dierks & Allen Standards Track [Page 47] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 47] RFC 2246 The TLS Protocol Version 1.0 January 1999
8.1.1. RSA
8.1.1. RSA
When RSA is used for server authentication and key exchange, a 48- byte pre_master_secret is generated by the client, encrypted under the server's public key, and sent to the server. The server uses its private key to decrypt the pre_master_secret. Both parties then convert the pre_master_secret into the master_secret, as specified above.
When RSA is used for server authentication and key exchange, a 48- byte pre_master_secret is generated by the client, encrypted under the server's public key, and sent to the server. The server uses its private key to decrypt the pre_master_secret. Both parties then convert the pre_master_secret into the master_secret, as specified above.
RSA digital signatures are performed using PKCS #1 [PKCS1] block type 1. RSA public key encryption is performed using PKCS #1 block type 2.
RSA digital signatures are performed using PKCS #1 [PKCS1] block type 1. RSA public key encryption is performed using PKCS #1 block type 2.
8.1.2. Diffie-Hellman
8.1.2. Diffie-Hellman
A conventional Diffie-Hellman computation is performed. The negotiated key (Z) is used as the pre_master_secret, and is converted into the master_secret, as specified above.
A conventional Diffie-Hellman computation is performed. The negotiated key (Z) is used as the pre_master_secret, and is converted into the master_secret, as specified above.
Note: Diffie-Hellman parameters are specified by the server, and may
be either ephemeral or contained within the server's certificate.
Note: Diffie-Hellman parameters are specified by the server, and may be either ephemeral or contained within the server's certificate.
9. Mandatory Cipher Suites
9. Mandatory Cipher Suites
In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher 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 fragmented, compressed and encrypted based on the current connection state. The messages are treated as transparent data to the record layer.
Application data messages are carried by the Record Layer and are fragmented, compressed and encrypted based on the current connection state. The messages are treated as transparent data to the record layer.
Dierks & Allen Standards Track [Page 48] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 48] RFC 2246 The TLS Protocol Version 1.0 January 1999
A. Protocol constant values
A. Protocol constant values
This section describes protocol types and constants.
This section describes protocol types and constants.
A.1. Record layer
A.1. Record layer
struct {
uint8 major, minor;
} ProtocolVersion;
struct { uint8 major, minor; } ProtocolVersion;
ProtocolVersion version = { 3, 1 }; /* TLS v1.0 */
ProtocolVersion version = { 3, 1 }; /* TLS v1.0 */
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;
enum { change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255) } ContentType;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
struct { ContentType type; ProtocolVersion version; uint16 length; opaque fragment[TLSPlaintext.length]; } TLSPlaintext;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSCompressed.length];
} TLSCompressed;
struct { ContentType type; ProtocolVersion version; uint16 length; opaque fragment[TLSCompressed.length]; } TLSCompressed;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
} fragment;
} TLSCiphertext;
struct { ContentType type; ProtocolVersion version; uint16 length; select (CipherSpec.cipher_type) { case stream: GenericStreamCipher; case block: GenericBlockCipher; } fragment; } TLSCiphertext;
stream-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
} GenericStreamCipher;
stream-ciphered struct { opaque content[TLSCompressed.length]; opaque MAC[CipherSpec.hash_size]; } GenericStreamCipher;
block-ciphered struct {
opaque content[TLSCompressed.length];
block-ciphered struct { opaque content[TLSCompressed.length];
Dierks & Allen Standards Track [Page 49] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 49] RFC 2246 The TLS Protocol Version 1.0 January 1999
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
opaque MAC[CipherSpec.hash_size]; uint8 padding[GenericBlockCipher.padding_length]; uint8 padding_length; } GenericBlockCipher;
A.2. Change cipher specs message
A.2. Change cipher specs message
struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
struct { enum { change_cipher_spec(1), (255) } type; } ChangeCipherSpec;
A.3. Alert messages
A.3. Alert messages
enum { warning(1), fatal(2), (255) } AlertLevel;
enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed(21),
record_overflow(22),
decompression_failure(30),
handshake_failure(40),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
(255)
} AlertDescription;
enum { close_notify(0), unexpected_message(10), bad_record_mac(20), decryption_failed(21), record_overflow(22), decompression_failure(30), handshake_failure(40), bad_certificate(42), unsupported_certificate(43), certificate_revoked(44), certificate_expired(45), certificate_unknown(46), illegal_parameter(47), unknown_ca(48), access_denied(49), decode_error(50), decrypt_error(51), export_restriction(60), protocol_version(70), insufficient_security(71), internal_error(80), user_canceled(90), no_renegotiation(100), (255) } AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
struct { AlertLevel level; AlertDescription description; } Alert;
Dierks & Allen Standards Track [Page 50] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 50] RFC 2246 The TLS Protocol Version 1.0 January 1999
A.4. Handshake protocol
A.4. Handshake protocol
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255)
} HandshakeType;
enum { hello_request(0), client_hello(1), server_hello(2), certificate(11), server_key_exchange (12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange(16), finished(20), (255) } HandshakeType;
struct {
HandshakeType msg_type;
uint24 length;
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
} Handshake;
struct { HandshakeType msg_type; uint24 length; select (HandshakeType) { case hello_request: HelloRequest; case client_hello: ClientHello; case server_hello: ServerHello; case certificate: Certificate; case server_key_exchange: ServerKeyExchange; case certificate_request: CertificateRequest; case server_hello_done: ServerHelloDone; case certificate_verify: CertificateVerify; case client_key_exchange: ClientKeyExchange; case finished: Finished; } body; } Handshake;
A.4.1. Hello messages
A.4.1. Hello messages
struct { } HelloRequest;
struct { } HelloRequest;
struct {
uint32 gmt_unix_time;
opaque random_bytes[28];
} Random;
struct { uint32 gmt_unix_time; opaque random_bytes[28]; } Random;
opaque SessionID<0..32>;
opaque SessionID<0..32>;
uint8 CipherSuite[2];
uint8 CipherSuite[2];
enum { null(0), (255) } CompressionMethod;
enum { null(0), (255) } CompressionMethod;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..2^16-1>; CompressionMethod compression_methods<1..2^8-1>;
Dierks & Allen Standards Track [Page 51] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 51] RFC 2246 The TLS Protocol Version 1.0 January 1999
} ClientHello;
} ClientHello;
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
} ServerHello;
struct { ProtocolVersion server_version; Random random; SessionID session_id; CipherSuite cipher_suite; CompressionMethod compression_method; } ServerHello;
A.4.2. Server authentication and key exchange messages
A.4.2. Server authentication and key exchange messages
opaque ASN.1Cert<2^24-1>;
opaque ASN.1Cert<2^24-1>;
struct {
ASN.1Cert certificate_list<1..2^24-1>;
} Certificate;
struct { ASN.1Cert certificate_list<1..2^24-1>; } Certificate;
enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
struct {
opaque RSA_modulus<1..2^16-1>;
opaque RSA_exponent<1..2^16-1>;
} ServerRSAParams;
struct { opaque RSA_modulus<1..2^16-1>; opaque RSA_exponent<1..2^16-1>; } ServerRSAParams;
struct {
opaque DH_p<1..2^16-1>;
opaque DH_g<1..2^16-1>;
opaque DH_Ys<1..2^16-1>;
} ServerDHParams;
struct { opaque DH_p<1..2^16-1>; opaque DH_g<1..2^16-1>; opaque DH_Ys<1..2^16-1>; } ServerDHParams;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params;
};
} ServerKeyExchange;
struct { select (KeyExchangeAlgorithm) { case diffie_hellman: ServerDHParams params; Signature signed_params; case rsa: ServerRSAParams params; Signature signed_params; }; } ServerKeyExchange;
enum { anonymous, rsa, dsa } SignatureAlgorithm;
enum { anonymous, rsa, dsa } SignatureAlgorithm;
select (SignatureAlgorithm)
{ case anonymous: struct { };
case rsa:
digitally-signed struct {
select (SignatureAlgorithm) { case anonymous: struct { }; case rsa: digitally-signed struct {
Dierks & Allen Standards Track [Page 52] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 52] RFC 2246 The TLS Protocol Version 1.0 January 1999
opaque md5_hash[16];
opaque sha_hash[20];
};
case dsa:
digitally-signed struct {
opaque sha_hash[20];
};
} Signature;
opaque md5_hash[16]; opaque sha_hash[20]; }; case dsa: digitally-signed struct { opaque sha_hash[20]; }; } Signature;
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
(255)
} ClientCertificateType;
enum { rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), (255) } ClientCertificateType;
opaque DistinguishedName<1..2^16-1>;
opaque DistinguishedName<1..2^16-1>;
struct {
ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<3..2^16-1>;
} CertificateRequest;
struct { ClientCertificateType certificate_types<1..2^8-1>; DistinguishedName certificate_authorities<3..2^16-1>; } CertificateRequest;
struct { } ServerHelloDone;
struct { } ServerHelloDone;
A.4.3. Client authentication and key exchange messages
A.4.3. Client authentication and key exchange messages
struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: DiffieHellmanClientPublicValue;
} exchange_keys;
} ClientKeyExchange;
struct { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret; case diffie_hellman: DiffieHellmanClientPublicValue; } exchange_keys; } ClientKeyExchange;
struct {
ProtocolVersion client_version;
opaque random[46];
struct { ProtocolVersion client_version; opaque random[46];
} PreMasterSecret;
} PreMasterSecret;
struct {
public-key-encrypted PreMasterSecret pre_master_secret;
} EncryptedPreMasterSecret;
struct { public-key-encrypted PreMasterSecret pre_master_secret; } EncryptedPreMasterSecret;
enum { implicit, explicit } PublicValueEncoding;
enum { implicit, explicit } PublicValueEncoding;
struct {
select (PublicValueEncoding) {
case implicit: struct {};
case explicit: opaque DH_Yc<1..2^16-1>;
struct { select (PublicValueEncoding) { case implicit: struct {}; case explicit: opaque DH_Yc<1..2^16-1>;
Dierks & Allen Standards Track [Page 53] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 53] RFC 2246 The TLS Protocol Version 1.0 January 1999
} dh_public;
} ClientDiffieHellmanPublic;
} dh_public; } ClientDiffieHellmanPublic;
struct {
Signature signature;
} CertificateVerify;
struct { Signature signature; } CertificateVerify;
A.4.4. Handshake finalization message
A.4.4. Handshake finalization message
struct {
opaque verify_data[12];
} Finished;
struct { opaque verify_data[12]; } Finished;
A.5. The CipherSuite
A.5. The CipherSuite
The following values define the CipherSuite codes used in the client hello and server hello messages.
The following values define the CipherSuite codes used in the client hello and server hello messages.
A CipherSuite defines a cipher specification supported in TLS Version 1.0.
A CipherSuite defines a cipher specification supported in TLS Version 1.0.
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 not be negotiated, as it provides no more protection than an unsecured connection.
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 not be negotiated, as it provides no more protection than an 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 provide an RSA certificate that can be used for key exchange. The server may request either an RSA or a DSS signature-capable certificate in the certificate request message.
The following CipherSuite definitions require that the server provide an RSA certificate that can be used for key exchange. The server may request either an RSA or a DSS signature-capable certificate in the certificate request message.
CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };
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_SHA = { 0x00,0x05 };
CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };
CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };
CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };
CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }; 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_SHA = { 0x00,0x05 }; CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
The following CipherSuite definitions are used for server- authenticated (and optionally client-authenticated) Diffie-Hellman. DH denotes cipher suites in which the server's certificate contains the Diffie-Hellman parameters signed by the certificate authority
The following CipherSuite definitions are used for server- authenticated (and optionally client-authenticated) Diffie-Hellman. DH denotes cipher suites in which the server's certificate contains the Diffie-Hellman parameters signed by the certificate authority
Dierks & Allen Standards Track [Page 54] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 54] RFC 2246 The TLS Protocol Version 1.0 January 1999
(CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman parameters are signed by a DSS or RSA certificate, which has been signed by the CA. The signing algorithm used is specified after the DH or DHE parameter. The server can request an RSA or DSS signature- capable certificate from the client for client authentication or it may request a Diffie-Hellman certificate. Any Diffie-Hellman certificate provided by the client must use the parameters (group and generator) described by the server.
(CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman parameters are signed by a DSS or RSA certificate, which has been signed by the CA. The signing algorithm used is specified after the DH or DHE parameter. The server can request an RSA or DSS signature- capable certificate from the client for client authentication or it may request a Diffie-Hellman certificate. Any Diffie-Hellman certificate provided by the client must use the parameters (group and generator) described by the server.
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_3DES_EDE_CBC_SHA = { 0x00,0x0D };
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_3DES_EDE_CBC_SHA = { 0x00,0x10 };
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_3DES_EDE_CBC_SHA = { 0x00,0x13 };
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_3DES_EDE_CBC_SHA = { 0x00,0x16 };
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_3DES_EDE_CBC_SHA = { 0x00,0x0D }; 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_3DES_EDE_CBC_SHA = { 0x00,0x10 }; 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_3DES_EDE_CBC_SHA = { 0x00,0x13 }; 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_3DES_EDE_CBC_SHA = { 0x00,0x16 };
The following cipher suites are used for completely anonymous Diffie-Hellman communications in which neither party is authenticated. Note that this mode is vulnerable to man-in-the-middle attacks and is therefore deprecated.
The following cipher suites are used for completely anonymous Diffie-Hellman communications in which neither party is authenticated. Note that this mode is vulnerable to man-in-the-middle attacks and is therefore deprecated.
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_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
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_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; 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_WITH_DES_CBC_SHA = { 0x00,0x1A }; CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
Note: All cipher suites whose first byte is 0xFF are considered
private and can be used for defining local/experimental
algorithms. Interoperability of such types is a local matter.
Note: All cipher suites whose first byte is 0xFF are considered private and can be used for defining local/experimental algorithms. Interoperability of such types is a local matter.
Note: Additional cipher suites can be registered by publishing an RFC
which specifies the cipher suites, including the necessary TLS
protocol information, including message encoding, premaster
secret derivation, symmetric encryption and MAC calculation and
appropriate reference information for the algorithms involved.
The RFC editor's office may, at its discretion, choose to publish
specifications for cipher suites which are not completely
described (e.g., for classified algorithms) if it finds the
specification to be of technical interest and completely
specified.
Note: Additional cipher suites can be registered by publishing an RFC which specifies the cipher suites, including the necessary TLS protocol information, including message encoding, premaster secret derivation, symmetric encryption and MAC calculation and appropriate reference information for the algorithms involved. The RFC editor's office may, at its discretion, choose to publish specifications for cipher suites which are not completely described (e.g., for classified algorithms) if it finds the specification to be of technical interest and completely specified.
Dierks & Allen Standards Track [Page 55] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 55] RFC 2246 The TLS Protocol Version 1.0 January 1999
Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
reserved to avoid collision with Fortezza-based cipher suites in
SSL 3.
Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are reserved to avoid collision with Fortezza-based cipher suites in SSL 3.
A.6. The Security Parameters
A.6. The Security Parameters
These security parameters are determined by the TLS Handshake Protocol and provided as parameters to the TLS Record Layer in order to initialize a connection state. SecurityParameters includes:
These security parameters are determined by the TLS Handshake Protocol and provided as parameters to the TLS Record Layer in order to initialize a connection state. SecurityParameters includes:
enum { null(0), (255) } CompressionMethod;
enum { null(0), (255) } CompressionMethod;
enum { server, client } ConnectionEnd;
enum { server, client } ConnectionEnd;
enum { null, rc4, rc2, des, 3des, des40, idea }
BulkCipherAlgorithm;
enum { null, rc4, rc2, des, 3des, des40, idea } BulkCipherAlgorithm;
enum { stream, block } CipherType;
enum { stream, block } CipherType;
enum { true, false } IsExportable;
enum { true, false } IsExportable;
enum { null, md5, sha } MACAlgorithm;
enum { null, md5, sha } MACAlgorithm;
/* The algorithms specified in CompressionMethod, BulkCipherAlgorithm, and MACAlgorithm may be added to. */
/* The algorithms specified in CompressionMethod, BulkCipherAlgorithm, and MACAlgorithm may be added to. */
struct {
ConnectionEnd entity;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 key_size;
uint8 key_material_length;
IsExportable is_exportable;
MACAlgorithm mac_algorithm;
uint8 hash_size;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
struct { ConnectionEnd entity; BulkCipherAlgorithm bulk_cipher_algorithm; CipherType cipher_type; uint8 key_size; uint8 key_material_length; IsExportable is_exportable; MACAlgorithm mac_algorithm; uint8 hash_size; CompressionMethod compression_algorithm; opaque master_secret[48]; opaque client_random[32]; opaque server_random[32]; } SecurityParameters;
Dierks & Allen Standards Track [Page 56] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 56] RFC 2246 The TLS Protocol Version 1.0 January 1999
B. Glossary
B. Glossary
application protocol
An application protocol is a protocol that normally layers
directly on top of the transport layer (e.g., TCP/IP). Examples
include HTTP, TELNET, FTP, and SMTP.
application protocol An application protocol is a protocol that normally layers directly on top of the transport layer (e.g., TCP/IP). Examples include HTTP, TELNET, FTP, and SMTP.
asymmetric cipher
See public key cryptography.
asymmetric cipher See public key cryptography.
authentication
Authentication is the ability of one entity to determine the
identity of another entity.
authentication Authentication is the ability of one entity to determine the identity of another entity.
block cipher
A block cipher is an algorithm that operates on plaintext in
groups of bits, called blocks. 64 bits is a common block size.
block cipher A block cipher is an algorithm that operates on plaintext in groups of bits, called blocks. 64 bits is a common block size.
bulk cipher
A symmetric encryption algorithm used to encrypt large quantities
of data.
bulk cipher A symmetric encryption algorithm used to encrypt large quantities of data.
cipher block chaining (CBC)
CBC is a mode in which every plaintext block encrypted with a
block cipher is first exclusive-ORed with the previous ciphertext
block (or, in the case of the first block, with the
initialization vector). For decryption, every block is first
decrypted, then exclusive-ORed with the previous ciphertext block
(or IV).
cipher block chaining (CBC) CBC is a mode in which every plaintext block encrypted with a block cipher is first exclusive-ORed with the previous ciphertext block (or, in the case of the first block, with the initialization vector). For decryption, every block is first decrypted, then exclusive-ORed with the previous ciphertext block (or IV).
certificate
As part of the X.509 protocol (a.k.a. ISO Authentication
framework), certificates are assigned by a trusted Certificate
Authority and provide a strong binding between a party's identity
or some other attributes and its public key.
certificate As part of the X.509 protocol (a.k.a. ISO Authentication framework), certificates are assigned by a trusted Certificate Authority and provide a strong binding between a party's identity or some other attributes and its public key.
client
The application entity that initiates a TLS connection to a
server. This may or may not imply that the client initiated the
underlying transport connection. The primary operational
difference between the server and client is that the server is
generally authenticated, while the client is only optionally
authenticated.
client The application entity that initiates a TLS connection to a server. This may or may not imply that the client initiated the underlying transport connection. The primary operational difference between the server and client is that the server is generally authenticated, while the client is only optionally authenticated.
client write key
The key used to encrypt data written by the client.
client write key The key used to encrypt data written by the client.
Dierks & Allen Standards Track [Page 57] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 57] RFC 2246 The TLS Protocol Version 1.0 January 1999
client write MAC secret
The secret data used to authenticate data written by the client.
client write MAC secret The secret data used to authenticate data written by the client.
connection
A connection is a transport (in the OSI layering model
definition) that provides a suitable type of service. For TLS,
such connections are peer to peer relationships. The connections
are transient. Every connection is associated with one session.
connection A connection is a transport (in the OSI layering model definition) that provides a suitable type of service. For TLS, such connections are peer to peer relationships. The connections are transient. Every connection is associated with one session.
Data Encryption Standard
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
that in TLS, for key generation purposes, DES is treated as
having an 8 byte key length (64 bits), but it still only provides
56 bits of protection. (The low bit of each key byte is presumed
to be set to produce odd parity in that key byte.) DES can also
be operated in a mode where three independent keys and three
encryptions are used for each block of data; this uses 168 bits
of key (24 bytes in the TLS key generation method) and provides
the equivalent of 112 bits of security. [DES], [3DES]
Data Encryption Standard 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 that in TLS, for key generation purposes, DES is treated as having an 8 byte key length (64 bits), but it still only provides 56 bits of protection. (The low bit of each key byte is presumed to be set to produce odd parity in that key byte.) DES can also be operated in a mode where three independent keys and three encryptions are used for each block of data; this uses 168 bits of key (24 bytes in the TLS key generation method) and provides the equivalent of 112 bits of security. [DES], [3DES]
Digital Signature Standard (DSS)
A standard for digital signing, including the Digital Signing
Algorithm, approved by the National Institute of Standards and
Technology, defined in NIST FIPS PUB 186, "Digital Signature
Standard," published May, 1994 by the U.S. Dept. of Commerce.
[DSS]
Digital Signature Standard (DSS) A standard for digital signing, including the Digital Signing Algorithm, approved by the National Institute of Standards and Technology, defined in NIST FIPS PUB 186, "Digital Signature Standard," published May, 1994 by the U.S. Dept. of Commerce. [DSS]
digital signatures
Digital signatures utilize public key cryptography and one-way
hash functions to produce a signature of the data that can be
authenticated, and is difficult to forge or repudiate.
digital signatures Digital signatures utilize public key cryptography and one-way hash functions to produce a signature of the data that can be authenticated, and is difficult to forge or repudiate.
handshake
An initial negotiation between client and server that establishes
the parameters of their transactions.
handshake An initial negotiation between client and server that establishes the parameters of their transactions.
Initialization Vector (IV)
When a block cipher is used in CBC mode, the initialization
vector is exclusive-ORed with the first plaintext block prior to
encryption.
Initialization Vector (IV) When a block cipher is used in CBC mode, the initialization vector is exclusive-ORed with the first plaintext block prior to encryption.
IDEA
A 64-bit block cipher designed by Xuejia Lai and James Massey.
[IDEA]
IDEA A 64-bit block cipher designed by Xuejia Lai and James Massey. [IDEA]
Dierks & Allen Standards Track [Page 58] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 58] RFC 2246 The TLS Protocol Version 1.0 January 1999
Message Authentication Code (MAC)
A Message Authentication Code is a one-way hash computed from a
message and some secret data. It is difficult to forge without
knowing the secret data. Its purpose is to detect if the message
has been altered.
Message Authentication Code (MAC) A Message Authentication Code is a one-way hash computed from a message and some secret data. It is difficult to forge without knowing the secret data. Its purpose is to detect if the message has been altered.
master secret
Secure secret data used for generating encryption keys, MAC
secrets, and IVs.
master secret Secure secret data used for generating encryption keys, MAC secrets, and IVs.
MD5
MD5 is a secure hashing function that converts an arbitrarily
long data stream into a digest of fixed size (16 bytes). [MD5]
MD5 MD5 is a secure hashing function that converts an arbitrarily long data stream into a digest of fixed size (16 bytes). [MD5]
public key cryptography
A class of cryptographic techniques employing two-key ciphers.
Messages encrypted with the public key can only be decrypted with
the associated private key. Conversely, messages signed with the
private key can be verified with the public key.
public key cryptography A class of cryptographic techniques employing two-key ciphers. Messages encrypted with the public key can only be decrypted with the associated private key. Conversely, messages signed with the private key can be verified with the public key.
one-way hash function
A one-way transformation that converts an arbitrary amount of
data into a fixed-length hash. It is computationally hard to
reverse the transformation or to find collisions. MD5 and SHA are
examples of one-way hash functions.
one-way hash function A one-way transformation that converts an arbitrary amount of data into a fixed-length hash. It is computationally hard to reverse the transformation or to find collisions. MD5 and SHA are examples of one-way hash functions.
RC2
A block cipher developed by Ron Rivest at RSA Data Security, Inc.
[RSADSI] described in [RC2].
RC2 A block cipher developed by Ron Rivest at RSA Data Security, Inc. [RSADSI] described in [RC2].
RC4
A stream cipher licensed by RSA Data Security [RSADSI]. A
compatible cipher is described in [RC4].
RC4 A stream cipher licensed by RSA Data Security [RSADSI]. A compatible cipher is described in [RC4].
RSA
A very widely used public-key algorithm that can be used for
either encryption or digital signing. [RSA]
RSA A very widely used public-key algorithm that can be used for either encryption or digital signing. [RSA]
salt
Non-secret random data used to make export encryption keys resist
precomputation attacks.
salt Non-secret random data used to make export encryption keys resist precomputation attacks.
server
The server is the application entity that responds to requests
for connections from clients. See also under client.
server The server is the application entity that responds to requests for connections from clients. See also under client.
Dierks & Allen Standards Track [Page 59] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 59] RFC 2246 The TLS Protocol Version 1.0 January 1999
session
A TLS session is an association between a client and a server.
Sessions are created by the handshake protocol. Sessions define a
set of cryptographic security parameters, which can be shared
among multiple connections. Sessions are used to avoid the
expensive negotiation of new security parameters for each
connection.
session A TLS session is an association between a client and a server. Sessions are created by the handshake protocol. Sessions define a set of cryptographic security parameters, which can be shared among multiple connections. Sessions are used to avoid the expensive negotiation of new security parameters for each connection.
session identifier
A session identifier is a value generated by a server that
identifies a particular session.
session identifier A session identifier is a value generated by a server that identifies a particular session.
server write key
The key used to encrypt data written by the server.
server write key The key used to encrypt data written by the server.
server write MAC secret
The secret data used to authenticate data written by the server.
server write MAC secret The secret data used to authenticate data written by the server.
SHA
The Secure Hash Algorithm is defined in FIPS PUB 180-1. It
produces a 20-byte output. Note that all references to SHA
actually use the modified SHA-1 algorithm. [SHA]
SHA The Secure Hash Algorithm is defined in FIPS PUB 180-1. It produces a 20-byte output. Note that all references to SHA actually use the modified SHA-1 algorithm. [SHA]
SSL
Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
SSL Version 3.0
SSL Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on SSL Version 3.0
stream cipher
An encryption algorithm that converts a key into a
cryptographically-strong keystream, which is then exclusive-ORed
with the plaintext.
stream cipher An encryption algorithm that converts a key into a cryptographically-strong keystream, which is then exclusive-ORed with the plaintext.
symmetric cipher
See bulk cipher.
symmetric cipher See bulk cipher.
Transport Layer Security (TLS)
This protocol; also, the Transport Layer Security working group
of the Internet Engineering Task Force (IETF). See "Comments" at
the end of this document.
Transport Layer Security (TLS) This protocol; also, the Transport Layer Security working group of the Internet Engineering Task Force (IETF). See "Comments" at the end of this document.
Dierks & Allen Standards Track [Page 60] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 60] RFC 2246 The TLS Protocol Version 1.0 January 1999
C. CipherSuite definitions
C. CipherSuite definitions
CipherSuite Is Key Cipher Hash
Exportable Exchange
CipherSuite Is Key Cipher Hash Exportable Exchange
TLS_NULL_WITH_NULL_NULL * NULL NULL NULL TLS_RSA_WITH_NULL_MD5 * RSA NULL MD5 TLS_RSA_WITH_NULL_SHA * RSA NULL SHA TLS_RSA_EXPORT_WITH_RC4_40_MD5 * RSA_EXPORT RC4_40 MD5 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 * RSA_EXPORT RC2_CBC_40 MD5 TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA * RSA_EXPORT DES40_CBC SHA TLS_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA * DH_DSS_EXPORT DES40_CBC SHA TLS_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA * DH_RSA_EXPORT DES40_CBC SHA TLS_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC SHA TLS_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC SHA TLS_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 * DH_anon_EXPORT RC4_40 MD5 TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA DH_anon DES40_CBC SHA TLS_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA
TLS_NULL_WITH_NULL_NULL * NULL NULL NULL TLS_RSA_WITH_NULL_MD5 * RSA NULL MD5 TLS_RSA_WITH_NULL_SHA * RSA NULL SHA TLS_RSA_EXPORT_WITH_RC4_40_MD5 * RSA_EXPORT RC4_40 MD5 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 * RSA_EXPORT RC2_CBC_40 MD5 TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA * RSA_EXPORT DES40_CBC SHA TLS_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA * DH_DSS_EXPORT DES40_CBC SHA TLS_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA * DH_RSA_EXPORT DES40_CBC SHA TLS_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC SHA TLS_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC SHA TLS_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 * DH_anon_EXPORT RC4_40 MD5 TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA DH_anon DES40_CBC SHA TLS_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA
* Indicates IsExportable is True
* Indicates IsExportable is True
Key
Exchange
Algorithm Description Key size limit
Key Exchange Algorithm Description Key size limit
DHE_DSS Ephemeral DH with DSS signatures None
DHE_DSS_EXPORT Ephemeral DH with DSS signatures DH = 512 bits
DHE_RSA Ephemeral DH with RSA signatures None
DHE_RSA_EXPORT Ephemeral DH with RSA signatures DH = 512 bits,
RSA = none
DH_anon Anonymous DH, no signatures None
DH_anon_EXPORT Anonymous DH, no signatures DH = 512 bits
DHE_DSS Ephemeral DH with DSS signatures None DHE_DSS_EXPORT Ephemeral DH with DSS signatures DH = 512 bits DHE_RSA Ephemeral DH with RSA signatures None DHE_RSA_EXPORT Ephemeral DH with RSA signatures DH = 512 bits, RSA = none DH_anon Anonymous DH, no signatures None DH_anon_EXPORT Anonymous DH, no signatures DH = 512 bits
Dierks & Allen Standards Track [Page 61] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierks & Allen Standards Track [Page 61] RFC 2246 The TLS Protocol Version 1.0 January 1999
DH_DSS DH with DSS-based certificates None
DH_DSS_EXPORT DH with DSS-based certificates DH = 512 bits
DH_RSA DH with RSA-based certificates None
DH_RSA_EXPORT DH with RSA-based certificates DH = 512 bits,
RSA = none
NULL No key exchange N/A
RSA RSA key exchange None
RSA_EXPORT RSA key exchange RSA = 512 bits
DH_DSS DH with DSS-based certificates None DH_DSS_EXPORT DH with DSS-based certificates DH = 512 bits DH_RSA DH with RSA-based certificates None DH_RSA_EXPORT DH with RSA-based certificates DH = 512 bits, RSA = none NULL No key exchange N/A RSA RSA key exchange None RSA_EXPORT RSA key exchange RSA = 512 bits
Key size limit
The key size limit gives the size of the largest public key that
can be legally used for encryption in cipher suites that are
exportable.
Key size limit The key size limit gives the size of the largest public key that can be legally used for encryption in cipher suites that are exportable.
Key Expanded Effective IV Block
Cipher Type Material Key Material Key Bits Size Size
Key Expanded Effective IV Block Cipher Type Material Key Material Key Bits Size Size
NULL * Stream 0 0 0 0 N/A
IDEA_CBC Block 16 16 128 8 8
RC2_CBC_40 * Block 5 16 40 8 8
RC4_40 * Stream 5 16 40 0 N/A
RC4_128 Stream 16 16 128 0 N/A
DES40_CBC * Block 5 8 40 8 8
DES_CBC Block 8 8 56 8 8
3DES_EDE_CBC Block 24 24 168 8 8
_なし、ブロック16 16 128 8 8RC2_CBC_40*が5 16 40 8 8RC4_40*ストリーム5 16 40 0を妨げるというヌル*ストリーム0 0 0 0考えCBC、なし、RC4_128ストリーム16 16 128、0、なし、DES40_CBC*は5 8 40 8 8DES_CBCブロック8 8 56 8 8 3DES_EDE_CBCブロック24 24 168 8 8を妨げます。
* Indicates IsExportable is true.
* IsExportableが本当であることを示します。
Type
Indicates whether this is a stream cipher or a block cipher
running in CBC mode.
CBCモードへ駆け込んで、これがストリーム暗号かブロック暗号であることにかかわらずIndicatesをタイプしてください。
Key Material
The number of bytes from the key_block that are used for
generating the write keys.
主要なMaterial、主要な_ブロックからの生成するのに使用されるバイト数、キーを書いてください。
Expanded Key Material
The number of bytes actually fed into the encryption algorithm
バイト数が実際に暗号化アルゴリズムに与えた拡張Key Material
Effective Key Bits
How much entropy material is in the key material being fed into
the encryption routines.
有効なKey Bits Howいろいろな事のエントロピーの材料は暗号化ルーチンに入れられた主要な有形物中です。
IV Size
How much data needs to be generated for the initialization
vector. Zero for stream ciphers; equal to the block size for
block ciphers.
生成される多くのデータが初期化ベクトルに必要があるIV Size How。 ストリーム暗号のためのゼロ。 ブロックするブロック・サイズへの同輩は解きます。
Dierks & Allen Standards Track [Page 62] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[62ページ]RFC2246TLSプロトコルバージョン1999年1月1日
Block Size
The amount of data a block cipher enciphers in one chunk; a
block cipher running in CBC mode can only encrypt an even
multiple of its block size.
ブロック暗号が1つの塊で暗号化するデータの量のSizeを妨げてください。 CBCモードへ駆け込むブロック暗号はブロック・サイズの同等の倍数を暗号化できるだけです。
Hash Hash Padding
function Size Size
NULL 0 0
MD5 16 48
SHA 20 40
ハッシュHash Padding機能Size Size NULL0 0MD5 16 48SHA20 40
Dierks & Allen Standards Track [Page 63] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[63ページ]RFC2246TLSプロトコルバージョン1999年1月1日
D. Implementation Notes
D。 実装注意
The TLS protocol cannot prevent many common security mistakes. This section provides several recommendations to assist implementors.
TLSプロトコルは多くの共通の安全保障誤りを防ぐことができません。 このセクションは作成者を補助するといういくつかの推薦を提供します。
D.1. Temporary RSA keys
D.1。 一時的なRSAキー
US Export restrictions limit RSA keys used for encryption to 512 bits, but do not place any limit on lengths of RSA keys used for signing operations. Certificates often need to be larger than 512 bits, since 512-bit RSA keys are not secure enough for high-value transactions or for applications requiring long-term security. Some certificates are also designated signing-only, in which case they cannot be used for key exchange.
米国のExport制限は、暗号化に使用されるRSAキーを512ビットに制限しますが、署名操作に使用されるRSAキーの長さにどんな限界も置きません。 証明書は、しばしば512ビットより大きい必要があります、高値のトランザクションか長期のセキュリティを必要とするアプリケーションには、512ビットのRSAキーが十分安全でないので。 また、いくつかの証明書を署名だけに指定します、その場合、主要な交換にそれらを使用できません。
When the public key in the certificate cannot be used for encryption, the server signs a temporary RSA key, which is then exchanged. In exportable applications, the temporary RSA key should be the maximum allowable length (i.e., 512 bits). Because 512-bit RSA keys are relatively insecure, they should be changed often. For typical electronic commerce applications, it is suggested that keys be changed daily or every 500 transactions, and more often if possible. Note that while it is acceptable to use the same temporary key for multiple transactions, it must be signed each time it is used.
暗号化に証明書の公開鍵を使用できないとき、サーバは一時的なRSAキーに署名します。(次に、それは、交換されます)。 輸出向きのアプリケーションでは、一時的なRSAキーは最大の許容できる長さであるべきです(すなわち、512ビット)。 512ビットのRSAキーが比較的不安定であるので、しばしばそれらを変えるべきです。 典型的な電子商取引アプリケーションにおいて、できれば、しばしばキーが変えられた日刊誌か500のトランザクション毎と、その他であると示唆されます。 多数の取引に同じ一時的なキーを使用するのが許容できる間それが使用されている各回であるとそれに署名しなければならないことに注意してください。
RSA key generation is a time-consuming process. In many cases, a low-priority process can be assigned the task of key generation.
RSAキー生成は手間がかかったプロセスです。 多くの場合、低い優先度プロセスにキー生成に関するタスクを割り当てることができます。
Whenever a new key is completed, the existing temporary key can be replaced with the new one.
新しいキーが完成するときはいつも、既存の一時的なキーを新しい方に取り替えることができます。
D.2. Random Number Generation and Seeding
D.2。 乱数発生と種子
TLS requires a cryptographically-secure pseudorandom number generator (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs based on secure hash operations, most notably MD5 and/or SHA, are acceptable, but cannot provide more security than the size of the random number generator state. (For example, MD5-based PRNGs usually provide 128 bits of state.)
TLSは暗号で安全な擬似ランダム数のジェネレータ(PRNG)を必要とします。 PRNGsを設計して、種を蒔きながら、注意を中に入れなければなりません。 安全なハッシュ操作に基づくPRNGs(最も著しくMD5、そして/または、SHA)は許容できますが、乱数発生器状態のサイズより多くのセキュリティを提供できません。 (例えば、通常、MD5ベースのPRNGsは128ビットの状態を提供します。)
To estimate the amount of seed material being produced, add the number of bits of unpredictable information in each seed byte. For example, keystroke timing values taken from a PC compatible's 18.2 Hz timer provide 1 or 2 secure bits each, even though the total size of the counter value is 16 bits or more. To seed a 128-bit PRNG, one would thus require approximately 100 such timer values.
作り出される種子の材料の量を見積もるには、それぞれの種子バイトにおける、ビットの予測できない情報の数を加えてください。 例えば、コンパチブルPCの18.2Hzのタイマから取られたキーストロークタイミング値はそれぞれを1ビットか安全な2ビット提供します、対価の総サイズが16ビット以上ですが。 128ビットのPRNGに種を蒔くために、その結果、人はそのようなおよそ100のタイマ値を必要とするでしょう。
Dierks & Allen Standards Track [Page 64] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[64ページ]RFC2246TLSプロトコルバージョン1999年1月1日
Warning: The seeding functions in RSAREF and versions of BSAFE prior to
3.0 are order-independent. For example, if 1000 seed bits are
supplied, one at a time, in 1000 separate calls to the seed
function, the PRNG will end up in a state which depends only
on the number of 0 or 1 seed bits in the seed data (i.e.,
there are 1001 possible final states). Applications using
BSAFE or RSAREF must take extra care to ensure proper seeding.
This may be accomplished by accumulating seed bits into a
buffer and processing them all at once or by processing an
incrementing counter with every seed bit; either method will
reintroduce order dependence into the seeding process.
警告: RSAREFでの種子機能と3.0の前のBSAFEのバージョンはオーダーから独立しています。 例えば、一度に一つ1000の別々の呼び出しで1000種子ビットを種子機能に供給すると、PRNGは種子データの0か1つの種子ビットの数だけに依存する状態で終わるでしょう(すなわち、1001の可能な最終的な州があります)。 BSAFEかRSAREFを使用するアプリケーションは、適切な種子を確実にするために付加的な注意を払わなければなりません。 これはバッファとそれらを一気に処理することへの蓄積している種子ビットかあらゆる種子ビットで増加しているカウンタを処理することによって、達成されるかもしれません。 メソッドは種子プロセスをオーダーの依存に再紹介するでしょう。
D.3. Certificates and authentication
D.3。 証明書と認証
Implementations are responsible for verifying the integrity of certificates and should generally support certificate revocation messages. Certificates should always be verified to ensure proper signing by a trusted Certificate Authority (CA). The selection and addition of trusted CAs should be done very carefully. Users should be able to view information about the certificate and root CA.
実装は、証明書の保全について確かめるのに責任があって、一般に、証明書取消しがメッセージであるとサポートするべきです。 証明書は、信じられたCertificate Authority(カリフォルニア)で適切な署名を確実にするためにいつも確かめられるべきです。 信じられたCAsの選択と追加は非常に慎重に完了しているべきです。 ユーザは、証明書の情報を見て、カリフォルニアを根づかせることができるべきです。
D.4. CipherSuites
D.4。 CipherSuites
TLS supports a range of key sizes and security levels, including some which provide no or minimal security. A proper implementation will probably not support many cipher suites. For example, 40-bit encryption is easily broken, so implementations requiring strong security should not allow 40-bit keys. Similarly, anonymous Diffie- Hellman is strongly discouraged because it cannot prevent man-in- the-middle attacks. Applications should also enforce minimum and maximum key sizes. For example, certificate chains containing 512-bit RSA keys or signatures are not appropriate for high-security applications.
TLSは、さまざまな主要な規模とセキュリティがいいえを前提とするいくつかか最小量のセキュリティを含むレベルであると、サポートします。 適切な履行はたぶん多くの暗号スイートを支えないでしょう。 例えば、40ビットの暗号化が容易に壊されるので、強いセキュリティを必要とする実装は40ビットのキーを許容するべきではありません。 中の男性を防ぐことができないので同様に、匿名のディフィー・ヘルマンが強くがっかりしている、-、-、中央、攻撃。 また、アプリケーションは最小の、そして、最大の主要なサイズを実施するべきです。 例えば、高セキュリティアプリケーションには、512ビットのRSAキーを含む証明書チェーンか署名が適切ではありません。
Dierks & Allen Standards Track [Page 65] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[65ページ]RFC2246TLSプロトコルバージョン1999年1月1日
E. Backward Compatibility With SSL
E。 SSLとの後方の互換性
For historical reasons and in order to avoid a profligate consumption of reserved port numbers, application protocols which are secured by TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same connection port: for example, the https protocol (HTTP secured by SSL or TLS) uses port 443 regardless of which security protocol it is using. Thus, some mechanism must be determined to distinguish and negotiate among the various protocols.
歴史的な理由であり、TLS1.0、SSL3.0、およびSSL2.0によって保証されるアプリケーション・プロトコルはすべて、予約されたポートナンバーの放蕩な消費を避けるために頻繁に同じ接続ポートを共有します: 例えば、httpsプロトコル(SSLかTLSによって保証されたHTTP)はそれが使用しているどのセキュリティプロトコルにかかわらずポート443を使用するか。 したがって、何らかのメカニズムが、様々なプロトコルの中で区別して、交渉するのにおいて決定しているに違いありません。
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
should send client hello messages using the SSL 3.0 record format and
client hello structure, sending {3, 1} for the version field to note
that they support TLS 1.0. If the server supports only SSL 3.0, it
will respond with an SSL 3.0 server hello; if it supports TLS, with a
TLS server hello. The negotiation then proceeds as appropriate for
the negotiated protocol.
TLSバージョン1.0とSSL3.0は非常に同様です。 したがって、両方をサポートするのは簡単です。 3.0のサーバをSSLと交渉したがっているTLSクライアントがこんにちは、SSL3.0レコード形式を使用するメッセージとクライアントをクライアントに送るべきである、こんにちは、バージョン分野が、TLSが1.0であるとサポートすることに注意するように3、1を送って、構造化します。 サーバがSSL3.0だけをサポートすると、SSL3.0サーバで応じる、こんにちは。 それは、TLSとTLSがサーバであるとサポートします。こんにちは。 そして、交渉は交渉されたプロトコルのために適宜続きます。
Similarly, a TLS server which wishes to interoperate with SSL 3.0
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
has a version field of {3, 0}, denoting that this client does not
support TLS.
同様に、SSLと共に3.0人のクライアントを共同利用したがっているTLSサーバがSSL3.0クライアントを受け入れるべきである、こんにちは、SSL3.0サーバで通信して、応じる、こんにちは、SSL3.0クライアントである、こんにちは、どれに、受け取って、このクライアントがTLSをサポートしないのを指示して、3、0のバージョン分野がありますか?
Whenever a client already knows the highest protocol known to a server (for example, when resuming a session), it should initiate the connection in that native protocol.
クライアントが既にサーバに知られている中で最も高いプロトコルを知る(例えばセッションを再開するとき)ときはいつも、それはその固有のプロトコルにおける接続を開始するべきです。
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 either client hello format if they wish to support SSL 2.0 clients on the same connection port. The only deviations from the Version 2.0 specification are the ability to specify a version with a value of three and the support for more ciphering types in the CipherSpec.
TLS1.0に、SSLバージョンが2.0のサーバであるとサポートするクライアントはこんにちは、SSLバージョン2.0クライアントメッセージ[SSL2]を送らなければなりません。 TLSサーバがどちらのクライアントも受け入れるべきである、こんにちは、同じ接続ポートの上の2.0人のクライアントをSSLにサポートしたいなら、フォーマットします。 唯一の逸脱、バージョンから、2.0仕様は3の値でバージョンを指定する能力であり、もう少し解くサポートは中でCipherSpecをタイプします。
Warning: The ability to send Version 2.0 client hello messages will be
phased out with all due haste. Implementors should make every
effort to move forward as quickly as possible. Version 3.0
provides better mechanisms for moving to newer versions.
警告: バージョン2.0クライアントを送る能力、こんにちは、メッセージはすべての当然の迅速で段階的に廃止されるでしょう。 作成者は、できるだけ急速に前方へ動くためにあらゆる努力するべきです。 バージョン3.0は、より新しいバージョンに移行するのにより良いメカニズムを提供します。
The following cipher specifications are carryovers from SSL Version 2.0. These are assumed to use RSA for key exchange and authentication.
以下の暗号仕様はSSLバージョン2.0からの繰越しです。 これらが主要な交換と認証にRSAを使用すると思われます。
V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 };
V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };
0×01、0×00、_MD5とV2CipherSpec TLS_RC4_128_=0×80。 0×02、0×00、_MD5とV2CipherSpec TLS_RC4_128_EXPORT40_=0×80。 V2CipherSpec TLS0×03、0×00、__MD5とRC2_CBC_128_CBC_=0x80。
Dierks & Allen Standards Track [Page 66] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[66ページ]RFC2246TLSプロトコルバージョン1999年1月1日
V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
= { 0x04,0x00,0x80 };
V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };
V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };
V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_は_MD5と共に0×04、0×00、0×80と等しいです。 0×05、0×00、__MD5とV2CipherSpec TLS_考え128_CBC_=0×80。 0×06、0×00、_MD5とV2CipherSpec TLS_デス_64_CBC_=0×40。 V2CipherSpec TLS_デス_192_EDE3_CBC_は_MD5と共に0×07、0×00、0xC0と等しいです。
Cipher specifications native to TLS can be included in Version 2.0 client hello messages using the syntax below. Any V2CipherSpec element with its first byte equal to zero will be ignored by Version 2.0 servers. Clients sending any of the above V2CipherSpecs should also include the TLS equivalent (see Appendix A.5):
バージョン2.0クライアントにTLS固有の暗号仕様を含むことができる、こんにちは、以下の構文を使用するメッセージ。 ゼロへの最初のバイト同輩がいるどんなV2CipherSpec要素もバージョン2.0サーバによって無視されるでしょう。 また、上のV2CipherSpecsのいずれも送るクライアントはTLS同等物を入れるべきです(Appendix A.5を見てください):
V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
V2CipherSpec(TLS名を見る)は0×00、CipherSuiteと等しいです。
E.1. Version 2 client hello
E.1。 バージョン2クライアント、こんにちは。
The Version 2.0 client hello message is presented below using this document's presentation model. The true definition is still assumed to be the SSL Version 2.0 specification.
バージョン2.0クライアント、こんにちは、このドキュメントのプレゼンテーションモデルを使用する下にメッセージは提示されます。 本当の定義はSSLバージョン2.0仕様であるとまだ思われています。
uint8 V2CipherSpec[3];
uint8 V2CipherSpec[3]。
struct {
uint8 msg_type;
Version version;
uint16 cipher_spec_length;
uint16 session_id_length;
uint16 challenge_length;
V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
opaque session_id[V2ClientHello.session_id_length];
Random challenge;
} V2ClientHello;
struct uint8 msg_タイプ; バージョンバージョン; uint16暗号_仕様_の長さ; uint16セッション_イド_の長さ; uint16の挑戦_長さ; V2CipherSpec暗号_仕様[V2ClientHello.cipher_仕様_の長さ]; 不明瞭なセッション_イド[V2ClientHello.session_イド_の長さ]; 無作為の挑戦;V2ClientHello。
msg_type
This field, in conjunction with the version field, identifies a
version 2 client hello message. The value should be one (1).
タイプThisがバージョン分野に関連してさばくmsg_がバージョン2クライアントを特定する、こんにちは、メッセージ。 値は1つ(1)であるべきである。
version
The highest version of the protocol supported by the client
(equals ProtocolVersion.version, see Appendix A.1).
クライアント(同輩ProtocolVersion.version、Appendix A.1を見る)でプロトコルの最も高いバージョンがサポートしたバージョン。
cipher_spec_length
This field is the total length of the field cipher_specs. It
cannot be zero and must be a multiple of the V2CipherSpec length
(3).
Thisがさばく暗号_仕様_の長さは分野暗号_仕様の全長です。 それは、ゼロであることができなく、V2CipherSpecの長さ(3)の倍数であるに違いありません。
Dierks & Allen Standards Track [Page 67] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[67ページ]RFC2246TLSプロトコルバージョン1999年1月1日
session_id_length
This field must have a value of either zero or 16. If zero, the
client is creating a new session. If 16, the session_id field
will contain the 16 bytes of session identification.
Thisがさばくセッション_イド_の長さはゼロか16のどちらかの値を持たなければなりません。 ゼロであるなら、クライアントは新しいセッションを作成しています。 16であるなら、セッション_イド分野は16バイトのセッション識別を含むでしょう。
challenge_length
The length in bytes of the client's challenge to the server to
authenticate itself. This value must be 32.
_クライアントのバイトで表現される長さがそれ自体を認証するのをサーバに挑む長さに挑戦してください。 この値は32でなければなりません。
cipher_specs
This is a list of all CipherSpecs the client is willing and able
to use. There must be at least one CipherSpec acceptable to the
server.
暗号_仕様Thisはクライアントが望んでいて使用できるすべてのCipherSpecsのリストです。 サーバに許容できる少なくとも1CipherSpecがあるに違いありません。
session_id
If this field's length is not zero, it will contain the
identification for a session that the client wishes to resume.
このフィールドの長さのセッション_イドIfがゼロでない、それはセッションのためのクライアントが再開したがっている識別を含むでしょう。
challenge
The client challenge to the server for the server to identify
itself is a (nearly) arbitrary length random. The TLS server will
right justify the challenge data to become the ClientHello.random
data (padded with leading zeroes, if necessary), as specified in
this protocol specification. If the length of the challenge is
greater than 32 bytes, only the last 32 bytes are used. It is
legitimate (but not necessary) for a V3 server to reject a V2
ClientHello that has fewer than 16 bytes of challenge data.
クライアントが、サーバがそれ自体を特定するのをサーバに挑む挑戦はa(ほとんど)任意の長さの無作為です。 TLSサーバはClientHello.randomデータ(主なゼロで、必要なら、そっと歩く)になるように挑戦データを右詰めに望んでいます、このプロトコル仕様で指定されるように。 挑戦の長さが32バイト以上であるなら、最後の32バイトだけが使用されています。 V3サーバが16バイト未満の挑戦データを持っているV2 ClientHelloを拒絶するのは、正統、そして、(必要でない。)です。
Note: Requests to resume a TLS session should use a TLS client hello.
以下に注意してください。 TLSセッションを再開するという要求はTLSクライアントを使用するべきです。こんにちは。
E.2. Avoiding man-in-the-middle version rollback
E.2。 中央の男性バージョンロールバックを避けます。
When TLS clients fall back to Version 2.0 compatibility mode, they should use special PKCS #1 block formatting. This is done so that TLS servers will reject Version 2.0 sessions with TLS-capable clients.
TLSクライアント秋が2.0互換性モードをバージョンに支持するとき、彼らは特別なPKCS#1ブロック形式を使用するべきです。 TLSサーバがTLS有能なクライアントとのバージョン2.0セッションを拒絶するように、これをします。
When TLS clients are in Version 2.0 compatibility mode, they set the right-hand (least-significant) 8 random bytes of the PKCS padding (not including the terminal null of the padding) for the RSA encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY to 0x03 (the other padding bytes are random). After decrypting the ENCRYPTED-KEY-DATA field, servers that support TLS should issue an error if these eight padding bytes are 0x03. Version 2.0 servers receiving blocks padded in this manner will proceed normally.
TLSであるときに、バージョンにはクライアントがいます。2.0互換性モード、彼らは右手(最も最少に重要な)の無作為の8バイトのPKCSがCLIENT-MASTER-KEYのENCRYPTED-KEY-DATA分野のRSA暗号化のために0×03にそっと歩く(詰め物の端末のヌルを含んでいない)ように設定します(他の詰め物バイトは無作為です)。 ENCRYPTED-KEY-DATA分野を解読した後に、TLSをサポートするサーバはこれらの8詰め物バイトが0×03であるなら誤りを発行するべきです。 通常、この様に水増しされたブロックを受け取るバージョン2.0サーバが続くでしょう。
Dierks & Allen Standards Track [Page 68] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[68ページ]RFC2246TLSプロトコルバージョン1999年1月1日
F. Security analysis
F。 証券分析
The TLS protocol is designed to establish a secure connection between a client and a server communicating over an insecure channel. This document makes several traditional assumptions, including that attackers have substantial computational resources and cannot obtain secret information from sources outside the protocol. Attackers are assumed to have the ability to capture, modify, delete, replay, and otherwise tamper with messages sent over the communication channel. This appendix outlines how TLS has been designed to resist a variety of attacks.
TLSプロトコルは、不安定なチャンネルの上に交信しながらクライアントとサーバの間で安全な接続を証明するように設計されています。 このドキュメントがいくつかの伝統的な仮定をして、それを含んでいて、攻撃者は、かなりのコンピュータのリソースを持って、ソースからプロトコルの外で秘密の情報を得ることができません。 攻撃者にはキャプチャして変更して削除して再演してそうでなければ通信チャネルの上に送られたメッセージをいじる能力があると思われます。 この付録はTLSがさまざまな攻撃に抵抗するようにどう設計されているかを概説します。
F.1. Handshake protocol
F.1。 握手プロトコル
The handshake protocol is responsible for selecting a CipherSpec and generating a Master Secret, which together comprise the primary cryptographic parameters associated with a secure session. The handshake protocol can also optionally authenticate parties who have certificates signed by a trusted certificate authority.
握手プロトコルはCipherSpecを選択するのに原因となります、そして、Master Secretを生成して、どれが安全なセッションに関連しているプライマリ暗号のパラメタを一緒に包括しますか? また、握手プロトコルは任意に信じられた認証局で証明書を署名させるパーティーを認証できます。
F.1.1. Authentication and key exchange
F.1.1。 認証と主要な交換
TLS supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. Whenever the server is authenticated, the channel is secure against man-in-the-middle attacks, but completely anonymous sessions are inherently vulnerable to such attacks. Anonymous servers cannot authenticate clients. If the server is authenticated, its certificate message must provide a valid certificate chain leading to an acceptable certificate authority. Similarly, authenticated clients must supply an acceptable certificate to the server. Each party is responsible for verifying that the other's certificate is valid and has not expired or been revoked.
TLSは3つの認証モードをサポートします: 双方、非認証されたクライアント、および総匿名によるサーバ証明の認証。 サーバが認証されるときはいつも、チャンネルは介入者攻撃に対して安全ですが、完全に匿名のセッションは本来そのような攻撃に被害を受け易いです。 匿名のサーバはクライアントを認証できません。 サーバが認証されるなら、証明書メッセージは許容できる認証局に通じる有効な証明書チェーンを提供しなければなりません。 同様に、認証されたクライアントは許容できる証明書をサーバに供給しなければなりません。各当事者は、もう片方の証明書が有効であることを確かめるのに責任があって、吐き出されるか、または取り消されていません。
The general goal of the key exchange process is to create a pre_master_secret known to the communicating parties and not to attackers. The pre_master_secret will be used to generate the master_secret (see Section 8.1). The master_secret is required to generate the certificate verify and finished messages, encryption keys, and MAC secrets (see Sections 7.4.8, 7.4.9 and 6.3). By sending a correct finished message, parties thus prove that they know the correct pre_master_secret.
主要な交換プロセスの一般的な目標は攻撃者にとって知られるのではなく、交信パーティーにおいて知られている前_のマスター_秘密を作成することです。 前_のマスター_秘密は、マスター_秘密を生成するのに使用されるでしょう(セクション8.1を見てください)。 証明書を作る_秘密が必要であるマスターがメッセージ、暗号化キー、およびMAC秘密を確かめて、完成させた、(セクション7.4.8、7.4を見てください、.9と6.3) 正しい終わっているメッセージを送ることによって、その結果、パーティーは、彼らが正しい前_のマスター_秘密を知っていると立証します。
F.1.1.1. Anonymous key exchange
F.1.1.1。 匿名の主要な交換
Completely anonymous sessions can be established using RSA or Diffie-Hellman for key exchange. With anonymous RSA, the client encrypts a pre_master_secret with the server's uncertified public key
主要な交換にRSAかディフィー-ヘルマンを使用することで完全に匿名のセッションを確立できます。 匿名のRSAと共に、クライアントはサーバの非公認された公開鍵で前_のマスター_秘密を暗号化します。
Dierks & Allen Standards Track [Page 69] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[69ページ]RFC2246TLSプロトコルバージョン1999年1月1日
extracted from the server key exchange message. The result is sent in a client key exchange message. Since eavesdroppers do not know the server's private key, it will be infeasible for them to decode the pre_master_secret. (Note that no anonymous RSA Cipher Suites are defined in this document).
サーバの主要な交換メッセージから、抽出されます。 クライアントの主要な交換メッセージで結果を送ります。 立ち聞きする者がサーバの秘密鍵を知らないので、彼らが前_のマスター_秘密を解読するのは、実行不可能でしょう。 (どんな匿名のRSA Cipher Suitesも本書では定義されないことに注意します。)
With Diffie-Hellman, the server's public parameters are contained in the server key exchange message and the client's are sent in the client key exchange message. Eavesdroppers who do not know the private values should not be able to find the Diffie-Hellman result (i.e. the pre_master_secret).
ディフィー-ヘルマンと共に、サーバの主要な交換メッセージにサーバの公共のパラメタを含んでいます、そして、クライアントの主要な交換メッセージでクライアントを送りました。 個人的な値を知らない立ち聞きする者は、ディフィー-ヘルマンが結果(すなわち、前_のマスター_秘密)であることがわかることができないべきです。
Warning: Completely anonymous connections only provide protection
against passive eavesdropping. Unless an independent tamper-
proof channel is used to verify that the finished messages
were not replaced by an attacker, server authentication is
required in environments where active man-in-the-middle
attacks are a concern.
警告: 完全に匿名の接続は受け身の盗聴に対する保護を提供するだけです。 独立しているタンパー証拠チャンネルが終わっているメッセージが攻撃者に取り替えられなかったことを確かめるのに使用されない場合、サーバ証明が中央の活発な男性攻撃が関心である環境で必要です。
F.1.1.2. RSA key exchange and authentication
F.1.1.2。 RSAの主要な交換と認証
With RSA, key exchange and server authentication are combined. The public key may be either contained in the server's certificate or may be a temporary RSA key sent in a server key exchange message. When temporary RSA keys are used, they are signed by the server's RSA or DSS certificate. The signature includes the current ClientHello.random, so old signatures and temporary keys cannot be replayed. Servers may use a single temporary RSA key for multiple negotiation sessions.
RSAと、主要な交換とサーバ証明は結合されています。 公開鍵は、サーバの証明書に含まれるかもしれないか、サーバの主要な交換メッセージで送られた一時的なRSAキーであるかもしれません。 一時的なRSAキーが使用されているとき、それらはサーバのRSAかDSS証明書によって署名されます。 署名が現在のClientHello.randomを含んでいるので、古い署名と一時的なキーを再演できません。 サーバは複数の交渉セッションのために主要な独身の一時的なRSAを使用するかもしれません。
Note: The temporary RSA key option is useful if servers need large
certificates but must comply with government-imposed size limits
on keys used for key exchange.
以下に注意してください。 一時的なRSA主要なオプションは、役に立ちますが、サーバの必要性大きい証明書ですが、主要な交換に使用されるキーの上に政府によって課されたサイズ限界に従わなければなりません。
After verifying the server's certificate, the client encrypts a pre_master_secret with the server's public key. By successfully decoding the pre_master_secret and producing a correct finished message, the server demonstrates that it knows the private key corresponding to the server certificate.
サーバの証明書について確かめた後に、クライアントはサーバの公開鍵で前_のマスター_秘密を暗号化します。 首尾よく前_のマスター_秘密を解読して、正しい終わっているメッセージを出すことによって、サーバは、サーバ証明書に対応する秘密鍵を知っているのを示します。
When RSA is used for key exchange, clients are authenticated using the certificate verify message (see Section 7.4.8). The client signs a value derived from the master_secret and all preceding handshake messages. These handshake messages include the server certificate, which binds the signature to the server, and ServerHello.random, which binds the signature to the current handshake process.
主要な交換、クライアントが証明書を使用することで認証されるので使用されるRSAがメッセージについて確かめるとき(セクション7.4.8を見てください)。 クライアントは、マスター_秘密から得られた値とすべての前の握手がメッセージであると署名します。 これらの握手メッセージはサーバ証明書とServerHello.randomを含んでいます。(証明書はサーバに署名を縛ります)。(ServerHello.randomは現在の握手プロセスに署名を縛ります)。
Dierks & Allen Standards Track [Page 70] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[70ページ]RFC2246TLSプロトコルバージョン1999年1月1日
F.1.1.3. Diffie-Hellman key exchange with authentication
F.1.1.3。 認証によるディフィー-ヘルマンの主要な交換
When Diffie-Hellman key exchange is used, the server can either supply a certificate containing fixed Diffie-Hellman parameters or can use the server key exchange message to send a set of temporary Diffie-Hellman parameters signed with a DSS or RSA certificate. Temporary parameters are hashed with the hello.random values before signing to ensure that attackers do not replay old parameters. In either case, the client can verify the certificate or signature to ensure that the parameters belong to the server.
ディフィー-ヘルマンの主要な交換が使用されているとき、サーバは、固定ディフィー-ヘルマンパラメタを含む証明書を提供できるか、またはDSSかRSA証明書を契約された1セットの一時的なディフィー-ヘルマンパラメタを送るのにサーバの主要な交換メッセージを使用できます。 攻撃者が古いパラメタを再演しないのを保証するために署名する前のhello.random値に従って、一時的なパラメタは論じ尽くされます。 どちらの場合ではも、クライアントは、パラメタがサーバに属すのを保証するために証明書か署名について確かめることができます。
If the client has a certificate containing fixed Diffie-Hellman parameters, its certificate contains the information required to complete the key exchange. Note that in this case the client and server will generate the same Diffie-Hellman result (i.e., pre_master_secret) every time they communicate. To prevent the pre_master_secret from staying in memory any longer than necessary, it should be converted into the master_secret as soon as possible. Client Diffie-Hellman parameters must be compatible with those supplied by the server for the key exchange to work.
クライアントに固定ディフィー-ヘルマンパラメタを含む証明書があるなら、証明書は主要な交換を終了するのに必要である情報を含んでいます。 この場合彼らが交信するときはいつも、クライアントとサーバが、同じディフィー-ヘルマンが結果(すなわち、前_のマスター_秘密)であると生成することに注意してください。 前_のマスター_秘密がもうメモリに残っているのを防ぐために、それはできるだけ早く、必要とするよりマスター_秘密に変換されるべきです。 クライアントディフィー-ヘルマンパラメタは主要な交換が扱うサーバから供給するそれらと互換性があるに違いありません。
If the client has a standard DSS or RSA certificate or is unauthenticated, it sends a set of temporary parameters to the server in the client key exchange message, then optionally uses a certificate verify message to authenticate itself.
クライアントが標準のDSSかRSA証明書を持っているか、または非認証されるなら、1セットの一時的なパラメタをクライアントの主要な交換メッセージにおけるサーバに送って、次に、任意に、証明書がメッセージについて確かめる用途はそれ自体を認証します。
F.1.2. Version rollback attacks
F.1.2。 バージョンロールバック攻撃
Because TLS includes substantial improvements over SSL Version 2.0, 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 TLS- capable parties use an SSL 2.0 handshake.
TLSがSSLバージョン2.0の上の実質的な改善を含んでいるので、攻撃者はTLS有能なクライアントとサーバをバージョン2.0へ後ろへ下がらせようとするかもしれません。 この攻撃が起こることができる、(唯一、)、2回のTLSの有能なパーティーがSSL2.0握手を使用します。
Although the solution using non-random PKCS #1 block type 2 message padding is inelegant, it provides a reasonably secure way for Version 3.0 servers to detect the attack. This solution is not secure against attackers who can brute force the key and substitute a new ENCRYPTED-KEY-DATA message containing the same key (but with normal padding) before the application specified wait threshold has expired. Parties concerned about attacks of this scale should not be using 40-bit encryption keys anyway. Altering the padding of the least- significant 8 bytes of the PKCS padding does not impact security for the size of the signed hashes and RSA key lengths used in the protocol, since this is essentially equivalent to increasing the input block size by 8 bytes.
ソリューションの使用の非無作為のPKCS#1、はタイプ2を妨げますが、メッセージ詰め物は優美ではありません、とそれが攻撃を検出するために3.0のサーバをバージョンに合理的に安全な道で前提とします。 このソリューションはアプリケーションの指定された待ち敷居が期限が切れる前に同じキー(しかし通常の詰め物で)を含む主要で代わりのa新しいENCRYPTED-KEY-DATAが通信させる馬鹿力をそうすることができる攻撃者に対して安全ではありません。 このスケールの攻撃に関して心配している党はとにかく40ビットの暗号化キーを使用するべきではありません。 PKCS詰め物の最少重要な8バイトの詰め物を変更するのはプロトコルに使用される署名しているハッシュとRSAキー長のサイズのためにセキュリティに影響を与えません、これが本質的には入力ブロック・サイズを8バイト増強するのに同等であるので。
Dierks & Allen Standards Track [Page 71] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[71ページ]RFC2246TLSプロトコルバージョン1999年1月1日
F.1.3. Detecting attacks against the handshake protocol
F.1.3。 握手プロトコルに対して攻撃を検出します。
An attacker might try to influence the handshake exchange to make the parties select different encryption algorithms than they would normally choose. Because many implementations will support 40-bit exportable encryption and some may even support null encryption or MAC algorithms, this attack is of particular concern.
攻撃者は、通常、選ぶだろうよりパーティーが握手交換で異なった暗号化アルゴリズムを選択するのに影響を及ぼそうとするかもしれません。 ヌル暗号化かMACがアルゴリズムであると多くの実装が40ビットの輸出向きの暗号化をサポートして、或るものが、サポートさえするかもしれないので、この攻撃は特別の関心のものです。
For this attack, an attacker must actively change one or more handshake messages. If this occurs, the client and server will compute different values for the handshake message hashes. As a result, the parties will not accept each others' finished messages. Without the master_secret, the attacker cannot repair the finished messages, so the attack will be discovered.
この攻撃のために、攻撃者は活発に1つ以上の握手メッセージを変えなければなりません。 これが起こると、クライアントとサーバは握手メッセージハッシュのために異価を計算するでしょう。 その結果、パーティーはそれぞれ他のものの終わっているメッセージを受け入れないでしょう。 マスター_秘密がなければ、攻撃者が終わっているメッセージを修理できないので、攻撃は発見されるでしょう。
F.1.4. Resuming sessions
F.1.4。 再開します。
When a connection is established by resuming a session, new ClientHello.random and ServerHello.random values are hashed with the session's master_secret. Provided that the master_secret has not been compromised and that the secure hash operations used to produce the encryption keys and MAC secrets are secure, the connection should be secure and effectively independent from previous connections. Attackers cannot use known encryption keys or MAC secrets to compromise the master_secret without breaking the secure hash operations (which use both SHA and MD5).
接続がセッション、新しいClientHello.random、およびServerHello.randomを再開することによって確立されるとき、値はセッションのマスター_秘密で論じ尽くされます。 マスター_秘密が感染されていなくて、安全が操作を論じ尽くすのが以前はよく暗号化キーを生産していて、MAC秘密が安全であれば、接続は、安全であって、事実上、前の接続によって独立しているべきです。 攻撃者は、安全なハッシュ操作(SHAとMD5の両方を使用する)を壊さないでマスター_秘密に感染するのに知られている暗号化キーかMAC秘密を使用できません。
Sessions cannot be resumed unless both the client and server agree. If either party suspects that the session may have been compromised, or that certificates may have expired or been revoked, it should force a full handshake. An upper limit of 24 hours is suggested for session ID lifetimes, since an attacker who obtains a master_secret may be able to impersonate the compromised party until the corresponding session ID is retired. Applications that may be run in relatively insecure environments should not write session IDs to stable storage.
クライアントとサーバの両方が同意しないなら、セッションを再開できません。 何れの当事者が、証明書がセッションが感染されたか、吐き出されたか、または取り消されたかもしれないと疑うなら、それは完全な握手を強制するべきです。 24時間の上限はセッションID生涯示されます、対応するセッションIDが回収されるまでマスター_秘密を得る攻撃者が感染しているパーティーをまねることができるかもしれないので。 比較的不安定な環境に立候補することであるかもしれないアプリケーションはセッションIDを安定貯蔵まで書くべきではありません。
F.1.5. MD5 and SHA
F.1.5。 MD5とSHA
TLS uses hash functions very conservatively. Where possible, both MD5 and SHA are used in tandem to ensure that non-catastrophic flaws in one algorithm will not break the overall protocol.
TLSは非常に保守的にハッシュ関数を使用します。 可能であるところでは、MD5とSHAの両方が、1つのアルゴリズムによる非壊滅的な欠点が総合的なプロトコルを破らないのを保証するのに2人乗り自転車で使用されます。
F.2. Protecting application data
F.2。 アプリケーションデータを保護します。
The master_secret is hashed with the ClientHello.random and ServerHello.random to produce unique data encryption keys and MAC secrets for each connection.
マスター_秘密は、各接続のためにユニークなデータ暗号化キーとMAC秘密を作り出すためにClientHello.randomとServerHello.randomと共に論じ尽くされます。
Dierks & Allen Standards Track [Page 72] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[72ページ]RFC2246TLSプロトコルバージョン1999年1月1日
Outgoing data is protected with a MAC before transmission. To prevent message replay or modification attacks, the MAC is computed from the MAC secret, the sequence number, the message length, the message contents, and two fixed character strings. The message type field is necessary to ensure that messages intended for one TLS Record Layer client are not redirected to another. The sequence number ensures that attempts to delete or reorder messages will be detected. Since sequence numbers are 64-bits long, they should never overflow. Messages from one party cannot be inserted into the other's output, since they use independent MAC secrets. Similarly, the server-write and client-write keys are independent so stream cipher keys are used only once.
発信データはトランスミッションの前のMACと共に保護されます。 メッセージ再生か変更攻撃を防ぐために、MACはMAC秘密、一連番号、メッセージ長、メッセージ内容、および固定キャラクタが結ぶ2から計算されます。 メッセージタイプ分野が、1人のTLS Record Layerクライアントのために意図するメッセージが別のものに向け直されないのを保証するのに必要です。 一連番号は、削除する試みか追加注文メッセージが検出されるのを確実にします。 長い間一連番号が64ビットであるので、それらは決してあふれるべきではありません。 独立しているMAC秘密を使用するので、1回のパーティーからのメッセージをもう片方の出力に挿入できません。 同様に、サーバで書いていてクライアントと同じくらい書いているキーが独立しているので、ストリーム暗号キーはかつてだけ使用されます。
If an attacker does break an encryption key, all messages encrypted with it can be read. Similarly, compromise of a MAC key can make message modification attacks possible. Because MACs are also encrypted, message-alteration attacks generally require breaking the encryption algorithm as well as the MAC.
攻撃者が暗号化キーを壊すなら、それで暗号化されたすべてのメッセージは読むことができます。 同様に、MACキーの感染で、メッセージ変更攻撃は可能になる場合があります。 また、MACsが暗号化されるので、一般に、メッセージ変更攻撃は、MACと同様に暗号化アルゴリズムを破るのを必要とします。
Note: MAC secrets may be larger than encryption keys, so messages can
remain tamper resistant even if encryption keys are broken.
以下に注意してください。 MAC秘密が暗号化キーより大きいかもしれないので、暗号化キーが壊れても、メッセージは耐タンパー性のままで残ることができます。
F.3. Final notes
F.3。 最後通達
For TLS to be able to provide a secure connection, both the client and server systems, keys, and applications must be secure. In addition, the implementation must be free of security errors.
TLSが安全な接続を提供できるように、クライアント、サーバシステム、キー、およびアプリケーションの両方が安全でなければなりません。 さらに、実装には、セキュリティ誤りがあってはいけません。
The system is only as strong as the weakest key exchange and authentication algorithm supported, and only trustworthy cryptographic functions should be used. Short public keys, 40-bit bulk encryption keys, and anonymous servers should be used with great caution. Implementations and users must be careful when deciding which certificates and certificate authorities are acceptable; a dishonest certificate authority can do tremendous damage.
システムはサポートされた最も弱い主要な交換と単に認証アルゴリズムと同じくらい強いです、そして、信頼できる暗号の機能だけが使用されるべきです。 短い公開鍵、40ビットの大量の暗号化キー、および匿名のサーバは十分な注意と共に使用されるべきです。 どの証明書と認証局が許容できるかを決めるとき、実装とユーザは慎重であるに違いありません。 不正直な認証局は物凄い損害を与えることができます。
Dierks & Allen Standards Track [Page 73] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[73ページ]RFC2246TLSプロトコルバージョン1999年1月1日
G. Patent Statement
G。 特許声明
Some of the cryptographic algorithms proposed for use in this protocol have patent claims on them. In addition Netscape Communications Corporation has a patent claim on the Secure Sockets Layer (SSL) work that this standard is based on. The Internet Standards Process as defined in RFC 2026 requests that a statement be obtained from a Patent holder indicating that a license will be made available to applicants under reasonable terms and conditions.
このプロトコルにおける使用のために提案された暗号アルゴリズムのいくつかには、それらの特許請求の範囲があります。 追加ネットスケープ社では、この規格が基づいているセキュリティソケットレイヤー(SSL)仕事の特許請求の範囲を持っています。 RFC2026で定義されるインターネットStandards Processは、声明が無理のない条件と条件のもとでライセンスを利用可能にするのを示すPatent所有者から応募者まで得られるよう要求します。
The Massachusetts Institute of Technology has granted RSA Data Security, Inc., exclusive sub-licensing rights to the following patent issued in the United States:
マサチューセッツ工科大学はRSA Data Security Inc.を与えました、と以下の特許への独占的なサブ認可している権利は合衆国で発行しました:
Cryptographic Communications System and Method ("RSA"), No.
4,405,829
暗号の通信網とメソッド("RSA")、いいえ、440万5829
Netscape Communications Corporation has been issued the following patent in the United States:
合衆国で以下の特許をネットスケープ社に発行しました:
Secure Socket Layer Application Program Apparatus And Method
("SSL"), No. 5,657,390
Secure Socket Layerアプリケーション・プログラム装置とメソッド("SSL")、いいえ、565万7390
Netscape Communications has issued the following statement:
ネットスケープ・コミュニケーションズは以下の声明を発行しました:
Intellectual Property Rights
知的所有権
Secure Sockets Layer
セキュリティソケットレイヤー
The United States Patent and Trademark Office ("the PTO")
recently issued U.S. Patent No. 5,657,390 ("the SSL Patent") to
Netscape for inventions described as Secure Sockets Layers
("SSL"). The IETF is currently considering adopting SSL as a
transport protocol with security features. Netscape encourages
the royalty-free adoption and use of the SSL protocol upon the
following terms and conditions:
米国特許商標局(「PTO」)は最近、セキュリティソケットレイヤー("SSL")として記述された発明品のために、米国特許番号5,657,390(「SSL特許」)をNetscapeに発行しました。 IETFは、現在、SSLを採用するのが、セキュリティ機能があるトランスポート・プロトコルであるとみなしています。 Netscapeは以下の条件でのSSLプロトコルのロイヤリティのいらない採用と使用を奨励します:
* If you already have a valid SSL Ref license today which
includes source code from Netscape, an additional patent
license under the SSL patent is not required.
* あなたが有効なSSL RefにNetscapeからソースコードを含んでいる今日を既に認可させるなら、SSL特許の下における追加特許ライセンスは必要ではありません。
* If you don't have an SSL Ref license, you may have a royalty
free license to build implementations covered by the SSL
Patent Claims or the IETF TLS specification provided that you
do not to assert any patent rights against Netscape or other
companies for the implementation of SSL or the IETF TLS
recommendation.
* SSL Refライセンスがないなら、あなたはあなたがSSLの実装かIETF TLS推薦のためにどんな特許もNetscapeに対する権利か他の会社であると断言しないようにすればSSL PatentクレームかIETF TLS仕様でカバーされた実装を築き上げるロイヤルティフリーなライセンスを持つことができます。
Dierks & Allen Standards Track [Page 74] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[74ページ]RFC2246TLSプロトコルバージョン1999年1月1日
What are "Patent Claims":
「特許請求の範囲」は何です:
Patent claims are claims in an issued foreign or domestic patent
that:
特許請求の範囲は発行された外国の、または、国内の特許で以下のことというクレームです。
1) must be infringed in order to implement methods or build
products according to the IETF TLS specification; or
メソッドを実装するか、またはIETF TLS仕様通りに製品を造るために1)を侵害しなければなりません。 または
2) patent claims which require the elements of the SSL patent
claims and/or their equivalents to be infringed.
2) SSL特許請求の範囲、そして/または、それらの同等物の要素が侵害されるのを必要とするクレームの特許をとってください。
The Internet Society, Internet Architecture Board, Internet Engineering Steering Group and the Corporation for National Research Initiatives take no position on the validity or scope of the patents and patent applications, nor on the appropriateness of the terms of the assurance. The Internet Society and other groups mentioned above have not made any determination as to any other intellectual property rights which may apply to the practice of this standard. Any further consideration of these matters is the user's own responsibility.
インターネット協会、インターネット・アーキテクチャ委員会、インターネットEngineering Steering Group、およびNational Research Initiativesのための社は特許と特許出願の正当性か範囲の上と、そして、保証に関する諸条件の適切さの上の立場を全く取りません。 前記のようにインターネット協会と他のグループはこの規格の習慣に申請されるかもしれないいかなる他の知的所有権に関しても少しの決断もしていません。 これらの件のどんなさらなる考慮もユーザの自己の責任です。
Security Considerations
セキュリティ問題
Security issues are discussed throughout this memo.
このメモ中で安全保障問題について議論します。
References
参照
[3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
[3DES]W.タクマン、「ヘルマンはデスの近道のソリューションを全く提示しない」IEEE Spectrum、v。 16、n。 7 1979年7月、pp40-41。
[BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against
Protocols Based on RSA Encryption Standard PKCS #1" in
Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
1--12, 1998.
[BLEI]Bleichenbacher D.、「プロトコルに対する選ばれた暗号文攻撃は暗号理論における進歩における暗号化標準のPKCS#1インチをRSAに基礎づけました--暗号98年、LNCS vol.1462、ページ」 1--12, 1998.
[DES] ANSI X3.106, "American National Standard for Information
Systems-Data Link Encryption," American National Standards
Institute, 1983.
[デス]ANSI X3.106、「情報システムデータ・リンク暗号化のための米国標準規格」、American National Standards Institut、1983。
[DH1] W. Diffie and M. E. Hellman, "New Directions in
Cryptography," IEEE Transactions on Information Theory, V.
IT-22, n. 6, Jun 1977, pp. 74-84.
[DH1]W.ディフィーとM.E.ヘルマン、「暗号に関する新傾向」、情報Theory、V.IT-22、nのIEEE Transactions。 6 1977年6月、ページ 74-84.
[DSS] NIST FIPS PUB 186, "Digital Signature Standard," National
Institute of Standards and Technology, U.S. Department of
Commerce, May 18, 1994.
[DSS]NIST FIPSパブ186、「デジタル署名基準」、米国商務省標準技術局、米国商務省、1994年5月18日。
[FTP] Postel J., and J. Reynolds, "File Transfer Protocol", STD 9,
RFC 959, October 1985.
[FTP]ポステルJ.、およびJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、1985年10月。
Dierks & Allen Standards Track [Page 75] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[75ページ]RFC2246TLSプロトコルバージョン1999年1月1日
[HTTP] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[HTTP] バーナーズ・リー、T.、フィールディング、R.、およびH.Frystyk、「HTTP/1インチ、RFC1945、1996年ハイパーテキスト転送プロトコル--5月。」
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication," RFC 2104, February
1997.
[HMAC] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH
Series in Information Processing, v. 1, Konstanz: Hartung-
Gorre Verlag, 1992.
[IDEA]X.レイ、情報Processing、vの「ブロック暗号のデザインとセキュリティ」のETH Series。 1、コンスタンツ: ハルトゥングGorre Verlag、1992。
[MD2] Kaliski, B., "The MD2 Message Digest Algorithm", RFC 1319,
April 1992.
[MD2] Kaliski、B.、「MD2メッセージダイジェストアルゴリズム」、RFC1319、1992年4月。
[MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
April 1992.
[MD5] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard,"
version 1.5, November 1993.
[PKCS1]RSA研究所、「PKCS#1:」 "RSA Encryption Standard"、バージョン1.5、1993年11月。
[PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
Standard," version 1.5, November 1993.
[PKCS6]RSA研究所、「PKCS#6:」 "RSA Extended Certificate Syntax Standard"、バージョン1.5、1993年11月。
[PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
Standard," version 1.5, November 1993.
[PKCS7]RSA研究所、「PKCS#7:」 "RSA Cryptographic Message Syntax Standard"、バージョン1.5、1993年11月。
[PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
Public Key Infrastructure: Part I: X.509 Certificate and CRL
Profile", RFC 2459, January 1999.
[PKIX] Housley、R.、フォード、W.、ポーク、W.、およびD.が独奏される、「インターネット公開鍵基盤:」 部分I: 「X.509証明書とCRLプロフィール」、RFC2459、1月1999日
[RC2] Rivest, R., "A Description of the RC2(r) Encryption
Algorithm", RFC 2268, January 1998.
[RC2] Rivest、R.、「RC2(r)暗号化アルゴリズムの記述」、RFC2268、1998年1月。
[RC4] Thayer, R. and K. Kaukonen, A Stream Cipher Encryption
Algorithm, Work in Progress.
[RC4] セイヤー、R.、およびK.コウコネン(ストリーム暗号暗号化アルゴリズム)は進行中で働いています。
[RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key Cryptosystems,"
Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-
126.
[RSA] R.Rivest、A.シャミル、およびL.M.Adleman、「デジタル署名と公開鍵暗号系を得るためのメソッド」、ACM(v)のCommunications。 21、n。 2 1978年2月、ページ 120- 126.
[RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782
[RSADSI]はRSA Data Security Inc.、Tel:に連絡します。 415-595-8782
[SCH] B. Schneier. Applied Cryptography: Protocols, Algorithms,
and Source Code in C, Published by John Wiley & Sons, Inc.
1994.
[SCH]B.シュナイアー。 暗号を適用します: ジョン・ワイリーと息子Inc.1994によって発行されたCのプロトコル、アルゴリズム、およびソースコード
Dierks & Allen Standards Track [Page 76] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[76ページ]RFC2246TLSプロトコルバージョン1999年1月1日
[SHA] NIST FIPS PUB 180-1, "Secure Hash Standard," National
Institute of Standards and Technology, U.S. Department of
Commerce, Work in Progress, May 31, 1994.
[SHA]NIST FIPSパブ180-1、「安全なハッシュ規格」、米国商務省標準技術局、米国商務省は進歩、1994年5月31日に働いています。
[SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
Corp., Feb 9, 1995.
[SSL2] 1995年2月9日のヒックマン、キップ、「SSLプロトコル」ネットスケープ・コミュニケーションズ。
[SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
Netscape Communications Corp., Nov 18, 1996.
[SSL3] 1996年11月18日のA.フライ料理人、P.Karlton、およびP.コッハー、「SSL3.0プロトコル」、ネットスケープ・コミュニケーションズ。
[TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
September 1981.
[TCP] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[TEL] Postel J., and J. Reynolds, "Telnet Protocol
Specifications", STD 8, RFC 854, May 1993.
[TEL] ポステルJ.、およびJ.レイノルズ、「telnetプロトコル仕様」、STD8、RFC854は1993がそうするかもしれません。
[TEL] Postel J., and J. Reynolds, "Telnet Option Specifications",
STD 8, RFC 855, May 1993.
[TEL] ポステルJ.、およびJ.レイノルズ、「telnetオプション仕様」(STD8、RFC855)は1993がそうするかもしれません。
[X509] CCITT. Recommendation X.509: "The Directory - Authentication
Framework". 1988.
[X509]CCITT。 推薦X.509: 「ディレクトリ--認証、フレームワーク、」 1988.
[XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External
Data Representation Standard, August 1995.
[XDR] R.Srinivansan、サン・マイクロシステムズ、RFC-1832: XDR: 1995年8月の外部データ表現規格。
Credits
クレジット
Win Treese Open Market
Win Treeseオープンマーケット
EMail: treese@openmarket.com
メール: treese@openmarket.com
Editors
エディターズ
Christopher Allen Tim Dierks Certicom Certicom
クリストファーアレンティムDierks Certicom Certicom
EMail: callen@certicom.com EMail: tdierks@certicom.com
メール: callen@certicom.com メール: tdierks@certicom.com
Authors' Addresses
作者のアドレス
Tim Dierks Philip L. Karlton Certicom Netscape Communications
ティムDierksフィリップL.Karlton Certicomネットスケープ・コミュニケーションズ
EMail: tdierks@certicom.com
メール: tdierks@certicom.com
Dierks & Allen Standards Track [Page 77] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[77ページ]RFC2246TLSプロトコルバージョン1999年1月1日
Alan O. Freier Paul C. Kocher Netscape Communications Independent Consultant
アランO.フライアポールC.コッハーネットスケープ・コミュニケーションズから独立しているコンサルタント
EMail: freier@netscape.com EMail: pck@netcom.com
メール: freier@netscape.com メール: pck@netcom.com
Other contributors
他の貢献者
Martin Abadi Robert Relyea Digital Equipment Corporation Netscape Communications
マーチンAbadiロバートレリアDECネットスケープ・コミュニケーションズ
EMail: ma@pa.dec.com EMail: relyea@netscape.com
メール: ma@pa.dec.com メール: relyea@netscape.com
Ran Canetti Jim Roskind IBM Watson Research Center Netscape Communications
カネッティジムRoskind IBMワトソン研究所ネットスケープ・コミュニケーションズを経営していました。
EMail: canetti@watson.ibm.com EMail: jar@netscape.com
メール: canetti@watson.ibm.com メール: jar@netscape.com
Taher Elgamal Micheal J. Sabin, Ph. D. Securify Consulting Engineer
タヘル・Elgamal Micheal J.セービン、博士号Securify開業技師
EMail: elgamal@securify.com EMail: msabin@netcom.com
メール: elgamal@securify.com メール: msabin@netcom.com
Anil R. Gangolli Dan Simon Structured Arts Computing Corp. Microsoft
コマツナギR.Gangolliダン・サイモンは社のマイクロソフトを計算する芸術を構造化しました。
EMail: gangolli@structuredarts.com EMail: dansimon@microsoft.com
メール: gangolli@structuredarts.com メール: dansimon@microsoft.com
Kipp E.B. Hickman Tom Weinstein Netscape Communications Netscape Communications
キップE.B.ヒックマントムワインスタインネットスケープ・コミュニケーションズネットスケープ・コミュニケーションズ
EMail: kipp@netscape.com EMail: tomw@netscape.com
メール: kipp@netscape.com メール: tomw@netscape.com
Hugo Krawczyk IBM Watson Research Center
ユーゴーKrawczyk IBMワトソン研究所
EMail: hugo@watson.ibm.com
メール: hugo@watson.ibm.com
Comments
コメント
The discussion list for the IETF TLS working group is located at the e-mail address <ietf-tls@lists.consensus.com>. Information on the group and information on how to subscribe to the list is at <http://lists.consensus.com/>.
IETF TLSワーキンググループのための議論リストがメール address <ietf-tls@lists.consensus.com に位置している、gt。 グループに関する情報とどうリストに加入するかの情報が<http://lists.consensus.com/>にあります。
Dierks & Allen Standards Track [Page 78] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[78ページ]RFC2246TLSプロトコルバージョン1999年1月1日
Archives of the list can be found at:
<http://www.imc.org/ietf-tls/mail-archive/>
以下でリストのアーカイブを見つけることができます。 <メールhttp://www.imc.org/ietf-tls/アーカイブ/>。
Dierks & Allen Standards Track [Page 79] RFC 2246 The TLS Protocol Version 1.0 January 1999
Dierksとアレン標準化過程[79ページ]RFC2246TLSプロトコルバージョン1999年1月1日
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Dierks & Allen Standards Track [Page 80]
Dierksとアレン標準化過程[80ページ]
一覧
スポンサーリンク
