RFC4346 日本語訳
4346 The Transport Layer Security (TLS) Protocol Version 1.1. T.Dierks, E. Rescorla. April 2006. (Format: TXT=187041 bytes) (Obsoletes RFC2246) (Obsoleted by RFC5246) (Updated by RFC4366, RFC4680, RFC4681) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group T. Dierks
Request for Comments: 4346 Independent
Obsoletes: 2246 E. Rescorla
Category: Standards Track RTFM, Inc.
April 2006
Dierksがコメントのために要求するワーキンググループT.をネットワークでつないでください: 4346年の無党派は以下を時代遅れにします。 2246年のE.レスコラカテゴリ: 標準化過程RTFM Inc.2006年4月
The Transport Layer Security (TLS) Protocol
Version 1.1
トランスポート層セキュリティ(TLS)プロトコルバージョン1.1
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document specifies Version 1.1 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security 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.1を指定します。 TLSプロトコルはインターネットの上に通信秘密保全を提供します。 プロトコルで、クライアント/サーバ・アプリケーションは盗み聞くのを防ぐように設計されている道、改ざん、またはメッセージ偽造で伝えます。
Dierks & Rescorla Standards Track [Page 1] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Differences from TLS 1.0 ...................................5
1.2. Requirements Terminology ...................................5
2. Goals ...........................................................5
3. Goals of This Document ..........................................6
4. Presentation Language ...........................................6
4.1. Basic Block Size ...........................................7
4.2. Miscellaneous ..............................................7
4.3. Vectors ....................................................7
4.4. Numbers ....................................................8
4.5. Enumerateds ................................................8
4.6. Constructed Types ..........................................9
4.6.1. Variants ...........................................10
4.7. Cryptographic Attributes ..................................11
4.8. Constants .................................................12
5. HMAC and the Pseudorandom Function .............................12
6. The TLS Record Protocol ........................................14
6.1. Connection States .........................................15
6.2. Record layer ..............................................17
6.2.1. Fragmentation ......................................17
6.2.2. Record Compression and Decompression ...............19
6.2.3. Record Payload Protection ..........................19
6.2.3.1. Null or Standard Stream Cipher ............20
6.2.3.2. CBC Block Cipher ..........................21
6.3. Key Calculation ...........................................24
7. The TLS Handshaking Protocols ..................................24
7.1. Change Cipher Spec Protocol ...............................25
7.2. Alert Protocol ............................................26
7.2.1. Closure Alerts .....................................27
7.2.2. Error Alerts .......................................28
7.3. Handshake Protocol Overview ...............................31
7.4. Handshake Protocol ........................................34
7.4.1. Hello Messages .....................................35
7.4.1.1. Hello request .............................35
7.4.1.2. Client Hello ..............................36
7.4.1.3. Server Hello ..............................39
7.4.2. Server Certificate .................................40
7.4.3. Server Key Exchange Message ........................42
7.4.4. Certificate request ................................44
7.4.5. Server Hello Done ..................................46
7.4.6. Client certificate .................................46
7.4.7. Client Key Exchange Message ........................47
7.4.7.1. RSA Encrypted Premaster Secret Message ....47
7.4.7.2. Client Diffie-Hellman Public Value ........50
7.4.8. Certificate verify .................................50
7.4.9. Finished ...........................................51
1. 序論…4 1.1. TLS1.0からの違い…5 1.2. 要件用語…5 2. 目標…5 3. このドキュメントの目標…6 4. プレゼンテーション言語…6 4.1. 文節サイズ…7 4.2. その他…7 4.3. ベクトル…7 4.4. 数…8 4.5. 列挙品目…8 4.6. タイプを構成します…9 4.6.1. 異形…10 4.7. 暗号の属性…11 4.8. 定数…12 5. HMACと擬似ランダムは機能します…12 6. TLSはプロトコルを記録します…14 6.1. 接続州…15 6.2. 層を記録してください…17 6.2.1. 断片化…17 6.2.2. 圧縮と減圧を記録してください…19 6.2.3. 有効搭載量保護を記録してください…19 6.2.3.1. ヌルの、または、標準のストリーム暗号…20 6.2.3.2. CBCは暗号を妨げます…21 6.3. 主要な計算…24 7. TLSハンドシェイクプロトコル…24 7.1. 暗号仕様プロトコルを変えてください…25 7.2. プロトコルを警告してください…26 7.2.1. 閉鎖警戒…27 7.2.2. 誤り警戒…28 7.3. 握手プロトコル概要…31 7.4. 握手プロトコル…34 7.4.1. こんにちは、メッセージ…35 7.4.1.1. こんにちは、要求…35 7.4.1.2. クライアント、こんにちは…36 7.4.1.3. サーバ、こんにちは…39 7.4.2. サーバ証明書…40 7.4.3. サーバの主要な交換メッセージ…42 7.4.4. 要求を証明してください…44 7.4.5. サーバ、こんにちは、します…46 7.4.6. クライアント証明書…46 7.4.7. クライアントの主要な交換メッセージ…47 7.4.7.1. RSAはPremaster秘密の通信を暗号化しました…47 7.4.7.2. クライアントのディフィー-ヘルマンの公共の価値…50 7.4.8. 証明書、確かめます。50 7.4.9. 終わっています…51
Dierks & Rescorla Standards Track [Page 2] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[2ページ]。
8. Cryptographic Computations .....................................52
8.1. Computing the Master Secret ...............................52
8.1.1. RSA ................................................53
8.1.2. Diffie-Hellman .....................................53
9. Mandatory Cipher Suites ........................................53
10. Application Data Protocol .....................................53
11. Security Considerations .......................................53
12. IANA Considerations ...........................................54
A. Appendix - Protocol constant values ............................55
A.1. Record layer .........................................55
A.2. Change cipher specs message ..........................56
A.3. Alert messages .......................................56
A.4. Handshake protocol ...................................57
A.4.1. Hello messages .....................................57
A.4.2. Server authentication and key exchange messages ....58
A.4.3. Client authentication and key exchange messages ....59
A.4.4.Handshake finalization message ......................60
A.5. The CipherSuite ......................................60
A.6. The Security Parameters ..............................63
B. Appendix - Glossary ............................................64
C. Appendix - CipherSuite definitions .............................68
D. Appendix - Implementation Notes ................................69
D.1 Random Number Generation and Seeding ..................70
D.2 Certificates and authentication .......................70
D.3 CipherSuites ..........................................70
E. Appendix - Backward Compatibility With SSL .....................71
E.1. Version 2 client hello ...............................72
E.2. Avoiding man-in-the-middle version rollback ..........74
F. Appendix - Security analysis ...................................74
F.1. Handshake protocol ...................................74
F.1.1. Authentication and key exchange ....................74
F.1.1.1. Anonymous key exchange ...........................75
F.1.1.2. RSA key exchange and authentication ..............75
F.1.1.3. Diffie-Hellman key exchange with authentication ..76
F.1.2. Version rollback attacks ...........................77
F.1.3. Detecting attacks against the handshake protocol ...77
F.1.4. Resuming sessions ..................................78
F.1.5. MD5 and SHA ........................................78
F.2. Protecting application data ..........................78
F.3. Explicit IVs .........................................79
F.4 Security of Composite Cipher Modes ...................79
F.5 Denial of Service ....................................80
F.6. Final notes ..........................................80
Normative References ..............................................81
Informative References ............................................82
8. 暗号の計算…52 8.1. マスター秘密を計算します…52 8.1.1. RSA…53 8.1.2. ディフィー-ヘルマン…53 9. 義務的な暗号スイート…53 10. アプリケーションデータは議定書を作ります…53 11. セキュリティ問題…53 12. IANA問題…54 A. 付録--恒常価値について議定書の中で述べてください…55 A.1。 層を記録してください…55 A.2。 暗号仕様メッセージを変えてください…56 A.3。 警告メッセージ…56 A.4。 握手プロトコル…57 A.4.1。 こんにちは、メッセージ…57 A.4.2。 サーバー証明とキーはメッセージを交換します…58 A.4.3。 クライアント認証とキーはメッセージを交換します…59A.4.4.Handshake決定メッセージ…60 A.5。 CipherSuite…60 A.6。 セキュリティパラメタ…63 B. 付録--用語集…64 C. 付録--CipherSuite定義…68 D. 付録--実装注意…69 D.1乱数発生であって種子…70通のD.2証明書と認証…70D.3 CipherSuites…70 E. 付録--SSLとの後方の互換性…71 E.1。 バージョン2クライアント、こんにちは…72 E.2。 中央の男性バージョンロールバックを避けます…74 F. 付録--Security分析…74 F.1。 握手プロトコル…74 F.1.1。 認証と主要な交換…74 F.1.1.1。 匿名の主要な交換…75 F.1.1.2。 RSAの主要な交換と認証…75 F.1.1.3。 認証によるディフィー-ヘルマンの主要な交換。76 F.1.2。 バージョンロールバックは攻撃されます…77 F.1.3。 握手に対して攻撃を検出して、議定書を作ってください…77 F.1.4。 再開します…78 F.1.5。 MD5とSHA…78 F.2。 アプリケーションデータを保護します…78 F.3。 明白なIVs…79 合成物のF.4セキュリティはモードを解きます…79F.5サービス妨害…80 F.6。 最終的な注意…80 標準の参照…81 有益な参照…82
Dierks & Rescorla Standards Track [Page 3] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[3ページ]。
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 [SCH] 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.
- 接続は個人的です。 左右対称の暗号はデータ暗号化(例えば、RC4[SCH]DES[DES]など)に使用されます。 この左右対称の暗号化のためのキーは、各接続のために唯一生成されて、別のプロトコル(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
this mode while another protocol is using the Record Protocol as a
transport for negotiating security parameters.
- 接続は頼もしいです。 メッセージ転送は、合わせられたMACを使用することでメッセージの保全チェックを含んでいます。 安全なハッシュ関数(例えば、SHA、MD5など)はMAC計算に使用されます。 Recordプロトコルは、MACなしで作動できますが、別のプロトコルがセキュリティパラメタを交渉するのに輸送として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
TLSの1つの利点はそれがアプリケーション・プロトコル独立者であるということです。 より高い平らなプロトコルはTLSプロトコルの上で層にされることができます。
Dierks & Rescorla Standards Track [Page 4] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[4ページ]。
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 to the judgment of the designers and implementors of protocols that run on top of TLS.
透過的に。 しかしながら、TLS規格はプロトコルがTLSと共にセキュリティをどう加えるかを指定しません。 どのようにTLSハンドシェイクに着手するか、そして、どのように証明書が交換した認証を解釈するかに関する決定はTLSの上で稼働するプロトコルのデザイナーと作成者の判断に任せます。
1.1. Differences from TLS 1.0
1.1. TLS1.0からの違い
This document is a revision of the TLS 1.0 [TLS1.0] protocol, and contains some small security improvements, clarifications, and editorial improvements. The major changes are:
このドキュメントは、TLS1.0[TLS1.0]プロトコルの改正であり、いくつかの小さいセキュリティ改良、明確化、および編集の改良を含んでいます。 大きな変化は以下の通りです。
- The implicit Initialization Vector (IV) is replaced with an
explicit IV to protect against CBC attacks [CBCATT].
- CBC攻撃[CBCATT]から守るために、内在している初期設定Vector(IV)を明白なIVに取り替えます。
- Handling of padding errors is changed to use the bad_record_mac
alert rather than the decryption_failed alert to protect against
CBC attacks.
- CBC攻撃から守るのに復号化の_の失敗した警戒よりむしろ悪い_記録_mac警戒を使用するために詰め物誤りの取り扱いを変えます。
- IANA registries are defined for protocol parameters.
- IANA登録はプロトコルパラメタのために定義されます。
- Premature closes no longer cause a session to be nonresumable.
- 時期尚早な閉鎖は、もうセッションが非再開可能であることを引き起こしません。
- Additional informational notes were added for various new attacks
on TLS.
- 追加情報の注意はTLSに対する様々な新しい攻撃のために加えられました。
In addition, a number of minor clarifications and editorial improvements were made.
さらに、多くの小さい方の明確化と編集の改良をしました。
1.2. Requirements Terminology
1.2. 要件用語
In this document, the keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" are to be interpreted as described in RFC 2119 [REQ].
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「」 「5月」はRFC2119[REQ]で説明されるように解釈されることになっているべきです。
2. Goals
2. 目標
The goals of TLS Protocol, in order of their priority, are as follows:
彼らの優先権の順に、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 can successfully exchange
cryptographic parameters without knowledge of one another's code.
2. 相互運用性: 独立しているプログラマはお互いのコードに関する知識なしで暗号のパラメタを首尾よく交換できるTLSを利用するアプリケーションを開発できるべきです。
Dierks & Rescorla Standards Track [Page 5] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[5ページ]。
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: preventing
the need to create a new protocol (and risking the introduction of
possible new weaknesses) and avoiding the need to implement an
entire new security library.
3. 伸展性: TLSはどの新しい公開鍵にフレームワークを提供しようとするか、そして、必要に応じて大量の暗号化メソッドは取り入れることができます。 また、これは2つのサブ目標を達成するでしょう: 新しいプロトコル(可能な新しい弱点の導入を危険にさらして)を作成する必要性を防いで、全体の新しいセキュリティライブラリを実装する必要性を避けます。
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.1, TLS 1.0, and SSL 3.0 do not interoperate (although each protocol incorporates a mechanism by which an implementation can back down prior versions). This document is intended primarily for readers who will be implementing the protocol and for 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.1、TLS1.0、およびSSL3.0が共同利用しないほど(各プロトコルは実装が先のバージョンの下側にそうして戻ることができるメカニズムを組み込みますが)重要です。 このドキュメントは主としてプロトコルを実装する読者とそれの暗号の分析をするもののために意図します。 仕様は念頭にこれで書かれています、そして、それらの2つのグループの必要性を反映することを意図します。 その理由で、アルゴリズム依存するデータ構造と規則の多くがテキスト(コネと対照的に付録)のボディーに含まれています、それらへの、より簡単なアクセスを提供して。
This document is not intended to supply any details of service definition or of 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; it has no general application beyond that particular goal.
このドキュメントは外部の表現における、データの形式に対処します。 以下の非常に基本的で何気なくいくらか定義されたプレゼンテーション構文は使用されるでしょう。 構文は構造にいくつかのソースから描かれます。 構文と意図の両方でその構文とXDRのプログラミング言語「C」[XDR]に類似していますが、あまりに多くの平行線を描くのは危険でしょう。 ドキュメントTLSだけにはこのプレゼンテーション言語の目的があります。 それには、その特定の目標を超えて一般的適用が全くありません。
Dierks & Rescorla Standards Track [Page 6] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[6ページ]。
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つのベクトル*/
Variable-length vectors are defined by specifying a subrange of legal lengths, inclusively, using the notation <floor..ceiling>. When
可変長のベクトルは、記法<床を使用することで包括的に法的な長さのサブレンジを指定することによって、定義されます。天井>。 いつ
Dierks & Rescorla Standards Track [Page 7] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[7ページ]。
these are 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 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です。 タイプenumの分野は定義で宣言された値を仮定できるだけです。 各定義は異なったタイプです。 同じタイプの列挙品目だけを割り当てられてもよいか、または比較してもよいです。 あらゆる要素、列挙された必須では、値は以下の例に示されるように割り当てられてください。 列挙の要素が注文されないので、どんなオーダーでもどんなユニークな値もそれらに割り当てることができます。
Dierks & Rescorla Standards Track [Page 8] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[8ページ]。
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]]。
The fields within a structure may be qualified using the type's name, with 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番目の野原について言及します。 構造定義は埋め込まれるかもしれません。
Dierks & Rescorla Standards Track [Page 9] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[9ページ]。
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, an
タイプの前でセレクタに値を指定することによって、異形構造は資格があるかもしれません(狭くされます)。 例えば
orange VariantRecord
オレンジのVariantRecord
is a narrowed type of a VariantRecord containing a variant_body of type V2.
VariantRecordの狭くされたタイプはタイプV2の異形_ボディーを含んでいますか?
Dierks & Rescorla Standards Track [Page 10] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[10ページ]。
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 1, as described in [PKCS1A].
RSA署名では、2つのハッシュ(1SHAと1MD5)の36バイトの構造に署名します(秘密鍵で、暗号化されます)。 それは[PKCS1A]で説明されるようにPKCS#1ゴシック体1でコード化されます。
Note: The standard reference for PKCS#1 is now RFC 3447 [PKCS1B].
However, to minimize differences with TLS 1.0 text, we are
using the terminology of RFC 2313 [PKCS1A].
以下に注意してください。 現在、PKCS#1の標準の参照はRFC3447です[PKCS1B]。 しかしながら、TLS1.0テキストで違いを最小にするために、私たちはRFC2313[PKCS1A]の用語を使用しています。
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.
ストリーム暗号暗号化では、平文は同じ量の出力がaから暗号で生成されている排他的な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 that 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 & Rescorla Standards Track [Page 11] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[11ページ]。
An RSA-encrypted value is encoded with PKCS #1 block type 2, as described in [PKCS1A].
RSAによって暗号化された値は[PKCS1A]で説明されるようにPKCS#1ゴシック体2でコード化されます。
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, and then the entire structure is encrypted with a stream cipher. The length of this structure, in bytes, would be equal to two 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 because 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 require 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, and is 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, data). Additional hash algorithms can be defined by cipher suites
さまざまな異なったハッシュアルゴリズムでHMACを使用できます。TLSは2つの異なったアルゴリズム、MD5、およびSHA1との握手にそれを使用します、HMAC_MD5(秘密、データ)とHMAC_SHA(秘密、データ)としてこれらを指示して。 暗号スイートは追加ハッシュアルゴリズムを定義できます。
Dierks & Rescorla Standards Track [Page 12] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[12ページ]。
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 that should guarantee its security if either algorithm remains secure.
PRFをできるだけ安全にするように、それはどちらのアルゴリズムも安全なままで残っているならセキュリティを保証するべきである方法で2つのハッシュアルゴリズムを使用します。
First, we define a data expansion function, P_hash(secret, data) that 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()は以下と定義されます。
A(0) = seed
A(i) = HMAC_hash(secret, A(i-1))
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 is being used to create 64 bytes of data, it will have to be iterated 4 times (through A(4)), creating 80 bytes of output data; the last 16 bytes of the final iteration will 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-ORing the outputs of these two expansion functions together.
TLSのPRFはP_MD5ともう片方の半分で秘密を2つの半分に分けて、データを生成するのに半分を使用することによって作成されて、P_SHA-1、当時の排他的なORingがあるデータが一緒にこれらの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の最初のバイトと同じになるでしょう。
Dierks & Rescorla Standards Track [Page 13] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[13ページ]。
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)と等しいです。
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バイト、およびS2に最後のL_S2バイトを取って。
The PRF is then defined as the result of mixing the two pseudorandom streams by exclusive-ORing them together.
そして、PRFは排他的なORingのそれらで2つの擬似ランダムストリームを一緒に混合するという結果と定義されます。
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. Generating an 80-byte output will require that P_MD5 iterate through A(5), while P_SHA-1 will only iterate through A(4).
MD5が16バイトの出力を起こして、SHA-1が20バイトの出力を起こすので彼らの内部の繰り返しの境界が並べられないことに注意してください。 出力が必要とするP_MD5がPである間にA(5)を通して繰り返す80バイトにSHA-1がA(4)を通して繰り返すだけである_を生成します。
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, reassembled, and 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.1). All such values must be defined by RFC 2434 Standards Action. See Section 11 for IANA Considerations for ContentType values.
4人の記録的なプロトコルクライアントが本書では説明されます: 握手プロトコル、注意深いプロトコル、変化暗号仕様プロトコル、およびアプリケーションデータは議定書を作ります。 TLSプロトコルの拡大を許すために、記録的なプロトコルは追加レコード種類をサポートすることができます。 SHOULDが割り当てるどんな新しいレコード種類もここで説明された4つのレコード種類のためにすぐContentType値を超えて値をタイプします(Appendix A.1を見てください)。 RFC2434Standards Actionはそのようなすべての値を定義しなければなりません。 IANA Considerationsに関してContentType値に関してセクション11を見てください。
If a TLS implementation receives a record type it does not understand, it SHOULD just ignore it. Any protocol designed for use
TLS実装がレコード種類を受け取るなら分からないで、それはSHOULDです。ちょっとそれを無視してください。 使用のために設計されたどんなプロトコル
Dierks & Rescorla Standards Track [Page 14] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[14ページ]。
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 taken to minimize the value of traffic analysis of these values.
TLS MUSTの上に、入念に設計されていて、それに対してすべての可能な攻撃に対処してください。 記録のタイプと長さが暗号化で保護されないので、それに注意してください、注意SHOULD。これらの値のトラヒック分析の値を最小にするために、取ります。
6.1. Connection States
6.1. 接続州
A TLS connection state is the operating environment of the TLS Record Protocol. It specifies a compression algorithm, and encryption algorithm, and a MAC algorithm. In addition, the parameters for these algorithms are known: the MAC secret and the bulk encryption keys 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 Change Cipher Spec 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 that 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秘密と大量の暗号化が中の接続の両方のために読書を合わせる、方向を書いてください。 論理的に、未払いの4つの接続州がいつもあります: 電流は、読まれた州、および未定を読み書きして、州に書きます。 すべての記録が、読まれた電流の下で処理されて、州に書きます。 TLS Handshakeプロトコルで未定の州のためのセキュリティパラメタを設定できて、Change Cipher Specが選択的に未定の州のどちらかを現在にすることができて、その場合、処分して、適切な現状を未定の状態に取り替えます。 そして、未定の状態は人影のない状態に再初期化されます。 セキュリティパラメタで初期化されていない状態を現状にするのは不法です。 初速度電流州は、いつもどんな暗号化、圧縮も、または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, and the block size
of the cipher (if appropriate).
暗号化アルゴリズムAnアルゴリズムを膨らませて、大量の暗号化に使用されてください。 この仕様はこのアルゴリズムの主要なサイズを含んでいます、そのキーの多くがどう秘密であるか、それがブロックかストリーム暗号と、暗号のブロック・サイズ(適切であるなら)であることにかかわらず。
MAC algorithm
An algorithm to be used for message authentication. This
specification includes the size of the hash 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 compression.
データ圧縮に使用されるべき圧縮アルゴリズムAnアルゴリズム。 この仕様はアルゴリズムが圧縮を必要とするというすべての情報を含まなければなりません。
master secret
A 48-byte secret shared between the two peers in the connection.
接続における2人の同輩の間で共有された秘密のA48バイトの秘密をマスタリングしてください。
Dierks & Rescorla Standards Track [Page 15] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[15ページ]。
client random
A 32-byte value provided by the client.
クライアントによって提供されたクライアントの無作為のA32バイトの価値。
server random
A 32-byte value provided by the server.
サーバによって提供されたサーバの無作為のA32バイトの価値。
These parameters are defined in the presentation language as:
これらのパラメタはプレゼンテーション言語で以下と定義されます。
enum { server, client } ConnectionEnd;
サーバ、クライアントをenumする、ConnectionEnd。
enum { null, rc4, rc2, des, 3des, des40, idea, aes }
BulkCipherAlgorithm;
ヌル、rc4、rc2、des、3des、des40、考えがaesするenum、BulkCipherAlgorithm。
enum { stream, block } CipherType;
ストリーム、ブロックをenumする、CipherType。
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;
MACAlgorithm mac_algorithm;
uint8 hash_size;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
struct、ConnectionEnd実体、;、BulkCipherAlgorithmは_暗号_アルゴリズムを膨らませます; CipherType暗号_タイプ; uint8の主要な_サイズ; uint8の主要な_の材料_長さ; MACAlgorithm mac_アルゴリズム; uint8ハッシュ_サイズ; CompressionMethod圧縮_アルゴリズム;はマスター_秘密[48]について不透明にします; クライアント_無作為の[32]について不透明にしてください; サーバ_について不透明にしてください 無作為の[32];、SecurityParameters。
The record layer will use the security parameters to generate the following four items:
記録的な層は以下の4つの項目を生成するのにセキュリティパラメタを使用するでしょう:
client write MAC secret
server write MAC secret
client write key
server write key
クライアントは秘密のサーバが秘密のクライアントがキーを書くと主要なサーバに書くMACに書く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 & Rescorla Standards Track [Page 16] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[16ページ]。
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. For stream ciphers,
this will also contain whatever state information is necessary to
allow the stream to continue to encrypt or decrypt data.
暗号は暗号化アルゴリズムの現状を述べます。 これはその接続のための予定されているキーから成るでしょう。 また、ストリーム暗号のために、これはどんなストリームが、データを暗号化するか、または解読し続けているのを許容するのに必要な州の情報も含むでしょう。
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. Sequence numbers do not wrap. If a TLS
implementation would need to wrap a sequence number, it must
renegotiate instead. A sequence number is incremented after each
record: specifically, the first record transmitted under a
particular connection state MUST use sequence number 0.
状態が別々に維持される一連番号を含む一連番号Each接続は州を読み書きします。 接続状態が作られているときはいつも、ゼロに一連番号を設定しなければなりません。活動的な状態。 一連番号は、タイプuint64にはあって、2^64-1を超えないかもしれません。 一連番号はどんな包装もしません。 TLS実装が、一連番号を包装する必要があるなら、それは代わりに再交渉されなければなりません。 一連番号は各記録の後に増加されます: 明確に、特定の接続状態の下で伝えられた最初の記録は一連番号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記録と合体するかもしれませんか、またはただ一つのメッセージはいくつかの記録の向こう側に断片化されるかもしれません)。
Dierks & Rescorla Standards Track [Page 17] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[17ページ]。
struct {
uint8 major, minor;
} ProtocolVersion;
struct、uint8少佐、未成年者;、ProtocolVersion。
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.1, which uses the version { 3, 2 }. The
version value 3.2 is historical: TLS version 1.1 is a minor
modification to the TLS 1.0 protocol, which was itself a minor
modification to the SSL 3.0 protocol, which bears the version
value 3.0. (See Appendix A.1.)
バージョン、使われるプロトコルのバージョン。 このドキュメントはTLSバージョン1.1について説明して、どれがバージョンを使用するか。3、2。 バージョン値3.2は歴史的です: TLSバージョン1.1はTLS1.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 is 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. However, records MUST be delivered to the network in the same order as they are protected by the record layer. Recipients MUST receive and process interleaved application layer traffic during handshakes subsequent to the first one on a connection.
以下に注意してください。 異なったTLS Record層のcontent typeに関するデータははさみ込まれるかもしれません。 一般に、アプリケーションデータはトランスミッションのために他のcontent typeより下側に上位です。 しかしながら、それらが記録的な層によって保護されるとき、同次で記録をネットワークに提供しなければなりません。 受取人は受信しなければなりません、そして、プロセスは接続での最初のものへのその後の握手の間、応用層トラフィックをはさみ込みました。
Dierks & Rescorla Standards Track [Page 18] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[18ページ]。
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構造に移します。 接続状態をアクティブにするときはいつも、圧縮機能はデフォルト州の情報で初期化されます。
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が一連番号を含んでいるので、なくなったか、付加的であるか、繰り返されたメッセージは検出可能です。
Dierks & Rescorla Standards Track [Page 19] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[19ページ]。
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と同じです。
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を見る)転向者TLSCompressed.fragmentはTLSCiphertext.fragmentとストリームTLSCiphertext.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_アルゴリズムで指定された論じ尽くすアルゴリズムを論じ尽くしてください。
Dierks & Rescorla Standards Track [Page 20] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[20ページ]。
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, DES, or AES), the encryption and MAC functions convert TLSCompressed.fragment structures to and from block TLSCiphertext.fragment structures.
ブロック暗号(RC2、DES、またはAESなどの)のために、暗号化とMAC機能は構造とブロックTLSCiphertext.fragment構造からTLSCompressed.fragment構造を変換します。
block-ciphered struct {
opaque IV[CipherSpec.block_length];
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
ブロックで解かれたstruct不透明なIV[CipherSpec.block_長さ]; 不明瞭な内容[TLSCompressed.length]; 不透明なMAC[CipherSpec.hash_サイズ]; uint8が_長さを水増しして、[GenericBlockCipher.padding_長さ]を水増しするuint8;GenericBlockCipher。
The MAC is generated as described in Section 6.2.3.1.
MACはセクション6.2.3で.1に説明されるように発生しています。
IV
Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit
IV in order to prevent the attacks described by [CBCATT]. We
recommend the following equivalently strong procedures. For
clarity we use the following notation.
SSLとTLSのIV Unlike旧バージョンであり、TLS1.1は、[CBCATT]によって説明された攻撃を防ぐのに明白なIVを使用します。 私たちは以下の同等に強い手順を推薦します。 明快ために、私たちは以下の記法を使用します。
IV
The transmitted value of the IV field in the GenericBlockCipher
structure.
IV、GenericBlockCipher構造のIV分野の伝えられた値。
CBC residue
The last ciphertext block of the previous record.
最後の暗号文が妨げる前の記録のCBCの残り。
mask
The actual value that the cipher XORs with the plaintext prior
to encryption of the first cipher block of the record.
最初の暗号の暗号化の前の平文がある暗号XORsが妨げる記録の実価にマスクをかけてください。
In prior versions of TLS, there was no IV field and the CBC
residue and mask were one and the same. See Sections 6.1,
6.2.3.2, and 6.3, of [TLS1.0] for details of TLS 1.0 IV handling.
TLSの先のバージョンには、IV分野が全くありませんでした、そして、CBCの残りとマスクは全く同じでした。 セクション6.1、6.2を見てください。.3 .2、およびTLS1.0IV取り扱いの詳細のための6.3[TLS1.0。]
Dierks & Rescorla Standards Track [Page 21] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[21ページ]。
One of the following two algorithms SHOULD be used to generate the
per-record IV:
1つ、以下の2アルゴリズムSHOULDに、使用されて、1記録あたりのIVを生成してください:
(1) Generate a cryptographically strong random string R of length
CipherSpec.block_length. Place R in the IV field. Set the
mask to R. Thus, the first cipher block will be encrypted as
E(R XOR Data).
(1) 暗号でaを生成してください。長さのCipherSpec.block_長さの強い無作為のストリングR。 IV分野にRを置いてください。 R.Thusにマスクを設定してください、そして、最初の暗号ブロックはE(R XOR Data)として暗号化されるでしょう。
(2) Generate a cryptographically strong random number R of length
CipherSpec.block_length and prepend it to the plaintext prior
to encryption. In this case either:
(2) 暗号で長さのCipherSpec.block_長さの強い乱数Rとprependをaに生成してください、それ、暗号化の前の平文に。 この場合どちらか:
(a) The cipher may use a fixed mask such as zero.
(b) The CBC residue from the previous record may be used as
the mask. This preserves maximum code compatibility with
TLS 1.0 and SSL 3. It also has the advantage that it does
not require the ability to quickly reset the IV, which is
known to be a problem on some systems.
(a) 暗号はゼロなどの固定マスクを使用するかもしれません。 (b) 前の記録からのCBCの残りはマスクとして使用されるかもしれません。 これはTLS1.0とSSL3との最大のコードの互換性を保存します。 また、それで、する利点はいくつかのシステムの上ですぐにIVをリセットする能力を必要としません。(それは、問題であることが知られています)。
In either (2)(a) or (2)(b) the data (R || data) is fed into
the encryption process. The first cipher block (containing
E(mask XOR R) is placed in the IV field. The first block of
content contains E(IV XOR data).
(2)(a)か(2)(b)のどちらかでは、データ(R| | データ)を暗号化プロセスに与えます。 1番目はブロックを解きます。E(マスクXOR R)を含むのはIV分野に置かれます。(最初のブロックの内容はE(IV XORデータ)を含んでいます。
The following alternative procedure MAY be used; however, it has
not been demonstrated to be as cryptographically strong as the
above procedures. The sender prepends a fixed block F to the
plaintext (or, alternatively, a block generated with a weak PRNG).
He then encrypts as in (2), above, using the CBC residue from the
previous block as the mask for the prepended block. Note that in
this case the mask for the first record transmitted by the
application (the Finished) MUST be generated using a
cryptographically strong PRNG.
以下の交替手続きは使用されるかもしれません。 しかしながら、それは同じくらい暗号でである示されていません。上の手順として、強いです。 送付者は平文(あるいはまた弱いPRNGと共に生成されたブロック)に固定ブロックFをprependsします。 そして、彼は前のブロックからの上で(2)でprependedブロックでマスクと同じくらい使用しているCBCの残りを暗号化します。 アプリケーション(Finished)で最初の記録が伝わったのでこの場合マスクに使用を生成しなければならないことに注意してください、暗号で、強いPRNG
The decryption operation for all three alternatives is the same.
The receiver decrypts the entire GenericBlockCipher structure and
then discards the first cipher block, corresponding to the IV
component.
すべての3つの選択肢のための復号化操作は同じです。 IVコンポーネントに対応している、受信機は、全体のGenericBlockCipherが構造であると解読して、次に、最初の暗号ブロックを捨てます。
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, 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 that are based on analysis of the
lengths of exchanged messages. Each uint8 in the padding data
vector MUST be filled with the padding length value. The receiver
平文の長さがブロック暗号のブロック長の不可欠の倍数であることを強制するために加えられるPaddingを水増しします。 詰め物はどんな最大255バイトの長さであるかもしれません、ブロック長の不可欠の倍数であるTLSCiphertext.lengthをもたらす限り。 必要とするより長い長さはプロトコルに対する交換されたメッセージの長さの分析に基づいている攻撃をだめにするのにおいて望ましいかもしれません。 詰め物長さの価値で詰め物データベクトルにおける各uint8を満たさなければなりません。 受信機
Dierks & Rescorla Standards Track [Page 22] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[22ページ]。
MUST check this padding and SHOULD use the bad_record_mac alert to
indicate padding errors.
チェックのこの詰め物とSHOULDは誤りを水増しする示す悪い_記録_mac警戒を使用しなければなりませんか?
padding_length
The padding length MUST 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 CipherSpec.block_length, TLSCompressed.length, CipherSpec.hash_size, and padding_length.
暗号化されたデータの長さ(TLSCiphertext.length)はCipherSpec.block_長さと、TLSCompressed.lengthと、CipherSpec.hash_サイズと、_長さを水増しする合計よりさらに1です。
Example: If the block length is 8 bytes, the content length
(TLSCompressed.length) is 61 bytes, and the MAC length is 20
bytes, then the length before padding is 82 bytes (this does
not include the IV, which may or may not be encrypted, as
discussed above). 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.
例: ブロック長が8バイトであり、コンテンツの長さ(TLSCompressed.length)が61バイトであり、MACの長さが20バイトであるなら、詰め物の前の長さは82バイト(これはIVを含んでいません、上で議論するように)です。IVは暗号化されるかもしれません。 したがって、詰め物長さの法8は、全長を8バイト(ブロック長)の同等の倍数にするように6と等しくなければなりません。 詰め物の長さは、254を通した6、14、22などであるかもしれません。 そっと歩いている長さは最小限です。必要であることで、6、詰め物は6バイトであるだろう、各含有は値6です。 したがって、ブロック暗号化の前のGenericBlockCipherのベスト8八重奏はxx06 06 06 06 06 06 06でしょう。(そこでは、xxがMACの最後の八重奏です)。
Note: With block ciphers in CBC mode (Cipher Block Chaining), it is
critical that the entire plaintext of the record be known
before any ciphertext is transmitted. Otherwise, it is
possible for the attacker to mount the attack described in
[CBCATT].
以下に注意してください。 CBCモード(暗号Block Chaining)によるブロック暗号で、どんな暗号文も伝えられる前に記録の全体の平文が知られているのは、重要です。 さもなければ、攻撃者が[CBCATT]で説明された攻撃を仕掛けるのは、可能です。
Implementation Note: Canvel et al. [CBCTIME] have demonstrated a
timing attack on CBC padding based on the time
required to compute the MAC. In order to defend
against this attack, implementations MUST ensure
that record processing time is essentially the
same whether or not the padding is correct. In
general, the best way to do this is to compute
the MAC even if the padding is incorrect, and
only then reject the packet. For instance, if
the pad appears to be incorrect, the
implementation might assume a zero-length pad
and then compute the MAC. This leaves a small
timing channel, since MAC performance depends to
some extent on the size of the data fragment,
実装注意: Canvel他 [CBCTIME]はMACを計算するのに必要である時間に基づいてそっと歩くCBCに対するタイミング攻撃を示しました。 この攻撃に対して防御するために、実装は、詰め物が正しいか否かに関係なく、記録的な処理時間が本質的には同じであることを確実にしなければなりません。 一般に、これをする最も良い方法が詰め物が不正確であってもMACを計算することであり、次にだけの、廃棄物はパケットです。 例えば、パッドが不正確であるように見えるなら、実装は、ゼロ・レングスパッドを仮定して、次に、MACを計算するかもしれません。 MAC性能がデータ断片のサイズにある程度よるので、これは小さいタイミングチャンネルを残します。
Dierks & Rescorla Standards Track [Page 23] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[23ページ]。
but it is not believed to be large enough to be
exploitable, due to the large block size of
existing MACs and the small size of the timing
signal.
しかし、利用可能であることができるくらい大きいのは信じられていません、既存のMACsの大きいブロック・サイズとタイミング信号の小型のため。
6.3. Key Calculation
6.3. 主要な計算
The Record Protocol requires an algorithm to generate keys, and MAC secrets from the security parameters provided by the handshake protocol.
Recordプロトコルは、キー、およびMACが握手プロトコルによって提供されたセキュリティパラメタからの秘密であると生成するためにアルゴリズムを必要とします。
The master secret is hashed into a sequence of secure bytes, which are assigned to the MAC secrets and keys 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, and a server write key, each of which is generated from the master secret in that order. Unused values are empty.
マスター秘密はMAC秘密に割り当てられる安全なバイトの系列に論じ尽くされます、そして、キーが現在の接続州が必要です(Appendix A.6を見てください)。 CipherSpecsは秘密のaクライアントがそれのそれぞれがそのオーダーにおけるマスター秘密から生成されるキーを書くとキー、およびサーバに書くMACに書くクライアントが、MAC秘密、サーバに書くaを必要とします。 未使用の値は空です。
When keys and MAC secrets are generated, the master secret is used as an entropy source.
キーとMAC秘密が発生しているとき、マスター秘密はエントロピーソースとして使用されます。
To generate the key material, compute
主要な材料を生成するには、計算してください。
key_block = PRF(SecurityParameters.master_secret,
"key expansion",
SecurityParameters.server_random +
SecurityParameters.client_random);
主要な_ブロックはPRFと(秘密のSecurityParameters.master_「キー拡張」で、_無作為の+SecurityParameters.client SecurityParameters.server_無作為)であることで等しいです。
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]
_が__秘密[SecurityParameters.hash_サイズ]のクライアント_が_キーを書くと_主要な[SecurityParameters.key_の材料_長さ]サーバ_に書くMACに書くと_MACの_の秘密の[SecurityParameters.hash_サイズ]サーバ_に書くクライアント[SecurityParameters.key_の材料_長さ]
Implementation note: The currently defined cipher suite that requires the most material is AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x 32 byte keys, 2 x 20 byte MAC secrets, and 2 x 16 byte Initialization Vectors, for a total of 136 bytes of key material.
実装注意: [TLSAES]で定義されて、最も多くの材料を必要とする現在定義された暗号スイートはAES_256_CBC_SHAです。 それは2x32バイトのキー、2x20バイトのMAC秘密、および2x16バイトの初期設定Vectorsを必要とします、合計136バイトの主要な材料のために。
7. The TLS Handshaking Protocols
7. TLSハンドシェイクプロトコル
TLS has three subprotocols that are used to allow peers to agree upon security parameters for the record layer, to authenticate themselves, to instantiate negotiated security parameters, and to report error conditions to each other.
TLSは同輩がセキュリティパラメタで記録的な層、自分たちを認証して、交渉されたセキュリティパラメタを例示して、エラー条件を互いに報告するのに同意するのを許容するのに使用される3つの「副-プロトコル」を持っています。
Dierks & Rescorla Standards Track [Page 24] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[24ページ]。
The Handshake Protocol is responsible for negotiating a session, which consists of the following items:
Handshakeプロトコルは以下の項目から成るセッションを交渉するのに原因となります:
session identifier
An arbitrary byte sequence chosen by the server to identify an
active or resumable session state.
アクティブであるか再開可能なセッション状態を特定するサーバによって選ばれたセッションの識別子のAnの任意のバイト列。
peer certificate
X509v3 [X509] certificate of the peer. This element of the state
may be null.
同輩の同輩証明書X509v3[X509]証明書。 状態のこの要素はヌルであるかもしれません。
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.)
仕様Specifiesを解いてください。大量データ暗号化アルゴリズム(ヌル、DESなどの)とMACアルゴリズム(MD5かSHAなどの)。 また、それはハッシュ_サイズなどの暗号の属性を定義します。 (公式の定義に関してAppendix A.6を見てください。)
master secret
48-byte secret shared between the client and server.
クライアントとサーバの間で共有された秘密の48バイトの秘密をマスタリングしてください。
is resumable
A flag indicating whether the session can be used to initiate new
connections.
再開可能A旗は、新しい接続を開始するのにセッションを使用できるかどうかを示していますか?
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.
そして、アプリケーションデータを保護するとき、これらの項目は、Record Layerによる使用のためにセキュリティパラメタを作成するのに使用されます。 TLS Handshakeプロトコルの再開機能を通した同じセッションを使用することで多くの接続を例示できます。
7.1. Change Cipher Spec Protocol
7.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.
変化暗号仕様プロトコルは、暗号戦略で変遷に合図するために存在しています。 プロトコルはただ一つのメッセージから成ります。(それは、現在(未定でない)の接続状態の下で暗号化されて、圧縮されます)。 メッセージは価値1の1バイトから成ります。
struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
struct、enumに、変化_暗号_仕様(1)、(255)はタイプされます;、ChangeCipherSpec。
The change cipher spec message is sent by both the client and the 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.
クライアントとサーバの両方で変化暗号仕様メッセージを送って、その後の記録が新たに交渉されたCipherSpecとキーの下に保護されるように受領者に通知します。 受信機が、このメッセージのレセプションでRecord Layerがすぐに状態まで読書をコピーするよう命令する、現状を読んでください。
Dierks & Rescorla Standards Track [Page 25] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[25ページ]。
Immediately after sending this message, the sender MUST 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).
作ってください、直後にこのメッセージ、送付者を送るのが、記録的な層に命令しなければならない未定の状態に書いてください、活動的な状態に書いてください。 (セクション6.1を見てください。) セキュリティパラメタが同意された後に握手にもかかわらず、検証の終わっているメッセージを送る(セクション7.4.9を見てください)前を除いて、変化暗号仕様メッセージを送ります。
Note: If a rehandshake occurs while data is flowing on a connection,
the communicating parties may continue to send data using the
old CipherSpec. However, once the ChangeCipherSpec has been
sent, the new CipherSpec MUST be used. The first side to send
the ChangeCipherSpec does not know that the other side has
finished computing the new keying material (e.g., if it has to
perform a time consuming public key operation). Thus, a small
window of time, during which the recipient must buffer the
data, MAY exist. In practice, with modern machines this
interval is likely to be fairly short.
以下に注意してください。 データが接続に流れている間、再握手が現れるなら、交信パーティーは、古いCipherSpecを使用することでデータを送り続けるかもしれません。 しかしながら、いったんChangeCipherSpecを送ると、新しいCipherSpecを使用しなければなりません。 ChangeCipherSpecを送る最初側は、反対側が、新しい合わせることの材料を計算し終えたのを知りません(例えば、時間がかかった公開鍵操作を実行しなければならないなら)。 したがって、時間の小さい窓は存在するかもしれません。(受取人は時間、データをバッファリングしなければなりません)。 近代的なマシンで、実際には、この間隔はかなり短い傾向があります。
7.2. Alert Protocol
7.2. 注意深いプロトコル
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.
TLS Record層によってサポートされたcontent typeの1つは注意深いタイプです。 警告メッセージはメッセージの厳しさと警戒の記述を伝えます。 接続の即座の終了における、致命的な結果のレベルがある警告メッセージ。 この場合、セッションに対応する他の接続は続くかもしれませんが、セッション識別子を無効にしなければなりません、失敗したセッションが新しい接続を証明するのに使用されるのを防いで。 他のメッセージのように、現在の接続州によって指定されるように、警告メッセージは、暗号化されて、圧縮されます。
enum { warning(1), fatal(2), (255) } AlertLevel;
警告(1)、致命的な(2)、(255)をenumする、AlertLevel。
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed(21),
record_overflow(22),
decompression_failure(30),
handshake_failure(40),
no_certificate_RESERVED (41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
enum、_未知(46)、不法な_パラメタ(47)、未知_ca(48)は、_オーバーフロー(22)、減圧_の故障(30)、握手_の故障(40)、_証明書_RESERVED(41)がない、悪い_証明書(42)、サポートされない_証明書(43)が、_記録_mac(20)、近い_が(0)、予期していなかった_メッセージ(10)に通知して、ひどく、復号化_が(21)に失敗したと記録して、証明書_が(44)を取り消して、証明書_が(45)を吐き出したと証明します。
Dierks & Rescorla Standards Track [Page 26] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[26ページ]。
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
(255)
} AlertDescription;
(49)が否定された_にアクセスしてください、そして、_誤り(50)を解読してください、そして、_が誤り(51)、_RESERVED(60)、_バージョン(70)、不十分な_セキュリティ(71)、インターナル_誤り(80)について議定書の中で述べてください、ユーザ_が(90)、いいえ_renegotiation(100)、(255)を取り消したという輸出_制限であると解読してください。 AlertDescription。
struct {
AlertLevel level;
AlertDescription description;
} Alert;
struct AlertLevelレベル; AlertDescription記述;警戒。
7.2.1. Closure Alerts
7.2.1. 閉鎖警戒
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. Note that as of TLS 1.1,
failure to properly close a connection no longer requires that a
session not be resumed. This is a change from TLS 1.0 to conform
with widespread implementation practice.
_が送付者がそれ以上のメッセージをこの接続に送らないように受取人に通知するようにThisメッセージに通知する閉鎖。 適切に接続を終えない場合TLS1.1現在もうセッションが再開されないのが必要でないことに注意してください。 これは広範囲の実装習慣に従うTLS1.0からの変化です。
Either party may initiate a close by sending a close_notify alert. Any data received after a closure alert is ignored.
何れの当事者は近い_が警戒に通知する間近の送付を開始するかもしれません。 閉鎖警戒が無視された後にどんなデータも受信されました。
Unless some other fatal alert has been transmitted, each party is required to send a close_notify alert before closing the write side of the connection. The other party MUST 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.
ある他の致命的な警戒が伝えられていない場合、各当事者が_が以前警戒に通知する閉鎖を閉じさせなければならない、接続の側面を書いてください。 相手は、_がそれ自身の警戒に通知する閉鎖で応じて、すぐに接続を閉鎖しなければならなくて、未定の状態でいずれも捨てるのは書きます。 閉鎖の創始者が面がある近い_が、読みを終える前の警戒に通知する接続の応じることを待つのにそれは必要ではありません。
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
TLSを使用するアプリケーション・プロトコルが、TLS接続が閉じるようになった後にどんなデータも基本的な輸送の上まで運ばれるかもしれないのを前提とするなら、TLS実装はTLS接続が終わったのを応用層に示す前に、注意深い状態で近い_が通知する応じることを受けなければなりません。 アプリケーション・プロトコルが少しの追加データも移しませんが、基本的な輸送接続を終えるだけであるなら、実装は、閉じるのを選ぶかもしれません。
Dierks & Rescorla Standards Track [Page 27] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[27ページ]。
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.
応じている近い_を待つことのない輸送に通知します。 TLSのための用法プロフィールがデータ伝送を管理する方法を書き取るためにこの規格の一部を全く取るべきではありません、接続がいつ開かれるか、または閉店するかを含んでいて。
Note: It is assumed that closing a connection reliably delivers
pending data before destroying the transport.
以下に注意してください。 接続を終えると輸送を破壊する前に未定のデータが確かに提供されると思われます。
7.2.2. Error Alerts
7.2.2. 誤り警戒
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 a fatal alert message, both parties immediately close the connection. Servers and clients MUST forget any session-identifiers, keys, and secrets associated with a failed connection. Thus, any connection terminated with a fatal alert MUST NOT be resumed. The following error alerts are defined:
TLS Handshakeプロトコルのエラー処理は非常に簡単です。 誤りが検出されるとき、検出パーティーはメッセージを相手に送ります。 致命的な警告メッセージのトランスミッションか受領に、双方はすぐに、接続を終えます。 サーバとクライアントは失敗した接続に関連しているどんなセッション識別子、キー、および秘密も忘れなければなりません。 したがって、致命的な警戒で終えられた少しの接続も再開してはいけません。 以下の誤り警戒は定義されます:
unexpected_message
An inappropriate message was received. This alert is always fatal
and should never be observed in communication between proper
implementations.
予期していなかった_メッセージAn不適当なメッセージを受け取りました。 この警戒は、いつも致命的であり、適切な履行のコミュニケーションで決して観察されるべきではありません。
bad_record_mac
This alert is returned if a record is received with an incorrect
MAC. This alert also MUST be returned if an alert is sent because
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.
不正確なMACと共に記録を受け取るなら、悪い_記録_mac This警戒を返します。 TLSCiphertextが病人で道を解読したので警戒を送るなら、この警戒も返さなければなりません: それはブロック長の同等の倍数ではありませんでしたチェックされる場合、詰め物値が正しくはありませんでした。 このメッセージはいつも致命的です。
decryption_failed
This alert MAY be returned if 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.
無効の方法で解読されて、復号化の_の失敗したThis警戒はTLSCiphertextであるなら返されるかもしれません: それはブロック長の同等の倍数ではありませんでしたチェックされる場合、詰め物値が正しくはありませんでした。 このメッセージはいつも致命的です。
Note: Differentiating between bad_record_mac and decryption_failed
alerts may permit certain attacks against CBC mode as used in
TLS [CBCATT]. It is preferable to uniformly use the
bad_record_mac alert to hide the specific type of the error.
以下に注意してください。 悪い_を区別して、記録_macと復号化の_の失敗した警戒はTLS[CBCATT]で使用されるようにCBCモードに対してある攻撃を可能にするかもしれません。 誤りの特定のタイプを隠すのに一様に悪い_記録_mac警戒を使用するのは望ましいです。
record_overflow
A TLSCiphertext record was received that 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.
2^14+2048バイト以上の長さ、または2^14+1024バイト以上でTLSCompressed記録に解読された記録を持っていた記録_オーバーフローA TLSCiphertext記録を受け取りました。 このメッセージはいつも致命的です。
Dierks & Rescorla Standards Track [Page 28] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[28ページ]。
decompression_failure
The decompression function received improper input (e.g., data
that would expand to excessive length). This message is always
fatal.
減圧_失敗、減圧機能は不適当な入力(例えば過度の長さに広がるデータ)を受け取りました。 このメッセージはいつも致命的です。
handshake_failure
Reception of a handshake_failure alert message indicates that
the sender was unable to negotiate an acceptable set of
security parameters given the options available. This is a
fatal error.
握手_失敗警告メッセージの握手_失敗Receptionは、利用可能なオプションを考えて、送付者が許容できるセットのセキュリティパラメタを交渉できなかったのを示します。 これは致命的な誤りです。
no_certificate_RESERVED
This alert was used in SSLv3 but not in TLS. It should not be
sent by compliant implementations.
_証明書_RESERVED This警戒は、全くSSLv3で使用されましたが、TLSで使用されなかったというわけではありません。 対応する実装はそれを送るべきではありません。
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有効な証明書が受け取られたことを否定しましたが、アクセスコントロールが適用されたとき、送付者は、交渉を続けないと決めました。 このメッセージはいつも致命的です。
Dierks & Rescorla Standards Track [Page 29] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[29ページ]。
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が正しく署名について確かめることができないのを含んでいて、失敗された握手の暗号の操作であると解読するか、主要な交換を解読するか、または終わっているメッセージを有効にしてください。
export_restriction_RESERVED
This alert was used in TLS 1.0 but not TLS 1.1.
制限_RESERVED Thisが警告する輸出_はTLS1.1ではなく、TLS1.0で使用されました。
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 (such as a memory allocation failure) makes it
impossible to continue. 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 is 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
要求かクライアントに対応したサーバでこんにちは、初期のハンドシェイクの後にこんにちはに対応したクライアントによるいいえ_renegotiation Sent。 通常、これらのどちらかが再交渉に通じるでしょう。 それが適切でないときに、受取人はこの警戒で応じるべきです。 その時、オリジナルのリクエスタは、接続を続けるかどうか決めることができます。 これが適切である1つのケースがサーバが要望に応じるためにプロセスを量産したところです。 プロセスは始動とそれにおけるセキュリティパラメタ(キー長、認証など)を受け取るかもしれません。
Dierks & Rescorla Standards Track [Page 30] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[30ページ]。
might be difficult to communicate changes to these parameters
after that point. This message is always a warning.
そのポイント後のこれらのパラメタへの変化を伝えるのは難しくするかもしれなくなってください。 いつもこのメッセージは警告です。
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 receiving party MAY decide at its discretion whether to treat this as a fatal error or not. However, all messages that are transmitted with a level of fatal MUST be treated as fatal messages.
すべての誤りによって、注意深いレベルが明らかに指定されないところでは、送付パーティーは、これが致命的な誤りであるかどうかと自己判断で決心するかもしれません。 警告のレベルがある警戒が受け取られているなら、受領者は、致命的な誤りとしてこれを扱うかどうか自己判断で決めるかもしれません。 しかしながら、致命的のレベルで送られるすべてのメッセージを致命的なメッセージとして扱わなければなりません。
New alert values MUST be defined by RFC 2434 Standards Action. See Section 11 for IANA Considerations for alert values.
RFC2434Standards Actionは新しい注意深い値を定義しなければなりません。 IANA Considerationsに関して注意深い値に関してセクション11を見てください。
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 whether TLS always negotiates the strongest possible connection between two peers. There are a number of ways in which 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
より高い層がTLSがいつも2人の同輩の間の可能な限り強い接続を交渉するかどうかにひどく頼るべきでないことに注意してください。 中央の男性攻撃者が最少への2実体ドロップダウンをそれらがサポートする安全なメソッドにするのを試みることができる多くの方法があります。 プロトコルはこの危険を最小にするように設計されていますが、利用可能な攻撃がまだあります。 for
Dierks & Rescorla Standards Track [Page 31] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[31ページ]。
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.
例、攻撃者は安全なサービスが走るポートへのアクセスを妨げるか、または同輩に非認証された接続を交渉させるのを試みることができました。 原理は、より高いレベルがそれらのセキュリティ要件が何であるかにおいて認識力があって、彼らが必要とすることほど安全でないチャンネルの上に情報を決して伝えてはいけないということです。 どんな暗号スイートも約束のレベルのセキュリティを提供するので、TLSプロトコルは安全です: あなたが証明書について確かめたホストと共に1024年のビットのRSAの主要な交換と3DESを交渉するなら、あなたは、そんなに安全であると予想できます。
However, one SHOULD never send data over a link encrypted with 40-bit security unless one feels that data is worth no more than the effort required to break that encryption.
しかしながら、1SHOULDは人が、データはその暗号化を壊すのに必要である取り組みだけの価値があると感じない場合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 by defining the use of the messages to allow the client and server to agree upon a shared secret. This secret MUST be quite long; currently defined key exchange methods exchange secrets that 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 the 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. Next, 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-
次のこんにちは、メッセージであり、それが認証されるつもりであると、サーバは証明書を送るでしょう。 さらに、サーバの主要な交換メッセージを送るかもしれません、それが必要であるなら(例えば、サーバで証明書が全くないか、または証明書が署名だけのためのものであるなら)。 サーバが認証されるなら、クライアントから証明書を要求するかもしれません、それが選択された暗号スイートに適切であるなら。 次にサーバがサーバを送る、こんにちは、それを示して、メッセージをする、こんにちは、-通信してください、握手のフェーズは完全です。 そして、サーバはクライアント応答を待っています。 サーバが証明書要求メッセージを送ったなら、クライアントは証明書メッセージを送らなければなりません。 現在、クライアントの主要な交換メッセージを送って、そのメッセージの内容がクライアントの間で選択された公開鍵アルゴリズムによる、こんにちは、サーバ、こんにちは。 クライアントが署名能力、aがある証明書をデジタルに送ったなら
Dierks & Rescorla Standards Track [Page 32] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[32ページ]。
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. At this point, the handshake is complete, and the client and server may begin to exchange application layer data. (See flow chart below.) Application data MUST NOT be sent prior to the completion of the first handshake (before a cipher suite other TLS_NULL_WITH_NULL_NULL is established).
ここに、変化暗号仕様メッセージはクライアントによって送られます、そして、クライアントは現在のCipher Specに未定のCipher Specをコピーします。 そして、クライアントはすぐに、新しいアルゴリズム、キー、および秘密の下に終わっているメッセージを送ります。 応答では、サーバは、それ自身の変化暗号仕様メッセージを送って、現在のCipher Specに未定を移して、新しいCipher Specの下に終わっているメッセージを送るでしょう。 ここに、握手は完了しています、そして、クライアントとサーバは応用層データを交換し始めるかもしれません。 (以下のフローチャートを見てください。) 最初の握手の完成の前にアプリケーションデータを送ってはいけません(暗号スイートの前では、他のTLS_NULL_WITH_NULL_NULLは設立されます)。
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.
クライアントは、再開されるのにセッションのSession IDを使用することでClientHelloを送ります。 そして、サーバはマッチがないかどうかセッションキャッシュをチェックします。
Dierks & Rescorla Standards Track [Page 33] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[33ページ]。
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価値があるServerHelloを送るでしょう。 ここに、クライアントとサーバの両方が、暗号仕様メッセージを変化に送って、直接終わっているメッセージに続かなければなりません。 再建がいったん完全になると、クライアントとサーバは応用層データを交換し始めるかもしれません。 (以下のフローチャートを見てください。) Session IDマッチが見つけられないなら、サーバは新しいセッションIDを生成します、そして、TLSクライアントとサーバは完全な握手を実行します。
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;
struct、HandshakeType msg_タイプ; /*握手タイプ*/uint24の長さ; /*バイトが中で*/選んだ(HandshakeType)を通信させる、_要求: こんにちは、HelloRequestをケースに入れてください; _: こんにちは、ケースクライアントClientHello
Dierks & Rescorla Standards Track [Page 34] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[34ページ]。
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;
サーバ_をケースに入れてください、こんにちは: ServerHello。 証明書をケースに入れてください: 証明書。 サーバの_の主要な_交換をケースに入れてください: ServerKeyExchange。 証明書_要求をケースに入れてください: CertificateRequest。 サーバ_をケースに入れてください、こんにちは、行われた_: ServerHelloDone。 ケース証明書_は以下について確かめます。 CertificateVerify。 クライアントの_の主要な_交換をケースに入れてください: ClientKeyExchange。 ケースは終わりました: 終わっています。 ボディー。 } 握手。
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 is described only in its first position. The one message that is not bound by these ordering rules is 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ポジションだけで説明されます。 規則を注文するこれらによって縛られない1つのメッセージがHello Requestメッセージです。(いつでも、送ることができますが、握手の途中に到着するなら、そのメッセージはクライアントによって無視されるべきです)。
New Handshake message type values MUST be defined via RFC 2434 Standards Action. See Section 11 for IANA Considerations for these values.
RFC2434Standards Actionを通して新しいHandshakeメッセージタイプ値を定義しなければなりません。 IANA Considerationsに関してこれらの値に関してセクション11を見てください。
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
こんにちは、要求がクライアントがクライアントを送ることによって新たに交渉プロセスを開始するべきであるという簡単な通知である、こんにちは、便利であるときには、通信してください。 クライアントが現在セッションを交渉していると、このメッセージはクライアントによって無視されるでしょう。 それが、応じるように願って、再交渉するために、セッション、またはクライアントがそうするかもしれないことを願わないなら、このメッセージはクライアントによって無視されるかもしれません。
Dierks & Rescorla Standards Track [Page 35] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[35ページ]。
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.
要求、サーバをこんにちはに送った後に、その後の握手交渉が完全になるまで、SHOULDは要求を繰り返しません。
Structure of this message:
このメッセージの構造:
struct { } HelloRequest;
struct、HelloRequest。
Note: This message MUST NOT be included in the message hashes that
are maintained throughout the handshake and used in the
finished messages and the certificate verify message.
以下に注意してください。 握手の間中維持されて、終わっているメッセージと証明書で使用されるハッシュがメッセージについて確かめるというメッセージにこのメッセージを含んではいけません。
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,
ignoring leap seconds) 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バイトの無作為の_バイト。
Dierks & Rescorla Standards Track [Page 36] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[36ページ]。
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, from this connection, or from 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, and 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 it is 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>。
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が記載する圧縮アルゴリズムのクライアントは自分の好みに従って注文されたクライアントをサポートしました。
Dierks & Rescorla Standards Track [Page 37] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[37ページ]。
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.2. (See
Appendix E for details about backward compatibility.)
TLSのバージョンが議定書を作るクライアントが今会期中に伝えたがっているクライアント_バージョン。 このSHOULD、最新のものになってください、(高さ、評価、)、クライアントによってサポートされたバージョン。 仕様のこのバージョンのために、バージョンは3.2になるでしょう。 (後方の互換性に関する詳細に関して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 if the
client wishes to generate new security parameters.
クライアントがこの接続に使用したがっているセッションのセッション_イドID。 どんなセッション_イドも利用可能でないか、またはクライアントが新しいセキュリティパラメタを生成したいなら、この分野は人影がないはずです。
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 that a client hello message include extra data after the compression methods. This data MUST be included
互換性注意を転送してください: 下位互換のためにそれがそのaクライアントに受入れられる、こんにちは、圧縮方法の後にインクルードの付加的なデータを通信させてください。 このデータを含まなければなりません。
Dierks & Rescorla Standards Track [Page 38] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[38ページ]。
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.
別の方法で無視しなければならないのを除いた握手が論じ尽くすコネ。 これが法的である唯一の握手メッセージです。 他のすべてのメッセージに関しては、メッセージのデータ量は正確にメッセージの記述に合わなければなりません。
Note: For the intended use of trailing data in the ClientHello,
see RFC 3546 [TLSEXT].
以下に注意してください。 ClientHelloにおける引きずっているデータの意図している使用に関しては、RFC3546[TLSEXT]を見てください。
7.4.1.3. Server Hello
7.4.1.3. サーバ、こんにちは。
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。
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.2. (See
Appendix E for details about backward compatibility.)
サーバによってサポートされて、This分野が、より低くそれを含むサーバ_バージョンは、クライアントというクライアントでこんにちはを最も高く示しました。仕様のこのバージョンのために、バージョンは3.2です。 (後方の互換性に関する詳細に関してAppendix Eを見てください。)
random
This structure is generated by the server and MUST be
independently generated from the ClientHello.random.
無作為のThis構造をサーバによって生成されて、ClientHello.randomから独自に生成しなければなりません。
Dierks & Rescorla Standards Track [Page 39] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[39ページ]。
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 that matches the key exchange
method, as follows. Unless otherwise specified, the signing
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.
証明書タイプは、選択された暗号スイートの主要な交換アルゴリズムに適切でなければならなく、一般に、X.509v3証明書です。 それは以下の主要な交換メソッドに合っているキーを含まなければなりません。 別の方法で指定されない場合、証明書のための署名アルゴリズムは証明書キーのためのアルゴリズムと同じであるに違いありません。 別の方法で指定されない場合、公開鍵はどんな長さのものであるかもしれません。
Dierks & Rescorla Standards Track [Page 40] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[40ページ]。
Key Exchange Algorithm Certificate Key Type
主要な交換アルゴリズム証明書主要なタイプ
RSA RSA public key; the certificate MUST
allow the key to be used for encryption.
RSA RSA公開鍵。 証明書は、キーが暗号化に使用されるのを許容しなければなりません。
DHE_DSS DSS public key.
DHE_DSS DSS公開鍵。
DHE_RSA RSA public key that can be used for
signing.
署名に使用できるDHE_RSA RSA公開鍵。
DH_DSS Diffie-Hellman key. The algorithm used
to sign the certificate MUST be DSS.
DH_DSSディフィー-ヘルマンキー。 証明書に署名するのに使用されるアルゴリズムはDSSであるに違いありません。
DH_RSA Diffie-Hellman key. The algorithm used
to sign the certificate MUST be RSA.
DH_RSAディフィー-ヘルマンキー。 証明書に署名するのに使用されるアルゴリズムはRSAであるに違いありません。
All certificate profiles and 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 that 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>; 証明書。
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 that 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
同じメッセージタイプと構造は証明書要求メッセージへのクライアントの応答に使用されるでしょう。 クライアントがそうするかもしれないことに注意してください。
Dierks & Rescorla Standards Track [Page 41] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[41ページ]。
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:
サーバ証明書メッセージ(送るなら)がクライアントが前マスター秘密を交換するのを許容できるくらいのデータを含まないときだけ、サーバはサーバの主要な交換メッセージを送ります。 以下の主要な交換メソッドに、これは本当です:
DHE_DSS
DHE_RSA
DH_anon
DHE_DSS DHE_RSA DH_、やがて。
It is not legal to send the server key exchange message for the
following key exchange methods:
以下の主要な交換メソッドのためにサーバの主要な交換メッセージを送るのは法的ではありません:
RSA
DH_DSS
DH_RSA
RSA DH_DSS DH_RSA
Meaning of this message:
このメッセージの意味:
This message conveys cryptographic information to allow the client
to communicate the premaster secret: either an RSA public key with
which to encrypt the premaster secret, 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 that 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を定義するときサーバの主要な交換メッセージを送る、主要な交換アルゴリズムに関連づけられた証明書タイプがクライアントが前マスター秘密を交換できるくらいの情報を提供しない場合にだけ。
Dierks & Rescorla Standards Track [Page 42] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[42ページ]。
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)。
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。
Dierks & Rescorla Standards Track [Page 43] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[43ページ]。
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
case rsa:
ServerRSAParams params;
};
} ServerParams;
struct、ケースdiffie_hellman: ServerDHParams paramsケースrsa: (ServerRSAParams params)を選択してください(KeyExchangeAlgorithm);、ServerParams。
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。
struct {
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;
struct、(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 it is appropriate for the selected cipher suite.
選択された暗号スイートに、それが適切であるなら、非匿名のサーバはクライアントから証明書を任意に要求できます。
Dierks & Rescorla Standards Track [Page 44] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[44ページ]。
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が通信する、)
Structure of this message:
このメッセージの構造:
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20),
(255)
enum、rsa_サイン(1)、dss_サイン(2)、_dh(3)、_dh(4)、_のはかない_rsa dh_RESERVED(5)、_のはかない_dss dh_RESERVED(6)、fortezza_dms_RESERVED(20)が修理されたdss_が修理されたrsa_(255)
} ClientCertificateType;
} ClientCertificateType。
opaque DistinguishedName<1..2^16-1>;
DistinguishedName<1について不透明にしてください。2^16-1>。
struct {
ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
struct ClientCertificateType証明書_タイプ<1..2^8-1>; DistinguishedName<0..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 to describe both known roots and a
desired authorization space. If the certificate_authorities
list is empty then the client MAY send any certificate of the
appropriate ClientCertificateType, unless there is some
external arrangement to the contrary.
_許容できる認証局の分類名の当局Aリストを証明してください。 これらの分類名はカリフォルニアか下位のカリフォルニアとして必要な分類名を根に指定するかもしれません。 したがって、知られているルーツと必要な承認スペースの両方について説明するのにこのメッセージを使用できます。 証明書_当局リストが空であるなら、クライアントは適切なClientCertificateTypeのどんな証明書も送るかもしれません、何らかの外部のアレンジメントがそれと反対にない場合。
ClientCertificateType values are divided into three groups:
ClientCertificateType値は3つのグループに分割されます:
1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
reserved for IETF Standards Track protocols.
1. 0(ゼロ)〜63小数(0x3F)まで包括的な値はIETF Standards Trackプロトコルのために予約されます。
2. Values from 64 decimal (0x40) through 223 decimal (0xDF)
inclusive are reserved for assignment for non-Standards Track
methods.
2. 64小数(0×40)から223小数(0xDF)まで包括的な値は非規格Trackメソッドのための課題のために予約されます。
3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
inclusive are reserved for private use.
3. 224小数(0xE0)から255小数(0xFF)まで包括的な値は私的使用目的で予約されます。
Dierks & Rescorla Standards Track [Page 45] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[45ページ]。
Additional information describing the role of IANA in the allocation of ClientCertificateType code points is described in Section 11.
ClientCertificateTypeコード・ポイントの配分でIANAの役割について説明する追加情報がセクション11で説明されます。
Note: Values listed as RESERVED may not be used. They were used in
SSLv3.
以下に注意してください。 RESERVEDが使用されないかもしれないので、値は記載しました。 それらはSSLv3で使用されました。
Note: DistinguishedName is derived from [X501]. DistinguishedNames
are represented in DER-encoded format.
以下に注意してください。 [X501]からDistinguishedNameを得ます。 DistinguishedNamesはDERによってコード化された形式で表されます。
Note: It is a fatal handshake_failure alert for an anonymous server
to request client authentication.
以下に注意してください。 匿名のサーバがクライアント認証を要求するのは、致命的な握手_故障警報です。
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.
こんにちは、されたメッセージ、クライアントSHOULDがサーバを受け取り次第必要なら、サーバがa有効な証明書を提供したことを確かめて、それをチェックする、サーバ、こんにちは、パラメタは許容できます。
Structure of this message:
このメッセージの構造:
struct { } ServerHelloDone;
struct、ServerHelloDone。
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. That is, the certificate_list structure has a
length of zero. 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.
これがサーバを受け取った後にクライアントが送ることができる最初のメッセージである、こんにちは、されたメッセージ。 サーバが証明書を要求する場合にだけ、このメッセージを送ります。 どんな適当な証明書も利用可能でないなら、クライアントSHOULDは証明書を全く含まない証明書メッセージを送ります。 すなわち、証明書_リスト構造には、ゼロの長さがあります。 クライアント認証が握手が続くようにサーバによって必要とされるなら、それは致命的な握手故障警報で応じるかもしれません。 クライアント証明書にセクション7.4.2で定義されたCertificate構造を使用させます。
Dierks & Rescorla Standards Track [Page 46] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[46ページ]。
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 MUST immediately
follow the client certificate message, if it is sent. Otherwise
it MUST 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 that 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
that contained a Diffie-Hellman public key whose parameters (group
and generator) matched those specified by the server in its
certificate, this message MUST 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;
} exchange_keys;
} ClientKeyExchange;
(KeyExchangeAlgorithm)を選択してください。struct、ケースrsa: EncryptedPreMasterSecretケースdiffie_hellman: (ClientDiffieHellmanPublic)は_キーを交換します;、ClientKeyExchange。
7.4.7.1. RSA Encrypted Premaster Secret Message
7.4.7.1. RSAはPremaster秘密の通信を暗号化しました。
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
主要な協定と認証において使用されていて、クライアントが48バイトの前マスター秘密を生成するということであることは、RSAがそうならサーバの証明書か一時的なRSAキーから公開鍵を使用することでそれを暗号化します。
Dierks & Rescorla Standards Track [Page 47] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[47ページ]。
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 and is not a message in
itself.
サーバの主要な交換メッセージに提供して、暗号化された前マスター秘密の通信で結果を送ります。 この構造は、クライアントの主要な交換メッセージの異形であり、本来メッセージではありません。
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.
最新(最も新しい)のバージョンがクライアントでサポートしたクライアント_バージョン。 これは、バージョン後退復帰攻撃を検出するのに使用されます。 前マスター秘密を受け取るこの値が合っているサーバSHOULDチェックのときに、値は、クライアントというクライアントでこんにちはと伝えました。メッセージ。
random
46 securely-generated random bytes.
無作為のしっかりと発生している無作為の46バイト。
struct {
public-key-encrypted PreMasterSecret pre_master_secret;
} EncryptedPreMasterSecret;
struct、公開鍵で暗号化されたPreMasterSecret前_のマスター_秘密;、EncryptedPreMasterSecret。
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で指定されるように。
Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be
used to attack a TLS server that is using PKCS#1 v 1.5 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 v1.5 formatted or not.
以下に注意してください。 攻撃は、ダニエルでTLSサーバを攻撃するのに、Bleichenbacher[BLEI]を使用できると発見しました、すなわち、1.5に対してPKCS#1を使用すると、RSAがコード化されました。 攻撃は1v1.5がフォーマットした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 a server
receives an incorrectly formatted RSA block, it 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ブロックが正しくコード化されるか否かに関係なく、サーバは同様に行動するでしょう。
[PKCS1B] defines a newer version of PKCS#1 encoding that is
more secure against the Bleichenbacher attack. However, for
maximal compatibility with TLS 1.0, TLS 1.1 retains the
original encoding. No variants of the Bleichenbacher attack
[PKCS1B]はBleichenbacher攻撃に対して、より安全なPKCS#1コード化の、より新しいバージョンを定義します。 しかしながら、TLS1.0との最大限度の互換性のために、TLS1.1はオリジナルのコード化を保有します。 Bleichenbacher攻撃の異形がありません。
Dierks & Rescorla Standards Track [Page 48] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[48ページ]。
are known to exist provided that the above recommendations are
followed.
上の推薦が続かれていれば、存在するのが知られています。
Implementation Note: Public-key-encrypted data is represented as an
opaque vector <0..2^16-1> (see Section 4.7).
Thus, the RSA-encrypted PreMasterSecret in a
ClientKeyExchange is preceded by two length
bytes. These bytes are redundant in the case of
RSA because the EncryptedPreMasterSecret is the
only data in the ClientKeyExchange and its
length can therefore be unambiguously
determined. The SSLv3 specification was not
clear about the encoding of public-key-encrypted
data, and therefore many SSLv3 implementations
do not include the length bytes, encoding the
RSA encrypted data directly in the
ClientKeyExchange message.
実装注意: 公開鍵で暗号化されたデータは不透明なベクトル<0として表されます。2^16-1 >(セクション4.7を見ます)。 したがって、ClientKeyExchangeのRSAによって暗号化されたPreMasterSecretは2長さのバイト先行されています。 EncryptedPreMasterSecretがClientKeyExchangeで唯一のデータであり、したがって、明白に長さは測定できるので、これらのバイトはRSAの場合で余分です。 SSLv3仕様は公開鍵で暗号化されたデータのコード化に関して明確ではありませんでした、そして、したがって、多くのSSLv3実装は長さのバイトを含んでいません、そして、RSAをコード化すると、直接ClientKeyExchangeメッセージのデータは暗号化されました。
This specification requires correct encoding of
the EncryptedPreMasterSecret complete with
length bytes. The resulting PDU is incompatible
with many SSLv3 implementations. Implementors
upgrading from SSLv3 must modify their
implementations to generate and accept the
correct encoding. Implementors who wish to be
compatible with both SSLv3 and TLS should make
their implementation's behavior dependent on the
protocol version.
この仕様は長さのバイトで完全なEncryptedPreMasterSecretの正しいコード化を必要とします。 結果として起こるPDUは多くのSSLv3実装と非互換です。 SSLv3からアップグレードする作成者は、正しいコード化を生成して、受け入れるように彼らの実装を変更しなければなりません。 SSLv3とTLSの両方と互換性がありたがっている作成者は彼らの実装の振舞いをプロトコルバージョンに依存するようにするべきです。
Implementation Note: It is now known that remote timing-based attacks
on SSL are possible, at least when the client
and server are on the same LAN. Accordingly,
implementations that use static RSA keys SHOULD
use RSA blinding or some other anti-timing
technique, as described in [TIMING].
実装注意: 今、クライアントとサーバが同じLANにあるとき、SSLに対するリモートタイミングベースの攻撃が可能であることが少なくとも知られています。 それに従って、静的なRSAキーSHOULDを使用する実装が[TIMING]で説明されるようにRSA盲目かある他の反タイミングのテクニックを使用します。
Note: The version number in the PreMasterSecret MUST be the version
offered by the client in the ClientHello, not the version
negotiated for the connection. This feature is designed to
prevent rollback attacks. Unfortunately, many implementations
use the negotiated version instead, and therefore checking the
version number may lead to failure to interoperate with such
incorrect client implementations. Client implementations, MUST
and Server implementations MAY, check the version number. In
practice, since the TLS handshake MACs prevent downgrade and no
good attacks are known on those MACs, ambiguity is not
considered a serious security risk. Note that if servers
choose to check the version number, they should randomize the
以下に注意してください。 PreMasterSecretのバージョン番号は接続のために交渉されたバージョンではなく、ClientHelloのクライアントによって提供されたバージョンであるに違いありません。 この特徴は、ロールバック攻撃を防ぐように設計されています。 残念ながら、多くの実装が代わりに交渉されたバージョンを使用します、そして、したがって、バージョン番号をチェックするのはそのような不正確なクライアント実装で共同利用しないことに通じるかもしれません。 そして、クライアント実装、Server実装5月、バージョン番号をチェックしなければならなくなってください。 TLS握手MACsがダウングレードを防いで、どんな良い攻撃もそれらのMACsで知られていないので、実際には、あいまいさは重大なセキュリティリスクであると考えられません。 サーバが、バージョン番号をチェックするのを選ぶなら、ランダマイズするべきであることに注意してください。
Dierks & Rescorla Standards Track [Page 49] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[49ページ]。
PreMasterSecret in case of error, rather than generate an
alert, in order to avoid variants on the Bleichenbacher attack.
[KPR03]
PreMasterSecret、誤りの場合には、むしろ、Bleichenbacherで異形を避けるために警戒を生成するより攻撃してください。 [KPR03]
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 and 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 it MUST be empty.
内在しているIf、クライアント証明書が既に適当なディフィーヘルマンキーを含んでいて、次に、Ycによって暗黙であり、再び送られる必要はありません。 この場合、クライアントの主要な交換メッセージを送るでしょうが、それは空であるに違いありません。
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 MUST immediately follow the client key exchange message.
このメッセージは、クライアント証明書の明白な検証を提供するのに使用されます。 このメッセージを署名能力を持っているクライアント証明書(固定ディフィー-ヘルマンパラメタを含むもの以外のすなわちすべての証明書)に従わせるだけです。 送ると、それはすぐに、クライアントの主要な交換メッセージに従わなければなりません。
Dierks & Rescorla Standards Track [Page 50] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[50ページ]。
Structure of this message:
このメッセージの構造:
struct {
Signature signature;
} CertificateVerify;
struct、署名署名;、CertificateVerify。
The Signature type is defined in 7.4.3.
Signatureタイプは7.4で.3に定義されます。
CertificateVerify.signature.md5_hash
MD5(handshake_messages);
CertificateVerify.signature.md5_ハッシュMD5(握手_メッセージ)。
CertificateVerify.signature.sha_hash
SHA(handshake_messages);
CertificateVerify.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]。
Dierks & Rescorla Standards Track [Page 51] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[51ページ]。
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 messages in this handshake (not
including any HelloRequest messages) up to but not including
this message. This is only data visible at the handshake
layer and does not include record layer headers. This is the
concatenation of all the Handshake structures, as defined in
7.4, exchanged thus far.
包含だけでないのへのこのメッセージとのこの握手(どんなHelloRequestメッセージも含んでいない)におけるすべてのメッセージからのデータの握手_メッセージAll。 これは、握手層で目に見えるデータだけであり、記録的な層のヘッダーを含んでいません。 これはこれまでのところ交換された7.4で定義されるようにすべての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 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 that is sent second will include the prior one.
_が通信させる値の握手がクライアントで始まるすべての握手メッセージを含んでいる、こんにちは、上がりますが、含んでいなくて、これはメッセージを終えました。 これは証明書を含んでいるでしょう、したがって、.8がメッセージについて確かめるという(送るなら)セクション7.4の握手_メッセージと異なっているかもしれません。 また、クライアントによって送られた終わっているメッセージへの握手_メッセージはそれからサーバによって送られた終わっているメッセージにおいて異なるようになるでしょう、2番目に、送られるのが先のものを含むので。
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.
以下に注意してください。 変化暗号仕様メッセージ、警戒、およびいかなる他のレコード種類も、握手メッセージでなく、またハッシュ計算に含まれていません。 また、Hello Requestメッセージは握手ハッシュから省略されます。
8. Cryptographic Computations
8. 暗号の計算
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.
接続保護を始めるために、TLS Recordプロトコルはひとそろいのアルゴリズム、マスター秘密、クライアント、およびサーバの無作為の値の仕様を必要とします。 認証、暗号化、およびMACアルゴリズムは、サーバによって選択された暗号_スイートのそばで決心していて、こんにちはをサーバで明らかにしました。メッセージ。 圧縮アルゴリズムが交渉される、こんにちは、通信して、中と交換される、無作為が、評価するこんにちは、メッセージ。 残っているすべてはマスター秘密について計算することです。
8.1. Computing the Master Secret
8.1. マスター秘密を計算します。
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.
すべての主要な交換メソッドにおいて、同じアルゴリズムは、前_のマスター_秘密をマスター_秘密に変換するのに使用されます。 マスター_秘密がいったん計算されると、前_のマスター_秘密はメモリから削除されるべきです。
Dierks & Rescorla Standards Track [Page 52] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[52ページ]。
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random)
[0..47];
_が秘密の=PRF(_前_のマスターの秘密の、そして、「マスター秘密」の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.
いつもマスター秘密は長さがちょうど48バイトです。 主要な交換メソッドによって、前マスター秘密の長さは異なるでしょう。
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.
サーバ証明と主要な交換にRSAを使用するとき、前_のマスター_秘密を48バイト、クライアントは生成して、サーバの公開鍵の下で暗号化して、サーバに送ります。サーバは、前_のマスター_秘密を解読するのに秘密鍵を使用します。 そして、双方は上で指定されるとして前_のマスター_秘密をマスター_秘密に変換します。
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デジタル署名は、PKCS#1[PKCS1]ゴシック体1を使用することで実行されます。 RSA公開鍵暗号化は、PKCS#1ゴシック体2を使用することで実行されます。
8.1.2. Diffie-Hellman
8.1.2. ディフィー-ヘルマン
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. Leading bytes of Z that contain all zero bits are stripped before it is used as the pre_master_secret.
従来のディフィー-ヘルマンの計算は実行されます。 交渉されたキー(Z)は、前_のマスター_秘密として使用されて、上で指定されるとしてマスター_秘密に変換されます。 それが前_のマスター_秘密として使用される前にすべてのゼロ・ビットを含む主なバイトのZは剥取られます。
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. 義務的な暗号スイート
In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
別の方法で指定するアプリケーションプロフィール規格がないとき、TLS対応することのアプリケーションは、暗号スイートTLS_RSA_WITH_3DES_EDE_がCBC_SHAであると実装しなければなりません。
10. Application Data Protocol
10. アプリケーションデータプロトコル
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.
アプリケーションデータメッセージは、現在の接続状態に基づいてRecord Layerによって運ばれて、断片化されて、圧縮されて、暗号化されます。 メッセージは記録的な層への見え透いたデータとして扱われます。
11. Security Considerations
11. セキュリティ問題
Security issues are discussed throughout this memo, especially in Appendices D, E, and F.
特にAppendices D、E、およびFでこのメモ中で安全保障問題について議論します。
Dierks & Rescorla Standards Track [Page 53] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[53ページ]。
12. IANA Considerations
12. IANA問題
This document describes a number of new registries that have been created by IANA. We recommended that they be placed as individual registries items under a common TLS category.
このドキュメントはIANAによって作成された多くの新しい登録について説明します。 私たちは、それらが個々の登録項目として一般的なTLSカテゴリの下で置かれることを勧めました。
Section 7.4.3 describes a TLS ClientCertificateType Registry to be maintained by the IANA, defining a number of such code point identifiers. ClientCertificateType identifiers with values in the range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards Action. Values from the range 64-223 (decimal) inclusive are assigned via [RFC2434] Specification Required. Identifier values from 224-255 (decimal) inclusive are reserved for RFC 2434 Private Use. The registry will initially be populated with the values in this document, Section 7.4.4.
Section 7.4.3 describes a TLS ClientCertificateType Registry to be maintained by the IANA, defining a number of such code point identifiers. ClientCertificateType identifiers with values in the range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards Action. Values from the range 64-223 (decimal) inclusive are assigned via [RFC2434] Specification Required. Identifier values from 224-255 (decimal) inclusive are reserved for RFC 2434 Private Use. The registry will initially be populated with the values in this document, Section 7.4.4.
Section A.5 describes a TLS Cipher Suite Registry to be maintained by the IANA, and it defines a number of such cipher suite identifiers. Cipher suite values with the first byte in the range 0-191 (decimal) inclusive are assigned via RFC 2434 Standards Action. Values with the first byte in the range 192-254 (decimal) are assigned via RFC 2434 Specification Required. Values with the first byte 255 (decimal) are reserved for RFC 2434 Private Use. The registry will initially be populated with the values from Section A.5 of this document, [TLSAES], and from Section 3 of [TLSKRB].
Section A.5 describes a TLS Cipher Suite Registry to be maintained by the IANA, and it defines a number of such cipher suite identifiers. Cipher suite values with the first byte in the range 0-191 (decimal) inclusive are assigned via RFC 2434 Standards Action. Values with the first byte in the range 192-254 (decimal) are assigned via RFC 2434 Specification Required. Values with the first byte 255 (decimal) are reserved for RFC 2434 Private Use. The registry will initially be populated with the values from Section A.5 of this document, [TLSAES], and from Section 3 of [TLSKRB].
Section 6 requires that all ContentType values be defined by RFC 2434 Standards Action. IANA has created a TLS ContentType registry, initially populated with values from Section 6.2.1 of this document. Future values MUST be allocated via Standards Action as described in [RFC2434].
Section 6 requires that all ContentType values be defined by RFC 2434 Standards Action. IANA has created a TLS ContentType registry, initially populated with values from Section 6.2.1 of this document. Future values MUST be allocated via Standards Action as described in [RFC2434].
Section 7.2.2 requires that all Alert values be defined by RFC 2434 Standards Action. IANA has created a TLS Alert registry, initially populated with values from Section 7.2 of this document and from Section 4 of [TLSEXT]. Future values MUST be allocated via Standards Action as described in [RFC2434].
Section 7.2.2 requires that all Alert values be defined by RFC 2434 Standards Action. IANA has created a TLS Alert registry, initially populated with values from Section 7.2 of this document and from Section 4 of [TLSEXT]. Future values MUST be allocated via Standards Action as described in [RFC2434].
Section 7.4 requires that all HandshakeType values be defined by RFC 2434 Standards Action. IANA has created a TLS HandshakeType registry, initially populated with values from Section 7.4 of this document and from Section 2.4 of [TLSEXT]. Future values MUST be allocated via Standards Action as described in [RFC2434].
Section 7.4 requires that all HandshakeType values be defined by RFC 2434 Standards Action. IANA has created a TLS HandshakeType registry, initially populated with values from Section 7.4 of this document and from Section 2.4 of [TLSEXT]. Future values MUST be allocated via Standards Action as described in [RFC2434].
Dierks & Rescorla Standards Track [Page 54] RFC 4346 The TLS Protocol April 2006
Dierks & Rescorla Standards Track [Page 54] RFC 4346 The TLS Protocol April 2006
Appendix A. Protocol Constant Values
Appendix 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, 2 }; /* TLS v1.1 */
ProtocolVersion version = { 3, 2 }; /* TLS v1.1 */
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 IV[CipherSpec.block_length];
block-ciphered struct { opaque IV[CipherSpec.block_length];
Dierks & Rescorla Standards Track [Page 55] RFC 4346 The TLS Protocol April 2006
Dierks & Rescorla Standards Track [Page 55] RFC 4346 The TLS Protocol April 2006
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
opaque content[TLSCompressed.length]; 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),
no_certificate_RESERVED (41),
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_RESERVED(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), no_certificate_RESERVED (41), 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_RESERVED(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 & Rescorla Standards Track [Page 56] RFC 4346 The TLS Protocol April 2006
Dierks & Rescorla Standards Track [Page 56] RFC 4346 The TLS Protocol April 2006
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 & Rescorla Standards Track [Page 57] RFC 4346 The TLS Protocol April 2006
Dierks & Rescorla Standards Track [Page 57] RFC 4346 The TLS Protocol April 2006
} 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<0..2^24-1>;
} Certificate;
struct { ASN.1Cert certificate_list<0..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;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
struct { select (KeyExchangeAlgorithm) { case diffie_hellman: ServerDHParams params;
Dierks & Rescorla Standards Track [Page 58] RFC 4346 The TLS Protocol April 2006
Dierks & Rescorla Standards Track [Page 58] RFC 4346 The TLS Protocol April 2006
case rsa:
ServerRSAParams params;
};
} ServerParams;
case rsa: ServerRSAParams params; }; } ServerParams;
struct {
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;
struct { 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;
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20),
(255)
} ClientCertificateType;
enum { rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), fortezza_dms_RESERVED(20), (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<0..2^16-1>;
} CertificateRequest;
struct { ClientCertificateType certificate_types<1..2^8-1>; DistinguishedName certificate_authorities<0..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: ClientDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
struct { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret; case diffie_hellman: ClientDiffieHellmanPublic; } exchange_keys; } ClientKeyExchange;
Dierks & Rescorla Standards Track [Page 59] RFC 4346 The TLS Protocol April 2006
Dierks & Rescorla Standards Track [Page 59] RFC 4346 The TLS Protocol April 2006
struct {
ProtocolVersion client_version;
opaque random[46];
}
PreMasterSecret;
struct { ProtocolVersion client_version; opaque random[46]; } 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>;
} dh_public;
} ClientDiffieHellmanPublic;
struct { select (PublicValueEncoding) { case implicit: struct {}; case explicit: opaque DH_Yc<1..2^16-1>; } 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.1.
A CipherSuite defines a cipher specification supported in TLS Version 1.1.
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.
Dierks & Rescorla Standards Track [Page 60] RFC 4346 The TLS Protocol April 2006
Dierks & Rescorla Standards Track [Page 60] RFC 4346 The TLS Protocol April 2006
CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };
CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
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_WITH_RC4_128_MD5 = { 0x00,0x04 }; CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; 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 (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman parameters are signed by a DSS or RSA certificate that 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.
The following CipherSuite definitions are used for server- authenticated (and optionally client-authenticated) Diffie-Hellman. DH denotes cipher suites in which the server's certificate contains the Diffie-Hellman parameters signed by the certificate authority (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman parameters are signed by a DSS or RSA certificate that 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_WITH_DES_CBC_SHA = { 0x00,0x0C };
CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
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_WITH_DES_CBC_SHA = { 0x00,0x12 };
CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
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_WITH_DES_CBC_SHA = { 0x00,0x0C }; CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; 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_WITH_DES_CBC_SHA = { 0x00,0x12 }; CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; 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_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
When SSLv3 and TLS 1.0 were designed, the United States restricted the export of cryptographic software containing certain strong encryption algorithms. A series of cipher suites were designed to operate at reduced key lengths in order to comply with those regulations. Due to advances in computer performance, these algorithms are now unacceptably weak, and export restrictions have since been loosened. TLS 1.1 implementations MUST NOT negotiate these cipher suites in TLS 1.1 mode. However, for backward compatibility they may be offered in the ClientHello for use with TLS
When SSLv3 and TLS 1.0 were designed, the United States restricted the export of cryptographic software containing certain strong encryption algorithms. A series of cipher suites were designed to operate at reduced key lengths in order to comply with those regulations. Due to advances in computer performance, these algorithms are now unacceptably weak, and export restrictions have since been loosened. TLS 1.1 implementations MUST NOT negotiate these cipher suites in TLS 1.1 mode. However, for backward compatibility they may be offered in the ClientHello for use with TLS
Dierks & Rescorla Standards Track [Page 61] RFC 4346 The TLS Protocol April 2006
Dierks & Rescorla Standards Track [Page 61] RFC 4346 The TLS Protocol April 2006
1.0 or SSLv3-only servers. TLS 1.1 clients MUST check that the server did not choose one of these cipher suites during the handshake. These ciphersuites are listed below for informational purposes and to reserve the numbers.
1.0 or SSLv3-only servers. TLS 1.1 clients MUST check that the server did not choose one of these cipher suites during the handshake. These ciphersuites are listed below for informational purposes and to reserve the numbers.
CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 };
CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };
CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };
CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B };
CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E };
CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
The following cipher suites were defined in [TLSKRB] and are included here for completeness. See [TLSKRB] for details:
以下の暗号スイートは、[TLSKRB]で定義されて、完全性のためにここに含まれています。 詳細に関して[TLSKRB]を見てください:
CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E }:
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F };
CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 };
CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 };
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 };
CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 };
_DES_CBC_SHAとCipherSuite TLS_KRB5_は0×00、0x1Eと等しいです: _3DES_EDE_CBC_SHAとCipherSuite TLS_KRB5_は0×00、0x1Fと等しいです。 0×00、_RC4_128_SHAとCipherSuite TLS_KRB5_=0×20。 0×00、_考え_CBC_SHAとCipherSuite TLS_KRB5_=0×21。 _DES0×00、_CBC_MD5=0x22とCipherSuite TLS_KRB5_。 0×00、_3DES_EDE_CBC_MD5とCipherSuite TLS_KRB5_=0×23。 0×00、_RC4_128_MD5とCipherSuite TLS_KRB5_=0×24。 0×00、_考え_CBC_MD5とCipherSuite TLS_KRB5_=0×25。
The following exportable cipher suites were defined in [TLSKRB] and are included here for completeness. TLS 1.1 implementations MUST NOT negotiate these cipher suites.
以下の輸出向きの暗号スイートは、[TLSKRB]で定義されて、完全性のためにここに含まれています。 TLS1.1に、実装はこれらの暗号スイートを交渉してはいけません。
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26};
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27};
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28};
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29};
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A};
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B};
0×00、_DES_CBC_40_SHA=0×26があるCipherSuite TLS_KRB5_輸出_。 0×00、_RC2_CBC_40_SHA=0×27があるCipherSuite TLS_KRB5_輸出_。 0×00、_RC4_40_SHA=0×28があるCipherSuite TLS_KRB5_輸出_。 0×00、_DES_CBC_40_MD5=0×29があるCipherSuite TLS_KRB5_輸出_。 _RC2_CBC_40_MD5とCipherSuite TLS_KRB5_輸出_は0×00、0x2Aと等しいです。 _RC4_40_MD5とCipherSuite TLS_KRB5_輸出_は0×00、0x2Bと等しいです。
The following cipher suites were defined in [TLSAES] and are included here for completeness. See [TLSAES] for details:
以下の暗号スイートは、[TLSAES]で定義されて、完全性のためにここに含まれています。 詳細に関して[TLSAES]を見てください:
CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x2F };
CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x30 };
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x31 };
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x32 };
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x33 };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x34 };
_AES_128_CBC_SHAとCipherSuite TLS_RSA_は0×00、0x2Fと等しいです。 _AES0×00、_128_CBC_SHA=0x30とCipherSuite TLS_DH_DSS_。 _AES0×00、_128_CBC_SHA=0x31とCipherSuite TLS_DH_RSA_。 _AES0×00、_128_CBC_SHA=0x32とCipherSuite TLS_DHE_DSS_。 _AES0×00、_128_CBC_SHA=0x33とCipherSuite TLS_DHE_RSA_。 CipherSuite TLS_DH、__やがて、_AES_で、128_CBC_SHAは0×00、0×34と等しいです。
Dierks & Rescorla Standards Track [Page 62] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[62ページ]。
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x35 };
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x36 };
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x37 };
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x38 };
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x39 };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A };
_AES0×00、_256_CBC_SHA=0x35とCipherSuite TLS_RSA_。 _AES0×00、_256_CBC_SHA=0x36とCipherSuite TLS_DH_DSS_。 _AES0×00、_256_CBC_SHA=0x37とCipherSuite TLS_DH_RSA_。 _AES0×00、_256_CBC_SHA=0x38とCipherSuite TLS_DHE_DSS_。 _AES0×00、_256_CBC_SHA=0x39とCipherSuite TLS_DHE_RSA_。 CipherSuite TLS_DH、__やがて、_AES_で、256_CBC_SHAは0×00、0x3Aと等しいです。
The cipher suite space is divided into three regions:
暗号スイートのスペースは3つの領域に分割されます:
1. Cipher suite values with first byte 0x00 (zero) through decimal
191 (0xBF) inclusive are reserved for the IETF Standards Track
protocols.
1. 最初に、10進191(0xBF)を通して包括的なバイト0x00(ゼロ)がある暗号スイート値はIETF Standards Trackプロトコルのために予約されます。
2. Cipher suite values with first byte decimal 192 (0xC0) through
decimal 254 (0xFE) inclusive are reserved for assignment for
non-Standards Track methods.
2. 10進254(0xFE)を通した192(0xC0)の最初のバイト小数が包括的の暗号スイート値は非規格Trackメソッドのための課題のために予約されます。
3. Cipher suite values with first byte 0xFF are reserved for
private use.
3. 最初のバイト0xFFがある暗号スイート値は私的使用目的で予約されます。
Additional information describing the role of IANA in the allocation of cipher suite code points is described in Section 11.
暗号スイートコード・ポイントの配分でIANAの役割について説明する追加情報がセクション11で説明されます。
Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
reserved to avoid collision with Fortezza-based cipher suites
in SSL 3.
以下に注意してください。 暗号スイート値の0×00、0x1Cと0×00、0x1Dは、SSL3のFortezzaベースの暗号スイートとの衝突を避けるために予約されます。
A.6. The Security Parameters
A.6。 セキュリティパラメタ
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:
接続状態を初期化するためにこれらのセキュリティパラメタはTLS Handshakeプロトコルで決定して、パラメタとしてTLS Record Layerに提供します。 SecurityParametersは:
enum { null(0), (255) } CompressionMethod;
ヌル(0)、(255)をenumする、CompressionMethod。
enum { server, client } ConnectionEnd;
サーバ、クライアントをenumする、ConnectionEnd。
enum { null, rc4, rc2, des, 3des, des40, aes, idea }
BulkCipherAlgorithm;
ヌル、rc4、rc2、des、3des、des40、aes、考えをenumする、BulkCipherAlgorithm。
enum { stream, block } CipherType;
ストリーム、ブロックをenumする、CipherType。
enum { null, md5, sha } MACAlgorithm;
ヌル、md5がshaするenum、MACAlgorithm。
/* The algorithms specified in CompressionMethod,
BulkCipherAlgorithm, and MACAlgorithm may be added to. */
/*CompressionMethodで指定されたアルゴリズム、BulkCipherAlgorithm、およびMACAlgorithmに追加されるかもしれません。 */
Dierks & Rescorla Standards Track [Page 63] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[63ページ]。
struct {
ConnectionEnd entity;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 key_size;
uint8 key_material_length;
MACAlgorithm mac_algorithm;
uint8 hash_size;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
struct、ConnectionEnd実体、;、BulkCipherAlgorithmは_暗号_アルゴリズムを膨らませます; CipherType暗号_タイプ; uint8の主要な_サイズ; uint8の主要な_の材料_長さ; MACAlgorithm mac_アルゴリズム; uint8ハッシュ_サイズ; CompressionMethod圧縮_アルゴリズム;はマスター_秘密[48]について不透明にします; クライアント_無作為の[32]について不透明にしてください; サーバ_について不透明にしてください 無作為の[32];、SecurityParameters。
Appendix B. Glossary
付録B.用語集
Advanced Encryption Standard (AES)
AES is a widely used symmetric encryption algorithm. AES is a
block cipher with a 128, 192, or 256 bit keys and a 16 byte block
size. [AES] TLS currently only supports the 128 and 256 bit key
sizes.
エー・イー・エス(AES)AESは広く使用された左右対称の暗号化アルゴリズムです。 AESは128があるブロック暗号と、192ビットか256ビットのキーと16バイトのブロック・サイズです。 [AES]TLSは、現在、128と256ビットが主要なサイズであるとサポートするだけです。
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.
アプリケーション・プロトコルAnアプリケーション・プロトコルは通常、トランスポート層(例えば、TCP/IP)の直接上で層にされるプロトコルです。 例はHTTP、TELNET、FTP、およびSMTPを含んでいます。
asymmetric cipher
See public key cryptography.
非対称の暗号See公開鍵暗号。
authentication
Authentication is the ability of one entity to determine the
identity of another entity.
認証Authenticationは1つの実体が別の実体のアイデンティティを決定する能力です。
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.
ブロック暗号Aブロック暗号はブロックと呼ばれるビットのグループで平文を作動させるアルゴリズムです。 64ビットは共通ブロックサイズです。
bulk cipher
A symmetric encryption algorithm used to encrypt large quantities
of data.
左右対称の暗号化アルゴリズムが大量に関するデータを暗号化するのに使用した暗号Aを膨らませてください。
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).
暗号ブロック連鎖(CBC)CBCはブロック暗号で暗号化されたあらゆる平文ブロックが最初に、前の暗号文ブロック(または初期化ベクトルがある最初のブロックの場合で)がある排他的なORedであるモードです。 復号化のために、あらゆるブロックが、前の暗号文ブロック(または、IV)で最初に、解読されて、そして、ORedです排他的な。
Dierks & Rescorla Standards Track [Page 64] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[64ページ]。
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.
X.509プロトコル(通称ISO Authenticationフレームワーク)の証明書As部分、証明書はパーティーのアイデンティティかある他の属性とその公開鍵の間に信じられたCertificate Authorityによって割り当てられて、強い結合を提供します。
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.
クライアント. これがそうするサーバにTLS接続を開始しないかもしれないか、クライアントが基本的な輸送接続を開始したのを含意しないかもしれないアプリケーション実体。 サーバとクライアントのプライマリ操作上の違いは一般に、サーバが認証されるということです、クライアントが任意に認証されるだけですが。
client write key
The key used to encrypt data written by the client.
クライアントはクライアントによって書かれたデータを暗号化するのに使用されるキーをキーに書きます。
client write MAC secret
The secret data used to authenticate data written by the client.
クライアントはクライアントによって書かれたデータを認証するのに使用される機密データをMAC秘密に書きます。
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.
接続A接続は適当なタイプのサービスを提供する輸送(OSIレイヤリングモデル定義における)です。 TLSに関しては、そのような接続はピアツーピア関係です。 接続は一時的です。 すべての接続が1つのセッションに関連しています。
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]
データ暗号化規格DESは非常に広く使用された左右対称の暗号化アルゴリズムです。 DESは56ビットのキーがあるブロック暗号と8バイトのブロック・サイズです。 キー生成目的のために、TLSでは、DESが8バイトのキー長(64ビット)を持っているとして扱われますが、まだ56ビットの保護を提供しているだけであることに注意してください。 (あえてそれぞれの主要なバイトの低ビットがその主要なバイトにおける奇数パリティを生産するように設定されます。) また、3個の独立しているキーと3つの暗号化がそれぞれのブロックのデータに使用されるモードでDESを操作できます。 これは、キー(TLSキー生成メソッドによる24バイト)の168ビットを使用して、セキュリティの112ビットの同等物を提供します。 [デス][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 Signing Algorithmを含むデジタル署名の規格がNIST FIPS PUB186で定義したデジタル署名基準(DSS)、「デジタル署名基準。」(Commerceの米国部のそばの発行された1994年5月) [DSS]
Dierks & Rescorla Standards Track [Page 65] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[65ページ]。
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署名は、認証できる、鍛造するか、または否認するのが難しいデータの署名を起こすのに公開鍵暗号と一方向ハッシュ関数を利用します。
handshake
An initial negotiation between client and server that establishes
the parameters of their transactions.
握手Anはクライアントとサーバとのそれらのトランザクションのパラメタを確立する交渉に頭文字をつけます。
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.
ブロック暗号がCBCモードで使用されるときの初期設定Vector(IV)、初期化ベクトルは暗号化の前の最初の平文ブロックがある排他的なORedです。
IDEA
A 64-bit block cipher designed by Xuejia Lai and James Massey.
[IDEA]
Xuejiaレイとジェームス・マッシーによって設計されたIDEAのA64ビットのブロック暗号。 [考え]
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.
メッセージ立証コード(MAC)Aメッセージ立証コードはメッセージといくつかの機密データから計算された一方向ハッシュです。 機密データを知らないで鍛造するのは難しいです。 目的はメッセージが変更されたかどうか検出することです。
master secret
Secure secret data used for generating encryption keys, MAC
secrets, and IVs.
秘密のSecureが暗号化キー、MAC秘密、および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は固定サイズ(16バイト)のダイジェストに任意に長いデータ・ストリームを変換する安全な論じ尽くす機能です。 [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.
2キーを使う暗号のテクニックの公開鍵暗号Aのクラスが解かれます。 関連秘密鍵で公開鍵で暗号化されたメッセージは解読することができるだけです。 逆に、公開鍵で秘密鍵を契約されたメッセージについて確かめることができます。
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.
任意のデータ量を固定長ハッシュに変換する一方向ハッシュ関数A一方向変換。 変換を逆にするか、または計算上衝突を見つけにくいです。 MD5とSHAは一方向ハッシュ関数に関する例です。
RC2
A block cipher developed by Ron Rivest at RSA Data Security, Inc.
[RSADSI] described in [RC2].
RC2Aブロック暗号は[RC2]で説明されたRSA Data Security Inc.[RSADSI]におけるロンRivestで展開しました。
Dierks & Rescorla Standards Track [Page 66] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[66ページ]。
RC4
A stream cipher invented by Ron Rivest. A compatible cipher is
described in [SCH].
RC4AはロンRivestによって発明された暗号を流します。 コンパチブル暗号は[SCH]で説明されます。
RSA
A very widely used public-key algorithm that can be used for
either encryption or digital signing. [RSA]
RSA Aは非常に広く、暗号化かデジタル署名のどちらかに使用できる公開鍵アルゴリズムを使用しました。 [RSA]
server
The server is the application entity that responds to requests for
connections from clients. See also under client.
サーバ、サーバはクライアントから接続を求める要求に応じるアプリケーション実体です。 クライアントの下で参照。
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 that can be shared among
multiple connections. Sessions are used to avoid the expensive
negotiation of new security parameters for each connection.
セッションA TLSセッションはクライアントとサーバとの仲間です。セッションは握手プロトコルによって作成されます。 セッションは複数の接続の中で共有できる1セットの暗号のセキュリティパラメタを定義します。 セッションは、各接続のために新しいセキュリティパラメタの高価な交渉を避けるのに使用されます。
session identifier
A session identifier is a value generated by a server that
identifies a particular session.
セッション識別子Aセッション識別子は特定のセッションを特定するサーバによって生成された値です。
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.
サーバはサーバによって書かれたデータを認証するのに使用される機密データをMAC秘密に書きます。
SHA
The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
produces a 20-byte output. Note that all references to SHA
actually use the modified SHA-1 algorithm. [SHA]
SHA Secure Hash AlgorithmはFIPS PUB180-2で定義されます。 それは20バイトの出力を起こします。 SHAのすべての参照が実際に変更されたSHA-1アルゴリズムを使用することに注意してください。 [SHA]
SSL
Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
SSL Version 3.0
SSL NetscapeのSecure Socket Layerプロトコル[SSL3]。 TLSはSSLバージョン3.0に基づいています。
stream cipher
An encryption algorithm that converts a key into a
cryptographically strong keystream, which is then exclusive-ORed
with the plaintext.
それがキーを変換する暗号An暗号化アルゴリズムを流してください、暗号で、強いkeystream、次に平文がある排他的なORedである。
symmetric cipher
See bulk cipher.
左右対称の暗号Seeは暗号を膨らませます。
Dierks & Rescorla Standards Track [Page 67] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[67ページ]。
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.
これが議定書の中で述べるLayer Security(TLS)を輸送してください。 インターネット・エンジニアリング・タスク・フォース(IETF)のTransport Layer Securityワーキンググループも。 このドキュメントの端で「コメント」を見てください。
Appendix C. CipherSuite Definitions
付録C.CipherSuite定義
CipherSuite Key Exchange Cipher Hash
CipherSuiteの主要な交換暗号ハッシュ
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_WITH_RC4_128_MD5 RSA RC4_128 MD5 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_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_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_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_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_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_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 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_WITH_RC4_128_MD5 RSA RC4_128 MD5 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_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_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_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_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_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_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 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
Key
Exchange
Algorithm Description Key size limit
主要なExchange Algorithm記述Keyサイズ限界
DHE_DSS Ephemeral DH with DSS signatures None
DHE_RSA Ephemeral DH with RSA signatures None
DH_anon Anonymous DH, no signatures None
DH_DSS DH with DSS-based certificates None
DH_RSA DH with RSA-based certificates None
RSA = none
NULL No key exchange N/A
RSA RSA key exchange None
RSA署名None DH_とDSS署名None DHE_RSA Ephemeral DHとDHE_DSS Ephemeral DH、やがて、更生会DH、NULLのいいえの主要な交換N/A RSA RSAが合わせないRSAベースの証明書None RSA=なにもDSSベースの証明書None DH_RSA DHとどんな署名None DH_DSS DHもNoneを交換しません。
Dierks & Rescorla Standards Track [Page 68] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[68ページ]。
Key Expanded IV Block
Cipher Type Material Key Material Size Size
主要な拡張IVのブロック暗号タイプ物質的な材料サイズキーサイズ
NULL Stream 0 0 0 N/A
IDEA_CBC Block 16 16 8 8
RC2_CBC_40 Block 5 16 8 8
RC4_40 Stream 5 16 0 N/A
RC4_128 Stream 16 16 0 N/A
DES40_CBC Block 5 8 8 8
DES_CBC Block 8 8 8 8
3DES_EDE_CBC Block 24 24 8 8
_なし、_40ブロックのブロック16 16 8 8RC2_CBC5 16 8 8RC4_40が流れるというヌルストリーム0 0 0考えCBC、5、16、0、なし、なし、DES40_CBCブロック5 8 8 8DES_CBCブロック8 8 8 8 3DES_EDE_CBCが妨げるRC4_128ストリーム16 16 0、24 24、8 8
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を広げました。
IV Size
The amount of data needed to be generated for the initialization
vector. Zero for stream ciphers; equal to the block size for
block ciphers.
データの量のIV Sizeは、初期化ベクトルのために生成される必要がありました。 ストリーム暗号のためのゼロ。 ブロックするブロック・サイズへの同輩は解きます。
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
Appendix D. Implementation Notes
付録D.実装注意
The TLS protocol cannot prevent many common security mistakes. This section provides several recommendations to assist implementors.
TLSプロトコルは多くの共通の安全保障誤りを防ぐことができません。 このセクションは作成者を補助するといういくつかの推薦を提供します。
Dierks & Rescorla Standards Track [Page 69] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[69ページ]。
D.1. Random Number Generation and Seeding
D.1。 乱数発生と種子
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は暗号で安全な状態でaを必要とします。擬似ランダム数のジェネレータ(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. Seeding a 128-bit PRNG would thus require approximately 100 such timer values.
作り出される種子の材料の量を見積もるには、それぞれの種子バイトにおける、ビットの予測できない情報の数を加えてください。 例えば、コンパチブルPCの18.2Hzのタイマから取られたキーストロークタイミング値はそれぞれを1ビットか安全な2ビット提供します、対価の総サイズが16ビット以上ですが。 その結果、128ビットのPRNGに種を蒔くのはそのようなおよそ100のタイマ値を必要とするでしょう。
[RANDOM] provides guidance on the generation of random values.
[RANDOM]は無作為の値の世代のときに指導を提供します。
D.2 Certificates and Authentication
D.2証明書と認証
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.3 CipherSuites
D.3 CipherSuites
TLS supports a range of key sizes and security levels, including some that provide no or minimal security. A proper implementation will probably not support many cipher suites. For example, 40-bit encryption is easily broken, so implementations requiring strong security should not allow 40-bit keys. Similarly, anonymous Diffie- Hellman is strongly discouraged because it cannot prevent man-in- the-middle attacks. Applications should also enforce minimum and maximum key sizes. For example, certificate chains containing 512- bit RSA keys or signatures are not appropriate for high-security applications.
TLSは、さまざまな主要な規模とセキュリティがいいえを前提とするいくつかか最小量のセキュリティを含むレベルであると、サポートします。 適切な履行はたぶん多くの暗号スイートを支えないでしょう。 例えば、40ビットの暗号化が容易に壊されるので、強いセキュリティを必要とする実装は40ビットのキーを許容するべきではありません。 中の男性を防ぐことができないので同様に、匿名のディフィー・ヘルマンが強くがっかりしている、-、-、中央、攻撃。 また、アプリケーションは最小の、そして、最大の主要なサイズを実施するべきです。 例えば、512を含む証明書チェーンがRSAキーに噛み付いたか、または高セキュリティアプリケーションには、署名は適切ではありません。
Dierks & Rescorla Standards Track [Page 70] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[70ページ]。
Appendix E. Backward Compatibility with SSL
SSLとの付録のE.の後方の互換性
For historical reasons and in order to avoid a profligate consumption of reserved port numbers, application protocols that are secured by TLS 1.1, 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.1、TLS1.0、SSL3.0、およびSSL2.0によって保証されるアプリケーション・プロトコルはすべて、予約されたポートナンバーの放蕩な消費を避けるために頻繁に同じ接続ポートを共有します。 例えば、httpsプロトコル(SSLかTLSによって保証されたHTTP)はそれが使用しているどのセキュリティプロトコルにかかわらずポート443を使用するか。 したがって、何らかのメカニズムが、様々なプロトコルの中で区別して、交渉するのにおいて決定しているに違いありません。
TLS versions 1.1 and 1.0, and SSL 3.0 are very similar; thus,
supporting both is easy. TLS clients who wish to negotiate with such
older servers SHOULD send client hello messages using the SSL 3.0
record format and client hello structure, sending {3, 2} for the
version field to note that they support TLS 1.1. If the server
supports only TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0
server hello; if it supports TLS 1.1 it will respond with a TLS 1.1
server hello. The negotiation then proceeds as appropriate for the
negotiated protocol.
TLSバージョンは1.1、1.0、およびSSL3.0に非常に同様です。 したがって、両方をサポートするのは簡単です。 そのようなより古いサーバSHOULDと交渉したがっているTLSクライアントがこんにちは、SSL3.0レコード形式を使用するメッセージとクライアントをクライアントに送る、こんにちは、バージョン分野が、TLSが1.1であるとサポートすることに注意するように3、2を送って、構造化します。 サーバがTLS1.0かSSL3.0だけをサポートすると、downrev3.0サーバで応じる、こんにちは。 TLSが1.1であるとサポートすると、それはTLS1.1サーバで応じるでしょう。こんにちは。 そして、交渉は交渉されたプロトコルのために適宜続きます。
Similarly, a TLS 1.1 server that wishes to interoperate with TLS 1.0
or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages and
respond with a SSL 3.0 server hello if an SSL 3.0 client hello with a
version field of {3, 0} is received, denoting that this client does
not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a
version field of {3, 1} is received, the server SHOULD respond with a
TLS 1.0 hello with a version field of {3, 1}.
同様に、TLS1.0と共に共同利用したがっているTLS1.1サーバかSSL3.0クライアントSHOULDがSSL3.0クライアントを受け入れる、こんにちは、SSL3.0サーバで通信して、応じる、こんにちは、こんにちは、3、0のバージョン野原を受け取っていてSSL3.0クライアントであるなら、このクライアントがTLSをサポートしないのを指示します。 こんにちは、3、1のバージョン野原を受け取っていて同様に、サーバSHOULDはSSL3.0かTLS1.0であるならTLS1.0と共に応じます。3、1のバージョン分野でこんにちは。
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.
クライアントが既にサーバに知られている中で最も高いプロトコルを知って(例えばセッションを再開するとき)、それがSHOULDであるときはいつも、その固有のプロトコルにおける接続を開始してください。
TLS 1.1 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.1に、SSLバージョンが2.0のサーバであるとサポートするクライアントはこんにちは、SSLバージョン2.0クライアントメッセージ[SSL2]を送らなければなりません。 TLSサーバSHOULDがどちらのクライアントも受け入れる、こんにちは、同じ接続ポートの上の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クライアントを送る能力、こんにちは、メッセージはすべての当然の迅速で段階的に廃止されるでしょう。 作成者SHOULDは、できるだけ急速に前方へ動くためにあらゆる努力します。 バージョン3.0は、より新しいバージョンに移行するのにより良いメカニズムを提供します。
Dierks & Rescorla Standards Track [Page 71] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[71ページ]。
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 };
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 };
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。 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 SHOULDのいずれも送るクライアントがTLS同等物を入れます(Appendix A.5を見てください):
V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
V2CipherSpec(TLS名を見る)は0×00、CipherSuiteと等しいです。
Note: TLS 1.1 clients may generate the SSLv2 EXPORT cipher suites in
handshakes for backward compatibility but MUST NOT negotiate them
in TLS 1.1 mode.
以下に注意してください。 1.1人のクライアントがSSLv2 EXPORTを生成するかもしれないTLSは後方の互換性のための握手でスイートを解きますが、TLS1.1モードでそれらを交渉してはいけません。
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. Note that this message MUST be sent directly on the wire, not wrapped as an SSLv3 record
バージョン2.0クライアント、こんにちは、このドキュメントのプレゼンテーションモデルを使用する下にメッセージは提示されます。 本当の定義はSSLバージョン2.0仕様であるとまだ思われています。 SSLv3記録として包装されるのではなく、このメッセージを直接ワイヤに送らなければならないことに注意してください。
uint8 V2CipherSpec[3];
uint8 V2CipherSpec[3]。
struct {
uint16 msg_length;
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];
opaque challenge[V2ClientHello.challenge_length;
} V2ClientHello;
struct、uint16 msg_長さ; uint8 msg_タイプ; バージョンバージョン; uint16暗号_仕様_の長さ; uint16セッション_イド_の長さ; uint16の挑戦_長さ; V2CipherSpecは_仕様[V2ClientHello.cipher_仕様_の長さ]を解きます; セッション_イド[V2ClientHello.session_イド_の長さ]について不透明にしてください; 挑戦について不透明にしてください、[V2ClientHello.challenge_の長さ;、V2ClientHello。
Dierks & Rescorla Standards Track [Page 72] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[72ページ]。
msg_length
This field is the length of the following data in bytes. The high
bit MUST be 1 and is not part of the length.
Thisがさばくmsg_長さはバイトで表現される以下のデータの長さです。 高いビットは、1でなければならなく、長さの一部ではありません。
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)であったならSHOULDを評価してください。
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)の倍数であるに違いありません。
session_id_length
This field MUST have a value of zero.
Thisがさばくセッション_イド_の長さはゼロの値を持たなければなりません。
challenge_length
The length in bytes of the client's challenge to the server to
authenticate itself. When using the SSLv2 backward compatible
handshake the client MUST use a 32-byte challenge.
_クライアントのバイトで表現される長さがそれ自体を認証するのをサーバに挑む長さに挑戦してください。 SSLv2の後方のコンパチブル握手を使用するとき、クライアントは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
This field MUST be empty.
セッション_イドThis分野は人影がないに違いありません。
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 MUST use a TLS client
hello.
以下に注意してください。 TLSセッションを再開するという要求はTLSクライアントを使用しなければなりません。こんにちは。
Dierks & Rescorla Standards Track [Page 73] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[73ページ]。
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互換性モードをバージョンに支持して、彼らはSHOULD使用特別な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 SHOULDをサポートするサーバがこれらの8詰め物バイトが0×03であるなら誤りを発行します。 通常、この様に水増しされたブロックを受け取るバージョン2.0サーバが続くでしょう。
Appendix 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
TLSは3つの認証モードをサポートします: 双方、非認証されたクライアント、および総匿名によるサーバ証明の認証。 サーバが認証されるときはいつも、チャンネルは介入者攻撃に対して安全ですが、完全に匿名のセッションは本来そのような攻撃に被害を受け易いです。 匿名のサーバはクライアントを認証できません。 サーバが認証されるなら、証明書メッセージは許容できる認証局に通じる有効な証明書チェーンを提供しなければなりません。 同様に、認証されたクライアントは許容できる証明書を供給しなければなりません。
Dierks & Rescorla Standards Track [Page 74] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[74ページ]。
server. Each party is responsible for verifying that the other's certificate is valid and has not expired or been revoked.
サーバ各当事者は、もう片方の証明書が有効であることを確かめるのに責任があって、吐き出されるか、または取り消されていません。
The general goal of the key exchange process is to create a pre_master_secret known to the communicating parties and not to attackers. The pre_master_secret will be used to generate the master_secret (see Section 8.1). The master_secret is required to generate the 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 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.
主要な交換にRSAかディフィー・ヘルマンを使用することで完全に匿名のセッションを確立できます。 匿名のRSAと共に、サーバの非公認された公開鍵がサーバの主要な交換メッセージから抽出されている状態で、クライアントは前_のマスター_秘密を暗号化します。 クライアントの主要な交換メッセージで結果を送ります。 立ち聞きする者がサーバの秘密鍵を知らないので、彼らが前_のマスター_秘密を解読するのは、実行不可能でしょう。
Note: 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 either may be contained in the server's certificate or may be a temporary RSA key sent in a server key exchange message. When temporary RSA keys are used, they are signed by the server's RSA 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証明書によって署名されます。 署名が現在のClientHello.randomを含んでいるので、古い署名と一時的なキーを再演できません。 サーバは複数の交渉セッションのために主要な独身の一時的なRSAを使用するかもしれません。
Note: The temporary RSA key option is useful if servers need large
以下に注意してください。 役に立ちますが、一時的なRSA主要なオプションはサーバの必要性大きいです。
Dierks & Rescorla Standards Track [Page 75] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[75ページ]。
certificates but must comply with government-imposed size
limits on keys used for key exchange.
証明書にもかかわらず、必須は主要な交換に使用されるキーの上に政府によって課されたサイズ限界に従います。
Note that if ephemeral RSA is not used, compromise of the server's static RSA key results in a loss of confidentiality for all sessions protected under that static key. TLS users desiring Perfect Forward Secrecy should use DHE cipher suites. The damage done by exposure of a private key can be limited by changing one's private key (and certificate) frequently.
はかないRSAが使用されていないなら、すべてのセッションのための秘密性の損失におけるサーバの静的なRSA主要な結果の感染がその静的なキーの下に保護されたことに注意してください。 Perfect Forward Secrecyを望んでいるTLSユーザはDHE暗号スイートを使用するべきです。 頻繁に人の秘密鍵(そして、証明書)を変えることによって、秘密鍵の暴露によって与えられる損害は制限できます。
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は現在の握手プロセスに署名を縛ります)。
F.1.1.3. Diffie-Hellman Key Exchange with Authentication
F.1.1.3。 認証とのディフィー-ヘルマンの主要なExchange
When Diffie-Hellman key exchange is used, the server can either supply a certificate containing fixed Diffie-Hellman parameters or 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セットの一時的なパラメタをクライアントの主要な交換メッセージにおけるサーバに送って、次に、任意に、証明書がメッセージについて確かめる用途はそれ自体を認証します。
Dierks & Rescorla Standards Track [Page 76] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[76ページ]。
If the same DH keypair is to be used for multiple handshakes, either because the client or server has a certificate containing a fixed DH keypair or because the server is reusing DH keys, care must be taken to prevent small subgroup attacks. Implementations SHOULD follow the guidelines found in [SUBGROUP].
同じDH keypairが複数の握手に使用されるつもりであるなら、クライアントかサーバには固定DH keypairを含む証明書があるか、またはサーバがDHキーを再利用しているので、小さいサブグループ攻撃を防ぐために注意しなければなりません。 実装SHOULDは[SUBGROUP]で見つけられたガイドラインに従います。
Small subgroup attacks are most easily avoided by using one of the DHE ciphersuites and generating a fresh DH private key (X) for each handshake. If a suitable base (such as 2) is chosen, g^X mod p can be computed very quickly, therefore the performance cost is minimized. Additionally, using a fresh key for each handshake provides Perfect Forward Secrecy. Implementations SHOULD generate a new X for each handshake when using DHE ciphersuites.
DHE ciphersuitesの1つを使用して、各握手のために新鮮なDHが秘密鍵(X)であると生成することによって、小さいサブグループ攻撃は最も容易に避けられます。 適当なベース(2などの)が選ばれているなら、非常にすぐにg^Xモッズpを計算できます、したがって、性能費用は最小にされます。 さらに、各握手に新鮮なキーを使用すると、Perfect Forward Secrecyは提供されます。 DHE ciphersuitesを使用するとき、実装SHOULDは各握手のための新しいXを生成します。
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 use 40-bit encryption keys. 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バイト増強するのに同等であるので。
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 chooses.
攻撃者は、影響を及ぼすだろうよりパーティーが握手交換で異なった暗号化アルゴリズムを選択するのに影響を及ぼそうとするかもしれません。通常、選びます。
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つ以上の握手メッセージを変えなければなりません。 これが起こると、クライアントとサーバは握手メッセージハッシュのために異価を計算するでしょう。 その結果、パーティーはそれぞれ他のものの終わっているメッセージを受け入れないでしょう。 マスター_秘密がなければ、攻撃者が終わっているメッセージを修理できないので、攻撃は発見されるでしょう。
Dierks & Rescorla Standards Track [Page 77] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[77ページ]。
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と共に論じ尽くされます。
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回のパーティーからのメッセージをもう片方の出力に挿入できません。 同様に、サーバで書いていてクライアントと同じくらい書いているキーが独立しているので、ストリーム暗号キーは一度だけ使用されます。
Dierks & Rescorla Standards Track [Page 78] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[78ページ]。
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. Explicit IVs
F.3。 明白なIVs
[CBCATT] describes a chosen plaintext attack on TLS that depends on knowing the IV for a record. Previous versions of TLS [TLS1.0] used the CBC residue of the previous record as the IV and therefore enabled this attack. This version uses an explicit IV in order to protect against this attack.
[CBCATT]は記録でIVを知っているのによるTLSに選ばれた平文攻撃を説明します。 TLS[TLS1.0]の旧バージョンは、IVとして前の記録のCBCの残りを使用して、したがって、この攻撃を可能にしました。 このバージョンは、この攻撃から守るのに明白なIVを使用します。
F.4. Security of Composite Cipher Modes
F.4。 合成暗号モードのセキュリティ
TLS secures transmitted application data via the use of symmetric encryption and authentication functions defined in the negotiated ciphersuite. The objective is to protect both the integrity and confidentiality of the transmitted data from malicious actions by active attackers in the network. It turns out that the order in which encryption and authentication functions are applied to the data plays an important role for achieving this goal [ENCAUTH].
TLSは、伝えられたアプリケーションがデータであると交渉されたciphersuiteで定義された左右対称の暗号化と認証機能の使用で機密保護します。 目的はネットワークにおける活発な攻撃者による悪意がある行為から保全と伝えられたデータの秘密性の両方を保護することです。 どの暗号化と認証機能がデータに適用されているかのオーダーがこの目標[ENCAUTH]を達成するために重要な役割を果たすと判明します。
The most robust method, called encrypt-then-authenticate, first applies encryption to the data and then applies a MAC to the ciphertext. This method ensures that the integrity and confidentiality goals are obtained with ANY pair of encryption and MAC functions, provided that the former is secure against chosen plaintext attacks and that the MAC is secure against chosen-message attacks. TLS uses another method, called authenticate-then-encrypt, in which first a MAC is computed on the plaintext and then the concatenation of plaintext and MAC is encrypted. This method has been proven secure for CERTAIN combinations of encryption functions and MAC functions, but it is not guaranteed to be secure in general. In particular, it has been shown that there exist perfectly secure encryption functions (secure even in the information-theoretic sense) that combined with any secure MAC function, fail to provide the confidentiality goal against an active attack. Therefore, new ciphersuites and operation modes adopted into TLS need to be analyzed under the authenticate-then-encrypt method to verify that they achieve the stated integrity and confidentiality goals.
最も強健なメソッドであって、呼ばれる、暗号化、次に、認証する、データへの暗号化がまず最初に、適用されて、暗号文へのMACはその時、適用します。 このメソッドはMACが確実に前者が選ばれた平文攻撃に対して安全であればどんな組の暗号化とMAC機能でも保全と秘密性目標を得て、選ばれたメッセージ攻撃に対して安全になるようにします。 TLSは別のメソッドを使用します、呼ばれて認証、次に、暗号化する、最初に、a MACがどれであるかで、暗号化された平文とMACの平文と次に、連結のときに、計算されています。 このメソッドは暗号化機能とMAC機能のCERTAIN組み合わせに安全であると立証されましたが、それは、一般に、安全になるように保証されません。 特に、どんな安全なMAC機能にも結合した完全に安全な暗号化機能(情報理論的な意味でさえ安全な)が存在するのが示されて、活発な攻撃に対して秘密性目標を提供しないでください。 したがって、新しいciphersuitesとオペレーションモードが分析される必要性をTLSに採用した、認証、次に、暗号化する、彼らが述べられた保全と秘密性目標を達成することを確かめるメソッド。
Dierks & Rescorla Standards Track [Page 79] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[79ページ]。
Currently, the security of the authenticate-then-encrypt method has been proven for some important cases. One is the case of stream ciphers in which a computationally unpredictable pad of the length of the message, plus the length of the MAC tag, is produced using a pseudo-random generator and this pad is xor-ed with the concatenation of plaintext and MAC tag. The other is the case of CBC mode using a secure block cipher. In this case, security can be shown if one applies one CBC encryption pass to the concatenation of plaintext and MAC and uses a new, independent, and unpredictable IV for each new pair of plaintext and MAC. In previous versions of SSL, CBC mode was used properly EXCEPT that it used a predictable IV in the form of the last block of the previous ciphertext. This made TLS open to chosen plaintext attacks. This version of the protocol is immune to those attacks. For exact details in the encryption modes proven secure, see [ENCAUTH].
現在のセキュリティ、認証、次に、暗号化する、メソッドはいくつかの重要な例のために立証されました。 1つはメッセージの長さの計算上予測できないパッド、およびMACタグの長さが擬似ランダムジェネレータを使用することで生産されて、平文とMACタグの連結でこのパッドがxor-教育であるストリーム暗号に関するケースです。 もう片方が安全なブロック暗号を使用するCBCモードに関するケースです。 この場合、セキュリティは、1つが1個のCBC暗号化パスを適用するかどうかを平文とMACの連結に示すことができて、平文とMACの各新しいペアに新しくて、独立していて、予測できないIVを使用します。 SSLの旧バージョンでは、前の暗号文の最後のブロックの形で予測できるIVを使用したのを除いて、CBCモードは適切に使用されました。 これで、TLSは選ばれた平文攻撃に開かれるようになりました。 プロトコルのこのバージョンはそれらの攻撃に免疫です。 安全であると立証された暗号化モードによる正確な詳細に関しては、[ENCAUTH]を見てください。
F.5. Denial of Service
F.5。 サービス妨害
TLS is susceptible to a number of denial of service (DoS) attacks. In particular, an attacker who initiates a large number of TCP connections can cause a server to consume large amounts of CPU doing RSA decryption. However, because TLS is generally used over TCP, it is difficult for the attacker to hide his point of origin if proper TCP SYN randomization is used [SEQNUM] by the TCP stack.
TLSはサービス(DoS)攻撃の多くの否定に影響されやすいです。 特に、多くのTCP接続を開始する攻撃者はサーバにRSA復号化をする多量のCPUを消費させることができます。 しかしながら、TLSがTCPの上で一般に使用されるので、適切なTCP SYN無作為化がTCPスタックによって使用されるなら[SEQNUM]、攻撃者が彼の原産地を隠すのは、難しいです。
Because TLS runs over TCP, it is also susceptible to a number of denial of service attacks on individual connections. In particular, attackers can forge RSTs, thereby terminating connections, or forge partial TLS records, thereby causing the connection to stall. These attacks cannot in general be defended against by a TCP-using protocol. Implementors or users who are concerned with this class of attack should use IPsec AH [AH-ESP] or ESP [AH-ESP].
TLSがTCPをひくので、また、それも個々の接続の多くのサービス不能攻撃に影響されやすいです。 攻撃者は特に、RSTsを鍛造して、その結果、接続を終えるか、または部分的なTLS記録を作り出して、その結果、接続が失速することを引き起こすことができます。 一般に、TCPを使用しているプロトコルはこれらの攻撃に防御できません。 このクラスの攻撃に関する作成者かユーザがIPsec AH[AH-超能力]か超能力[AH-超能力]を使用するべきです。
F.6. Final Notes
F.6。 最後通達
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 & Rescorla Standards Track [Page 80] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[80ページ]。
Normative References
引用規格
[AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard (AES)"
FIPS 197. November 26, 2001.
[AES]米国商務省標準技術局、「エー・イー・エス(AES)のための仕様」FIPS197。 2001年11月26日。
[3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To
DES," IEEE Spectrum, v. 16, n. 7, July 1979, pp. 40-41.
[3DES]W.タクマン、「ヘルマンはデスの近道のソリューションを全く提示しない」IEEE Spectrum、v。 16、n。 7 1979年7月、ページ 40-41.
[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。
[DSS] NIST FIPS PUB 186-2, "Digital Signature Standard,"
National Institute of Standards and Technology, U.S.
Department of Commerce, 2000.
[DSS]NIST FIPSパブ186-2、「デジタル署名基準」、米国商務省標準技術局、米国商務省、2000。
[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。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321,
April 1992.
[MD5] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[PKCS1A] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1:
RSA Cryptography Specifications Version 1.5", RFC 2313,
March 1998.
[PKCS1A]B.Kaliski、「公開鍵暗号化標準(PKCS)#1:」 RSA暗号仕様バージョン1.5インチ、RFC2313、3月1998日
[PKCS1B] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
(PKCS) #1: RSA Cryptography Specifications Version 2.1",
RFC 3447, February 2003.
[PKCS1B]J.イェンソン、B.Kaliski、「公開鍵暗号化標準(PKCS)#1:」 RSA暗号仕様バージョン2.1インチ、RFC3447、2月2003日
[PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[PKIX] Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[RC2] Rivest, R., "A Description of the RC2(r) Encryption
Algorithm", RFC 2268, March 1998.
[RC2] Rivest、R.、「RC2(r)暗号化アルゴリズムの記述」、RFC2268、1998年3月。
[SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms,
and Source Code in C, 2ed", Published by John Wiley &
Sons, Inc. 1996.
[SCH]B.シュナイアー。 「適用された暗号:」 ジョンワイリーと息子によって発行された「C、2edのプロトコル、アルゴリズム、およびソースコード」Inc.1996。
Dierks & Rescorla Standards Track [Page 81] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[81ページ]。
[SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National
Institute of Standards and Technology, U.S. Department of
Commerce., August 2001.
[SHA]NIST FIPSパブ180-2、「安全なハッシュ規格」、米国商務省標準技術局、米国商務省、8月2001日
[REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[REQ] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[TLSAES] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)", RFC
3268, June 2002.
[TLSAES]Chown、2002年6月のP.、「トランスポート層セキュリティ(TLS)のためのエー・イー・エス(AES)Ciphersuites」RFC3268。
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003.
[TLSEXT]ブレーク-ウィルソン、S.、ニストロム、M.、Hopwood(D.、ミッケルセン、J.、およびT.ライト)は「層のセキュリティ(TLS)拡大を輸送します」、RFC3546、2003年6月。
[TLSKRB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712,
October 1999.
[TLSKRB] MedvinskyとA.とM.Hur、「トランスポート層セキュリティ(TLS)へのケルベロス暗号スイートの追加」、RFC2712、1999年10月。
Informative References
有益な参照
[AH-ESP] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[ああ、-、超能力、]、ケント、S.、「IP認証ヘッダー」、RFC4302、12月2005日
Eastlake 3rd, D., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4305, December 2005.
イーストレーク3番目、D.、「セキュリティが有効搭載量(超能力)と認証ヘッダー(ああ)であるとカプセル化するための暗号アルゴリズム実装要件」、RFC4305、2005年12月。
[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.
[CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
Problems and Countermeasures",
http://www.openssl.org/~bodo/tls-cbc.txt.
[CBCATT]メラー、B.、「SSL/TLSのCBC Ciphersuitesのセキュリティ:」 「問題と対策」、 http://www.openssl.org/~bodo/tls-cbc.txt 。
[CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel",
http://lasecwww.epfl.ch/memo_ssl.shtml, 2003.
[CBCTIME] Canvel、B.、「SSL/TLSチャンネルにおけるパスワード妨害」、 http://lasecwww.epfl.ch/memo_ssl.shtml 、2003。
[ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
for Protecting Communications (Or: How Secure is SSL?)",
Crypto 2001.
[ENCAUTH]Krawczyk、H.、「Protecting Communications(: または、SecureはどうSSLですか?)のためのEncryptionとAuthenticationのOrder」Crypto2001。
Dierks & Rescorla Standards Track [Page 82] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[82ページ]。
[KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
March 2003.
2003年3月の[KPR03]クリマ対ポコルニー、O.、ローザ、T.が「SSL/TLSでRSAベースのセッションを攻撃すること」での http://eprint.iacr.org/2003/052/
[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月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005.
イーストレークとD.と3番目、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」[無作為]のBCP106、2005年6月のRFC4086。
[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.
[SEQNUM] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996.
[SEQNUM]Bellovin S. (「一連番号攻撃に対して防御すること」でのRFC1948)は1996がそうするかもしれません。
[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プロトコル」、ネットスケープ・コミュニケーションズ。
[SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
Attacks on the Diffie-Hellman Key Agreement Method for
S/MIME", RFC 2785, March 2000.
[サブグループ] Zuccherato、R.、「S/MIMEのためにディフィー-ヘルマンの主要な協定メソッドに対する「小さいサブグループ」攻撃を避けるためのメソッド」、RFC2785(2000年3月)。
[TCP] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005.
[TCP] ヘルストリョームとG.とP.ジョーンズ、「テキストの会話のためのRTP有効搭載量」、RFC4103、2005年6月。
[TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
practical", USENIX Security Symposium 2003.
[TIMING] Boneh、D.、Brumley、D.、「リモートタイミング攻撃は実用的である」USENIX Security Symposium2003。
[TLS1.0] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[TLS1.0] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[X501] ITU-T Recommendation X.501: Information Technology - Open
Systems Interconnection - The Directory: Models, 1993.
[X501]ITU-T推薦X.501: 情報技術--オープン・システム・インターコネクション--ディレクトリ: モデル、1993。
[X509] ITU-T Recommendation X.509 (1997 E): Information
Technology - Open Systems Interconnection - "The Directory
- Authentication Framework". 1988.
[X509]ITU-T推薦X.509(1997E): 情報技術(オープン・システム・インターコネクション)、「ディレクトリ--認証、フレームワーク、」 1988.
Dierks & Rescorla Standards Track [Page 83] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[83ページ]。
[XDR] Srinivasan, R., "XDR: External Data Representation
Standard", RFC 1832, August 1995.
[XDR]Srinivasan、R.、「XDR:」 「外部データ表現規格」、RFC1832、1995年8月。
Authors' Addresses
作者のアドレス
Working Group Chairs
作業部会いす
Win Treese
Win Treese
EMail: treese@acm.org
メール: treese@acm.org
Eric Rescorla
エリック・レスコラ
EMail: ekr@rtfm.com
メール: ekr@rtfm.com
Editors
エディターズ
Tim Dierks Independent
ティムDierks Independent
EMail: tim@dierks.org
メール: tim@dierks.org
Eric Rescorla RTFM, Inc.
エリックレスコラRTFM Inc.
EMail: ekr@rtfm.com
メール: ekr@rtfm.com
Other Contributors
他の貢献者
Christopher Allen (co-editor of TLS 1.0) Alacrity Ventures EMail: ChristopherA@AlacrityManagement.com
クリストファー・アレン(TLS1.0の共同エディタ)敏活ベンチャーはメールされます: ChristopherA@AlacrityManagement.com
Martin Abadi University of California, Santa Cruz EMail: abadi@cs.ucsc.edu
マーチンAbadiカリフォルニア大学、サンタクルスメール: abadi@cs.ucsc.edu
Ran Canetti IBM EMail: canetti@watson.ibm.com
カネッティIBM EMailは走りました: canetti@watson.ibm.com
Dierks & Rescorla Standards Track [Page 84] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[84ページ]。
Taher Elgamal Securify EMail: taher@securify.com
タヘルElgamal Securifyはメールします: taher@securify.com
Anil Gangolli EMail: anil@busybuddha.org
コマツナギGangolliメール: anil@busybuddha.org
Kipp Hickman
キップ・ヒックマン
Phil Karlton (co-author of SSLv3)
フィルKarlton(SSLv3の共著者)
Paul Kocher (co-author of SSLv3) Cryptography Research EMail: paul@cryptography.com
ポール・コッハー(SSLv3の共著者)暗号研究メール: paul@cryptography.com
Hugo Krawczyk Technion Israel Institute of Technology EMail: hugo@ee.technion.ac.il
ユーゴーKrawczyk Technionイスラエル工科大学EMail: hugo@ee.technion.ac.il
Robert Relyea Netscape Communications EMail: relyea@netscape.com
ロバートレリアネットスケープ・コミュニケーションズEMail: relyea@netscape.com
Jim Roskind Netscape Communications EMail: jar@netscape.com
ジムRoskindネットスケープ・コミュニケーションズEMail: jar@netscape.com
Michael Sabin
マイケル・セービン
Dan Simon Microsoft, Inc. EMail: dansimon@microsoft.com
ダンサイモンマイクロソフトInc.EMail: dansimon@microsoft.com
Tom Weinstein
トム・ワインスタイン
Dierks & Rescorla Standards Track [Page 85] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[85ページ]。
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/>にあります。
Archives of the list can be found at:
<http://www.imc.org/ietf-tls/mail-archive/>
以下でリストのアーカイブを見つけることができます。 <メールhttp://www.imc.org/ietf-tls/アーカイブ/>。
Dierks & Rescorla Standards Track [Page 86] RFC 4346 The TLS Protocol April 2006
DierksとレスコラStandardsはTLSプロトコル2006年4月にRFC4346を追跡します[86ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Dierks & Rescorla Standards Track [Page 87]
Dierksとレスコラ標準化過程[87ページ]
一覧
スポンサーリンク
