RFC5246 日本語訳
5246 The Transport Layer Security (TLS) Protocol Version 1.2. T.Dierks, E. Rescorla. August 2008. (Format: TXT=222395 bytes) (Obsoletes RFC3268, RFC4346, RFC4366) (Updates RFC4492) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group T. Dierks Request for Comments: 5246 Independent Obsoletes: 3268, 4346, 4366 E. Rescorla Updates: 4492 RTFM, Inc. Category: Standards Track August 2008
Dierksがコメントのために要求するワーキンググループT.をネットワークでつないでください: 5246年の無党派は以下を時代遅れにします。 3268、4346、4366のE.レスコラアップデート: 4492年のRTFM Inc.カテゴリ: 標準化過程2008年8月
The Transport Layer Security (TLS) Protocol
Version 1.2
トランスポート層セキュリティ(TLS)プロトコルバージョン1.2
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document specifies Version 1.2 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.2を指定します。 TLSプロトコルはインターネットの上に通信秘密保全を提供します。 プロトコルで、クライアント/サーバ・アプリケーションは盗み聞くのを防ぐように設計されている道、改ざん、またはメッセージ偽造で伝えます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Requirements Terminology ...................................5
1.2. Major Differences from TLS 1.1 .............................5
2. Goals ...........................................................6
3. Goals of This Document ..........................................7
4. Presentation Language ...........................................7
4.1. Basic Block Size ...........................................7
4.2. Miscellaneous ..............................................8
4.3. Vectors ....................................................8
4.4. Numbers ....................................................9
4.5. Enumerateds ................................................9
4.6. Constructed Types .........................................10
4.6.1. Variants ...........................................10
4.7. Cryptographic Attributes ..................................12
4.8. Constants .................................................14
5. HMAC and the Pseudorandom Function .............................14
6. The TLS Record Protocol ........................................15
6.1. Connection States .........................................16
6.2. Record Layer ..............................................19
6.2.1. Fragmentation ......................................19
1. 序論…4 1.1. 要件用語…5 1.2. TLS1.1からの主要な違い…5 2. 目標…6 3. このドキュメントの目標…7 4. プレゼンテーション言語…7 4.1. 文節サイズ…7 4.2. その他…8 4.3. ベクトル…8 4.4. 数…9 4.5. 列挙品目…9 4.6. タイプを構成します…10 4.6.1. 異形…10 4.7. 暗号の属性…12 4.8. 定数…14 5. HMACと擬似ランダムは機能します…14 6. TLSはプロトコルを記録します…15 6.1. 接続州…16 6.2. 層を記録してください…19 6.2.1. 断片化…19
Dierks & Rescorla Standards Track [Page 1] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[1ページ]。
6.2.2. Record Compression and Decompression ...............20
6.2.3. Record Payload Protection ..........................21
6.2.3.1. Null or Standard Stream Cipher ............22
6.2.3.2. CBC Block Cipher ..........................22
6.2.3.3. AEAD Ciphers ..............................24
6.3. Key Calculation ...........................................25
7. The TLS Handshaking Protocols ..................................26
7.1. Change Cipher Spec Protocol ...............................27
7.2. Alert Protocol ............................................28
7.2.1. Closure Alerts .....................................29
7.2.2. Error Alerts .......................................30
7.3. Handshake Protocol Overview ...............................33
7.4. Handshake Protocol ........................................37
7.4.1. Hello Messages .....................................38
7.4.1.1. Hello Request .............................38
7.4.1.2. Client Hello ..............................39
7.4.1.3. Server Hello ..............................42
7.4.1.4. Hello Extensions ..........................44
7.4.1.4.1. Signature Algorithms ...........45
7.4.2. Server Certificate .................................47
7.4.3. Server Key Exchange Message ........................50
7.4.4. Certificate Request ................................53
7.4.5. Server Hello Done ..................................55
7.4.6. Client Certificate .................................55
7.4.7. Client Key Exchange Message ........................57
7.4.7.1. RSA-Encrypted Premaster Secret Message ....58
7.4.7.2. Client Diffie-Hellman Public Value ........61
7.4.8. Certificate Verify .................................62
7.4.9. Finished ...........................................63
8. Cryptographic Computations .....................................64
8.1. Computing the Master Secret ...............................64
8.1.1. RSA ................................................65
8.1.2. Diffie-Hellman .....................................65
9. Mandatory Cipher Suites ........................................65
10. Application Data Protocol .....................................65
11. Security Considerations .......................................65
12. IANA Considerations ...........................................65
Appendix A. Protocol Data Structures and Constant Values ..........68
A.1. Record Layer ..............................................68
A.2. Change Cipher Specs Message ...............................69
A.3. Alert Messages ............................................69
A.4. Handshake Protocol ........................................70
A.4.1. Hello Messages .....................................71
A.4.2. Server Authentication and Key Exchange Messages ....72
A.4.3. Client Authentication and Key Exchange Messages ....74
A.4.4. Handshake Finalization Message .....................74
A.5. The Cipher Suite ..........................................75
A.6. The Security Parameters ...................................77
6.2.2. 圧縮と減圧を記録してください…20 6.2.3. 有効搭載量保護を記録してください…21 6.2.3.1. ヌルの、または、標準のストリーム暗号…22 6.2.3.2. CBCは暗号を妨げます…22 6.2.3.3. AEADは解きます…24 6.3. 主要な計算…25 7. TLSハンドシェイクプロトコル…26 7.1. 暗号仕様プロトコルを変えてください…27 7.2. プロトコルを警告してください…28 7.2.1. 閉鎖警戒…29 7.2.2. 誤り警戒…30 7.3. 握手プロトコル概要…33 7.4. 握手プロトコル…37 7.4.1. こんにちは、メッセージ…38 7.4.1.1. こんにちは、要求…38 7.4.1.2. クライアント、こんにちは…39 7.4.1.3. サーバ、こんにちは…42 7.4.1.4. こんにちは、拡大…44 7.4.1.4.1. 署名アルゴリズム…45 7.4.2. サーバ証明書…47 7.4.3. サーバの主要な交換メッセージ…50 7.4.4. 要求を証明してください…53 7.4.5. サーバ、こんにちは、します…55 7.4.6. クライアント証明書…55 7.4.7. クライアントの主要な交換メッセージ…57 7.4.7.1. RSAによって暗号化されたPremaster秘密の通信…58 7.4.7.2. クライアントのディフィー-ヘルマンの公共の価値…61 7.4.8. 証明書、確かめます。62 7.4.9. 終わっています…63 8. 暗号の計算…64 8.1. マスター秘密を計算します…64 8.1.1. RSA…65 8.1.2. ディフィー-ヘルマン…65 9. 義務的な暗号スイート…65 10. アプリケーションデータは議定書を作ります…65 11. セキュリティ問題…65 12. IANA問題…65付録A.はデータ構造と恒常価値について議定書の中で述べます…68 A.1。 層を記録してください…68 A.2。 暗号眼鏡メッセージを変えてください…69 A.3。 警告メッセージ…69 A.4。 握手プロトコル…70 A.4.1。 こんにちは、メッセージ…71 A.4.2。 サーバー証明とキーはメッセージを交換します…72 A.4.3。 クライアント認証とキーはメッセージを交換します…74 A.4.4。 握手決定メッセージ…74 A.5。 暗号スイート…75 A.6。 セキュリティパラメタ…77
Dierks & Rescorla Standards Track [Page 2] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[2ページ]。
A.7. Changes to RFC 4492 .......................................78
Appendix B. Glossary ..............................................78
Appendix C. Cipher Suite Definitions ..............................83
Appendix D. Implementation Notes ..................................85
D.1. Random Number Generation and Seeding ......................85
D.2. Certificates and Authentication ...........................85
D.3. Cipher Suites .............................................85
D.4. Implementation Pitfalls ...................................85
Appendix E. Backward Compatibility ................................87
E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 ................87
E.2. Compatibility with SSL 2.0 ................................88
E.3. Avoiding Man-in-the-Middle Version Rollback ...............90
Appendix F. Security Analysis .....................................91
F.1. Handshake Protocol ........................................91
F.1.1. Authentication and Key Exchange ....................91
F.1.1.1. Anonymous Key Exchange ....................91
F.1.1.2. RSA Key Exchange and Authentication .......92
F.1.1.3. Diffie-Hellman Key Exchange with
Authentication ............................92
F.1.2. Version Rollback Attacks ...........................93
F.1.3. Detecting Attacks Against the Handshake Protocol ...94
F.1.4. Resuming Sessions ..................................94
F.2. Protecting Application Data ...............................94
F.3. Explicit IVs ..............................................95
F.4. Security of Composite Cipher Modes ........................95
F.5. Denial of Service .........................................96
F.6. Final Notes ...............................................96
Normative References ..............................................97
Informative References ............................................98
Working Group Information ........................................101
Contributors .....................................................101
A.7。 RFC4492への変化…78付録B.用語集…78付録C.はスイート定義を解きます…83 付録D.実装注意…85 D.1。 乱数発生であって種子…85 D.2。 証明書と認証…85 D.3。 スイートを解いてください…85 D.4。 実装落とし穴…85 付録のE.の後方の互換性…87 E.1。 TLS1.0/1.1との互換性とSSL3.0…87 E.2。 SSL2.0との互換性…88 E.3。 中央の男性バージョンロールバックを避けます…90 付録F.証券分析…91 F.1。 握手プロトコル…91 F.1.1。 認証と主要な交換…91 F.1.1.1。 匿名の主要な交換…91 F.1.1.2。 RSAの主要な交換と認証…92 F.1.1.3。 認証とのディフィー-ヘルマンの主要なExchange…92 F.1.2。 バージョンロールバックは攻撃されます…93 F.1.3。 握手に対して攻撃を検出して、議定書を作ってください…94 F.1.4。 再開します…94 F.2。 アプリケーションデータを保護します…94 F.3。 明白なIVs…95 F.4。 合成物のセキュリティはモードを解きます…95 F.5。 サービス妨害…96 F.6。 最終的な注意…96 標準の参照…97 有益な参照…98 ワーキンググループ情報…101人の貢献者…101
Dierks & Rescorla Standards Track [Page 3] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[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., AES [AES], 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.
- 接続は個人的です。 左右対称の暗号はデータ暗号化(例えば、AES[AES]、RC4[SCH]など)に使用されます。 この左右対称の暗号化のためのキーは、各接続のために唯一生成されて、別のプロトコル(TLS Handshakeプロトコルなどの)によって交渉された秘密に基づいています。 また、暗号化なしでRecordプロトコルを使用できます。
- The connection is reliable. Message transport includes a message
integrity check using a keyed MAC. Secure hash functions (e.g.,
SHA-1, 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-1など)は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], DSA [DSS], etc.). This
authentication can be made optional, but is generally required for
at least one of the peers.
- 同輩のアイデンティティが認証された使用非対称である場合がある、公開鍵、暗号(例えば、RSA[RSA]、DSA[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.
- 交渉は信頼できます: コミュニケーションへのパーティーによって検出されないで、どんな攻撃者も交渉コミュニケーションを変更できません。
Dierks & Rescorla Standards Track [Page 4] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[4ページ]。
One advantage of TLS is that it is application protocol independent. Higher-level protocols can layer on top of the TLS protocol transparently. The TLS standard, however, does not specify how protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS.
TLSの1つの利点はそれがアプリケーション・プロトコル独立者であるということです。 上位レベル・プロトコルはTLSプロトコルの上で透過的に層にされることができます。 しかしながら、TLS規格はプロトコルがTLSと共にセキュリティをどう加えるかを指定しません。 どのようにTLSハンドシェイクに着手するか、そして、どのように証明書が交換した認証を解釈するかに関する決定はTLSの上で稼働するプロトコルのデザイナーと作成者の判断に任せます。
1.1. Requirements Terminology
1.1. 要件用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [REQ].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[REQ]で説明されるように本書では解釈されることであるべきですか?
1.2. Major Differences from TLS 1.1
1.2. TLS1.1からの主要な違い
This document is a revision of the TLS 1.1 [TLS1.1] protocol which contains improved flexibility, particularly for negotiation of cryptographic algorithms. The major changes are:
このドキュメントは改良された柔軟性を含むTLS1.1[TLS1.1]プロトコルの改正です、特に暗号アルゴリズムの交渉のために。大きな変化は以下の通りです。
- The MD5/SHA-1 combination in the pseudorandom function (PRF) has
been replaced with cipher-suite-specified PRFs. All cipher suites
in this document use P_SHA256.
- 擬似ランダム機能(PRF)におけるMD5/SHA-1組み合わせを暗号スイートが指定しているPRFsに取り替えました。 すべての暗号スイートが本書ではP_SHA256を使用します。
- The MD5/SHA-1 combination in the digitally-signed element has been
replaced with a single hash. Signed elements now include a field
that explicitly specifies the hash algorithm used.
- デジタルに署名している要素におけるMD5/SHA-1組み合わせをただ一つのハッシュに取り替えました。 署名している要素は現在、明らかに使用されるハッシュアルゴリズムを指定する分野を含んでいます。
- Substantial cleanup to the client's and server's ability to
specify which hash and signature algorithms they will accept.
Note that this also relaxes some of the constraints on signature
and hash algorithms from previous versions of TLS.
- それらがどのハッシュと署名アルゴリズムを受け入れるかを指定するクライアントとサーバの能力へのかなりのクリーンアップ。 また、これが署名とハッシュアルゴリズムでTLSの旧バージョンから規制のいくつかを弛緩することに注意してください。
- Addition of support for authenticated encryption with additional
data modes.
- 追加データモードがある認証された暗号化のサポートの追加。
- TLS Extensions definition and AES Cipher Suites were merged in
from external [TLSEXT] and [TLSAES].
- TLS Extensions定義とAES Cipher Suitesでは、外部の[TLSEXT]と[TLSAES]から、合併されました。
- Tighter checking of EncryptedPreMasterSecret version numbers.
- EncryptedPreMasterSecretバージョン番号の、よりきつい照合。
- Tightened up a number of requirements.
- 多くの要件を強化しました。
- Verify_data length now depends on the cipher suite (default is
still 12).
- _データの長さについて確かめてください。現在、スイートは暗号によります(それでも、デフォルトは12です)。
- Cleaned up description of Bleichenbacher/Klima attack defenses.
- Bleichenbacher/クリマ攻撃ディフェンスの記述をきれいにしました。
Dierks & Rescorla Standards Track [Page 5] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[5ページ]。
- Alerts MUST now be sent in many cases.
- 多くの場合、現在、警戒を送らなければなりません。
- After a certificate_request, if no certificates are available,
clients now MUST send an empty certificate list.
- 証明書_要求の後に、どんな証明書も利用可能でないなら、クライアントは現在、空の証明書リストを送らなければなりません。
- TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement
cipher suite.
- 現在、TLS_RSA_WITH_AES_128_CBC_SHAは暗号がスイートであると実装する義務的です。
- Added HMAC-SHA256 cipher suites.
- 加えられたHMAC-SHA256はスイートを解きます。
- Removed IDEA and DES cipher suites. They are now deprecated and
will be documented in a separate document.
- 取り除かれたIDEAとDESはスイートを解きます。 それらは、現在、推奨しなく、別々のドキュメントに記録されるでしょう。
- Support for the SSLv2 backward-compatible hello is now a MAY, not
a SHOULD, with sending it a SHOULD NOT. Support will probably
become a SHOULD NOT in the future.
- 後方コンパチブルSSLv2のサポート、こんにちは、現在はSHOULDではなく、SHOULD NOTをそれに送るのがある5月です。 サポートは将来、たぶんSHOULD NOTになるでしょう。
- Added limited "fall-through" to the presentation language to allow
multiple case arms to have the same encoding.
- 複数のケースを許容するプレゼンテーション言語に加えられた限られた「通じて、低下すること」は、同じコード化を持つために軍備されます。
- Added an Implementation Pitfalls sections
- Implementation Pitfalls部を加えます。
- The usual clarifications and editorial work.
- 普通の明確化と社説は働いています。
2. Goals
2. 目標
The goals of the TLS protocol, in order of 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を利用するアプリケーションを開発できるべきです。
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プロトコルは最初から設立される必要があるポートの数を減少させるために体系をキャッシュする任意のセッションを取り入れました。 さらに、ネットワーク活動を抑えるために、注意しました。
Dierks & Rescorla Standards Track [Page 6] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[6ページ]。
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 the various versions of TLS and SSL 3.0 do not interoperate (although each protocol incorporates a mechanism by which an implementation can back down to 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の違いは劇的ではありませんが、それらはTLSと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だけにはこのプレゼンテーション言語の目的があります。 それには、その特定の目標を超えて一般的適用が全くありません。
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 byte stream, a multi-byte item (a numeric in the example) is formed (using C notation) by:
すべてのデータ項目の表現は明らかに指定されます。 基礎データブロック・サイズは1バイト(すなわち、8ビット)です。 左から右までデータ項目は先端から下部への複数のバイト、バイトの連結です。 バイト・ストリームから、マルチバイト項目(例の数値)は以下によって形成されます(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.
マルチバイト値のためのこのバイト順は、平凡なネットワークバイトオーダーかビッグエンディアン形式です。
Dierks & Rescorla Standards Track [Page 7] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[7ページ]。
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 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, which is 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
以下の例では、義務的であるのは、300〜400バイトのタイプ不透明なものを含まなければならないベクトルです。 それは空であるはずがありません。 実際の長さの分野は2バイト、uint16を消費します(セクション4.4を見てください)。(uint16は値400を表すことができます)。 他方ではと、より長い間、最大800バイトのデータ、または400のuint16要素を表すことができて、それは空であるかもしれません。 コード化はaを含むでしょう。
Dierks & Rescorla Standards Track [Page 8] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[8ページ]。
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).
2バイトの実際の長さの分野はベクトルにprependedされました。 コード化されたベクトルの長さはただ一つの要素の長さの同等の倍数であるに違いありません(例えば、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 byte (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に同等です。
Note that in some cases (e.g., DH parameters) it is necessary to represent integers as opaque vectors. In such cases, they are represented as unsigned integers (i.e., leading zero octets are not required even if the most significant bit is set).
そんなにいくつかの場合、不透明なベクトルとして整数を表すのが必要であることに注意してください(例えば、DHパラメタ)。 そのような場合、それらは符号のない整数として表されます(最も重要なビットが設定されても、すなわち、先行ゼロ八重奏は必要ではありません)。
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の分野は定義で宣言された値を仮定できるだけです。 各定義は異なったタイプです。 同じタイプの列挙品目だけを割り当てられてもよいか、または比較してもよいです。 あらゆる要素、列挙された必須では、値は以下の例に示されるように割り当てられてください。 列挙の要素が注文されないので、どんなオーダーでもどんなユニークな値もそれらに割り当てることができます。
enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
enum、e1(v1)、e2(v2)、…、en(vn)、[(n)]]、Te。
An enumerated occupies 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)は着色します。
Dierks & Rescorla Standards Track [Page 9] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[9ページ]。
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番目の野原について言及します。 構造定義は埋め込まれるかもしれません。
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. Case arms have limited fall-through: if two case arms follow in immediate succession with no fields in between, then they
定義された構造で、異形は何らかの環境の中で利用可能な知識に基づいているかもしれません。 セレクタは構造が定義する可能な異形を定義する列挙型であるに違いありません。 選ぶところで宣言された列挙のあらゆる要素のためのケースアームがあるに違いありません。 ケース兵器は、通じて低下するのを制限しました: 2が兵器をケースに入れるなら、即座の継承では、間、次に、それらで分野なしで続いてください。
Dierks & Rescorla Standards Track [Page 10] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[10ページ]。
both contain the same fields. Thus, in the example below, "orange" and "banana" both contain V2. Note that this is a new piece of syntax in TLS 1.2.
両方が同じ分野を含んでいます。 したがって、以下の例では、「オレンジ」と「バナナ」はともにV2を含んでいます。 これがTLS1.2の新しい片の構文であることに注意してください。
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 e3: case e4: Te3;
....
case en: Ten;
} [[fv]];
} [[Tv]];
T1 f1; T2 f2; Tn fn; (E)を選択してください。struct、e4をケースに入れてください: Te3、e1をケースに入れてください: Te1; ケースe2: Te2;はe3をケースに入れます: アンをケースに入れてください: 10[[fv]];、[[Tv]]。
For example:
例えば:
enum { apple, orange, banana } VariantTag;
りんご、オレンジ、バナナをenumする、VariantTag。
struct {
uint16 number;
opaque string<0..10>; /* variable length */
} V1;
structの*uint16番号; 不透明なストリング<0..10>;/可変な長さ*/V1。
struct {
uint32 number;
opaque string[10]; /* fixed length */
} V2;
struct uint32番号; 不透明なストリング[10];/*固定長*/V2。
struct {
select (VariantTag) { /* value of selector is implicit */
case apple:
V1; /* VariantBody, tag = apple */
case orange:
case banana:
V2; /* VariantBody, tag = orange or banana */
} variant_body; /* optional label on variant */
} VariantRecord;
(VariantTag)を選択してください。struct、セレクタの/*値は内在している*/ケースりんごです: V1; タグ=りんご*/ケースオレンジ: ケースバナナ: /*VariantBody、V2; /*VariantBody、タグ=オレンジまたはバナナ*/、異形_ボディー; 異形*/の/*任意のラベル、VariantRecord。
Dierks & Rescorla Standards Track [Page 11] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[11ページ]。
4.7. Cryptographic Attributes
4.7. 暗号の属性
The five cryptographic operations -- digital signing, stream cipher encryption, block cipher encryption, authenticated encryption with additional data (AEAD) encryption, and public key encryption -- are designated digitally-signed, stream-ciphered, block-ciphered, aead- 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).
5つの暗号の操作--デジタル署名、ストリーム暗号暗号化(ブロック暗号暗号化)は追加データ(AEAD)暗号化、および公開鍵暗号化による暗号化--解かれたデジタルに署名していて、ストリームで解かれて、ブロックで解かれたaeadに指定されて、公開鍵によって暗号化されているのをそれぞれ認証しました。 フィールドの暗号の処理は、フィールドのタイプ仕様の前に適切なキーワード名称をprependingすることによって、指定されます。 暗号化キーは現在のセッション州によって含意されます(セクション6.1を見てください)。
A digitally-signed element is encoded as a struct DigitallySigned:
デジタルに署名している要素はstruct DigitallySignedとしてコード化されます:
struct {
SignatureAndHashAlgorithm algorithm;
opaque signature<0..2^16-1>;
} DigitallySigned;
struct SignatureAndHashAlgorithmアルゴリズム; 不透明な署名<0..2^16-1>;DigitallySigned。
The algorithm field specifies the algorithm used (see Section 7.4.1.4.1 for the definition of this field). Note that the introduction of the algorithm field is a change from previous versions. The signature is a digital signature using those algorithms over the contents of the element. The contents themselves do not appear on the wire but are simply calculated. The length of the signature is specified by the signing algorithm and key.
アルゴリズム分野が使用されるアルゴリズムを指定する、(セクション7.4.1を見てください、.4、この分野の定義のための.1) アルゴリズム分野の導入が旧バージョンからの変化であることに注意してください。 署名は要素のコンテンツの上でそれらのアルゴリズムを使用するデジタル署名です。 内容自体は、ワイヤの上に現れませんが、単に計算されます。 署名の長さは署名アルゴリズムとキーによって指定されます。
In RSA signing, the opaque vector contains the signature generated using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. As discussed in [PKCS1], the DigestInfo MUST be DER-encoded [X680] [X690]. For hash algorithms without parameters (which includes SHA-1), the DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL, but implementations MUST accept both without parameters and with NULL parameters. Note that earlier versions of TLS used a different RSA signature scheme that did not include a DigestInfo encoding.
RSA署名では、不透明なベクトルは[PKCS1]で定義されたRSASSA-PKCS1-v1_5署名体系を使用することで生成された署名を含んでいます。 [PKCS1]で議論するように、DigestInfoはDERによってコード化された[X680][X690]であるに違いない。 パラメタ(SHA-1を含んでいる)のないハッシュアルゴリズムのために、DigestInfo.AlgorithmIdentifier.parameters分野はNULLでなければなりませんが、実装はパラメタなしでNULLパラメタで受け入れなければなりません。 TLSの以前のバージョンがDigestInfoコード化を含んでいなかった異なったRSA署名体系を使用したことに注意してください。
In DSA, the 20 bytes of the SHA-1 hash are run directly through the Digital Signing Algorithm with no additional hashing. This produces two values, r and s. The DSA signature is an opaque vector, as above, the contents of which are the DER encoding of:
DSAでは、SHA-1ハッシュの20バイトは追加論じ尽くすことのないDigital Signing Algorithm直接を通した走行です。 これは2つの値、r、およびsを生産します。 DSA署名は上の不透明なベクトルです。それの内容は以下のDERコード化です。
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
以下をDss-Sig評価してください:= 系列r整数、s整数
Dierks & Rescorla Standards Track [Page 12] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[12ページ]。
Note: In current terminology, DSA refers to the Digital Signature Algorithm and DSS refers to the NIST standard. In the original SSL and TLS specs, "DSS" was used universally. This document uses "DSA" to refer to the algorithm, "DSS" to refer to the standard, and it uses "DSS" in the code point definitions for historical continuity.
以下に注意してください。 現在の用語で、DSAはDigital Signature Algorithmについて言及します、そして、DSSはNIST規格について言及します。 オリジナルのSSLとTLS眼鏡では、「DSS」は一般に使用されました。 このドキュメントはアルゴリズム、規格について言及する「DSS」について言及するのに"DSA"を使用します、そして、それは歴史的な連続にコードポイント定義に「DSS」を使用します。
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 AEAD encryption, the plaintext is simultaneously encrypted and integrity protected. The input may be of any length, and aead- ciphered output is generally larger than the input in order to accommodate the integrity check value.
AEAD暗号化では、平文は同時に暗号化されました、そして、保全は保護されました。 入力がどんな長さのものであるかもしれなくも、一般に、aeadの解かれた出力は、保全チェック価値を収容するために入力より大きいです。
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 encryption algorithm and key.
公開鍵暗号化では、公開鍵アルゴリズムは、単に合っている秘密鍵でそれを解読することができるような方法でデータを暗号化するのに使用されます。 公開鍵で暗号化された要素は不透明なベクトル<0としてコード化されます。2^16-1 >。(そこでは、長さが暗号化アルゴリズムとキーによって指定されます)。
RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme defined in [PKCS1].
RSA暗号化は[PKCS1]で定義されたRSAES-PKCS1-v1_5暗号化体系を使用し終わっています。
In the following example
以下の例で
stream-ciphered struct {
uint8 field1;
uint8 field2;
digitally-signed opaque {
uint8 field3<0..255>;
uint8 field4;
};
} UserType;
ストリームで解かれたstruct uint8 field1; uint8 field2; 不透明なものuint8 field3<0..255>(uint8 field4)にデジタルに署名する;UserType。
The contents of the inner struct (field3 and field4) are used as input for the signature/hash 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 signature and hash algorithm, plus two bytes for the length of the signature, plus the length of the output of the signing
内側のstruct(field3とfield4)の内容は署名/ハッシュアルゴリズムのために入力されるように使用されています、そして、次に、全体の構造はストリーム暗号で暗号化されます。 バイトで表現されるこの構造の長さはfield1とfield2のための2バイト、署名とハッシュアルゴリズムのための2バイト、および署名の長さ、および署名の出力の長さのための2バイトと等しいでしょう。
Dierks & Rescorla Standards Track [Page 13] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[13ページ]。
algorithm. The length of the signature is known because the algorithm and key used for the signing are known prior to encoding or decoding this structure.
アルゴリズム。 この構造をコード化するか、または解読する前に署名に使用されるアルゴリズムとキーが知られているので、署名の長さは知られています。
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と擬似ランダム機能
The TLS record layer uses a keyed Message Authentication Code (MAC) to protect message integrity. The cipher suites defined in this document use a construction known as HMAC, described in [HMAC], which is based on a hash function. Other cipher suites MAY define their own MAC constructions, if needed.
TLSの記録的な層は、メッセージの保全を保護するのに、合わせられたメッセージ立証コード(MAC)を使用します。 本書では定義された暗号スイートはハッシュ関数に基づいている[HMAC]で説明されたHMACとして知られている工事を使用します。 必要であるなら、他の暗号スイートはそれら自身のMAC構造を定義するかもしれません。
In addition, a construction is required to do expansion of secrets into blocks of data for the purposes of key generation or validation. This pseudorandom function (PRF) takes as input a secret, a seed, and an identifying label and produces an output of arbitrary length.
さらに、工事が、キー生成か合法化の目的のためのブロックのデータに秘密の拡張をするのに必要です。 (PRF)が取るこの擬似ランダム機能は、秘密、種子、および特定ラベルを入力して、任意の長さの出力を起こします。
In this section, we define one PRF, based on HMAC. This PRF with the SHA-256 hash function is used for all cipher suites defined in this document and in TLS documents published prior to this document when TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a stronger standard hash function.
このセクションで、私たちはHMACに基づいて1PRFを定義します。 SHA-256ハッシュ関数があるこのPRFは本書では定義されたすべての暗号スイートとTLS1.2が交渉されるときこのドキュメントの前で発表されたTLSドキュメントで使用されます。 新しい暗号スイートは明らかにPRFを指定しなければなりません、そして、一般に、SHOULDはSHA-256とTLS PRFか、より強い標準のハッシュ関数を使用します。
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_は任意の量の出力に秘密と種子を広げるのにただ一つのハッシュ関数を使用する(秘密、データ)を論じ尽くします:
Dierks & Rescorla Standards Track [Page 14] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[14ページ]。
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 necessary to produce the required quantity of data. For example, if P_SHA256 is being used to create 80 bytes of data, it will have to be iterated three times (through A(3)), creating 96 bytes of output data; the last 16 bytes of the final iteration will then be discarded, leaving 80 bytes of output data.
必要な量のデータを作り出すために必要な同じくらい何回もP_ハッシュを繰り返すことができます。 例えば、P_SHA256が80バイトのデータを作成するのに使用されていると、それが3回繰り返されなければならない、(96バイトの出力データを作成するA(3))を通して。 そして、80バイトの出力をデータに残して、最終的な繰り返しのベスト16バイトは捨てられるでしょう。
TLS's PRF is created by applying P_hash to the secret as:
TLSのPRFは、以下としてP_ハッシュを秘密に適用することによって、作成されます。
PRF(secret, label, seed) = P_<hash>(secret, label + seed)
PRF(秘密、ラベルに種を蒔く)はP_<ハッシュ>と等しいです。(秘密、ラベル+種子)
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
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 protocols that use the record protocol 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 content types can be supported by the record protocol. New record content type values are assigned by IANA in the TLS Content Type Registry as described in Section 12.
記録的なプロトコルを使用する4つのプロトコルが本書では説明されます: 握手プロトコル、注意深いプロトコル、変化暗号仕様プロトコル、およびアプリケーションデータは議定書を作ります。 TLSプロトコルの拡大を許すために、記録的なプロトコルは追加記録的なcontent typeをサポートすることができます。 新しい記録的なcontent type値はセクション12で説明されるようにTLS Content Type RegistryのIANAによって割り当てられます。
Dierks & Rescorla Standards Track [Page 15] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[15ページ]。
Implementations MUST NOT send record types not defined in this document unless negotiated by some extension. If a TLS implementation receives an unexpected record type, it MUST send an unexpected_message alert.
実装は何らかの拡大で本書では交渉されない場合定義されなかったレコード種類を送ってはいけません。 TLS実装が予期していなかったレコード種類を受け取るなら、それは予期していなかった_メッセージアラートを送らなければなりません。
Any protocol designed for use over TLS must be carefully designed to deal with all possible attacks against it. As a practical matter, this means that the protocol designer must be aware of what security properties TLS does and does not provide and cannot safely rely on the latter.
それに対してすべての可能な攻撃に対処するように入念にTLSの上の使用のために設計されたどんなプロトコルも設計しなければなりません。 実際問題として、これは、プロトコルデザイナーが特性のTLSがどんなセキュリティをするかを意識しているに違いないことを意味して、提供しないで、安全に後者を当てにすることができません。
Note in particular that type and length of a record are not protected by encryption. If this information is itself sensitive, application designers may wish to take steps (padding, cover traffic) to minimize information leakage.
記録のタイプと長さが暗号化で保護されないことに特に注意してください。 この情報がそれ自体で機密であるなら、アプリケーション設計者は、情報漏出を最小にするために手を打ちたがっているかもしれません(詰め物、カバートラフィック)。
6.1. Connection States
6.1. 接続州
A TLS connection state is the operating environment of the TLS Record Protocol. It specifies a compression algorithm, an encryption algorithm, and a MAC algorithm. In addition, the parameters for these algorithms are known: the MAC key 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 ChangeCipherSpec 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プロトコルで未定の州のためのセキュリティパラメタを設定できて、ChangeCipherSpecが選択的に未定の州のどちらかを現在にすることができて、その場合、処分して、適切な現状を未定の状態に取り替えます。 そして、未定の状態は人影のない状態に再初期化されます。 セキュリティパラメタで初期化されていない状態を現状にするのは不法です。 初速度電流州は、いつもどんな暗号化、圧縮も、または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。
PRF algorithm
An algorithm used to generate keys from the master secret (see
Sections 5 and 6.3).
PRFアルゴリズムAnアルゴリズムは以前はマスター秘密からキーをよく生成していました(セクション5と6.3を見てください)。
Dierks & Rescorla Standards Track [Page 16] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[16ページ]。
bulk encryption algorithm
An algorithm to be used for bulk encryption. This specification
includes the key size of this algorithm, whether it is a block,
stream, or AEAD cipher, the block size of the cipher (if
appropriate), and the lengths of explicit and implicit
initialization vectors (or nonces).
暗号化アルゴリズムAnアルゴリズムを膨らませて、大量の暗号化に使用されてください。 この仕様はこのアルゴリズム、それがブロックであるか、そして、ストリーム、またはAEAD暗号の主要なサイズ、暗号のブロック・サイズ(適切であるなら)、および明白で暗黙の初期化ベクトルの長さ(または、一回だけ)を含んでいます。
MAC algorithm
An algorithm to be used for message authentication. This
specification includes the size of the value returned by the MAC
algorithm.
通報認証に使用されるべきMACアルゴリズムAnアルゴリズム。 この仕様はMACアルゴリズムで返された値のサイズを含んでいます。
compression algorithm
An algorithm to be used for data compression. This specification
must include all information the algorithm requires to do
compression.
データ圧縮に使用されるべき圧縮アルゴリズムAnアルゴリズム。 この仕様はアルゴリズムが圧縮するのを必要とするすべての情報を含まなければなりません。
master secret
A 48-byte secret shared between the two peers in the connection.
接続における2人の同輩の間で共有された秘密のA48バイトの秘密をマスタリングしてください。
client random
A 32-byte value provided by the client.
クライアントによって提供されたクライアントの無作為の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 { tls_prf_sha256 } PRFAlgorithm;
enum tls_prf_sha256、PRFAlgorithm。
enum { null, rc4, 3des, aes }
BulkCipherAlgorithm;
ヌル、rc4、3desがaesするenum、BulkCipherAlgorithm。
enum { stream, block, aead } CipherType;
ストリーム、ブロック、aeadをenumする、CipherType。
enum { null, hmac_md5, hmac_sha1, hmac_sha256,
hmac_sha384, hmac_sha512} MACAlgorithm;
ヌル、hmac_md5、hmac_sha1、hmac_sha256、hmac_sha384、hmac_sha512をenumする、MACAlgorithm。
enum { null(0), (255) } CompressionMethod;
ヌル(0)、(255)をenumする、CompressionMethod。
/* The algorithms specified in CompressionMethod, PRFAlgorithm,
BulkCipherAlgorithm, and MACAlgorithm may be added to. */
/*CompressionMethodで指定されたアルゴリズム、PRFAlgorithm、BulkCipherAlgorithm、およびMACAlgorithmに追加されるかもしれません。 */
Dierks & Rescorla Standards Track [Page 17] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[17ページ]。
struct {
ConnectionEnd entity;
PRFAlgorithm prf_algorithm;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 enc_key_length;
uint8 block_length;
uint8 fixed_iv_length;
uint8 record_iv_length;
MACAlgorithm mac_algorithm;
uint8 mac_length;
uint8 mac_key_length;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
struct、ConnectionEnd実体; PRFAlgorithm prf_アルゴリズム、;、BulkCipherAlgorithmは_暗号_アルゴリズムを膨らませます; CipherTypeは_タイプを解きます; uint8 encの_の主要な_の長さ; uint8のブロック_長さ; uint8が_iv_長さ; uint8記録_iv_の長さ; MACAlgorithm mac_を修理した アルゴリズムの_の無作為の; uint8 mac_長さ; uint8 macの_の主要な_の長さ; CompressionMethodの圧縮_アルゴリズムの; 不明瞭なマスター_秘密[48];不透明なクライアント_の無作為の[32];不明瞭なサーバ[32];、SecurityParameters。
The record layer will use the security parameters to generate the following six items (some of which are not required by all ciphers, and are thus empty):
記録的な層は以下の6つの項目(それの或るものは、すべての暗号が必要でなく、その結果、空である)を生成するのにセキュリティパラメタを使用するでしょう:
client write MAC key
server write MAC key
client write encryption key
server write encryption key
client write IV
server write IV
クライアントは暗号化の主要なクライアントがIVを書くと主要なサーバが、主要なクライアントが書くと暗号化の主要なサーバに書くMACに書くIVサーバを書くMACに書きます。
The client write parameters are used by the server when receiving and processing records and vice versa. The algorithm used for generating these items from the security parameters is described in Section 6.3.
クライアントは記録を受け取って、処理するとき、パラメタがサーバによって使用されて、逆もまた同様ですと書きます。 セキュリティパラメタからこれらの項目を生成するのに使用されるアルゴリズムはセクション6.3で説明されます。
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.
暗号は暗号化アルゴリズムの現状を述べます。 これはその接続のための予定されているキーから成るでしょう。 また、ストリーム暗号のために、これはどんなストリームが、データを暗号化するか、または解読し続けているのを許容するのに必要な州の情報も含むでしょう。
Dierks & Rescorla Standards Track [Page 18] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[18ページ]。
MAC key
The MAC key 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の記録的な層は、より高い層から非空きブロックの任意のサイズで非解釈されたデータを受け取ります。
6.2.1. Fragmentation
6.2.1. 断片化
The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType MAY be coalesced into a single TLSPlaintext record, or a single message MAY be fragmented across several records).
記録的な層は2^の塊におけるデータを14バイト以下運ぶTLSPlaintext記録に情報ブロックを断片化します。 クライアントメッセージ限界は記録的な層の中に保持されません(すなわち、同じContentTypeに関する複数のクライアントメッセージがただ一つのTLSPlaintext記録と合体するかもしれませんか、またはただ一つのメッセージはいくつかの記録の向こう側に断片化されるかもしれません)。
struct {
uint8 major;
uint8 minor;
} ProtocolVersion;
struct uint8少佐; 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.
同封の断片を処理するのに使用される上位レベル・プロトコルをタイプしてください。
Dierks & Rescorla Standards Track [Page 19] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[19ページ]。
version
The version of the protocol being employed. This document
describes TLS Version 1.2, which uses the version { 3, 3 }. The
version value 3.3 is historical, deriving from the use of {3, 1}
for TLS 1.0. (See Appendix A.1.) Note that a client that
supports multiple versions of TLS may not know what version will
be employed before it receives the ServerHello. See Appendix E
for discussion about what record layer version number should be
employed for ClientHello.
バージョン、使われるプロトコルのバージョン。 このドキュメントはTLSバージョン1.2について説明して、どれがバージョンを使用するか。3、3。 3、1のTLS1.0の使用を得て、バージョン値3.3は歴史的です。 (付録A.1を見てください。) TLSの複数のバージョンをサポートするクライアントが、ServerHelloを受ける前にどんなバージョンが使われるかを知らないかもしれないことに注意してください。 どんな記録的な層のバージョン番号がClientHelloに使われるべきであるか議論に関してAppendix Eを見てください。
length
The length (in bytes) of the following TLSPlaintext.fragment. The
length MUST NOT exceed 2^14.
長さ、以下のTLSPlaintext.fragmentの長さ(バイトによる)。 長さは2^14を超えてはいけません。
fragment
The application data. This data is transparent and treated as an
independent block to be dealt with by the higher-level protocol
specified by the type field.
アプリケーションデータを断片化してください。 このデータは、透明であり、タイプ分野によって指定された上位レベル・プロトコルによって対処されるために独立しているブロックとして扱われます。
Implementations MUST NOT send zero-length fragments of Handshake, Alert, or ChangeCipherSpec content types. Zero-length fragments of Application data MAY be sent as they are potentially useful as a traffic analysis countermeasure.
実装はHandshake、Alert、またはChangeCipherSpec content typeのゼロ・レングス断片を送ってはいけません。 それらがトラヒック分析対策として潜在的に役に立つのでデータが送られるかもしれないApplicationのゼロ・レングス断片。
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記録的な層のcontent typeに関するデータははさみ込まれるかもしれません。 一般に、アプリケーションデータはトランスミッションのために他のcontent typeより下側に上位です。 しかしながら、それらが記録的な層によって保護されるとき、同次で記録をネットワークに提供しなければなりません。 受取人は受信しなければなりません、そして、プロセスは接続での最初のものへのその後の握手の間、応用層トラフィックをはさみ込みました。
6.2.2. Record Compression and Decompression
6.2.2. 圧縮と減圧を記録してください。
All records are compressed using the compression algorithm defined in the current session state. There is always an active compression algorithm; however, initially it is defined as CompressionMethod.null. The compression algorithm translates a TLSPlaintext structure into a TLSCompressed structure. Compression functions are initialized with default state information whenever a connection state is made active. [RFC3749] describes compression algorithms for TLS.
すべての記録が、現在のセッション状態で定義された圧縮アルゴリズムを使用することで圧縮されます。 アクティブな圧縮アルゴリズムがいつもあります。 しかしながら、初めは、それはCompressionMethod.nullと定義されます。 圧縮アルゴリズムはTLSPlaintext構造をTLSCompressed構造に移します。 接続状態をアクティブにするときはいつも、圧縮機能はデフォルト州の情報で初期化されます。 [RFC3749]はTLSのために圧縮アルゴリズムを説明します。
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 MUST report a fatal decompression failure error.
圧縮は、losslessでなければならなく、コンテンツの長さを1024バイト以上増強しないかもしれません。 減圧機能が2以上^を長さに14バイト減圧するTLSCompressed.fragmentに遭遇するなら、それは致命的な減圧失敗誤りを報告しなければなりません。
Dierks & Rescorla Standards Track [Page 20] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[20ページ]。
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 MUST NOT exceed 2^14 + 1024.
長さ、以下のTLSCompressed.fragmentの長さ(バイトによる)。 長さは2^14+1024を超えてはいけません。
fragment
The compressed form of TLSPlaintext.fragment.
TLSPlaintext.fragmentの圧縮形を断片化してください。
Note: A CompressionMethod.null operation is an identity operation;
no fields are altered.
以下に注意してください。 CompressionMethod.null操作は一致演算です。 分野は全く変更されません。
Implementation note: Decompression functions are responsible for
ensuring that messages cannot cause internal buffer overflows.
実装注意: メッセージが内部のバッファオーバーフローを引き起こさない場合があるのを確実にするのに減圧機能は原因となります。
6.2.3. Record Payload Protection
6.2.3. 有効搭載量保護を記録してください。
The encryption and MAC functions translate a TLSCompressed
structure into a TLSCiphertext. The decryption functions reverse
the process. The MAC of the record also includes a sequence
number so that missing, extra, or repeated messages are
detectable.
暗号化とMAC機能はTLSCompressed構造をTLSCiphertextに翻訳します。 復号化機能はプロセスを逆にします。 また、記録のMACが一連番号を含んでいるので、なくなったか、付加的であるか、繰り返されたメッセージは検出可能です。
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (SecurityParameters.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
case aead: GenericAEADCipher;
} fragment;
} TLSCiphertext;
struct ContentTypeタイプ; ProtocolVersionバージョン; uint16の長さ; ケースストリーム: ケースが、: GenericBlockCipher; aead: GenericAEADCipherをケースに入れるのを妨げるというGenericStreamCipherが断片化する選んだ(SecurityParameters.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 MUST NOT exceed 2^14 + 2048.
長さ、以下のTLSCiphertext.fragmentの長さ(バイトによる)。 長さは2^14+2048を超えてはいけません。
Dierks & Rescorla Standards Track [Page 21] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[21ページ]。
fragment
The encrypted form of TLSCompressed.fragment, with the MAC.
MACと共にTLSCompressed.fragmentの暗号化されたフォームを断片化してください。
6.2.3.1. Null or Standard Stream Cipher
6.2.3.1. ヌルの、または、標準のストリーム暗号
Stream ciphers (including BulkCipherAlgorithm.null; see Appendix A.6) convert TLSCompressed.fragment structures to and from stream TLSCiphertext.fragment structures.
ストリーム暗号(BulkCipherAlgorithm.nullを含んでいます; Appendix A.6を見る)は構造とストリームTLSCiphertext.fragment構造からTLSCompressed.fragment構造を変換します。
stream-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length];
} GenericStreamCipher;
ストリームで解かれたstruct不透明なもの満足している[TLSCompressed.length]; 不透明なMAC[SecurityParameters.mac_長さ];GenericStreamCipher。
The MAC is generated as:
MACは以下として生成されます。
MAC(MAC_write_key, seq_num +
TLSCompressed.type +
TLSCompressed.version +
TLSCompressed.length +
TLSCompressed.fragment);
MAC(MAC_は_キー、seq_num+TLSCompressed.type+TLSCompressed.version+TLSCompressed.length+TLSCompressed.fragmentに書きます)。
where "+" denotes concatenation.
「+」が連結を指示するところ。
seq_num
The sequence number for this record.
これのための一連番号が記録するseq_num。
MAC
The MAC algorithm specified by SecurityParameters.mac_algorithm.
MACアルゴリズムがSecurityParameters.mac_アルゴリズムで指定したMAC。
Note that the MAC is computed before encryption. The stream cipher encrypts the entire block, including the MAC. For stream ciphers that do not use a synchronization vector (such as RC4), the stream cipher state from the end of one record is simply used on the subsequent packet. If the cipher suite 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). For both null and stream ciphers, TLSCiphertext.length is TLSCompressed.length plus SecurityParameters.mac_length.
MACが暗号化の前に計算されることに注意してください。 ストリーム暗号はMACを含む全体のブロックを暗号化します。 同期ベクトル(RC4などの)を使用しないストリーム暗号のために、1つの記録の終わりからのストリーム暗号状態はその後のパケットの上で単に使用されます。 暗号スイートがTLS_NULL_WITH_NULL_NULLであるなら、暗号化は一致演算から成ります(すなわち、データが暗号化されていません、そして、MACサイズはゼロです、どんなMACも使用されていないのを含意して)。 ヌルとストリーム暗号の両方に関しては、TLSCiphertext.lengthはTLSCompressed.lengthとSecurityParameters.mac_長さです。
6.2.3.2. CBC Block Cipher
6.2.3.2. CBCブロック暗号
For block ciphers (such as 3DES or AES), the encryption and MAC functions convert TLSCompressed.fragment structures to and from block TLSCiphertext.fragment structures.
ブロック暗号(3DESかAESなどの)のために、暗号化とMAC機能は構造とブロックTLSCiphertext.fragment構造からTLSCompressed.fragment構造を変換します。
Dierks & Rescorla Standards Track [Page 22] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[22ページ]。
struct {
opaque IV[SecurityParameters.record_iv_length];
block-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
};
} GenericBlockCipher;
struct不透明なものIV[SecurityParameters.record_iv_の長さ]; ブロックで解かれたstruct不明瞭な内容[TLSCompressed.length]; 不透明なMAC[SecurityParameters.mac_長さ]; [GenericBlockCipher.padding_長さ]を水増しするuint8; _長さを水増しするuint8;;GenericBlockCipher。
The MAC is generated as described in Section 6.2.3.1.
MACはセクション6.2.3で.1に説明されるように発生しています。
IV
The Initialization Vector (IV) SHOULD be chosen at random, and
MUST be unpredictable. Note that in versions of TLS prior to 1.1,
there was no IV field, and the last ciphertext block of the
previous record (the "CBC residue") was used as the IV. This was
changed to prevent the attacks described in [CBCATT]. For block
ciphers, the IV length is of length
SecurityParameters.record_iv_length, which is equal to the
SecurityParameters.block_size.
IV The Initialization Vector (IV) SHOULD be chosen at random, and MUST be unpredictable. Note that in versions of TLS prior to 1.1, there was no IV field, and the last ciphertext block of the previous record (the "CBC residue") was used as the IV. This was changed to prevent the attacks described in [CBCATT]. For block ciphers, the IV length is of length SecurityParameters.record_iv_length, which is equal to the SecurityParameters.block_size.
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
MUST check this padding and MUST use the bad_record_mac alert to
indicate padding errors.
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 MUST check this padding and MUST use the bad_record_mac alert to indicate padding errors.
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.
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.
The encrypted data length (TLSCiphertext.length) is one more than the sum of SecurityParameters.block_length, TLSCompressed.length, SecurityParameters.mac_length, and padding_length.
The encrypted data length (TLSCiphertext.length) is one more than the sum of SecurityParameters.block_length, TLSCompressed.length, SecurityParameters.mac_length, and padding_length.
Example: If the block length is 8 bytes, the content length (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes, then the length before padding is 82 bytes (this does not include the
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
Dierks & Rescorla Standards Track [Page 23] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 23] RFC 5246 TLS August 2008
IV. 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.
IV. Thus, the padding length modulo 8 must be equal to 6 in order to make the total length an even multiple of 8 bytes (the block length). The padding length can be 6, 14, 22, and so on, through 254. If the padding length were the minimum necessary, 6, the padding would be 6 bytes, each containing the value 6. Thus, the last 8 octets of the GenericBlockCipher before block encryption would be xx 06 06 06 06 06 06 06, where xx is the last octet of the MAC.
Note: With block ciphers in CBC mode (Cipher Block Chaining), 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].
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].
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, 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.
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, 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.
6.2.3.3. AEAD Ciphers
6.2.3.3. AEAD Ciphers
For AEAD [AEAD] ciphers (such as [CCM] or [GCM]), the AEAD function converts TLSCompressed.fragment structures to and from AEAD TLSCiphertext.fragment structures.
For AEAD [AEAD] ciphers (such as [CCM] or [GCM]), the AEAD function converts TLSCompressed.fragment structures to and from AEAD TLSCiphertext.fragment structures.
struct {
opaque nonce_explicit[SecurityParameters.record_iv_length];
aead-ciphered struct {
opaque content[TLSCompressed.length];
};
} GenericAEADCipher;
struct { opaque nonce_explicit[SecurityParameters.record_iv_length]; aead-ciphered struct { opaque content[TLSCompressed.length]; }; } GenericAEADCipher;
AEAD ciphers take as input a single key, a nonce, a plaintext, and "additional data" to be included in the authentication check, as described in Section 2.1 of [AEAD]. The key is either the client_write_key or the server_write_key. No MAC key is used.
AEAD ciphers take as input a single key, a nonce, a plaintext, and "additional data" to be included in the authentication check, as described in Section 2.1 of [AEAD]. The key is either the client_write_key or the server_write_key. No MAC key is used.
Each AEAD cipher suite MUST specify how the nonce supplied to the AEAD operation is constructed, and what is the length of the GenericAEADCipher.nonce_explicit part. In many cases, it is
Each AEAD cipher suite MUST specify how the nonce supplied to the AEAD operation is constructed, and what is the length of the GenericAEADCipher.nonce_explicit part. In many cases, it is
Dierks & Rescorla Standards Track [Page 24] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 24] RFC 5246 TLS August 2008
appropriate to use the partially implicit nonce technique described in Section 3.2.1 of [AEAD]; with record_iv_length being the length of the explicit part. In this case, the implicit part SHOULD be derived from key_block as client_write_iv and server_write_iv (as described in Section 6.3), and the explicit part is included in GenericAEAEDCipher.nonce_explicit.
appropriate to use the partially implicit nonce technique described in Section 3.2.1 of [AEAD]; with record_iv_length being the length of the explicit part. In this case, the implicit part SHOULD be derived from key_block as client_write_iv and server_write_iv (as described in Section 6.3), and the explicit part is included in GenericAEAEDCipher.nonce_explicit.
The plaintext is the TLSCompressed.fragment.
The plaintext is the TLSCompressed.fragment.
The additional authenticated data, which we denote as additional_data, is defined as follows:
The additional authenticated data, which we denote as additional_data, is defined as follows:
additional_data = seq_num + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.length;
additional_data = seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length;
where "+" denotes concatenation.
where "+" denotes concatenation.
The aead_output consists of the ciphertext output by the AEAD encryption operation. The length will generally be larger than TLSCompressed.length, but by an amount that varies with the AEAD cipher. Since the ciphers might incorporate padding, the amount of overhead could vary with different TLSCompressed.length values. Each AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. Symbolically,
The aead_output consists of the ciphertext output by the AEAD encryption operation. The length will generally be larger than TLSCompressed.length, but by an amount that varies with the AEAD cipher. Since the ciphers might incorporate padding, the amount of overhead could vary with different TLSCompressed.length values. Each AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. Symbolically,
AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext,
additional_data)
AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext, additional_data)
In order to decrypt and verify, the cipher takes as input the key, nonce, the "additional_data", and the AEADEncrypted value. The output is either the plaintext or an error indicating that the decryption failed. There is no separate integrity check. That is:
In order to decrypt and verify, the cipher takes as input the key, nonce, the "additional_data", and the AEADEncrypted value. The output is either the plaintext or an error indicating that the decryption failed. There is no separate integrity check. That is:
TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce,
AEADEncrypted,
additional_data)
TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce, AEADEncrypted, additional_data)
If the decryption fails, a fatal bad_record_mac alert MUST be generated.
If the decryption fails, a fatal bad_record_mac alert MUST be generated.
6.3. Key Calculation
6.3. Key Calculation
The Record Protocol requires an algorithm to generate keys required by the current connection state (see Appendix A.6) from the security parameters provided by the handshake protocol.
The Record Protocol requires an algorithm to generate keys required by the current connection state (see Appendix A.6) from the security parameters provided by the handshake protocol.
Dierks & Rescorla Standards Track [Page 25] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 25] RFC 5246 TLS August 2008
The master secret is expanded into a sequence of secure bytes, which is then split to a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key. Each of these is generated from the byte sequence in that order. Unused values are empty. Some AEAD ciphers may additionally require a client write IV and a server write IV (see Section 6.2.3.3).
The master secret is expanded into a sequence of secure bytes, which is then split to a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key. Each of these is generated from the byte sequence in that order. Unused values are empty. Some AEAD ciphers may additionally require a client write IV and a server write IV (see Section 6.2.3.3).
When keys and MAC keys are generated, the master secret is used as an entropy source.
When keys and MAC keys are generated, the master secret is used as an entropy source.
To generate the key material, compute
To generate the key material, compute
key_block = PRF(SecurityParameters.master_secret,
"key expansion",
SecurityParameters.server_random +
SecurityParameters.client_random);
key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random);
until enough output has been generated. Then, the key_block is partitioned as follows:
until enough output has been generated. Then, the key_block is partitioned as follows:
client_write_MAC_key[SecurityParameters.mac_key_length]
server_write_MAC_key[SecurityParameters.mac_key_length]
client_write_key[SecurityParameters.enc_key_length]
server_write_key[SecurityParameters.enc_key_length]
client_write_IV[SecurityParameters.fixed_iv_length]
server_write_IV[SecurityParameters.fixed_iv_length]
client_write_MAC_key[SecurityParameters.mac_key_length] server_write_MAC_key[SecurityParameters.mac_key_length] client_write_key[SecurityParameters.enc_key_length] server_write_key[SecurityParameters.enc_key_length] client_write_IV[SecurityParameters.fixed_iv_length] server_write_IV[SecurityParameters.fixed_iv_length]
Currently, the client_write_IV and server_write_IV are only generated for implicit nonce techniques as described in Section 3.2.1 of [AEAD].
Currently, the client_write_IV and server_write_IV are only generated for implicit nonce techniques as described in Section 3.2.1 of [AEAD].
Implementation note: The currently defined cipher suite which requires the most material is AES_256_CBC_SHA256. It requires 2 x 32 byte keys and 2 x 32 byte MAC keys, for a total 128 bytes of key material.
Implementation note: The currently defined cipher suite which requires the most material is AES_256_CBC_SHA256. It requires 2 x 32 byte keys and 2 x 32 byte MAC keys, for a total 128 bytes of key material.
7. The TLS Handshaking Protocols
7. The TLS Handshaking Protocols
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 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.
The Handshake Protocol is responsible for negotiating a session, which consists of the following items:
The Handshake Protocol is responsible for negotiating a session, which consists of the following items:
Dierks & Rescorla Standards Track [Page 26] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 26] RFC 5246 TLS August 2008
session identifier
An arbitrary byte sequence chosen by the server to identify an
active or resumable session state.
session identifier An arbitrary byte sequence chosen by the server to identify an active or resumable session state.
peer certificate
X509v3 [PKIX] certificate of the peer. This element of the state
may be null.
peer certificate X509v3 [PKIX] certificate of the peer. This element of the state may be null.
compression method
The algorithm used to compress data prior to encryption.
compression method The algorithm used to compress data prior to encryption.
cipher spec
Specifies the pseudorandom function (PRF) used to generate keying
material, the bulk data encryption algorithm (such as null, AES,
etc.) and the MAC algorithm (such as HMAC-SHA1). It also defines
cryptographic attributes such as the mac_length. (See Appendix
A.6 for formal definition.)
cipher spec Specifies the pseudorandom function (PRF) used to generate keying material, the bulk data encryption algorithm (such as null, AES, etc.) and the MAC algorithm (such as HMAC-SHA1). It also defines cryptographic attributes such as the mac_length. (See Appendix A.6 for formal definition.)
master secret
48-byte secret shared between the client and server.
master secret 48-byte secret shared between the client and server.
is resumable
A flag indicating whether the session can be used to initiate new
connections.
is resumable A flag indicating whether the session can be used to initiate new connections.
These items are then used to create security parameters for use by the record layer when protecting application data. Many connections can be instantiated using the same session through the resumption feature of the TLS Handshake Protocol.
These items are then used to create security parameters for use by the record layer when protecting application data. Many connections can be instantiated using the same session through the resumption feature of the TLS Handshake Protocol.
7.1. Change Cipher Spec Protocol
7.1. Change Cipher Spec Protocol
The change cipher spec protocol exists to signal transitions in ciphering strategies. The protocol consists of a single message, which is encrypted and compressed under the current (not the pending) connection state. The message consists of a single byte of value 1.
The change cipher spec protocol exists to signal transitions in ciphering strategies. The protocol consists of a single message, which is encrypted and compressed under the current (not the pending) connection state. The message consists of a single byte of value 1.
struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
struct { enum { change_cipher_spec(1), (255) } type; } ChangeCipherSpec;
The ChangeCipherSpec 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. Immediately after sending this message, the sender MUST instruct the record layer to make the write pending state the write active state.
The ChangeCipherSpec 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. Immediately after sending this message, the sender MUST instruct the record layer to make the write pending state the write active state.
Dierks & Rescorla Standards Track [Page 27] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 27] RFC 5246 TLS August 2008
(See Section 6.1.) The ChangeCipherSpec message is sent during the handshake after the security parameters have been agreed upon, but before the verifying Finished message is sent.
(See Section 6.1.) The ChangeCipherSpec message is sent during the handshake after the security parameters have been agreed upon, but before the verifying Finished message is sent.
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.
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.
7.2. Alert Protocol
7.2. Alert Protocol
One of the content types supported by the TLS record layer is the alert type. Alert messages convey the severity of the message (warning or fatal) and a description of the alert. Alert messages with a level of fatal result in the immediate termination of the connection. In this case, other connections corresponding to the session may continue, but the session identifier MUST be invalidated, preventing the failed session from being used to establish new connections. Like other messages, alert messages are encrypted and compressed, as specified by the current connection state.
One of the content types supported by the TLS record layer is the alert type. Alert messages convey the severity of the message (warning or fatal) and a description of the alert. Alert messages with a level of fatal result in the immediate termination of the connection. In this case, other connections corresponding to the session may continue, but the session identifier MUST be invalidated, preventing the failed session from being used to establish new connections. Like other messages, alert messages are encrypted and compressed, as specified by the current connection state.
enum { warning(1), fatal(2), (255) } AlertLevel;
enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed_RESERVED(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),
enum { close_notify(0), unexpected_message(10), bad_record_mac(20), decryption_failed_RESERVED(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),
Dierks & Rescorla Standards Track [Page 28] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 28] RFC 5246 TLS August 2008
export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110),
(255)
} AlertDescription;
export_restriction_RESERVED(60), protocol_version(70), insufficient_security(71), internal_error(80), user_canceled(90), no_renegotiation(100), unsupported_extension(110), (255) } AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
struct { AlertLevel level; AlertDescription description; } Alert;
7.2.1. Closure Alerts
7.2.1. Closure Alerts
The client and the server must share knowledge that the connection is ending in order to avoid a truncation attack. Either party may initiate the exchange of closing messages.
The client and the server must share knowledge that the connection is ending in order to avoid a truncation attack. Either party may initiate the exchange of closing messages.
close_notify
This message notifies the recipient that the sender will not send
any more messages on this connection. 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.
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.
Either party may initiate a close by sending a close_notify alert. Any data received after a closure alert is ignored.
Either party may initiate a close by sending a close_notify alert. Any data received after a closure alert is ignored.
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.
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 transport without waiting for the responding close_notify. No part
If the application protocol using TLS provides that any data may be carried over the underlying transport after the TLS connection is closed, the TLS implementation must receive the responding close_notify alert before indicating to the application layer that the TLS connection has ended. If the application protocol will not transfer any additional data, but will only close the underlying transport connection, then the implementation MAY choose to close the transport without waiting for the responding close_notify. No part
Dierks & Rescorla Standards Track [Page 29] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 29] RFC 5246 TLS August 2008
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.
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.
Note: It is assumed that closing a connection reliably delivers pending data before destroying the transport.
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 Alerts
Error handling in the TLS Handshake protocol is very simple. When an error is detected, the detecting party sends a message to the other party. Upon transmission or receipt of 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.
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.
Whenever an implementation encounters a condition which is defined as a fatal alert, it MUST send the appropriate alert prior to closing the connection. For all errors where an alert level is not explicitly specified, the sending party MAY determine at its discretion whether to treat this as a fatal error or not. If the implementation chooses to send an alert but intends to close the connection immediately afterwards, it MUST send that alert at the fatal alert level.
Whenever an implementation encounters a condition which is defined as a fatal alert, it MUST send the appropriate alert prior to closing the connection. For all errors where an alert level is not explicitly specified, the sending party MAY determine at its discretion whether to treat this as a fatal error or not. If the implementation chooses to send an alert but intends to close the connection immediately afterwards, it MUST send that alert at the fatal alert level.
If an alert with a level of warning is sent and received, generally the connection can continue normally. If the receiving party decides not to proceed with the connection (e.g., after having received a no_renegotiation alert that it is not willing to accept), it SHOULD send a fatal alert to terminate the connection. Given this, the sending party cannot, in general, know how the receiving party will behave. Therefore, warning alerts are not very useful when the sending party wants to continue the connection, and thus are sometimes omitted. For example, if a peer decides to accept an expired certificate (perhaps after confirming this with the user) and wants to continue the connection, it would not generally send a certificate_expired alert.
If an alert with a level of warning is sent and received, generally the connection can continue normally. If the receiving party decides not to proceed with the connection (e.g., after having received a no_renegotiation alert that it is not willing to accept), it SHOULD send a fatal alert to terminate the connection. Given this, the sending party cannot, in general, know how the receiving party will behave. Therefore, warning alerts are not very useful when the sending party wants to continue the connection, and thus are sometimes omitted. For example, if a peer decides to accept an expired certificate (perhaps after confirming this with the user) and wants to continue the connection, it would not generally send a certificate_expired alert.
The following error alerts are defined:
The following error alerts are defined:
unexpected_message
An inappropriate message was received. This alert is always fatal
and should never be observed in communication between proper
implementations.
unexpected_message An inappropriate message was received. This alert is always fatal and should never be observed in communication between proper implementations.
Dierks & Rescorla Standards Track [Page 30] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 30] RFC 5246 TLS August 2008
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 and should
never be observed in communication between proper implementations
(except when messages were corrupted in the network).
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 and should never be observed in communication between proper implementations (except when messages were corrupted in the network).
decryption_failed_RESERVED
This alert was used in some earlier versions of TLS, and may have
permitted certain attacks against the CBC mode [CBCATT]. It MUST
NOT be sent by compliant implementations.
decryption_failed_RESERVED This alert was used in some earlier versions of TLS, and may have permitted certain attacks against the CBC mode [CBCATT]. It MUST NOT be sent by compliant implementations.
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 and
should never be observed in communication between proper
implementations (except when messages were corrupted in the
network).
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 and should never be observed in communication between proper implementations (except when messages were corrupted in the network).
decompression_failure
The decompression function received improper input (e.g., data
that would expand to excessive length). This message is always
fatal and should never be observed in communication between proper
implementations.
decompression_failure The decompression function received improper input (e.g., data that would expand to excessive length). This message is always fatal and should never be observed in communication between proper implementations.
handshake_failure
Reception of a handshake_failure alert message indicates that the
sender was unable to negotiate an acceptable set of security
parameters given the options available. This is a fatal error.
handshake_failure Reception of a handshake_failure alert message indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available. This is a fatal error.
no_certificate_RESERVED
This alert was used in SSLv3 but not any version of TLS. It MUST
NOT be sent by compliant implementations.
no_certificate_RESERVED This alert was used in SSLv3 but not any version of TLS. It MUST NOT be sent by compliant implementations.
bad_certificate
A certificate was corrupt, contained signatures that did not
verify correctly, etc.
bad_certificate A certificate was corrupt, contained signatures that did not verify correctly, etc.
unsupported_certificate
A certificate was of an unsupported type.
unsupported_certificate A certificate was of an unsupported type.
certificate_revoked
A certificate was revoked by its signer.
certificate_revoked A certificate was revoked by its signer.
Dierks & Rescorla Standards Track [Page 31] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 31] RFC 5246 TLS August 2008
certificate_expired
A certificate has expired or is not currently valid.
certificate_expired A certificate has expired or is not currently valid.
certificate_unknown
Some other (unspecified) issue arose in processing the
certificate, rendering it unacceptable.
certificate_unknown Some other (unspecified) issue arose in processing the certificate, rendering it unacceptable.
illegal_parameter
A field in the handshake was out of range or inconsistent with
other fields. This message is always fatal.
illegal_parameter A field in the handshake was out of range or inconsistent with other fields. This message is always fatal.
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.
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.
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.
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.
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 and should never be observed in
communication between proper implementations (except when messages
were corrupted in the network).
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 and should never be observed in communication between proper implementations (except when messages were corrupted in the network).
decrypt_error
A handshake cryptographic operation failed, including being unable
to correctly verify a signature or validate a Finished message.
This message is always fatal.
decrypt_error A handshake cryptographic operation failed, including being unable to correctly verify a signature or validate a Finished message. This message is always fatal.
export_restriction_RESERVED
This alert was used in some earlier versions of TLS. It MUST NOT
be sent by compliant implementations.
export_restriction_RESERVED This alert was used in some earlier versions of TLS. It MUST NOT be sent by compliant implementations.
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.
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.
Dierks & Rescorla Standards Track [Page 32] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 32] RFC 5246 TLS August 2008
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.
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.
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.
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.
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.
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.
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 might be difficult to
communicate changes to these parameters after that point. This
message is always a warning.
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 might be difficult to communicate changes to these parameters after that point. This message is always a warning.
unsupported_extension
sent by clients that receive an extended server hello containing
an extension that they did not put in the corresponding client
hello. This message is always fatal.
unsupported_extension sent by clients that receive an extended server hello containing an extension that they did not put in the corresponding client hello. This message is always fatal.
New Alert values are assigned by IANA as described in Section 12.
New Alert values are assigned by IANA as described in Section 12.
7.3. Handshake Protocol Overview
7.3. Handshake Protocol Overview
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.
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.
Dierks & Rescorla Standards Track [Page 33] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 33] RFC 5246 TLS August 2008
The TLS Handshake Protocol involves the following steps:
The TLS Handshake Protocol involves the following steps:
- Exchange hello messages to agree on algorithms, exchange random
values, and check for session resumption.
- 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 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 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がいつも2人の同輩の間の可能な限り強い接続を交渉するかどうかにひどく頼るべきでないことに注意してください。 中央の男性攻撃者が最少への2実体ドロップダウンをそれらがサポートする安全なメソッドにするのを試みることができる多くの方法があります。 プロトコルはこの危険を最小にするように設計されていますが、利用可能な攻撃がまだあります: 例えば、攻撃者は、安全なサービスが走るポートへのアクセスを妨げるか、または同輩に非認証された接続を交渉させるのを試みることができました。 原理は、より高いレベルがそれらのセキュリティ要件が何であるかにおいて認識力があって、彼らが必要とすることほど安全でないチャンネルの上に情報を決して伝えてはいけないということです。 どんな暗号スイートも約束のレベルのセキュリティを提供するので、TLSプロトコルは安全です: あなたが証明書について確かめたホストと共に1024年のビットのRSA主要な交換と3DESを交渉するなら、あなたは、そんなに安全であると予想できます。
These goals are achieved by the handshake protocol, which can be summarized as follows: The client sends a ClientHello message to which the server must respond with a ServerHello message, or else a fatal error will occur and the connection will fail. The ClientHello and ServerHello are used to establish security enhancement capabilities between client and server. The ClientHello and ServerHello 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.
これらの目標は握手プロトコルによって達成されます:(以下の通りプロトコルをまとめることができます)。 致命的な誤りは発生するでしょう、そして、クライアントがサーバがServerHelloメッセージで反応しなければならないClientHelloメッセージを送るか、または接続は失敗するでしょう。 ClientHelloとServerHelloは、クライアントとサーバの間のセキュリティ増進能力を証明するのに使用されます。ClientHelloとServerHelloは以下の属性を確立します: バージョン、Session ID、暗号スイート、および圧縮方法を議定書の中で述べてください。 さらに、2つの無作為の値を生成して、交換します: ClientHello.randomとServerHello.random。
Dierks & Rescorla Standards Track [Page 34] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[34ページ]。
The actual key exchange uses up to four messages: the server Certificate, the ServerKeyExchange, the client Certificate, and the ClientKeyExchange. 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 46 bytes upwards.
実際のキー交換は最大4つのメッセージを使用します: サーバCertificate、ServerKeyExchange、クライアントCertificate、およびClientKeyExchange。 これらのメッセージに形式を指定して、クライアントとサーバが共有秘密キーに同意するのを許容するメッセージの使用を定義することによって、新しい主要な交換メソッドを作成できます。 この秘密はかなり長くなければなりません。 現在定義された主要な交換メソッドは46バイトから上向きに変化する秘密を交換します。
Following the hello messages, the server will send its certificate in a Certificate message if it is to be authenticated. Additionally, a ServerKeyExchange 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 ServerHelloDone 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 CertificateRequest message, the client MUST send the Certificate message. The ClientKeyExchange message is now sent, and the content of that message will depend on the public key algorithm selected between the ClientHello and the ServerHello. If the client has sent a certificate with signing ability, a digitally-signed CertificateVerify message is sent to explicitly verify possession of the private key in the certificate.
次のこんにちは、メッセージであり、それが認証されるつもりであると、サーバはCertificateメッセージの証明書を送るでしょう。 さらに、ServerKeyExchangeメッセージを送るかもしれません、それが必要であるなら(例えば、サーバで証明書が全くないか、または証明書が署名だけのためのものであるなら)。 サーバが認証されるなら、クライアントから証明書を要求するかもしれません、それが選択された暗号スイートに適切であるなら。 それを示して、次にサーバがServerHelloDoneメッセージを送る、こんにちは、-通信してください、握手のフェーズは完全です。 そして、サーバはクライアント応答を待っています。 サーバがCertificateRequestメッセージを送ったなら、クライアントはCertificateメッセージを送らなければなりません。 現在ClientKeyExchangeメッセージを送ります、そして、そのメッセージの内容はClientHelloとServerHelloの間で選択された公開鍵アルゴリズムによるでしょう。 クライアントが署名能力がある証明書を送ったなら、明らかに証明書の秘密鍵の所有物について確かめるためにデジタルに署名しているCertificateVerifyメッセージを送ります。
At this point, a ChangeCipherSpec 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 ChangeCipherSpec 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 than TLS_NULL_WITH_NULL_NULL is established).
ここに、ChangeCipherSpecメッセージはクライアントによって送られます、そして、クライアントは現在のCipher Specに未定のCipher Specをコピーします。 そして、クライアントはすぐに、新しいアルゴリズム、キー、および秘密の下にFinishedメッセージを送ります。 応答では、サーバは、それ自身のChangeCipherSpecメッセージを送って、現在のCipher Specに未定を移して、新しいCipher Specの下にFinishedメッセージを送るでしょう。 ここに、握手は完了しています、そして、クライアントとサーバは応用層データを交換し始めるかもしれません。 (以下のフローチャートを見てください。) 最初の握手の完成の前にアプリケーションデータを送ってはいけません(TLS_NULL_WITH_NULL_NULL以外の暗号スイートが設置される前に)。
Dierks & Rescorla Standards Track [Page 35] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[35ページ]。
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]<。-------- 完成アプリケーションデータ<。------->アプリケーションデータ
Figure 1. Message flow for a full handshake
図1。 完全な握手のためのメッセージ流動
* Indicates optional or situation-dependent messages that are not always sent.
* いつも送られるというわけではない任意の、または、状況依存するメッセージを示します。
Note: To help avoid pipeline stalls, ChangeCipherSpec is an independent TLS protocol content type, and is not actually a TLS handshake message.
以下に注意してください。 パイプライン売店、ChangeCipherSpecを避けるのを助けるのは、独立しているTLSプロトコルcontent typeであり、実際にTLS握手メッセージではありません。
When the client and server decide to resume a previous session or duplicate an existing session (instead of negotiating new security parameters), the message flow is as follows:
クライアントとサーバが、前のセッションを再開するか、または既存のセッションをコピーする(新しいセキュリティパラメタを交渉することの代わりに)と決めるとき、メッセージ流動は以下の通りです:
The client sends a ClientHello using the Session ID of the session to be resumed. The server then checks its session cache for a match. If a match is found, and the server is willing to re-establish the connection under the specified session state, it will send a ServerHello with the same Session ID value. At this point, both client and server MUST send ChangeCipherSpec messages and proceed directly to Finished messages. Once the re-establishment is complete, the client and server MAY begin to exchange application layer data. (See flow chart below.) If a Session ID match is not found, the server generates a new session ID, and the TLS client and server perform a full handshake.
クライアントは、再開されるのにセッションのSession IDを使用することでClientHelloを送ります。 そして、サーバはマッチがないかどうかセッションキャッシュをチェックします。 マッチが見つけられて、サーバが、指定されたセッション状態の下で接続を復職させても構わないと思っていると、それは同じSession ID価値があるServerHelloを送るでしょう。 ここに、クライアントとサーバの両方が、メッセージをChangeCipherSpecに送って、直接Finishedメッセージに続かなければなりません。 再建がいったん完全になると、クライアントとサーバは応用層データを交換し始めるかもしれません。 (以下のフローチャートを見てください。) Session IDマッチが見つけられないなら、サーバは新しいセッションIDを生成します、そして、TLSクライアントとサーバは完全な握手を実行します。
Dierks & Rescorla Standards Track [Page 36] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[36ページ]。
Client Server
クライアントサーバ
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
ClientHello-------->ServerHello[ChangeCipherSpec]<。-------- 終わっている[ChangeCipherSpec]は終わりました。-------->アプリケーションデータ<。------->アプリケーションデータ
Figure 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の記録的な層に握手メッセージを提供します。そこでは、彼らが1つ以上のTLSPlaintext構造の中でカプセル化されます。現在の活動的なセッション州によって指定されるように、構造は、処理されて、伝えられます。
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255)
} HandshakeType;
enum、こんにちは、_要求(0)、クライアント_、こんにちは、(1)、サーバ_、こんにちは、(2) 証明書(11)、サーバの_の主要な_交換(12)が_要求(13)、サーバ_を証明する、こんにちは、(14)、証明書_が行われた_が(15)、クライアントの_の主要な_交換(16)、終わっている(20)、(255)について確かめる、HandshakeType。
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
} Handshake;
struct、HandshakeType msg_タイプ; /*握手タイプ*/uint24の長さ; メッセージ*/選んだ(HandshakeType)の/*バイト、_: こんにちは、_要求: こんにちは、ケースHelloRequest; _: こんにちは、ケースクライアントClientHello; ケースサーバServerHello; ケース証明書: 証明書; サーバの_の主要な_交換: ServerKeyExchangeをケースに入れます; ケース証明書_要求: CertificateRequest; _行われた_: こんにちは、ケースサーバServerHelloDone; ケース証明書_が、: CertificateVerify; クライアントの_の主要な_交換: ケースは終わりました: 終わったというClientKeyExchangeをケースに入れることを確かめる、ボディー;、握手。
Dierks & Rescorla Standards Track [Page 37] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[37ページ]。
The handshake protocol messages are presented below in the order they MUST be sent; sending handshake messages in an unexpected order results in a fatal error. Unneeded handshake messages can be omitted, however. Note one exception to the ordering: the Certificate message is used twice in the handshake (from server to client, then from client to server), but described only in its first position. The one message that is not bound by these ordering rules is the HelloRequest 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つのメッセージがHelloRequestメッセージですが、握手の途中に到着するなら、クライアントはどのSHOULDを無視しますか?(いつでも、それを送ることができます)。
New handshake message types are assigned by IANA as described in Section 12.
新しい握手メッセージタイプはセクション12で説明されるようにIANAによって選任されます。
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.
フェーズメッセージは、クライアントとサーバの間でセキュリティ増進能力を交換するのに使用されます。こんにちは、新しいセッションが始まるとき、記録的な層の接続州の暗号化、ハッシュ、および圧縮アルゴリズムはヌルに初期化されます。 現在の接続状態は再交渉メッセージに使用されます。
7.4.1.1. Hello Request
7.4.1.1. こんにちは、要求
When this message will be sent:
このメッセージを送るとき:
The HelloRequest message MAY be sent by the server at any time.
サーバはいつでも、HelloRequestメッセージを送るかもしれません。
Meaning of this message:
このメッセージの意味:
HelloRequest is a simple notification that the client should begin
the negotiation process anew. In response, the client should send
a ClientHello message when convenient. This message is not
intended to establish which side is the client or server but
merely to initiate a new negotiation. Servers SHOULD NOT send a
HelloRequest immediately upon the client's initial connection. It
is the client's job to send a ClientHello at that time.
HelloRequestはクライアントが新たに交渉プロセスを開始するべきであるという簡単な通知です。 応答では、便利であるときに、クライアントはClientHelloメッセージを送るべきです。 どの側がクライアントかそれともサーバであるかを証明することを意図するのではなく、このメッセージは、単に新しい交渉を開始するために意図します。 サーバSHOULD NOTはすぐクライアントの初期の接続にHelloRequestを送ります。 その時ClientHelloを送るのは、クライアントの仕事です。
This message will be ignored by the client if the client is
currently negotiating a session. This message MAY be ignored by
the client if it does not wish to renegotiate a session, or the
client may, if it wishes, respond with a no_renegotiation alert.
Since handshake messages are intended to have transmission
precedence over application data, it is expected that the
negotiation will begin before no more than a few records are
received from the client. If the server sends a HelloRequest but
does not receive a ClientHello in response, it may close the
connection with a fatal alert.
クライアントが現在セッションを交渉していると、このメッセージはクライアントによって無視されるでしょう。 セッションを再交渉したがっていないか、または願うならクライアントがいいえ_再交渉警戒でこたえるかもしれないなら、このメッセージはクライアントによって無視されるかもしれません。 握手メッセージにはアプリケーションデータの上のトランスミッション先行があることを意図するので、クライアントからいくつかの記録だけを受け取る前に交渉が始まると予想されます。 サーバがHelloRequestを送りますが、応答ではClientHelloを受けないなら、それは致命的な警戒との関係を終えるかもしれません。
Dierks & Rescorla Standards Track [Page 38] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[38ページ]。
After sending a HelloRequest, servers SHOULD NOT repeat the
request until the subsequent handshake negotiation is complete.
HelloRequestを送った後に、その後の握手交渉が完全になるまで、サーバSHOULD NOTは要求を繰り返します。
Structure of this message:
このメッセージの構造:
struct { } HelloRequest;
struct、HelloRequest。
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.
握手の間中維持されて、Finishedメッセージと証明書で使用されるハッシュがメッセージについて確かめるというメッセージにこのメッセージを含んではいけません。
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 ClientHello as its first message. The client can also send a
ClientHello in response to a HelloRequest or on its own initiative
in order to renegotiate the security parameters in an existing
connection.
クライアントが最初にサーバに接続すると、それが、最初のメッセージとしてClientHelloを送るのに必要です。 また、クライアントは、既存の接続におけるセキュリティパラメタを再交渉するためにHelloRequestに対応したそれ自身のイニシアチブの上にClientHelloを送ることができます。
Structure of this message:
このメッセージの構造:
The ClientHello message includes a random structure, which is used
later in the protocol.
ClientHelloメッセージはランダム構造を含んでいます。(それは、後でプロトコルに使用されます)。
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, UTC, 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. Note that, for historical reasons, the data
element is named using GMT, the predecessor of the current
worldwide time base, UTC.
送付者の内部クロックに応じて、gmt_unix_は標準のUNIX32ビットの形式(1970年1月1日からの真夜中、飛躍秒を無視するUTC以来の秒)で現在の日時を調節します。 時計は基本的なTLSプロトコルで正しく設定されるのに必要ではありません。 よりハイレベルであるかアプリケーション・プロトコルが追加要件を定義するかもしれません。 データ要素がグリニッジ標準時に歴史的な理由にちなんで使用と命名されることに注意してください、現在の世界的な時間ベースの前任者、UTC。
random_bytes
28 bytes generated by a secure random number generator.
安全な乱数発生器によって生成された28バイトの無作為の_バイト。
The ClientHello 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,
ClientHelloメッセージは可変長のセッション識別子を含んでいます。 空でないなら、値はクライアントがセキュリティパラメタを再利用したがっている同じクライアントとサーバとのセッションを特定します。 セッション識別子は以前の接続から来ているかもしれません。
Dierks & Rescorla Standards Track [Page 39] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[39ページ]。
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.
この接続であるか、現在別のものから活発な接続 クライアントが接続のランダム構造と派生している値をアップデートするだけでありたいなら、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 cipher suite list, passed from the client to the server in the ClientHello message, contains the combinations of cryptographic algorithms supported by the client in order of the client's preference (favorite choice first). Each cipher suite defines a key exchange algorithm, a bulk encryption algorithm (including secret key length), a MAC algorithm, and a PRF. The server will select a cipher suite or, if no acceptable choices are presented, return a handshake failure alert and close the connection. If the list contains cipher suites the server does not recognize, support, or wish to use, the server MUST ignore those cipher suites, and process the remaining ones as usual.
ClientHelloメッセージでクライアントからサーバまで渡された暗号スイートリストはクライアントの好み(特選している1のお気に入りの番目)の順にクライアントによってサポートされた暗号アルゴリズムの組み合わせを含んでいます。 それぞれの暗号スイートは主要な交換アルゴリズム、大量の暗号化アルゴリズム(秘密鍵の長さを含んでいる)、MACアルゴリズム、およびPRFを定義します。 どんな許容できる選択も提示されないと、サーバは、暗号スイートを選択するか、握手故障警報を返して、または接続を終えるでしょう。 リストが使用するサーバが認識しない暗号スイート、サポート、または願望を含んでいるなら、サーバは、それらの暗号スイートを無視して、通常通りの残っているものを処理しなければなりません。
uint8 CipherSuite[2]; /* Cryptographic suite selector */
uint8 CipherSuite[2]。 /*暗号のスイートセレクタ*/
The ClientHello includes a list of compression algorithms supported by the client, ordered according to the client's preference.
ClientHelloは自分の好みに従って注文されたクライアントによってサポートされた圧縮アルゴリズムのリストを含んでいます。
enum { null(0), (255) } CompressionMethod;
ヌル(0)、(255)をenumする、CompressionMethod。
Dierks & Rescorla Standards Track [Page 40] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[40ページ]。
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ClientHello;
struct、ProtocolVersionクライアント_バージョン; 無作為の無作為; SessionIDセッション_イド;のCipherSuite暗号_スイート<2..2^16-2>; CompressionMethod圧縮_メソッド<1..2^8-1>; (拡大_プレゼント)を選択してください、structに以下を虚偽でケースに入れてください、; 本当に: 拡大拡大<0..2^16-1>をケースに入れてください;、;、ClientHello。
TLS allows extensions to follow the compression_methods field in an extensions block. The presence of extensions can be detected by determining whether there are bytes following the compression_methods at the end of the ClientHello. Note that this method of detecting optional data differs from the normal TLS method of having a variable-length field, but it is used for compatibility with TLS before extensions were defined.
TLSは拡大を拡大ブロックの圧縮_メソッド野原に続かせます。 ClientHelloの端で圧縮_メソッドに従って、バイトがあるかどうか決定することによって、拡大の存在を検出できます。 拡大が定義される前に任意のデータを検出するこのメソッドが可変長の分野を持つ正常なTLSメソッドと異なっていますが、それがTLSとの互換性に使用されることに注意してください。
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.3 (see
Appendix E for details about backward compatibility).
TLSのバージョンが議定書を作るクライアントが今会期中に伝えたがっているクライアント_バージョン。 このSHOULD、最新のものになってください、(高さ、評価、)、クライアントによってサポートされたバージョン。 仕様のこのバージョンのために、バージョンは3.3(後方の互換性に関する詳細に関して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 is 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
圧縮_メソッドThisはクライアント好みによって割り当てられたクライアントによってサポートされた圧縮方法のリストです。 セッション_イド分野が人影がなくないなら(セッション再開要求を含意して)、それは包含しなければなりません。
Dierks & Rescorla Standards Track [Page 41] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[41ページ]。
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.
そのセッションからの圧縮_メソッド。 このベクトルは含まなければなりません、そして、すべての実装はサポート、CompressionMethod.nullが含まなければなりません。 したがって、クライアントとサーバはいつも圧縮方法に同意できるでしょう。
extensions
Clients MAY request extended functionality from servers by sending
data in the extensions field. The actual "Extension" format is
defined in Section 7.4.1.4.
拡大Clientsは、サーバから拡大分野でデータを送ることによって、拡張機能性を要求するかもしれません。 書式が定義される実際の「拡大」セクション7.4 .1 .4。
In the event that a client requests additional functionality using extensions, and this functionality is not supplied by the server, the client MAY abort the handshake. A server MUST accept ClientHello messages both with and without the extensions field, and (as for all other messages) it MUST check that the amount of data in the message precisely matches one of these formats; if not, then it MUST send a fatal "decode_error" alert.
クライアントが拡張子を使用することで追加機能性を要求して、この機能性がサーバによって提供されない場合、クライアントは握手を中止するかもしれません。 サーバは分野と拡大分野なしでClientHelloメッセージを受け入れなければなりません、そして、メッセージのデータ量が正確にこれらの形式の1つに合っているのをチェックしなければなりません。 そうでなければ、そして、それは「_誤りを解読してください」という致命的な警戒を送らなければなりません。
After sending the ClientHello message, the client waits for a ServerHello message. Any handshake message returned by the server, except for a HelloRequest, is treated as a fatal error.
ClientHelloメッセージを送った後に、クライアントはServerHelloメッセージを待ちます。 HelloRequest以外のサーバによって返されたどんな握手メッセージも致命的な誤りとして扱われます。
7.4.1.3. Server Hello
7.4.1.3. サーバ、こんにちは。
When this message will be sent:
このメッセージを送るとき:
The server will send this message in response to a ClientHello
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.
それが許容できるセットのアルゴリズムを見つけることができたとき、サーバはClientHelloメッセージに対応してこのメッセージを送るでしょう。そのようなマッチを見つけることができないと、それは握手故障警報で応じるでしょう。
Structure of this message:
このメッセージの構造:
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ServerHello;
struct、ProtocolVersionサーバ_バージョン; 無作為の無作為; SessionIDセッション_イド;のCipherSuite暗号_スイート; CompressionMethod圧縮_メソッド; (拡大_プレゼント)を選択してください、structに以下を虚偽でケースに入れてください、; 本当に: 拡大拡大<0..2^16-1>をケースに入れてください;、;、ServerHello。
Dierks & Rescorla Standards Track [Page 42] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[42ページ]。
The presence of extensions can be detected by determining whether there are bytes following the compression_method field at the end of the ServerHello.
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.3. (See
Appendix E for details about backward compatibility.)
サーバによってサポートされて、This分野が、より低くそれを含むサーバ_バージョンは、クライアントというクライアントでこんにちはを最も高く示しました。仕様のこのバージョンのために、バージョンは3.3です。 (後方の互換性に関する詳細に関してAppendix Eを見てください。)
random
This structure is generated by the server and MUST be
independently generated from the ClientHello.random.
無作為のThis構造をサーバによって生成されて、ClientHello.randomから独自に生成しなければなりません。
session_id
This is the identity of the session corresponding to this
connection. If the ClientHello.session_id was non-empty, the
server will look in its session cache for a match. If a match is
found and the server is willing to establish the new connection
using the specified session state, the server will respond with
the same value as was supplied by the client. This indicates a
resumed session and dictates that the parties must proceed
directly to the Finished messages. Otherwise, this field will
contain a different value identifying the new session. The server
may return an empty session_id to indicate that the session will
not be cached and therefore cannot be resumed. If a session is
resumed, it must be resumed using the same cipher suite it was
originally negotiated with. Note that there is no requirement
that the server resume any session even if it had formerly
provided a session_id. Clients MUST be prepared to do a full
negotiation -- including negotiating new cipher suites -- during
any handshake.
セッション_イドThisはこの接続において、対応するセッションのアイデンティティです。 ClientHello.session_イドが非空であったなら、サーバはマッチのためにセッションキャッシュの中を見るでしょう。 マッチが見つけられて、サーバが、指定されたセッション状態を使用することで新しい接続を確立しても構わないと思っていると、サーバはクライアントによって供給されたのと同じ値で反応するでしょう。 これは、再開しているセッションを示して、パーティーが直接Finishedメッセージに続かなければならないと決めます。 さもなければ、この分野は新しいセッションを特定する異価を含むでしょう。 サーバは、セッションをキャッシュしないで、したがって、再開できないのを示すために空のセッション_イドを返すかもしれません。 セッションが再開されるなら、それが元々交渉された同じ暗号スイートを使用することでそれを再開しなければなりません。 以前セッション_イドを提供したとしてもサーバが再開するという要件が全くどんなセッションのときにもないことに注意してください。 どんな握手の間も、新しい暗号スイートを交渉するのを含んでいて、クライアントは完全な交渉をする用意ができていなければなりません。
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_メソッドによるリストから選択した圧縮_メソッド。 再開しているセッションのために、この分野は再開しているセッション状態からの値です。
extensions
A list of extensions. Note that only extensions offered by the
client can appear in the server's list.
拡大の拡大Aリスト。 クライアントによって提供された拡大だけがサーバのリストに現れることができることに注意してください。
Dierks & Rescorla Standards Track [Page 43] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[43ページ]。
7.4.1.4. Hello Extensions
7.4.1.4. こんにちは、拡大
The extension format is:
拡大形式は以下の通りです。
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
struct ExtensionType拡大_タイプ; 不透明な拡大_データ<0..2^16-1>;拡張子。
enum {
signature_algorithms(13), (65535)
} ExtensionType;
enum、署名_アルゴリズム(13)、(65535)ExtensionType。
Here:
ここ:
- "extension_type" identifies the particular extension type.
- 「拡大_タイプ」は特定の拡大タイプを特定します。
- "extension_data" contains information specific to the particular
extension type.
- 「拡大_データ」は特定の拡大タイプに、特定の情報を含んでいます。
The initial set of extensions is defined in a companion document [TLSEXT]. The list of extension types is maintained by IANA as described in Section 12.
拡大の始発は仲間ドキュメント[TLSEXT]で定義されます。 拡大タイプのリストはセクション12で説明されるようにIANAによって維持されます。
An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello. If a client receives an extension type in ServerHello that it did not request in the associated ClientHello, it MUST abort the handshake with an unsupported_extension fatal alert.
同じ拡大タイプが対応するClientHelloに現れなかったなら、拡大タイプはServerHelloに現れてはいけません。 クライアントがそれが関連ClientHelloで要求しなかったServerHelloの拡大タイプを受けるなら、それはサポートされない_拡大致命的な警戒で握手を中止しなければなりません。
Nonetheless, "server-oriented" extensions may be provided in the future within this framework. Such an extension (say, of type x) would require the client to first send an extension of type x in a ClientHello with empty extension_data to indicate that it supports the extension type. In this case, the client is offering the capability to understand the extension type, and the server is taking the client up on its offer.
それにもかかわらず、将来、このフレームワークの中で「サーバ指向」の拡大を提供するかもしれません。 そのような拡張子(たとえばタイプxについて)は、クライアントが最初に拡大タイプをサポートするのを示すためにClientHelloでの空の拡大によるタイプxの拡大に_データを送るのを必要とするでしょう。 この場合、クライアントは拡大タイプを理解する能力を提供しています、そして、サーバは申し出にクライアントを拾っています。
When multiple extensions of different types are present in the ClientHello or ServerHello messages, the extensions MAY appear in any order. There MUST NOT be more than one extension of the same type.
異なったタイプの複数の拡大がClientHelloかServerHelloメッセージに存在しているとき、拡大は順不同に現れるかもしれません。 同じタイプの1つ以上の拡大があるはずがありません。
Finally, note that extensions can be sent both when starting a new session and when requesting session resumption. Indeed, a client that requests session resumption does not in general know whether the server will accept this request, and therefore it SHOULD send the same extensions as it would send if it were not attempting resumption.
最終的に、ともに新しいセッションといつがセッション再開を要求し始めるかとき、拡大を送ることができることに注意してください。 本当に、再開を試みていないなら、一般に、セッション再開が、したがって、サーバはこの要求を受け入れて、それを受け入れるか否かに関係なく、SHOULDがそれと同じ拡大を送るのを知らないよう要求するクライアントは発信するでしょうに。
Dierks & Rescorla Standards Track [Page 44] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[44ページ]。
In general, the specification of each extension type needs to describe the effect of the extension both during full handshake and session resumption. Most current TLS extensions are relevant only when a session is initiated: when an older session is resumed, the server does not process these extensions in Client Hello, and does not include them in Server Hello. However, some extensions may specify different behavior during session resumption.
一般に、それぞれの拡大タイプの仕様は、完全な握手とセッション再開の間、拡大の効果について説明する必要があります。 セッションが開始されるときだけ、ほとんどの現在のTLS拡張子が関連しています: より古いセッションが再開されるとき、サーバは、Client Helloでこれらの拡大を処理しないで、またServer Helloにそれらを含んでいません。 しかしながら、いくつかの拡大がセッション再開の間、異なった振舞いを指定するかもしれません。
There are subtle (and not so subtle) interactions that may occur in this protocol between new features and existing features which may result in a significant reduction in overall security. The following considerations should be taken into account when designing new extensions:
総合的なセキュリティのかなりの減少をもたらすかもしれない新機能と既存の特徴の間には、このプロトコルで起こるかもしれない微妙で(あまりに微妙でない)の相互作用があります。 新しい拡大を設計するとき、以下の問題は考慮に入れられるべきです:
- Some cases where a server does not agree to an extension are error
conditions, and some are simply refusals to support particular
features. In general, error alerts should be used for the former,
and a field in the server extension response for the latter.
- サーバが拡大に同意しないいくつかのケースがエラー条件です、そして、何かが単に特定の特徴をサポートすることへの拒否です。 一般に、誤り警戒は前者、および後者のためのサーバ拡大応答における分野に使用されるべきです。
- Extensions should, as far as possible, be designed to prevent any
attack that forces use (or non-use) of a particular feature by
manipulation of handshake messages. This principle should be
followed regardless of whether the feature is believed to cause a
security problem.
- 拡大は、握手メッセージの操作で力が使用する特定の特徴のどんな攻撃(または、非使用)も防ぐようにできるだけ設計されるべきです。 特徴が警備上の問題を引き起こすと信じられているかどうかにかかわらずこの原則は従われるべきです。
Often the fact that the extension fields are included in the
inputs to the Finished message hashes will be sufficient, but
extreme care is needed when the extension changes the meaning of
messages sent in the handshake phase. Designers and implementors
should be aware of the fact that until the handshake has been
authenticated, active attackers can modify messages and insert,
remove, or replace extensions.
しばしば、拡大分野が入力でFinishedメッセージハッシュに含められているという事実は十分ですが、拡大が握手フェーズで送られたメッセージの意味を変えるとき、極端な注意が必要です。 デザイナーと作成者は握手が認証されるまで、活発な攻撃者が拡大をメッセージを変更して、挿入するか、取り除くか、または取り替えることができるという事実を知っているべきです。
- It would be technically possible to use extensions to change major
aspects of the design of TLS; for example the design of cipher
suite negotiation. This is not recommended; it would be more
appropriate to define a new version of TLS -- particularly since
the TLS handshake algorithms have specific protection against
version rollback attacks based on the version number, and the
possibility of version rollback should be a significant
consideration in any major design change.
- TLSのデザインの主要な局面を変えるのに拡張子を使用するのは技術的に可能でしょう。 例えば、暗号スイート交渉のデザイン。 これは推薦されません。 TLS握手アルゴリズムが特にバージョン番号に基づくバージョンロールバック攻撃に特異的予防を抱くのでTLSの新しいバージョンを定義するのが、より適切であるだろう、バージョンロールバックの可能性はどんな主要な設計変更でも重要な考慮であるべきです。
7.4.1.4.1. Signature Algorithms
7.4.1.4.1. 署名アルゴリズム
The client uses the "signature_algorithms" extension to indicate to the server which signature/hash algorithm pairs may be used in digital signatures. The "extension_data" field of this extension contains a "supported_signature_algorithms" value.
クライアントは、どの署名/ハッシュアルゴリズム組がデジタル署名に使用されるかもしれないかをサーバに示すのに「署名_アルゴリズム」拡張子を使用します。 この拡大の「拡大_データ」分野は「サポートしている_署名_アルゴリズム」値を含んでいます。
Dierks & Rescorla Standards Track [Page 45] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[45ページ]。
enum {
none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
sha512(6), (255)
} HashAlgorithm;
enum、なにも、(0)、md5(1)、sha1(2)、sha224(3)、sha256(4)、sha384(5)、sha512(6)、(255)、HashAlgorithm。
enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
SignatureAlgorithm;
匿名の(0)、rsa(1)、dsa(2)、ecdsa(3)、(255)をenumする、SignatureAlgorithm。
struct {
HashAlgorithm hash;
SignatureAlgorithm signature;
} SignatureAndHashAlgorithm;
struct HashAlgorithmハッシュ; SignatureAlgorithm署名;SignatureAndHashAlgorithm。
SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-2>;
SignatureAndHashAlgorithmは、_署名_アルゴリズムが<2であるとサポートしました。2^16-2>。
Each SignatureAndHashAlgorithm value lists a single hash/signature pair that the client is willing to verify. The values are indicated in descending order of preference.
それぞれのSignatureAndHashAlgorithm値はクライアントが確かめても構わないと思っているただ一つのハッシュ/署名組を記載します。 値は好みの降順で示されます。
Note: Because not all signature algorithms and hash algorithms may be accepted by an implementation (e.g., DSA with SHA-1, but not SHA-256), algorithms here are listed in pairs.
以下に注意してください。 実装(例えば、SHA-256ではなく、SHA-1とDSA)ですべての署名アルゴリズムとどんなハッシュアルゴリズムも受け入れないかもしれないので、ここのアルゴリズムは組で記載されています。
hash
This field indicates the hash algorithm which may be used. The
values indicate support for unhashed data, MD5 [MD5], SHA-1,
SHA-224, SHA-256, SHA-384, and SHA-512 [SHS], respectively. The
"none" value is provided for future extensibility, in case of a
signature algorithm which does not require hashing before signing.
ハッシュThis分野は使用されるかもしれないハッシュアルゴリズムを示します。 値はそれぞれ「非-論じ尽く」されたデータ、MD5[MD5]、SHA-1、SHA-224、SHA-256、SHA-384、およびSHA-512[SHS]のサポートを示します。 「なにも」値を将来の伸展性に提供します、署名の前に論じ尽くすのを必要としない署名アルゴリズムの場合に。
signature
This field indicates the signature algorithm that may be used.
The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
[PKCS1] and DSA [DSS], and ECDSA [ECDSA], respectively. The
"anonymous" value is meaningless in this context but used in
Section 7.4.3. It MUST NOT appear in this extension.
署名This分野は使用されるかもしれない署名アルゴリズムを示します。 値はそれぞれRSASSA-PKCS1-v1_5の匿名の署名、[PKCS1]、およびDSA[DSS]、およびECDSA[ECDSA]を示します。 「匿名」の値は、この文脈で無意味ですが、セクション7.4.3が使用されています。 それはこの拡大に現れてはいけません。
The semantics of this extension are somewhat complicated because the cipher suite indicates permissible signature algorithms but not hash algorithms. Sections 7.4.2 and 7.4.3 describe the appropriate rules.
暗号スイートがハッシュアルゴリズムセクション7.4.2ではなく許されている署名アルゴリズムを示すので、この拡大の意味論はいくらか複雑です、そして、7.4に、.3は適切な規則について説明します。
If the client supports only the default hash and signature algorithms (listed in this section), it MAY omit the signature_algorithms extension. If the client does not support the default algorithms, or supports other hash and signature algorithms (and it is willing to use them for verifying messages sent by the server, i.e., server certificates and server key exchange), it MUST send the
クライアントが、デフォルトハッシュと唯一の署名がアルゴリズム(このセクションで、記載されている)であるとサポートするなら、それは署名_アルゴリズム拡大を省略するかもしれません。 クライアントがデフォルトアルゴリズムをサポートしないか、または他のハッシュと署名アルゴリズムをサポートするなら(それは、サーバによって送られたメッセージ、すなわち、サーバ証明書について確かめるためのそれらとサーバの主要な交換を使用しても構わないと思っています)、それは発信しなければなりません。
Dierks & Rescorla Standards Track [Page 46] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[46ページ]。
signature_algorithms extension, listing the algorithms it is willing to accept.
それが受け入れても構わないと思っているアルゴリズムを記載する署名_アルゴリズム拡大。
If the client does not send the signature_algorithms extension, the server MUST do the following:
クライアントが署名_アルゴリズムに拡大を送らないなら、サーバは以下をしなければなりません:
- If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
sent the value {sha1,rsa}.
- 交渉された主要な交換アルゴリズムが1であるなら、(RSA、DHE_RSA、DH_RSA、RSA_PSK、ECDH_RSA、ECDHE_RSA)では、まるでクライアントがsha1、rsaを値に送ったかのように、振る舞ってください。
- If the negotiated key exchange algorithm is one of (DHE_DSS,
DH_DSS), behave as if the client had sent the value {sha1,dsa}.
- 交渉された主要な交換アルゴリズムが1であるなら、(DHE_DSS、DH_DSS)では、まるでクライアントがsha1、dsaを値に送ったかのように、振る舞ってください。
- If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.
- 交渉された主要な交換アルゴリズムが1であるなら、(ECDH_ECDSA、ECDHE_ECDSA)では、まるでクライアントがsha1、ecdsaを値に送ったかのように、振る舞ってください。
Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA-1.
以下に注意してください。 これはどんな明白な規則もないTLS1.1からの変化ですが、実際問題として人は、同輩がMD5とSHA-1をサポートすると仮定できます。
Note: this extension is not meaningful for TLS versions prior to 1.2. Clients MUST NOT offer it if they are offering prior versions. However, even if clients do offer it, the rules specified in [TLSEXT] require servers to ignore extensions they do not understand.
以下に注意してください。 TLSバージョンには、この拡大は1.2の前に重要ではありません。 彼らが先のバージョンを提供しているなら、クライアントはそれを提供してはいけません。 しかしながら、クライアントがそれを提供しても、[TLSEXT]で指定された規則は、彼らが理解していない拡大を無視するためにサーバを必要とします。
Servers MUST NOT send this extension. TLS servers MUST support receiving this extension.
サーバはこの拡大を送ってはいけません。 TLSサーバは、受信がこの拡大であるとサポートしなければなりません。
When performing session resumption, this extension is not included in Server Hello, and the server ignores the extension in Client Hello (if present).
セッション再開を実行するとき、この拡大はServer Helloに含まれていません、そして、サーバはClient Helloで拡大を無視します(存在しているなら)。
7.4.2. Server Certificate
7.4.2. サーバ証明書
When this message will be sent:
このメッセージを送るとき:
The server MUST send a Certificate message whenever the agreed-
upon key exchange method uses certificates for authentication
(this includes all key exchange methods defined in this document
except DH_anon). This message will always immediately follow the
ServerHello message.
主要な交換同意されたメソッドが認証に証明書を使用する(これは本書ではDHを除いて、_やがて定義されたすべての主要な交換メソッドを含んでいます)ときはいつも、サーバはCertificateメッセージを送らなければなりません。 このメッセージはすぐに、いつもServerHelloメッセージに従うでしょう。
Meaning of this message:
このメッセージの意味:
This message conveys the server's certificate chain to the client.
このメッセージはサーバの証明書チェーンをクライアントまで運びます。
The certificate MUST be appropriate for the negotiated cipher
suite's key exchange algorithm and any negotiated extensions.
交渉された暗号スイートの主要な交換アルゴリズムとどんな交渉された拡大にも、証明書は適切であるに違いありません。
Dierks & Rescorla Standards Track [Page 47] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[47ページ]。
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 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 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は証明書の系列(チェーン)です。 送付者の証明書はリストで一番にならなければなりません。 それぞれの次の証明書は直接それに先行するものを公認しなければなりません。 証明書合法化が、ルートキーが独自に分配されるのを必要とするので、ルート証明書権威を指定する自己署名入りの証書はチェーンから省略されるかもしれません、リモートエンドがどのような場合でも、それを有効にするために既にそれを所有しなければならないという仮定で。
The same message type and structure will be used for the client's response to a certificate request message. Note that a client MAY send no certificates if it does not have an appropriate certificate to send in response to the server's authentication request.
同じメッセージタイプと構造は証明書要求メッセージへのクライアントの応答に使用されるでしょう。 それにサーバの認証要求に対応して送るのが適切である証明書がないならクライアントが証明書を全く送らないかもしれないことに注意してください。
Note: PKCS #7 [PKCS7] is not used as the format for the certificate vector because PKCS #6 [PKCS6] extended certificates are not used. Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task of parsing the list more difficult.
以下に注意してください。 PKCS#6通[PKCS6]の拡張証明書が使用されていないので、PKCS#7[PKCS7]は証明書ベクトルに形式として使用されません。 また、リストを分析するタスクをより難しくして、PKCS#7はSEQUENCEよりむしろSETを定義します。
The following rules apply to the certificates sent by the server:
以下の規則はサーバによって送られた証明書に適用されます:
- The certificate type MUST be X.509v3, unless explicitly negotiated
otherwise (e.g., [TLSPGP]).
- 別の方法で(例えば[TLSPGP])明らかに交渉されない場合、証明書タイプはX.509v3であるに違いありません。
- The end entity certificate's public key (and associated
restrictions) MUST be compatible with the selected key exchange
algorithm.
- 終わりの実体証明書の公開鍵(そして、関連制限)は選択された主要な交換アルゴリズムと互換性があるに違いありません。
Key Exchange Alg. Certificate Key Type
主要な交換Alg。 証明書キータイプ
RSA RSA public key; the certificate MUST allow the
RSA_PSK key to be used for encryption (the
keyEncipherment bit MUST be set if the key
usage extension is present).
Note: RSA_PSK is defined in [TLSPSK].
RSA RSA公開鍵。 証明書は、RSA_PSKキーが暗号化に使用されるのを許容しなければなりません(主要な用法拡大が存在しているなら、keyEnciphermentビットを設定しなければなりません)。 以下に注意してください。 RSA_PSKは[TLSPSK]で定義されます。
Dierks & Rescorla Standards Track [Page 48] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[48ページ]。
DHE_RSA RSA public key; the certificate MUST allow the
ECDHE_RSA key to be used for signing (the
digitalSignature bit MUST be set if the key
usage extension is present) with the signature
scheme and hash algorithm that will be employed
in the server key exchange message.
Note: ECDHE_RSA is defined in [TLSECC].
DHE_RSA RSA公開鍵。 証明書は、ECDHE_RSAキーがサーバの主要な交換メッセージで使われる署名体系とハッシュアルゴリズムで署名すること(主要な用法拡大が存在しているなら、digitalSignatureビットを設定しなければならない)に使用されるのを許容しなければなりません。 以下に注意してください。 ECDHE_RSAは[TLSECC]で定義されます。
DHE_DSS DSA public key; the certificate MUST allow the
key to be used for signing with the hash
algorithm that will be employed in the server
key exchange message.
DHE_DSS DSA公開鍵。 証明書は、キーがサーバの主要な交換メッセージで使われるハッシュアルゴリズムと契約するのに使用されるのを許容しなければなりません。
DH_DSS Diffie-Hellman public key; the keyAgreement bit
DH_RSA MUST be set if the key usage extension is
present.
DH_DSSディフィー-ヘルマン公開鍵。 keyAgreementはDH_RSA MUSTに噛み付きました。主要な用法拡大が存在しているなら、用意ができてください。
ECDH_ECDSA ECDH-capable public key; the public key MUST
ECDH_RSA use a curve and point format supported by the
client, as described in [TLSECC].
ECDHの_のECDSA ECDHできる公開鍵。 公開鍵MUST ECDH_RSAは[TLSECC]で説明されるように形式がクライアントでサポートしたカーブとポイントを使用します。
ECDHE_ECDSA ECDSA-capable public key; the certificate MUST
allow the key to be used for signing with the
hash algorithm that will be employed in the
server key exchange message. The public key
MUST use a curve and point format supported by
the client, as described in [TLSECC].
ECDHEの_のECDSA ECDSAできる公開鍵。 証明書は、キーがサーバの主要な交換メッセージで使われるハッシュアルゴリズムと契約するのに使用されるのを許容しなければなりません。 公開鍵は[TLSECC]で説明されるように形式がクライアントでサポートしたカーブとポイントを使用しなければなりません。
- The "server_name" and "trusted_ca_keys" extensions [TLSEXT] are
used to guide certificate selection.
- 「サーバ_名」と「信じられた_ca_キー」拡張子[TLSEXT]は、証明書選択を誘導するのに使用されます。
If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension. Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with a DSA key). This is a departure from TLS 1.1, which required that the algorithms be the same. Note that this also implies that the DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the algorithm used to sign the certificate. Fixed DH certificates MAY be signed with any hash/signature algorithm pair appearing in the extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are historical.
クライアントが「署名_アルゴリズム」拡大を提供したなら、その拡大に現れるハッシュ/署名アルゴリズム組はサーバによって提供されたすべての証明書に署名しなければなりません。 これが、異なった署名アルゴリズムを使用するのが1つの署名アルゴリズムのためのキーを含む証明書に署名されるかもしれないのを含意することに注意してください(例えば、RSAキーはDSAキーでサインしました)。 これはTLS1.1からの出発です。(TLSはアルゴリズムが同じであることを必要としました)。 また、これが、DH_DSS、DH_RSA、ECDH_ECDSA、およびECDH_RSAの主要な交換アルゴリズムが証明書に署名するのに使用されるアルゴリズムを制限しないのを含意することに注意してください。 固定DH証明書は拡大に現れるどんなハッシュ/署名アルゴリズム組も契約されるかもしれません。 DH_DSSという名前、DH_RSA、ECDH_ECDSA、およびECDH_RSAは歴史的です。
Dierks & Rescorla Standards Track [Page 49] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[49ページ]。
If the server has multiple certificates, it chooses one of them based on the above-mentioned criteria (in addition to other criteria, such as transport layer endpoint, local configuration and preferences, etc.). If the server has a single certificate, it SHOULD attempt to validate that it meets these criteria.
サーバに複数の証明書があるなら、それは上記の評価基準(トランスポート層終点や地方の構成や好みなどの他の評価基準に加えた)に基づくそれらの1つを選びます。 サーバには、ただ一つの証明書があって、それは有効にするSHOULD試みです。これらの評価基準を満たします。
Note that there are certificates that use algorithms and/or algorithm combinations that cannot be currently used with TLS. For example, a certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in SubjectPublicKeyInfo) cannot be used because TLS defines no corresponding signature algorithm.
現在TLSと共に使用できないアルゴリズム、そして/または、アルゴリズム組み合わせを使用する証明書があることに注意してください。 例えば、TLSがどんな対応する署名アルゴリズムも定義しないので、RSASSA-PSS署名キー(SubjectPublicKeyInfoのイド-RSASSA-PSS OID)がある証明書を使用できません。
As cipher suites that specify new key exchange methods are specified for the TLS protocol, they will imply the certificate format and the required encoded keying information.
新しい主要な交換メソッドを指定する暗号スイートがTLSプロトコルに指定されるとき、彼らは証明書形式と情報を合わせながらコード化された必要を含意するでしょう。
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 ServerHello message, if this is an anonymous
negotiation).
または、サーバCertificateメッセージ直後このメッセージを送る、(ServerHelloメッセージこれが匿名の交渉であるなら
The ServerKeyExchange 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:
サーバCertificateメッセージ(送るなら)がクライアントが前マスター秘密を交換するのを許容できるくらいのデータを含まないときだけ、サーバはServerKeyExchangeメッセージを送ります。 以下の主要な交換メソッドに、これは本当です:
DHE_DSS
DHE_RSA
DH_anon
DHE_DSS DHE_RSA DH_、やがて。
It is not legal to send the ServerKeyExchange message for the
following key exchange methods:
以下の主要な交換メソッドへのServerKeyExchangeメッセージを送るのは法的ではありません:
RSA
DH_DSS
DH_RSA
RSA DH_DSS DH_RSA
Other key exchange algorithms, such as those defined in [TLSECC],
MUST specify whether the ServerKeyExchange message is sent or not;
and if the message is sent, its contents.
[TLSECC]で定義されたものなどの他の主要な交換アルゴリズムは、ServerKeyExchangeメッセージが送られるかどうか指定しなければなりません。 そして、メッセージを送るならそのコンテンツ。
Dierks & Rescorla Standards Track [Page 50] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[50ページ]。
Meaning of this message:
このメッセージの意味:
This message conveys cryptographic information to allow the client
to communicate the premaster secret: a Diffie-Hellman public key
with which the client can complete a key exchange (with the result
being the premaster secret) or a public key for some other
algorithm.
このメッセージはクライアントが前マスター秘密を伝えるのを許容するために暗号の情報を伝えます: クライアントがある他のアルゴリズムのために主要な交換(前マスター秘密である結果の)か公開鍵を終了できるディフィー-ヘルマン公開鍵。
Structure of this message:
このメッセージの構造:
enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa
/* may be extended, e.g., for ECDH -- see [TLSECC] */
} KeyExchangeAlgorithm;
例えば、ECDHのための広げられて、dssに、dheの_のrsaであって、_やがて、dhであって、rsaであって、dhな_dssであって、dhな_rsa/*がそうするかもしれないdhe_--[TLSECC]*/を見るのをenumする、KeyExchangeAlgorithm。
struct {
opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>;
} ServerDHParams; /* Ephemeral DH parameters */
struct不透明なdh_p<1..2^16-1>; 不透明なdh_g<1..2^16-1>; dh_Ys<1..2^16-1>について不透明にする;ServerDHParams。 /*はかないDHパラメタ*/
dh_p
The prime modulus used for the Diffie-Hellman operation.
主要な係数がディフィー-ヘルマンの操作に使用したdh_p。
dh_g
The generator used for the Diffie-Hellman operation.
ジェネレータがディフィー-ヘルマンの操作に使用したdh_g。
dh_Ys
The server's Diffie-Hellman public value (g^X mod p).
サーバのディフィー-ヘルマン公衆が評価するdh_Ys(g^Xモッズp)。
Dierks & Rescorla Standards Track [Page 51] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[51ページ]。
struct {
select (KeyExchangeAlgorithm) {
case dh_anon:
ServerDHParams params;
case dhe_dss:
case dhe_rsa:
ServerDHParams params;
digitally-signed struct {
opaque client_random[32];
opaque server_random[32];
ServerDHParams params;
} signed_params;
case rsa:
case dh_dss:
case dh_rsa:
struct {} ;
/* message is omitted for rsa, dh_dss, and dh_rsa */
/* may be extended, e.g., for ECDH -- see [TLSECC] */
};
} ServerKeyExchange;
struct、(KeyExchangeAlgorithm)を選択してください、_やがて、dhをケースに入れてください: dhe_dssをケースに入れてください: dhe_rsaをケースに入れてください: ServerDHParams params; 不透明なクライアント_無作為の[32]; structがサーバ_無作為の[32](ServerDHParams params)について不透明にするとデジタルに署名するのが_がparamsであると署名したというServerDHParams paramsはrsaをケースに入れます: dh_dssをケースに入れてください: dh_rsa: structをケースに入れてください、;、例えば、ECDHのための*メッセージがrsaに、dhに_dssに省略されて、広げられて、dh_rsa*//*がそうするかもしれない/--[TLSECC]*/を見てください ;、ServerKeyExchange。
params
The server's key exchange parameters.
サーバの主要な交換パラメタをparamsします。
signed_params
For non-anonymous key exchanges, a signature over the server's
key exchange parameters.
_params Forの非匿名の主要な交換、サーバの主要な交換パラメタの上の署名であると署名されます。
If the client has offered the "signature_algorithms" extension, the signature algorithm and hash algorithm MUST be a pair listed in that extension. Note that there is a possibility for inconsistencies here. For instance, the client might offer DHE_DSS key exchange but omit any DSA pairs from its "signature_algorithms" extension. In order to negotiate correctly, the server MUST check any candidate cipher suites against the "signature_algorithms" extension before selecting them. This is somewhat inelegant but is a compromise designed to minimize changes to the original cipher suite design.
クライアントが「署名_アルゴリズム」拡大を提供したなら、署名アルゴリズムとハッシュアルゴリズムはその拡大で記載された1組でなければなりません。 矛盾のための可能性がここにあることに注意してください。 例えば、クライアントは、_DSSの主要な交換をDHEに提供しますが、「署名_アルゴリズム」拡大からのどんなDSA組も省略するかもしれません。 正しく交渉するために、それらを選択する前に、サーバは「署名_アルゴリズム」拡大に対してどんな候補暗号スイートもチェックしなければなりません。 これは、いくらか優美でないのですが、オリジナルの暗号スイートデザインへの変化を最小にするように設計された感染です。
In addition, the hash and signature algorithms MUST be compatible with the key in the server's end-entity certificate. RSA keys MAY be used with any permitted hash algorithm, subject to restrictions in the certificate, if any.
さらに、ハッシュと署名アルゴリズムはサーバの終わり実体証明書のキーと互換性がなければなりません。 RSAキーはどんな証明書における制限を受けることがある受入れられたハッシュアルゴリズムでももしあれば使用されているかもしれません。
Because DSA signatures do not contain any secure indication of hash algorithm, there is a risk of hash substitution if multiple hashes may be used with any key. Currently, DSA [DSS] may only be used with SHA-1. Future revisions of DSS [DSS-3] are expected to allow the use of other digest algorithms with DSA, as well as guidance as to which
DSA署名がハッシュアルゴリズムのどんな安全なしるしも含んでいないので、複数のハッシュがどんなキーと共にも使用されるかもしれないなら、ハッシュ代替のリスクがあります。 現在、DSA[DSS]はSHA-1と共に使用されるだけであるかもしれません。 DSS[DSS-3]の今後の改正がDSA、および指導による他のダイジェストアルゴリズムの使用を許すと予想される、どれ
Dierks & Rescorla Standards Track [Page 52] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[52ページ]。
digest algorithms should be used with each key size. In addition, future revisions of [PKIX] may specify mechanisms for certificates to indicate which digest algorithms are to be used with DSA.
ダイジェストアルゴリズムはそれぞれの主要なサイズと共に使用されるべきです。 さらに、証明書が、どのダイジェストアルゴリズムがDSAと共に使用されるかことであるかを示すように、[PKIX]の今後の改正はメカニズムを指定するかもしれません。
As additional cipher suites 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のために追加暗号スイートを定義するときサーバの主要な交換メッセージを送る、主要な交換アルゴリズムに関連づけられた証明書タイプがクライアントが前マスター秘密を交換できるくらいの情報を提供しない場合にだけ。
7.4.4. Certificate Request
7.4.4. 証明書要求
When this message will be sent:
このメッセージを送るとき:
A non-anonymous server can optionally request a certificate from
the client, if appropriate for the selected cipher suite. This
message, if sent, will immediately follow the ServerKeyExchange
message (if it is sent; otherwise, this message follows the
server's Certificate message).
選択された暗号スイートに適切であるなら、非匿名のサーバはクライアントから証明書を任意に要求できます。 送るとこのメッセージがすぐにServerKeyExchangeメッセージに従う、(それを送ります; さもなければ、このメッセージがサーバの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)
} ClientCertificateType;
(1) dss_サイン(2)、_dh(3)が修理されたrsa_が_dh(4)が修理された_をdssして、_のはかない_rsa dh_RESERVED(5)、_のはかない_dss dh_RESERVED(6)が_dms_RESERVED(20)、(255)をfortezzaするというrsa_サインをenumする、ClientCertificateType。
opaque DistinguishedName<1..2^16-1>;
DistinguishedName<1について不透明にしてください。2^16-1>。
struct {
ClientCertificateType certificate_types<1..2^8-1>;
SignatureAndHashAlgorithm
supported_signature_algorithms<2^16-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
struct ClientCertificateType証明書_タイプ<1..2^8-1>; _署名_アルゴリズム<2^16-1>; DistinguishedName証明書_当局<0..2^16-1>であるとサポートされたSignatureAndHashAlgorithm;CertificateRequest。
certificate_types
A list of the types of certificate types that the client may
offer.
証明書_はクライアントが提供するかもしれない証明書タイプのタイプのAリストをタイプします。
rsa_sign a certificate containing an RSA key
dss_sign a certificate containing a DSA key
rsa_fixed_dh a certificate containing a static DH key.
dss_fixed_dh a certificate containing a static DH key
DSAの主要なrsa_を含む証明書は静的なDHキーを含む証明書を_dhに固定しました。rsa_はdss_が静的なDHキーを含む証明書を_dhに固定したというRSAの主要なdss_サインを含む証明書に署名します。
Dierks & Rescorla Standards Track [Page 53] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[53ページ]。
supported_signature_algorithms
A list of the hash/signature algorithm pairs that the server is
able to verify, listed in descending order of preference.
好みの降順で記載されていて、_署名_アルゴリズムAがサーバが確かめることができるハッシュ/署名アルゴリズム組のリストであるとサポートしました。
certificate_authorities
A list of the distinguished names [X501] of acceptable
certificate_authorities, represented in DER-encoded format. 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 known roots as well as 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.
_DERによってコード化された形式で代理をされた許容できる証明書_当局の分類名[X501]の当局Aリストを証明してください。 これらの分類名はカリフォルニアか下位のカリフォルニアとして必要な分類名を根に指定するかもしれません。 したがって、また、必要な承認スペースとして知られているルーツを記述するのにこのメッセージを使用できます。 証明書_当局リストが空であるなら、クライアントは適切なClientCertificateTypeのどんな証明書も送るかもしれません、何らかの外部のアレンジメントがそれと反対にない場合。
The interaction of the certificate_types and supported_signature_algorithms fields is somewhat complicated. certificate_types has been present in TLS since SSLv3, but was somewhat underspecified. Much of its functionality is superseded by supported_signature_algorithms. The following rules apply:
証明書_タイプとサポートしている_署名_アルゴリズム分野の相互作用はいくらか複雑です。_がタイプする証明書は、SSLv3以来TLSに存在していますが、いくらかunderspecifiedされました。 サポートしている_署名_アルゴリズムで機能性の多くが取って代わられます。以下の規則は適用されます:
- Any certificates provided by the client MUST be signed using a
hash/signature algorithm pair found in
supported_signature_algorithms.
- サポートしている_署名_アルゴリズムで見つけられたハッシュ/署名アルゴリズム組を使用して、クライアントによって提供されたどんな証明書にも署名しなければなりません。
- The end-entity certificate provided by the client MUST contain a
key that is compatible with certificate_types. If the key is a
signature key, it MUST be usable with some hash/signature
algorithm pair in supported_signature_algorithms.
- クライアントによって提供された終わり実体証明書は証明書_タイプと互換性があるキーを含まなければなりません。 キーが署名キーであるなら、何らかのハッシュ/署名アルゴリズム組と共にサポートしている_署名_アルゴリズムで使用可能であるに違いありません。
- For historical reasons, the names of some client certificate types
include the algorithm used to sign the certificate. For example,
in earlier versions of TLS, rsa_fixed_dh meant a certificate
signed with RSA and containing a static DH key. In TLS 1.2, this
functionality has been obsoleted by the
supported_signature_algorithms, and the certificate type no longer
restricts the algorithm used to sign the certificate. For
example, if the server sends dss_fixed_dh certificate type and
{{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply
with a certificate containing a static DH key, signed with RSA-
SHA1.
- 歴史的な理由で、何人かのクライアント証明書タイプの名前は証明書に署名するのに使用されるアルゴリズムを含んでいます。 例えば、TLSの以前のバージョンでは、_dhが修理されたrsa_はRSAでサインして、静的なDHキーを含む証明書を意味しました。 TLS1.2では、この機能性はサポートしている_署名_アルゴリズムで時代遅れにされました、そして、証明書タイプはもう証明書に署名するのに使用されるアルゴリズムを制限しません。 そして、例えば、サーバが発信するならdss_が_dh証明書タイプを修理した、sha1、dsa、sha1、rsa、署名タイプ(証明書が静的なDHキーを含んでいるクライアント5月の回答)はRSA- SHA1と契約しました。
New ClientCertificateType values are assigned by IANA as described in Section 12.
新しいClientCertificateType値はセクション12で説明されるようにIANAによって割り当てられます。
Note: Values listed as RESERVED may not be used. They were used in SSLv3.
以下に注意してください。 RESERVEDが使用されないかもしれないので、値は記載しました。 それらはSSLv3で使用されました。
Dierks & Rescorla Standards Track [Page 54] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[54ページ]。
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 ServerHelloDone message is sent by the server to indicate the
end of the ServerHello and associated messages. After sending
this message, the server will wait for a client response.
サーバでServerHelloDoneメッセージを送って、ServerHelloと関連メッセージの終わりを示します。 このメッセージを送った後に、サーバはクライアント応答を待っています。
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 ServerHelloDone message, the client SHOULD
verify that the server provided a valid certificate, if required,
and check that the server hello parameters are acceptable.
クライアントSHOULDがServerHelloDoneメッセージを受け取り次第必要なら、サーバが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
ServerHelloDone message. This message is only sent if the server
requests a certificate. If no suitable certificate is available,
the client MUST send a certificate message containing no
certificates. That is, the certificate_list structure has a
length of zero. If the client does not send any certificates, the
server MAY at its discretion either continue the handshake without
client authentication, or respond with a fatal handshake_failure
alert. Also, if some aspect of the certificate chain was
unacceptable (e.g., it was not signed by a known, trusted CA), the
server MAY at its discretion either continue the handshake
(considering the client unauthenticated) or send a fatal alert.
これはServerHelloDoneメッセージを受け取った後にクライアントが送ることができる最初のメッセージです。 サーバが証明書を要求する場合にだけ、このメッセージを送ります。 どんな適当な証明書も利用可能でないなら、クライアントは証明書を全く含まない証明書メッセージを送らなければなりません。 すなわち、証明書_リスト構造には、ゼロの長さがあります。 クライアントがどんな証明書も送らないなら、サーバは、自己判断でクライアント認証なしで握手を続けているか、または致命的な握手_故障警報で反応するかもしれません。 また、証明書チェーンの何らかの局面が容認できなかったなら(例えばそれは知られていて、信じられたカリフォルニアによって署名されませんでした)、サーバは、自己判断で握手(クライアントが非認証したと考える)を続けているか、または致命的な警戒を送るかもしれません。
Client certificates are sent using the Certificate structure
defined in Section 7.4.2.
クライアント証明書にセクション7.4.2で定義されたCertificate構造を使用させます。
Dierks & Rescorla Standards Track [Page 55] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[55ページ]。
Meaning of this message:
このメッセージの意味:
This message conveys the client's certificate chain to the server;
the server will use it when verifying the CertificateVerify
message (when the client authentication is based on signing) or
calculating the premaster secret (for non-ephemeral Diffie-
Hellman). The certificate MUST be appropriate for the negotiated
cipher suite's key exchange algorithm, and any negotiated
extensions.
このメッセージはクライアントの証明書チェーンをサーバまで運びます。 CertificateVerifyメッセージについて確かめるか(クライアント認証が署名に基づいているとき)、または前マスター秘密について計算するとき(非はかないディフィー・ヘルマンのために)、サーバはそれを使用するでしょう。 交渉された暗号スイートの主要な交換アルゴリズム、およびどんな交渉された拡大にも、証明書は適切であるに違いありません。
In particular:
特に:
- The certificate type MUST be X.509v3, unless explicitly negotiated
otherwise (e.g., [TLSPGP]).
- 別の方法で(例えば[TLSPGP])明らかに交渉されない場合、証明書タイプはX.509v3であるに違いありません。
- The end-entity certificate's public key (and associated
restrictions) has to be compatible with the certificate types
listed in CertificateRequest:
- 終わり実体証明書の公開鍵(そして、関連制限)はCertificateRequestに記載されている証明書タイプと互換性がなければなりません:
Client Cert. Type Certificate Key Type
クライアント本命。 型式証明の主要なタイプ
rsa_sign RSA public key; the certificate MUST allow the
key to be used for signing with the signature
scheme and hash algorithm that will be
employed in the certificate verify message.
rsa_サインRSA公開鍵。 証明書は、キーが署名体系と契約するのに使用されるのを許容しなければなりません、そして、証明書で使われるハッシュアルゴリズムはメッセージについて確かめます。
dss_sign DSA public key; the certificate MUST allow the
key to be used for signing with the hash
algorithm that will be employed in the
certificate verify message.
dss_サインDSA公開鍵。 証明書で使われるハッシュアルゴリズムと契約するとメッセージが確かめられるので、証明書は、キーが使用されるのを許容しなければなりません。
ecdsa_sign ECDSA-capable public key; the certificate MUST
allow the key to be used for signing with the
hash algorithm that will be employed in the
certificate verify message; the public key
MUST use a curve and point format supported by
the server.
ecdsa_はECDSAできる公開鍵に署名します。 証明書で使われるハッシュアルゴリズムと契約するとメッセージが確かめられるので、証明書は、キーが使用されるのを許容しなければなりません。 公開鍵は形式がサーバでサポートしたカーブとポイントを使用しなければなりません。
rsa_fixed_dh Diffie-Hellman public key; MUST use the same
dss_fixed_dh parameters as server's key.
rsa_は_dhディフィー-ヘルマン公開鍵を修理しました。 _dhパラメタがサーバのキーとして修理された同じdss_を使用しなければなりません。
rsa_fixed_ecdh ECDH-capable public key; MUST use the
ecdsa_fixed_ecdh same curve as the server's key, and MUST use a
point format supported by the server.
rsa_は_ecdh ECDHできる公開鍵を修理しました。 _ecdhのサーバのキーと同じカーブが修理されたecdsa_を使用しなければならなくて、サーバによってサポートされたポイント形式を使用しなければなりません。
- If the certificate_authorities list in the certificate request
message was non-empty, one of the certificates in the certificate
chain SHOULD be issued by one of the listed CAs.
- _証明書要求メッセージの当局リストは証明書であるなら非空でした、証明書チェーンSHOULDの証明書の1つ。記載CAsの1つによって発行されます。
Dierks & Rescorla Standards Track [Page 56] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[56ページ]。
- The certificates MUST be signed using an acceptable hash/
signature algorithm pair, as described in Section 7.4.4. Note
that this relaxes the constraints on certificate-signing
algorithms found in prior versions of TLS.
- セクション7.4.4で説明されるように許容できるハッシュ/署名アルゴリズム組を使用するのに証明書に署名しなければなりません。 これがTLSの先のバージョンで見つけられた証明書に署名するアルゴリズムで規制を寛げることに注意してください。
Note that, as with the server certificate, there are certificates that use algorithms/algorithm combinations that cannot be currently used with TLS.
現在TLSと共に使用できないアルゴリズム/アルゴリズム組み合わせを使用する証明書がサーバ証明書のようにあることに注意してください。
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 ServerHelloDone message.
このメッセージはいつもクライアントによって送られます。 それを送るなら、それはすぐに、クライアント証明書メッセージに従わなければなりません。 さもなければ、それはServerHelloDoneメッセージを受け取った後にクライアントによって送られた最初のメッセージであるに違いありません。
Meaning of this message:
このメッセージの意味:
With this message, the premaster secret is set, either by 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.
このメッセージと共に、前マスター秘密が設定されるか、RSAによって暗号化された秘密の直線伝動またはそれぞれの側が同じ前マスター秘密に同意できるディフィー-ヘルマンパラメタの伝達であります。
When the client is using an ephemeral Diffie-Hellman exponent,
then this message contains the client's Diffie-Hellman public
value. If the client is sending a certificate containing a static
DH exponent (i.e., it is doing fixed_dh client authentication),
then this message MUST be sent but MUST be empty.
クライアントがはかないディフィー-ヘルマン解説者を使用していると、このメッセージはクライアントのディフィー-ヘルマンの公共の値を含んでいます。 クライアントが静的なDH解説者を含む証明書を送るなら(すなわち、それは固定_dhクライアント認証をしています)、このメッセージは、送らなければなりませんが、空であるに違いありません。
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を見てください。
Dierks & Rescorla Standards Track [Page 57] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[57ページ]。
struct {
select (KeyExchangeAlgorithm) {
case rsa:
EncryptedPreMasterSecret;
case dhe_dss:
case dhe_rsa:
case dh_dss:
case dh_rsa:
case dh_anon:
ClientDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
(KeyExchangeAlgorithm)を選択してください。struct、ケースrsa: EncryptedPreMasterSecretケースdhe_dss: ケースdhe_rsa: ケースdh_dss: ケースdh_rsa: _やがてdhなケース: (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, and sends the result in
an encrypted premaster secret message. This structure is a
variant of the ClientKeyExchange message and is not a message in
itself.
RSAが主要な協定と認証に使用されているなら、クライアントは、48バイトの前マスター秘密を生成して、サーバの証明書から公開鍵を使用することでそれを暗号化して、暗号化された前マスター秘密の通信の結果を送ります。 この構造は、ClientKeyExchangeメッセージの異形であり、本来メッセージではありません。
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 rollback attacks.
最新(最も新しい)のバージョンがクライアントでサポートしたクライアント_バージョン。 これは、バージョンロールバック攻撃を検出するのに使用されます。
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で指定されるように。
Dierks & Rescorla Standards Track [Page 58] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[58ページ]。
Note: The version number in the PreMasterSecret is the version offered by the client in the ClientHello.client_version, not the version negotiated for the connection. This feature is designed to prevent rollback attacks. Unfortunately, some old implementations use the negotiated version instead, and therefore checking the version number may lead to failure to interoperate with such incorrect client implementations.
以下に注意してください。 PreMasterSecretのバージョン番号は接続のために交渉されたバージョンではなく、ClientHello.client_バージョンのクライアントによって提供されたバージョンです。 この特徴は、ロールバック攻撃を防ぐように設計されています。 残念ながら、いくつかの古い実装が代わりに交渉されたバージョンを使用します、そして、したがって、バージョン番号をチェックするのはそのような不正確なクライアント実装で共同利用しないことに通じるかもしれません。
Client implementations MUST always send the correct version number in PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher, server implementations MUST check the version number as described in the note below. If the version number is TLS 1.0 or earlier, server implementations SHOULD check the version number, but MAY have a configuration option to disable the check. Note that if the check fails, the PreMasterSecret SHOULD be randomized as described below.
クライアント実装はPreMasterSecretでいつも適度のバージョン番号を送らなければなりません。 ClientHello.client_バージョンがTLSより多くの1.1であるなら、サーバ実装は以下での注意で説明されるようにバージョン番号をチェックしなければなりません。 バージョン番号がTLS1.0以前であるなら、サーバ実装SHOULDはバージョン番号をチェックしますが、チェックを無効にする設定オプションを持っているかもしれません。 チェックやり損ない、PreMasterSecret SHOULDであるならそれに注意してください。説明されるとして、以下でランダマイズされてください。
Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al. [KPR03] can be used to attack a TLS server that reveals whether a particular message, when decrypted, is properly PKCS#1 formatted, contains a valid PreMasterSecret structure, or has the correct version number.
以下に注意してください。 Bleichenbacher[BLEI]によって発見された攻撃とクリマ他 解読されると特定のメッセージが適切にそうであるかどうかを明らかにするTLSサーバを攻撃するのに[KPR03]を使用できます。PKCS#1がフォーマットした、有効なPreMasterSecret構造を含んでいるか、または適度のバージョン番号を持っています。
As described by Klima [KPR03], these vulnerabilities can be avoided by treating incorrectly formatted message blocks and/or mismatched version numbers in a manner indistinguishable from correctly formatted RSA blocks. In other words:
クリマ[KPR03]によって説明されるように、正しくフォーマットされたRSAブロックから区別できない方法で不当にフォーマットされたメッセージブロック、そして/または、ミスマッチしているバージョン番号を扱うことによって、これらの脆弱性を避けることができます。 言い換えれば:
1. Generate a string R of 46 random bytes
1. ストリングが無作為の46バイトのRであると生成してください。
2. Decrypt the message to recover the plaintext M
2. 平文Mを回復するメッセージを解読してください。
3. If the PKCS#1 padding is not correct, or the length of message
M is not exactly 48 bytes:
pre_master_secret = ClientHello.client_version || R
else If ClientHello.client_version <= TLS 1.0, and version
number check is explicitly disabled:
pre_master_secret = M
else:
pre_master_secret = ClientHello.client_version || M[2..47]
3. PKCS#1詰め物が正しくないか、メッセージMの長さがちょうど48バイトでないなら: _前_のマスター秘密=ClientHello.client_バージョン|| RほかのIf ClientHello.client_バージョン<はTLS1.0と等しいです、そして、バージョン数のチェックは明らかに無効にされます: 前_のマスター_秘密はほかにMと等しいです: _前_のマスター秘密=ClientHello.client_バージョン|| M[2..47]
Note that explicitly constructing the pre_master_secret with the ClientHello.client_version produces an invalid master_secret if the client has sent the wrong version in the original pre_master_secret.
ClientHello.client_バージョンで明らかに前_のマスター_秘密を構成するとクライアントがオリジナルの前_のマスター_秘密の間違ったバージョンを送ったなら無効のマスター_秘密が作り出されることに注意してください。
An alternative approach is to treat a version number mismatch as a PKCS-1 formatting error and randomize the premaster secret completely:
代替的アプローチは、PKCS-1形式誤りとしてバージョン数のミスマッチを扱って、前マスター秘密を完全にランダマイズすることです:
Dierks & Rescorla Standards Track [Page 59] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[59ページ]。
1. Generate a string R of 48 random bytes
1. ストリングが無作為の48バイトのRであると生成してください。
2. Decrypt the message to recover the plaintext M
2. 平文Mを回復するメッセージを解読してください。
3. If the PKCS#1 padding is not correct, or the length of message
M is not exactly 48 bytes:
pre_master_secret = R
else If ClientHello.client_version <= TLS 1.0, and version
number check is explicitly disabled:
premaster secret = M
else If M[0..1] != ClientHello.client_version:
premaster secret = R
else:
premaster secret = M
3. PKCS#1詰め物が正しくないか、メッセージMの長さがちょうど48バイトでないなら: 前_のマスター_秘密=RほかのIf ClientHello.client_バージョン<はTLS1.0と等しいです、そして、バージョン数のチェックは明らかに無効にされます: 前マスター秘密の=MほかのIf M[0 .1]!=ClientHello.client_バージョン: 前マスター秘密はほかにRと等しいです: 前マスターの秘密の=M
Although no practical attacks against this construction are known, Klima et al. [KPR03] describe some theoretical attacks, and therefore the first construction described is RECOMMENDED.
この工事に対するどんな実用的な攻撃も知られていませんが、クリマ他です。 [KPR03]はいくつかの理論上の攻撃について説明します、そして、したがって、説明された最初の工事はRECOMMENDEDです。
In any case, a TLS server MUST NOT generate an alert if processing an RSA-encrypted premaster secret message fails, or the version number is not as expected. Instead, it MUST continue the handshake with a randomly generated premaster secret. It may be useful to log the real cause of failure for troubleshooting purposes; however, care must be taken to avoid leaking the information to an attacker (through, e.g., timing, log files, or other channels.)
どのような場合でも、RSAによって暗号化された前マスター秘密の通信を処理するのが失敗するか、または予想されるとしてバージョン番号がないなら、TLSサーバは警戒を生成してはいけません。 代わりに、それは手当たりしだいに発生している前マスター秘密がある握手を続けなければなりません。 トラブルシューティング目的のために失敗の本当の原因を登録するのは役に立つかもしれません。 しかしながら、情報を攻撃者に漏らすのを避けるために注意しなければなりません。(突き抜けて、例えば、調節していて、ファイル、または他のチャンネルを登録してください。)
The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure against the Bleichenbacher attack. However, for maximal compatibility with earlier versions of TLS, this specification uses the RSAES-PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known to exist provided that the above recommendations are followed.
[PKCS1]で定義されたRSAES-OAEP暗号化体系はBleichenbacher攻撃に対して、より安全です。 しかしながら、TLSの以前のバージョンとの最大限度の互換性のために、この仕様はRSAES-PKCS1-v1_5体系を使用します。 上の推薦が続かれていれば、Bleichenbacher攻撃の異形が全く存在するのが知られません。
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 -- they encode the RSA-encrypted data directly in the ClientKeyExchange message.
実装注意: 公開鍵で暗号化されたデータは不透明なベクトル<0として表されます。2^16-1 >(セクション4.7を見ます)。 したがって、ClientKeyExchangeのRSAによって暗号化されたPreMasterSecretは2長さのバイト先行されています。 EncryptedPreMasterSecretがClientKeyExchangeで唯一のデータであり、したがって、明白に長さは測定できるので、これらのバイトはRSAの場合で余分です。 したがって、多くのSSLv3実装は長さのバイトを含んでいません--SSLv3仕様は公開鍵の暗号化されたデータのコード化に関して明確ではありませんでした、そして、それらは直接ClientKeyExchangeメッセージのRSAによって暗号化されたデータをコード化します。
This specification requires correct encoding of the EncryptedPreMasterSecret complete with length bytes. The resulting PDU is incompatible with many SSLv3 implementations. Implementors
この仕様は長さのバイトで完全なEncryptedPreMasterSecretの正しいコード化を必要とします。 結果として起こるPDUは多くのSSLv3実装と非互換です。 作成者
Dierks & Rescorla Standards Track [Page 60] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[60ページ]。
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.
SSLv3からアップグレードするのは、正しいコード化を生成して、受け入れるようにそれらの実装を変更しなければなりません。 SSLv3とTLSの両方と互換性がありたがっている作成者は彼らの実装の振舞いをプロトコルバージョンに依存するようにするべきです。
Implementation note: It is now known that remote timing-based attacks on TLS are possible, at least when the client and server are on the same LAN. Accordingly, implementations that use static RSA keys MUST use RSA blinding or some other anti-timing technique, as described in [TIMING].
実装注意: 今、クライアントとサーバが同じLANにあるとき、TLSに対するリモートタイミングベースの攻撃が可能であることが少なくとも知られています。 それに従って、静的なRSAキーを使用する実装は[TIMING]で説明されるようにRSA盲目かある他の反タイミングのテクニックを使用しなければなりません。
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 has sent a certificate which contains a suitable
Diffie-Hellman key (for fixed_dh client authentication), 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が適当なディフィー-ヘルマンキー(固定_dhクライアント認証のための)を含む証明書を送って、次に、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)を評価します。
Dierks & Rescorla Standards Track [Page 61] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[61ページ]。
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.
このメッセージは、クライアント証明書の明白な検証を提供するのに使用されます。 このメッセージを署名能力を持っているクライアント証明書(固定ディフィー-ヘルマンパラメタを含むもの以外のすなわちすべての証明書)に従わせるだけです。 送ると、それはすぐに、クライアントの主要な交換メッセージに従わなければなりません。
Structure of this message:
このメッセージの構造:
struct {
digitally-signed struct {
opaque handshake_messages[handshake_messages_length];
}
} CertificateVerify;
struct、structにデジタルに署名する、不明瞭な握手_メッセージ[握手_メッセージ_の長さ];、CertificateVerify。
Here handshake_messages refers to all handshake messages sent or
received, starting at client hello and 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 Section 7.4) exchanged thus
far. Note that this requires both sides to either buffer the
messages or compute running hashes for all potential hash
algorithms up to the time of the CertificateVerify computation.
Servers can minimize this computation cost by offering a
restricted set of digest algorithms in the CertificateRequest
message.
ここには、_が通信させる握手がメッセージが送ったか、または受けたすべての握手を呼びます、クライアントで始まってこんにちは、密かに企てますが、握手メッセージのタイプと長さの分野を含むこのメッセージを、含んでいないこと。 これはこれまでのところ交換されたすべてのHandshake構造(セクション7.4で定義されるように)の連結です。 これがすべての潜在的ハッシュアルゴリズムのためにCertificateVerify計算の時間までメッセージをバッファリングするか、または実行しているハッシュを計算するために両側を必要とすることに注意してください。 サーバは、CertificateRequestメッセージの制限されたセットのダイジェストアルゴリズムを提供することによって、この計算費用を最小にすることができます。
The hash and signature algorithms used in the signature MUST be
one of those present in the supported_signature_algorithms field
of the CertificateRequest message. In addition, the hash and
signature algorithms MUST be compatible with the key in the
client's end-entity certificate. RSA keys MAY be used with any
permitted hash algorithm, subject to restrictions in the
certificate, if any.
アルゴリズムが署名に使用したハッシュと署名はCertificateRequestメッセージのサポートしている_署名_アルゴリズム分野に出席しているそれらの1つであるに違いありません。 さらに、ハッシュと署名アルゴリズムはクライアントの終わり実体証明書のキーと互換性がなければなりません。 RSAキーはどんな証明書における制限を受けることがある受入れられたハッシュアルゴリズムでももしあれば使用されているかもしれません。
Because DSA signatures do not contain any secure indication of
hash algorithm, there is a risk of hash substitution if multiple
hashes may be used with any key. Currently, DSA [DSS] may only be
used with SHA-1. Future revisions of DSS [DSS-3] are expected to
allow the use of other digest algorithms with DSA, as well as
guidance as to which digest algorithms should be used with each
key size. In addition, future revisions of [PKIX] may specify
mechanisms for certificates to indicate which digest algorithms
are to be used with DSA.
DSA署名がハッシュアルゴリズムのどんな安全なしるしも含んでいないので、複数のハッシュがどんなキーと共にも使用されるかもしれないなら、ハッシュ代替のリスクがあります。 現在、DSA[DSS]はSHA-1と共に使用されるだけであるかもしれません。 DSS[DSS-3]の今後の改正がDSAとの他のダイジェストアルゴリズムの使用を許すと予想されます、ダイジェストアルゴリズムがそれぞれの主要なサイズと共に使用されるべきである指導と同様に。 さらに、証明書が、どのダイジェストアルゴリズムがDSAと共に使用されるかことであるかを示すように、[PKIX]の今後の改正はメカニズムを指定するかもしれません。
Dierks & Rescorla Standards Track [Page 62] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[62ページ]。
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メッセージを送ります。 他の握手メッセージとFinishedメッセージの間に変化暗号仕様メッセージを受け取るのは不可欠です。
Meaning of this message:
このメッセージの意味:
The Finished message is the first one 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.
Finishedメッセージはただ交渉されたアルゴリズム、キー、および秘密で保護された最初のものです。 Finishedメッセージの受取人は、内容が正しいことを確かめなければなりません。 側が同輩からFinishedメッセージをいったんFinishedメッセージを送って、受けて、有効にすると、それは、接続の上にアプリケーションデータを送って、受け取り始めるかもしれません。
Structure of this message:
このメッセージの構造:
struct {
opaque verify_data[verify_data_length];
} Finished;
struct、不透明なものは_データについて確かめます[_データ_長さについて確かめてください];、終わっています。
verify_data
PRF(master_secret, finished_label, Hash(handshake_messages))
[0..verify_data_length-1];
_データPRFについて確かめてください(_秘密の、そして、完成している_がラベル、Hash(握手_メッセージ)であるとマスタリングしてください)[0..verify_データ_長さ-1]。
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メッセージに関しては、「サーバは完成しました」。
Hash denotes a Hash of the handshake messages. For the PRF
defined in Section 5, the Hash MUST be the Hash used as the basis
for the PRF. Any cipher suite which defines a different PRF MUST
also define the Hash to use in the Finished computation.
ハッシュは握手メッセージのHashを指示します。 セクション5で定義されたPRFに関しては、HashはPRFの基礎として使用されるHashであるに違いありません。 また、異なったPRF MUSTを定義するどんな暗号スイートもFinished計算における使用とHashを定義します。
In previous versions of TLS, the verify_data was always 12 octets
long. In the current version of TLS, it depends on the cipher
suite. Any cipher suite which does not explicitly specify
verify_data_length has a verify_data_length equal to 12. This
includes all existing cipher suites. Note that this
representation has the same encoding as with previous versions.
Future cipher suites MAY specify other lengths but such length
MUST be at least 12 bytes.
_について確かめてください。TLSの旧バージョンで長い間、いつもデータは12の八重奏でした。 TLSの最新版では、それは暗号スイートによります。 明らかに指定しないどんな暗号スイートも_のデータ_長さの等しい状態でaがデータ_長さで確かめる_について12まで確かめます。 これはすべての既存の暗号スイートを含んでいます。 この表現には同じくらいが旧バージョンのようにコード化しながらあることに注意してください。 将来の暗号スイートは他の長さを指定するかもしれませんが、そのような長さは少なくとも12バイトでなければなりません。
Dierks & Rescorla Standards Track [Page 63] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[63ページ]。
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
Section 7.4, exchanged thus far.
この握手(どんなHelloRequestメッセージも含んでいない)に上がっていて、しかし、含んでいないメッセージ、このすべてのメッセージからのデータの握手_メッセージAll。 これは、握手層で目に見えるデータだけであり、記録的な層のヘッダーを含んでいません。 これはこれまでのところ交換されたセクション7.4で定義されるようにすべてのHandshake構造の連結です。
It is a fatal error if a Finished message is not preceded by a ChangeCipherSpec message at the appropriate point in the handshake.
適切なポイントのChangeCipherSpecメッセージが握手でFinishedメッセージに先行しないなら、それは致命的な誤りです。
The value handshake_messages includes all handshake messages starting at ClientHello 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 CertificateVerify 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.
包含、このFinishedメッセージではなく、_メッセージがClientHelloで始まるすべての握手メッセージを含む値の握手。 CertificateVerifyメッセージを含んでいるでしょう(送るなら)、したがって、これはセクション7.4.8における握手_メッセージと異なっているかもしれません。 また、クライアントによって送られたFinishedメッセージへの握手_メッセージはそれからサーバによって送られたFinishedメッセージにおいて異なるようになるでしょう、2番目に、送られるのが先のものを含むので。
Note: ChangeCipherSpec messages, alerts, and any other record types are not handshake messages and are not included in the hash computations. Also, HelloRequest messages are omitted from handshake hashes.
以下に注意してください。 ChangeCipherSpecメッセージ、警戒、およびいかなる他のレコード種類も、握手メッセージでなく、またハッシュ計算に含まれていません。 また、HelloRequestメッセージは握手ハッシュから省略されます。
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 ServerHello 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アルゴリズムはサーバによって選択されて、ServerHelloメッセージで明らかにされた暗号_スイートのそばで決定しています。 圧縮アルゴリズムが交渉される、こんにちは、通信して、中と交換される、無作為が、評価するこんにちは、メッセージ。 残っているすべてはマスター秘密について計算することです。
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.
すべての主要な交換メソッドにおいて、同じアルゴリズムは、前_のマスター_秘密をマスター_秘密に変換するのに使用されます。 マスター_秘密がいったん計算されると、前_のマスター_秘密はメモリから削除されるべきです。
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バイトです。 主要な交換メソッドによって、前マスター秘密の長さは異なるでしょう。
Dierks & Rescorla Standards Track [Page 64] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[64ページ]。
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バイト、クライアントは生成して、サーバの公開鍵の下で暗号化して、サーバに送ります。サーバは、前_のマスター_秘密を解読するのに秘密鍵を使用します。 そして、双方は上で指定されるとして前_のマスター_秘密をマスター_秘密に変換します。
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_AES_128_CBC_SHA (see Appendix A.5 for the definition).
別の方法で指定するアプリケーションプロフィール規格がないとき、TLS対応することのアプリケーションは、暗号スイートTLS_RSA_WITH_AES_128_CBC_がSHAであると実装しなければなりません(定義に関してAppendix A.5を見てください)。
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.
アプリケーションデータメッセージは、現在の接続状態に基づいて記録的な層のそばで運ばれて、断片化されて、圧縮されて、暗号化されます。 メッセージは記録的な層への見え透いたデータとして扱われます。
11. Security Considerations
11. セキュリティ問題
Security issues are discussed throughout this memo, especially in Appendices D, E, and F.
特にAppendices D、E、およびFでこのメモ中で安全保障問題について議論します。
12. IANA Considerations
12. IANA問題
This document uses several registries that were originally created in [TLS1.1]. IANA has updated these to reference this document. The registries and their allocation policies (unchanged from [TLS1.1]) are listed below.
このドキュメントは元々[TLS1.1]で作成されたいくつかの登録を使用します。 IANAはこれが記録する参照にこれらをアップデートしました。 登録とそれらの配分方針([TLS1.1]から変わりのない)は以下に記載されています。
Dierks & Rescorla Standards Track [Page 65] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[65ページ]。
- TLS ClientCertificateType Identifiers Registry: Future values in
the range 0-63 (decimal) inclusive are assigned via Standards
Action [RFC2434]. Values in the range 64-223 (decimal) inclusive
are assigned via Specification Required [RFC2434]. Values from
224-255 (decimal) inclusive are reserved for Private Use
[RFC2434].
- TLS ClientCertificateType識別子登録: 範囲0-63(小数)で包括的な将来価値はStandards Action[RFC2434]を通して割り当てられます。 範囲64-223(小数)で包括的な値はSpecification Required[RFC2434]を通して割り当てられます。 224-255(小数)から包括的な値は兵士のUse[RFC2434]のために予約されます。
- TLS Cipher Suite Registry: Future values with the first byte in
the range 0-191 (decimal) inclusive are assigned via Standards
Action [RFC2434]. Values with the first byte in the range 192-254
(decimal) are assigned via Specification Required [RFC2434].
Values with the first byte 255 (decimal) are reserved for Private
Use [RFC2434].
- TLSはスイート登録を解きます: 範囲0-191(小数)で包括的な最初のバイトがある将来価値はStandards Action[RFC2434]を通して割り当てられます。 範囲192-254(小数)における最初のバイトがある値はSpecification Required[RFC2434]を通して割り当てられます。 最初のバイト255(小数)がある値は兵士のUse[RFC2434]のために予約されます。
- This document defines several new HMAC-SHA256-based cipher suites,
whose values (in Appendix A.5) have been allocated from the TLS
Cipher Suite registry.
- このドキュメントは値(Appendix A.5の)がTLS Cipher Suite登録から割り当てられたいくつかの新しいHMAC-SHA256ベースの暗号スイートを定義します。
- TLS ContentType Registry: Future values are allocated via
Standards Action [RFC2434].
- TLS ContentType登録: Standards Action[RFC2434]を通して将来価値を割り当てます。
- TLS Alert Registry: Future values are allocated via Standards
Action [RFC2434].
- TLSは登録を警告します: Standards Action[RFC2434]を通して将来価値を割り当てます。
- TLS HandshakeType Registry: Future values are allocated via
Standards Action [RFC2434].
- TLS HandshakeType登録: Standards Action[RFC2434]を通して将来価値を割り当てます。
This document also uses a registry originally created in [RFC4366]. IANA has updated it to reference this document. The registry and its allocation policy (unchanged from [RFC4366]) is listed below:
また、このドキュメントは元々[RFC4366]で作成された登録を使用します。 IANAはこれが記録する参照にそれをアップデートしました。 登録とその配分方針([RFC4366]から変わりのない)は以下に記載されています:
- TLS ExtensionType Registry: Future values are allocated via IETF
Consensus [RFC2434]. IANA has updated this registry to include
the signature_algorithms extension and its corresponding value
(see Section 7.4.1.4).
- TLS ExtensionType登録: IETF Consensus[RFC2434]を通して将来価値を割り当てます。 セクション7.4を見てください。IANAが署名_アルゴリズム拡大とその換算値を含むようにこの登録をアップデートした、(.1 .4)。
In addition, this document defines two new registries to be maintained by IANA:
さらに、このドキュメントはIANAによって維持される2つの新しい登録を定義します:
- TLS SignatureAlgorithm Registry: The registry has been initially
populated with the values described in Section 7.4.1.4.1. Future
values in the range 0-63 (decimal) inclusive are assigned via
Standards Action [RFC2434]. Values in the range 64-223 (decimal)
inclusive are assigned via Specification Required [RFC2434].
Values from 224-255 (decimal) inclusive are reserved for Private
Use [RFC2434].
- TLS SignatureAlgorithm登録: 登録は初めは、値説明されたコネセクション7.4.1の.4で.1に居住されました。 範囲0-63(小数)で包括的な将来価値はStandards Action[RFC2434]を通して割り当てられます。 範囲64-223(小数)で包括的な値はSpecification Required[RFC2434]を通して割り当てられます。 224-255(小数)から包括的な値は兵士のUse[RFC2434]のために予約されます。
Dierks & Rescorla Standards Track [Page 66] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[66ページ]。
- TLS HashAlgorithm Registry: The registry has been initially
populated with the values described in Section 7.4.1.4.1. Future
values in the range 0-63 (decimal) inclusive are assigned via
Standards Action [RFC2434]. Values in the range 64-223 (decimal)
inclusive are assigned via Specification Required [RFC2434].
Values from 224-255 (decimal) inclusive are reserved for Private
Use [RFC2434].
- TLS HashAlgorithm登録: 登録は初めは、値説明されたコネセクション7.4.1の.4で.1に居住されました。 範囲0-63(小数)で包括的な将来価値はStandards Action[RFC2434]を通して割り当てられます。 範囲64-223(小数)で包括的な値はSpecification Required[RFC2434]を通して割り当てられます。 224-255(小数)から包括的な値は兵士のUse[RFC2434]のために予約されます。
This document also uses the TLS Compression Method Identifiers
Registry, defined in [RFC3749]. IANA has allocated value 0 for
the "null" compression method.
また、このドキュメントは[RFC3749]で定義されたTLS Compression Method Identifiers Registryを使用します。 IANAは「ヌル」の圧縮方法のために値0を割り当てました。
Dierks & Rescorla Standards Track [Page 67] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[67ページ]。
Appendix A. Protocol Data Structures and Constant Values
付録A.プロトコルデータ構造と恒常価値
This section describes protocol types and constants.
このセクションはプロトコルタイプと定数について説明します。
A.1. Record Layer
A.1。 層を記録してください。
struct {
uint8 major;
uint8 minor;
} ProtocolVersion;
struct uint8少佐; uint8未成年者;ProtocolVersion。
ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/
ProtocolVersionバージョン= 3、3。 /*TLS v1.2*/
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。
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSCompressed.length];
} TLSCompressed;
struct ContentTypeタイプ; ProtocolVersionバージョン; uint16の長さ; 不明瞭な断片[TLSCompressed.length];TLSCompressed。
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (SecurityParameters.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
case aead: GenericAEADCipher;
} fragment;
} TLSCiphertext;
struct ContentTypeタイプ; ProtocolVersionバージョン; uint16の長さ; ケースストリーム: ケースが、: GenericBlockCipher; aead: GenericAEADCipherをケースに入れるのを妨げるというGenericStreamCipherが断片化する選んだ(SecurityParameters.cipher_タイプ);TLSCiphertext。
stream-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length];
} GenericStreamCipher;
stream-ciphered struct { opaque content[TLSCompressed.length]; opaque MAC[SecurityParameters.mac_length]; } GenericStreamCipher;
Dierks & Rescorla Standards Track [Page 68] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 68] RFC 5246 TLS August 2008
struct {
opaque IV[SecurityParameters.record_iv_length];
block-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
};
} GenericBlockCipher;
struct { opaque IV[SecurityParameters.record_iv_length]; block-ciphered struct { opaque content[TLSCompressed.length]; opaque MAC[SecurityParameters.mac_length]; uint8 padding[GenericBlockCipher.padding_length]; uint8 padding_length; }; } GenericBlockCipher;
struct {
opaque nonce_explicit[SecurityParameters.record_iv_length];
aead-ciphered struct {
opaque content[TLSCompressed.length];
};
} GenericAEADCipher;
struct { opaque nonce_explicit[SecurityParameters.record_iv_length]; aead-ciphered struct { opaque content[TLSCompressed.length]; }; } GenericAEADCipher;
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_RESERVED(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),
enum { close_notify(0), unexpected_message(10), bad_record_mac(20), decryption_failed_RESERVED(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),
Dierks & Rescorla Standards Track [Page 69] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 69] RFC 5246 TLS August 2008
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110), /* new */
(255)
} AlertDescription;
insufficient_security(71), internal_error(80), user_canceled(90), no_renegotiation(100), unsupported_extension(110), /* new */ (255) } AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
struct { AlertLevel level; AlertDescription description; } Alert;
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;
Dierks & Rescorla Standards Track [Page 70] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 70] RFC 5246 TLS August 2008
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-2>;
CompressionMethod compression_methods<1..2^8-1>;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ClientHello;
struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..2^16-2>; CompressionMethod compression_methods<1..2^8-1>; select (extensions_present) { case false: struct {}; case true: Extension extensions<0..2^16-1>; }; } ClientHello;
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ServerHello;
struct { ProtocolVersion server_version; Random random; SessionID session_id; CipherSuite cipher_suite; CompressionMethod compression_method; select (extensions_present) { case false: struct {}; case true: Extension extensions<0..2^16-1>; }; } ServerHello;
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
struct { ExtensionType extension_type; opaque extension_data<0..2^16-1>; } Extension;
Dierks & Rescorla Standards Track [Page 71] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 71] RFC 5246 TLS August 2008
enum {
signature_algorithms(13), (65535)
} ExtensionType;
enum { signature_algorithms(13), (65535) } ExtensionType;
enum{
none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
sha512(6), (255)
} HashAlgorithm;
enum {
anonymous(0), rsa(1), dsa(2), ecdsa(3), (255)
} SignatureAlgorithm;
enum{ none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } SignatureAlgorithm;
struct {
HashAlgorithm hash;
SignatureAlgorithm signature;
} SignatureAndHashAlgorithm;
struct { HashAlgorithm hash; SignatureAlgorithm signature; } SignatureAndHashAlgorithm;
SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-1>;
SignatureAndHashAlgorithm supported_signature_algorithms<2..2^16-1>;
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 { dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa
/* may be extended, e.g., for ECDH -- see [TLSECC] */
} KeyExchangeAlgorithm;
enum { dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa /* may be extended, e.g., for ECDH -- see [TLSECC] */ } KeyExchangeAlgorithm;
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 { 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 */
Dierks & Rescorla Standards Track [Page 72] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 72] RFC 5246 TLS August 2008
struct {
select (KeyExchangeAlgorithm) {
case dh_anon:
ServerDHParams params;
case dhe_dss:
case dhe_rsa:
ServerDHParams params;
digitally-signed struct {
opaque client_random[32];
opaque server_random[32];
ServerDHParams params;
} signed_params;
case rsa:
case dh_dss:
case dh_rsa:
struct {} ;
/* message is omitted for rsa, dh_dss, and dh_rsa */
/* may be extended, e.g., for ECDH -- see [TLSECC] */
} ServerKeyExchange;
struct { select (KeyExchangeAlgorithm) { case dh_anon: ServerDHParams params; case dhe_dss: case dhe_rsa: ServerDHParams params; digitally-signed struct { opaque client_random[32]; opaque server_random[32]; ServerDHParams params; } signed_params; case rsa: case dh_dss: case dh_rsa: struct {} ; /* message is omitted for rsa, dh_dss, and dh_rsa */ /* may be extended, e.g., for ECDH -- see [TLSECC] */ } ServerKeyExchange;
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;
Dierks & Rescorla Standards Track [Page 73] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 73] RFC 5246 TLS August 2008
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 dhe_dss:
case dhe_rsa:
case dh_dss:
case dh_rsa:
case dh_anon:
ClientDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
struct { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret; case dhe_dss: case dhe_rsa: case dh_dss: case dh_rsa: case dh_anon: ClientDiffieHellmanPublic; } exchange_keys; } ClientKeyExchange;
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 {
digitally-signed struct {
opaque handshake_messages[handshake_messages_length];
}
} CertificateVerify;
struct { digitally-signed struct { opaque handshake_messages[handshake_messages_length]; } } CertificateVerify;
A.4.4. Handshake Finalization Message
A.4.4. Handshake Finalization Message
struct {
opaque verify_data[verify_data_length];
} Finished;
struct { opaque verify_data[verify_data_length]; } Finished;
Dierks & Rescorla Standards Track [Page 74] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 74] RFC 5246 TLS August 2008
A.5. The Cipher Suite
A.5. The Cipher Suite
The following values define the cipher suite codes used in the ClientHello and ServerHello messages.
The following values define the cipher suite codes used in the ClientHello and ServerHello messages.
A cipher suite defines a cipher specification supported in TLS Version 1.2.
A cipher suite defines a cipher specification supported in TLS Version 1.2.
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 any 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 any signature-capable certificate in the certificate request message.
CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };
CipherSuite TLS_RSA_WITH_NULL_SHA256 = { 0x00,0x3B };
CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F };
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 };
CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3C };
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D };
CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }; CipherSuite TLS_RSA_WITH_NULL_SHA256 = { 0x00,0x3B }; CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F }; CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 }; CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3C }; CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D };
The following cipher suite 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 signature-capable certificate, which has been signed by the CA. The signing algorithm used by the server is specified after the DHE component of the CipherSuite name. The server can request any 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 cipher suite 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 signature-capable certificate, which has been signed by the CA. The signing algorithm used by the server is specified after the DHE component of the CipherSuite name. The server can request any 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.
Dierks & Rescorla Standards Track [Page 75] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 75] RFC 5246 TLS August 2008
CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
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_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_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x3E };
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3F };
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x40 };
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x67 };
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x68 };
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x69 };
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x6A };
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x6B };
CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; 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_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_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x3E }; CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3F }; CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x40 }; CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x67 }; CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x68 }; CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x69 }; CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x6A }; CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x6B };
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. Using this mode therefore is of limited use: These cipher suites MUST NOT be used by TLS 1.2 implementations unless the application layer has specifically requested to allow anonymous key exchange. (Anonymous key exchange may sometimes be acceptable, for example, to support opportunistic encryption when no set-up for authentication is in place, or when TLS is used as part of more complex security protocols that have other means to ensure authentication.)
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. Using this mode therefore is of limited use: These cipher suites MUST NOT be used by TLS 1.2 implementations unless the application layer has specifically requested to allow anonymous key exchange. (Anonymous key exchange may sometimes be acceptable, for example, to support opportunistic encryption when no set-up for authentication is in place, or when TLS is used as part of more complex security protocols that have other means to ensure authentication.)
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00,0x6C };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00,0x6D };
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 }; CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A }; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00,0x6C }; CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00,0x6D };
Note that using non-anonymous key exchange without actually verifying the key exchange is essentially equivalent to anonymous key exchange, and the same precautions apply. While non-anonymous key exchange will generally involve a higher computational and communicational cost than anonymous key exchange, it may be in the interest of interoperability not to disable non-anonymous key exchange when the application layer is allowing anonymous key exchange.
Note that using non-anonymous key exchange without actually verifying the key exchange is essentially equivalent to anonymous key exchange, and the same precautions apply. While non-anonymous key exchange will generally involve a higher computational and communicational cost than anonymous key exchange, it may be in the interest of interoperability not to disable non-anonymous key exchange when the application layer is allowing anonymous key exchange.
Dierks & Rescorla Standards Track [Page 76] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 76] RFC 5246 TLS August 2008
New cipher suite values have been assigned by IANA as described in Section 12.
New cipher suite values have been assigned by IANA as described in Section 12.
Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
reserved to avoid collision with Fortezza-based cipher suites in
SSL 3.
Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are reserved to avoid collision with Fortezza-based cipher suites in SSL 3.
A.6. The Security Parameters
A.6. The Security Parameters
These security parameters are determined by the TLS Handshake Protocol and provided as parameters to the TLS record layer in order to initialize a connection state. SecurityParameters includes:
These security parameters are determined by the TLS Handshake Protocol and provided as parameters to the TLS record layer in order to initialize a connection state. SecurityParameters includes:
enum { null(0), (255) } CompressionMethod;
enum { null(0), (255) } CompressionMethod;
enum { server, client } ConnectionEnd;
enum { server, client } ConnectionEnd;
enum { tls_prf_sha256 } PRFAlgorithm;
enum { tls_prf_sha256 } PRFAlgorithm;
enum { null, rc4, 3des, aes } BulkCipherAlgorithm;
enum { null, rc4, 3des, aes } BulkCipherAlgorithm;
enum { stream, block, aead } CipherType;
enum { stream, block, aead } CipherType;
enum { null, hmac_md5, hmac_sha1, hmac_sha256, hmac_sha384,
hmac_sha512} MACAlgorithm;
enum { null, hmac_md5, hmac_sha1, hmac_sha256, hmac_sha384, hmac_sha512} MACAlgorithm;
/* Other values may be added to the algorithms specified in CompressionMethod, PRFAlgorithm, BulkCipherAlgorithm, and MACAlgorithm. */
/* Other values may be added to the algorithms specified in CompressionMethod, PRFAlgorithm, BulkCipherAlgorithm, and MACAlgorithm. */
struct {
ConnectionEnd entity;
PRFAlgorithm prf_algorithm;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 enc_key_length;
uint8 block_length;
uint8 fixed_iv_length;
uint8 record_iv_length;
MACAlgorithm mac_algorithm;
uint8 mac_length;
uint8 mac_key_length;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
struct { ConnectionEnd entity; PRFAlgorithm prf_algorithm; BulkCipherAlgorithm bulk_cipher_algorithm; CipherType cipher_type; uint8 enc_key_length; uint8 block_length; uint8 fixed_iv_length; uint8 record_iv_length; MACAlgorithm mac_algorithm; uint8 mac_length; uint8 mac_key_length; CompressionMethod compression_algorithm; opaque master_secret[48]; opaque client_random[32]; opaque server_random[32]; } SecurityParameters;
Dierks & Rescorla Standards Track [Page 77] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 77] RFC 5246 TLS August 2008
A.7. Changes to RFC 4492
A.7. Changes to RFC 4492
RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS. This document changes some of the structures used in that document. This section details the required changes for implementors of both RFC 4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing RFC 4492 do not need to read this section.
RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS. This document changes some of the structures used in that document. This section details the required changes for implementors of both RFC 4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing RFC 4492 do not need to read this section.
This document adds a "signature_algorithm" field to the digitally- signed element in order to identify the signature and digest algorithms used to create a signature. This change applies to digital signatures formed using ECDSA as well, thus allowing ECDSA signatures to be used with digest algorithms other than SHA-1, provided such use is compatible with the certificate and any restrictions imposed by future revisions of [PKIX].
This document adds a "signature_algorithm" field to the digitally- signed element in order to identify the signature and digest algorithms used to create a signature. This change applies to digital signatures formed using ECDSA as well, thus allowing ECDSA signatures to be used with digest algorithms other than SHA-1, provided such use is compatible with the certificate and any restrictions imposed by future revisions of [PKIX].
As described in Sections 7.4.2 and 7.4.6, the restrictions on the signature algorithms used to sign certificates are no longer tied to the cipher suite (when used by the server) or the ClientCertificateType (when used by the client). Thus, the restrictions on the algorithm used to sign certificates specified in Sections 2 and 3 of RFC 4492 are also relaxed. As in this document, the restrictions on the keys in the end-entity certificate remain.
As described in Sections 7.4.2 and 7.4.6, the restrictions on the signature algorithms used to sign certificates are no longer tied to the cipher suite (when used by the server) or the ClientCertificateType (when used by the client). Thus, the restrictions on the algorithm used to sign certificates specified in Sections 2 and 3 of RFC 4492 are also relaxed. As in this document, the restrictions on the keys in the end-entity certificate remain.
Appendix B. Glossary
Appendix B. Glossary
Advanced Encryption Standard (AES)
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. TLS currently only supports the 128- and 256-bit key
sizes.
Advanced Encryption Standard (AES) 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. TLS currently only supports the 128- and 256-bit key sizes.
application protocol
An application protocol is a protocol that normally layers
directly on top of the transport layer (e.g., TCP/IP). Examples
include HTTP, TELNET, FTP, and SMTP.
application protocol An application protocol is a protocol that normally layers directly on top of the transport layer (e.g., TCP/IP). Examples include HTTP, TELNET, FTP, and SMTP.
asymmetric cipher
See public key cryptography.
asymmetric cipher See public key cryptography.
authenticated encryption with additional data (AEAD)
A symmetric encryption algorithm that simultaneously provides
confidentiality and message integrity.
authenticated encryption with additional data (AEAD) A symmetric encryption algorithm that simultaneously provides confidentiality and message integrity.
authentication
Authentication is the ability of one entity to determine the
identity of another entity.
authentication Authentication is the ability of one entity to determine the identity of another entity.
Dierks & Rescorla Standards Track [Page 78] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 78] RFC 5246 TLS August 2008
block cipher
A block cipher is an algorithm that operates on plaintext in
groups of bits, called blocks. 64 bits was, and 128 bits is, a
common block size.
block cipher A block cipher is an algorithm that operates on plaintext in groups of bits, called blocks. 64 bits was, and 128 bits is, a common block size.
bulk cipher
A symmetric encryption algorithm used to encrypt large quantities
of data.
bulk cipher A symmetric encryption algorithm used to encrypt large quantities of data.
cipher block chaining (CBC)
CBC is a mode in which every plaintext block encrypted with a
block cipher is first exclusive-ORed with the previous ciphertext
block (or, in the case of the first block, with the initialization
vector). For decryption, every block is first decrypted, then
exclusive-ORed with the previous ciphertext block (or IV).
cipher block chaining (CBC) CBC is a mode in which every plaintext block encrypted with a block cipher is first exclusive-ORed with the previous ciphertext block (or, in the case of the first block, with the initialization vector). For decryption, every block is first decrypted, then exclusive-ORed with the previous ciphertext block (or IV).
certificate
As part of the X.509 protocol (a.k.a. ISO Authentication
framework), certificates are assigned by a trusted Certificate
Authority and provide a strong binding between a party's identity
or some other attributes and its public key.
certificate As part of the X.509 protocol (a.k.a. ISO Authentication framework), certificates are assigned by a trusted Certificate Authority and provide a strong binding between a party's identity or some other attributes and its public key.
client
The application entity that initiates a TLS connection to a
server. This may or may not imply that the client initiated the
underlying transport connection. The primary operational
difference between the server and client is that the server is
generally authenticated, while the client is only optionally
authenticated.
client The application entity that initiates a TLS connection to a server. This may or may not imply that the client initiated the underlying transport connection. The primary operational difference between the server and client is that the server is generally authenticated, while the client is only optionally authenticated.
client write key
The key used to encrypt data written by the client.
client write key The key used to encrypt data written by the client.
client write MAC key
The secret data used to authenticate data written by the client.
client write MAC key The secret data used to authenticate data written by the client.
connection
A connection is a transport (in the OSI layering model definition)
that provides a suitable type of service. For TLS, such
connections are peer-to-peer relationships. The connections are
transient. Every connection is associated with one session.
connection A connection is a transport (in the OSI layering model definition) that provides a suitable type of service. For TLS, such connections are peer-to-peer relationships. The connections are transient. Every connection is associated with one session.
Data Encryption Standard
DES [DES] still is a very widely used symmetric encryption
algorithm although it is considered as rather weak now. 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
Data Encryption Standard DES [DES] still is a very widely used symmetric encryption algorithm although it is considered as rather weak now. 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
Dierks & Rescorla Standards Track [Page 79] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 79] RFC 5246 TLS August 2008
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 [3DES] 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.
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 [3DES] 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.
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-2, "Digital Signature
Standard", published January 2000 by the U.S. Department of
Commerce [DSS]. A significant update [DSS-3] has been drafted and
was published in March 2006.
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-2, "Digital Signature Standard", published January 2000 by the U.S. Department of Commerce [DSS]. A significant update [DSS-3] has been drafted and was published in March 2006.
digital signatures
Digital signatures utilize public key cryptography and one-way
hash functions to produce a signature of the data that can be
authenticated, and is difficult to forge or repudiate.
digital signatures Digital signatures utilize public key cryptography and one-way hash functions to produce a signature of the data that can be authenticated, and is difficult to forge or repudiate.
handshake An initial negotiation between client and server that
establishes the parameters of their transactions.
handshake An initial negotiation between client and server that establishes the parameters of their transactions.
Initialization Vector (IV)
When a block cipher is used in CBC mode, the initialization vector
is exclusive-ORed with the first plaintext block prior to
encryption.
Initialization Vector (IV) When a block cipher is used in CBC mode, the initialization vector is exclusive-ORed with the first plaintext block prior to encryption.
Message Authentication Code (MAC)
A Message Authentication Code is a one-way hash computed from a
message and some secret data. It is difficult to forge without
knowing the secret data. Its purpose is to detect if the message
has been altered.
Message Authentication Code (MAC) A Message Authentication Code is a one-way hash computed from a message and some secret data. It is difficult to forge without knowing the secret data. Its purpose is to detect if the message has been altered.
master secret
Secure secret data used for generating encryption keys, MAC
secrets, and IVs.
master secret Secure secret data used for generating encryption keys, MAC secrets, and IVs.
MD5
MD5 [MD5] is a hashing function that converts an arbitrarily long
data stream into a hash of fixed size (16 bytes). Due to
significant progress in cryptanalysis, at the time of publication
of this document, MD5 no longer can be considered a 'secure'
hashing function.
MD5 MD5 [MD5] is a hashing function that converts an arbitrarily long data stream into a hash of fixed size (16 bytes). Due to significant progress in cryptanalysis, at the time of publication of this document, MD5 no longer can be considered a 'secure' hashing function.
Dierks & Rescorla Standards Track [Page 80] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 80] RFC 5246 TLS August 2008
public key cryptography
A class of cryptographic techniques employing two-key ciphers.
Messages encrypted with the public key can only be decrypted with
the associated private key. Conversely, messages signed with the
private key can be verified with the public key.
public key cryptography A class of cryptographic techniques employing two-key ciphers. Messages encrypted with the public key can only be decrypted with the associated private key. Conversely, messages signed with the private key can be verified with the public key.
one-way hash function
A one-way transformation that converts an arbitrary amount of data
into a fixed-length hash. It is computationally hard to reverse
the transformation or to find collisions. MD5 and SHA are
examples of one-way hash functions.
one-way hash function A one-way transformation that converts an arbitrary amount of data into a fixed-length hash. It is computationally hard to reverse the transformation or to find collisions. MD5 and SHA are examples of one-way hash functions.
RC4
A stream cipher invented by Ron Rivest. A compatible cipher is
described in [SCH].
RC4 A stream cipher invented by Ron Rivest. A compatible cipher is described in [SCH].
RSA
A very widely used public key algorithm that can be used for
either encryption or digital signing. [RSA]
RSA A very widely used public key algorithm that can be used for either encryption or digital signing. [RSA]
server
The server is the application entity that responds to requests for
connections from clients. See also "client".
server The server is the application entity that responds to requests for connections from clients. See also "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.
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.
session identifier
A session identifier is a value generated by a server that
identifies a particular session.
session identifier A session identifier is a value generated by a server that identifies a particular session.
server write key
The key used to encrypt data written by the server.
server write key The key used to encrypt data written by the server.
server write MAC key
The secret data used to authenticate data written by the server.
server write MAC key The secret data used to authenticate data written by the server.
SHA
The Secure Hash Algorithm [SHS] is defined in FIPS PUB 180-2. It
produces a 20-byte output. Note that all references to SHA
(without a numerical suffix) actually use the modified SHA-1
algorithm.
SHA The Secure Hash Algorithm [SHS] is defined in FIPS PUB 180-2. It produces a 20-byte output. Note that all references to SHA (without a numerical suffix) actually use the modified SHA-1 algorithm.
Dierks & Rescorla Standards Track [Page 81] RFC 5246 TLS August 2008
Dierks & Rescorla Standards Track [Page 81] RFC 5246 TLS August 2008
SHA-256
The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2.
It produces a 32-byte output.
SHA-256 The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2. It produces a 32-byte output.
SSL
Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
SSL Version 3.0.
SSL Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on SSL Version 3.0.
stream cipher
An encryption algorithm that converts a key into a
cryptographically strong keystream, which is then exclusive-ORed
with the plaintext.
stream cipher An encryption algorithm that converts a key into a cryptographically strong keystream, which is then exclusive-ORed with the plaintext.
symmetric cipher
See bulk cipher.
左右対称の暗号Seeは暗号を膨らませます。
Transport Layer Security (TLS)
This protocol; also, the Transport Layer Security working group of
the Internet Engineering Task Force (IETF). See "Working Group
Information" at the end of this document (see page 99).
これが議定書の中で述べるLayer Security(TLS)を輸送してください。 インターネット・エンジニアリング・タスク・フォース(IETF)のTransport Layer Securityワーキンググループも。 このドキュメントの端で「ワーキンググループ情報」を見てください(99ページを参照してください)。
Dierks & Rescorla Standards Track [Page 82] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[82ページ]。
Appendix C. Cipher Suite Definitions
付録C.暗号スイート定義
Cipher Suite Key Cipher Mac
Exchange
暗号スイートキー暗号Mac交換
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_NULL_SHA256 RSA NULL SHA256 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA TLS_RSA_WITH_AES_256_CBC_SHA RSA AES_256_CBC SHA TLS_RSA_WITH_AES_128_CBC_SHA256 RSA AES_128_CBC SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 RSA AES_256_CBC SHA256 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_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_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES_128_CBC SHA TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES_128_CBC SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA TLS_DH_DSS_WITH_AES_128_CBC_SHA256 DH_DSS AES_128_CBC SHA256 TLS_DH_RSA_WITH_AES_128_CBC_SHA256 DH_RSA AES_128_CBC SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 DHE_DSS AES_128_CBC SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE_RSA AES_128_CBC SHA256 TLS_DH_anon_WITH_AES_128_CBC_SHA256 DH_anon AES_128_CBC SHA256 TLS_DH_DSS_WITH_AES_256_CBC_SHA256 DH_DSS AES_256_CBC SHA256 TLS_DH_RSA_WITH_AES_256_CBC_SHA256 DH_RSA AES_256_CBC SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 DHE_DSS AES_256_CBC SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 DHE_RSA AES_256_CBC SHA256 TLS_DH_anon_WITH_AES_256_CBC_SHA256 DH_anon AES_256_CBC SHA256
_______3DES_エーデCBC_SHAとRC4_128_SHA RSA RC4_128SHA TLS_RSA_とRC4_128_MD5 RSA RC4_128MD5 TLS_RSA_とヌル_SHA256 RSAのヌルSHA256 TLS_RSA_とヌル_SHA RSAのヌルSHA TLS_RSA_とヌル_MD5 RSAのヌルMD5 TLS_RSA_と_のヌル_ヌルのヌルヌルヌルTLS_RSA_とTLS_ヌル_; RSA 3DES_エーデ_、_AES_128_CBC_SHA RSA AES_128_CBC SHA TLS_RSA_とCBC SHA TLS_RSA_、_AES_256_CBC_SHA RSA AES_をもって_AES_128_CBC_SHA256 RSA AES_128_CBC SHA256 TLS_RSA_と256_CBC SHA TLS_RSA___3DES_エーデCBC_SHAと_AES_256_CBC_SHA256 RSA AES_256_CBC SHA256 TLS_DH_DSS_をもって; CBC_SHA DHE_RSA AES_128_CBC SHA TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA TLS_DH_DSS_WITH_AES_128_CBC_SHA256 DH_DSS AES_128_CBC SHA256 TLS_DH_RSA_WITH_AES_128_CBC_SHA256 DH_RSA AES_128_CBC SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 DHE_DSS AES_128_CBC SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE_RSA AES_128_CBC SHA256 TLS_DH_anon_WITH_AES_128_CBC_SHA256 DH_anon AES_128_CBC SHA256 TLS_DH_DSS_WITH_AES_256_CBC_SHA256 DH_DSS AES_256_CBC SHA256 TLS_DH_RSA_WITH_AES_256_CBC_SHA256 DH_RSA AES_256_CBC SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 DHE_DSS AES_256_CBC SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 DHE_RSA AES_256_CBC SHA256 TLS_DH_anon_WITH_AES_256_CBC_SHA256 DH_anon AES_256_CBC SHA256
Dierks & Rescorla Standards Track [Page 83] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[83ページ]。
Key IV Block
Cipher Type Material Size Size
------------ ------ -------- ---- -----
NULL Stream 0 0 N/A
RC4_128 Stream 16 0 N/A
3DES_EDE_CBC Block 24 8 8
AES_128_CBC Block 16 16 16
AES_256_CBC Block 32 16 16
主要なIVブロック暗号タイプ物質的なサイズサイズ------------ ------ -------- ---- ----- ヌルストリーム0 0、なし、なし、3DES_EDE_CBCブロック24 8 8AES_128_CBCブロック16 16 16AES_256_CBCが妨げるRC4_128ストリーム16 0、32 16 16
MAC Algorithm mac_length mac_key_length -------- ----------- ---------- -------------- NULL N/A 0 0 MD5 HMAC-MD5 16 16 SHA HMAC-SHA1 20 20 SHA256 HMAC-SHA256 32 32
MAC Algorithm mac_長さのmacの_の主要な_の長さ-------- ----------- ---------- -------------- ヌル、なし、0 0MD5 HMAC-MD5 16 16SHA HMAC-SHA1 20 20SHA256 HMAC-SHA256 32 32
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、主要な_ブロックからの生成するのに使用されるバイト数、キーを書いてください。
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 (this is equal to
SecurityParameters.record_iv_length).
データの量のIV Sizeは、初期化ベクトルのために生成される必要がありました。 ストリーム暗号のためのゼロ。 ブロックするブロック・サイズへの同輩は解きます(これはSecurityParameters.record_iv_の長さと等しいです)。
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モードへ駆け込むブロック暗号はブロック・サイズの同等の倍数を暗号化できるだけです。
Dierks & Rescorla Standards Track [Page 84] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[84ページ]。
Appendix D. Implementation Notes
付録D.実装注意
The TLS protocol cannot prevent many common security mistakes. This section provides several recommendations to assist implementors.
TLSプロトコルは多くの共通の安全保障誤りを防ぐことができません。 このセクションは作成者を補助するといういくつかの推薦を提供します。
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 SHA-1, are acceptable, but cannot provide more security than the size of the random number generator state.
TLSは暗号で安全な状態でaを必要とします。擬似ランダム数のジェネレータ(PRNG)。 PRNGsを設計して、種を蒔きながら、注意を中に入れなければなりません。 安全なハッシュ操作に基づくPRNGs(最も著しくSHA-1)は許容できますが、乱数発生器状態のサイズより多くのセキュリティを提供できません。
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. Cipher Suites
D.3。 暗号スイート
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 instance, 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は、さまざまな主要な規模とセキュリティがいいえを前提とするいくつかか最小量のセキュリティを含むレベルであると、サポートします。 適切な履行はたぶん多くの暗号スイートを支えないでしょう。 例えば、中央での男性攻撃を防ぐことができないので、匿名のディフィー-ヘルマンは強くがっかりしています。 また、アプリケーションは最小の、そして、最大の主要なサイズを実施するべきです。 例えば、512を含む証明書チェーンがRSAキーに噛み付いたか、または高セキュリティアプリケーションには、署名は適切ではありません。
D.4. Implementation Pitfalls
D.4。 実装落とし穴
Implementation experience has shown that certain parts of earlier TLS specifications are not easy to understand, and have been a source of interoperability and security problems. Many of these areas have
実装経験は以前のTLS仕様のある部分が分かり易くなく、問題これらの領域の多くが持っている相互運用性とセキュリティの源であることを示しました。
Dierks & Rescorla Standards Track [Page 85] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[85ページ]。
been clarified in this document, but this appendix contains a short list of the most important things that require special attention from implementors.
このドキュメントではっきりさせられます、この付録だけが作成者から特別な注意を必要とする最も重要なものの短いリストを含んでいます。
TLS protocol issues:
TLSは問題について議定書の中で述べます:
- Do you correctly handle handshake messages that are fragmented to
multiple TLS records (see Section 6.2.1)? Including corner cases
like a ClientHello that is split to several small fragments? Do
you fragment handshake messages that exceed the maximum fragment
size? In particular, the certificate and certificate request
handshake messages can be large enough to require fragmentation.
- あなたは正しく複数のTLS記録に断片化される握手メッセージを扱いますか?(セクション6.2.1を見てください) 数個の小さい破片に分割されるClientHelloのような角のケースを含んでいますか? あなたは最大の断片サイズを超えている握手メッセージを断片化しますか? 特に、証明書と証明書は、握手メッセージが断片化を必要とすることができるくらい大きい場合があるよう要求します。
- Do you ignore the TLS record layer version number in all TLS
records before ServerHello (see Appendix E.1)?
- あなたはServerHelloの前でのすべてのTLS記録のTLSの記録的な層のバージョン番号を無視しますか?(Appendix E.1を見てください)
- Do you handle TLS extensions in ClientHello correctly, including
omitting the extensions field completely?
- 拡大分野を完全に省略するのを含んでいて、あなたはClientHelloで正しくTLS拡張子を扱いますか?
- Do you support renegotiation, both client and server initiated?
While renegotiation is an optional feature, supporting it is
highly recommended.
- あなたは再交渉、クライアントと開始されたサーバの両方をサポートしますか? 再交渉はオプション機能ですが、それをサポートするのは非常にお勧めです。
- When the server has requested a client certificate, but no
suitable certificate is available, do you correctly send an empty
Certificate message, instead of omitting the whole message (see
Section 7.4.6)?
- サーバが、クライアント証明書にもかかわらず、どんな適当な証明書も利用可能でないよう要求したとき、あなたは正しく全体のメッセージを省略することの代わりに空のCertificateメッセージを送りますか?(セクション7.4.6を見てください)
Cryptographic details:
暗号の詳細:
- In the RSA-encrypted Premaster Secret, do you correctly send and
verify the version number? When an error is encountered, do you
continue the handshake to avoid the Bleichenbacher attack (see
Section 7.4.7.1)?
- RSAによって暗号化されたPremaster Secretでは、あなたは、正しくバージョン番号を送って、確かめますか? 誤りが遭遇するとき、あなたがBleichenbacher攻撃を避けるために握手を続けている、(見る、セクション7.4 .7 .1)?
- What countermeasures do you use to prevent timing attacks against
RSA decryption and signing operations (see Section 7.4.7.1)?
- あなたがRSA復号化に対するタイミング攻撃と操作に署名するのを防ぐのにどんな対策を使用するか、(見る、セクション7.4 .7 .1)?
- When verifying RSA signatures, do you accept both NULL and missing
parameters (see Section 4.7)? Do you verify that the RSA padding
doesn't have additional data after the hash value? [FI06]
- RSA署名について確かめるとき、あなたはNULLとなくなったパラメタの両方を受け入れますか?(セクション4.7を見てください) あなたは、RSA詰め物には追加データがハッシュ値の後にないことを確かめますか? [FI06]
- When using Diffie-Hellman key exchange, do you correctly strip
leading zero bytes from the negotiated key (see Section 8.1.2)?
- ディフィー-ヘルマンの主要な交換を使用するとき、あなたは交渉されたキーから先行ゼロバイトを正しく剥取りますか?(セクション8.1.2を見てください)
- Does your TLS client check that the Diffie-Hellman parameters sent
by the server are acceptable (see Section F.1.1.3)?
- あなたのTLSクライアントは、サーバによって送られたディフィー-ヘルマンパラメタが許容できるのをチェックしますか?(セクションF.1.1.3を見てください)
Dierks & Rescorla Standards Track [Page 86] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[86ページ]。
- How do you generate unpredictable IVs for CBC mode ciphers (see
Section 6.2.3.2)?
- あなたがCBCモード暗号のためにどのように予測できないIVsを生成するか、(見る、セクション6.2 .3 .2)?
- Do you accept long CBC mode padding (up to 255 bytes; see Section
6.2.3.2)?
- あなたは、長いCBCモードがそっと歩いていると受け入れます。(255バイト密かに企ててください;、見る、セクション6.2 .3 .2)?
- How do you address CBC mode timing attacks (Section 6.2.3.2)?
- あなたが、CBCモードがタイミング攻撃であるとどのように扱うか、(セクション6.2 .3 .2)?
- Do you use a strong and, most importantly, properly seeded random
number generator (see Appendix D.1) for generating the premaster
secret (for RSA key exchange), Diffie-Hellman private values, the
DSA "k" parameter, and other security-critical values?
- あなたは、前マスター秘密(RSAの主要な交換のための)、ディフィー-ヘルマンの個人的な値、DSA「k」パラメタ、および他のセキュリティ臨界値を生成するのに強くて最も重要に適切に種を蒔かれた乱数発生器(Appendix D.1を見る)を使用しますか?
Appendix E. Backward Compatibility
付録のE.の後方の互換性
E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0
E.1。 TLS1.0/1.1とSSL3.0との互換性
Since there are various versions of TLS (1.0, 1.1, 1.2, and any future versions) and SSL (2.0 and 3.0), means are needed to negotiate the specific protocol version to use. The TLS protocol provides a built-in mechanism for version negotiation so as not to bother other protocol components with the complexities of version selection.
TLS(1.0、1.1、1.2、およびどんな将来のバージョンも)とSSL(2.0と3.0)の様々なバージョンがあるので、手段が使用する特定のプロトコルバージョンを交渉するのに必要です。 TLSプロトコルは、バージョン選択の複雑さで他のプロトコルコンポーネントを苦しめないように内蔵のメカニズムをバージョン交渉に提供します。
TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use compatible ClientHello messages; thus, supporting all of them is relatively easy. Similarly, servers can easily handle clients trying to use future versions of TLS as long as the ClientHello format remains compatible, and the client supports the highest protocol version available in the server.
TLSバージョンは1.0、1.1、1.2、およびSSL3.0に非常に同様の、そして、使用コンパチブルClientHelloメッセージです。 したがって、それらを皆、サポートするのは比較的簡単です。 同様に、サーバは容易にClientHello形式が互換性があったままで残っていて、サーバで利用可能な最も高いプロトコルバージョンをサポートする限り、TLSの将来のバージョンを使用しようとするクライアントを扱うことができます。
A TLS 1.2 client who wishes to negotiate with such older servers will
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
ClientHello.client_version. If the server does not support this
version, it will respond with a ServerHello containing an older
version number. If the client agrees to use this version, the
negotiation will proceed as appropriate for the negotiated protocol.
そのようなより古いサーバと交渉したがっているTLS1.2クライアントは正常なTLS1.2ClientHelloを送るでしょう、ClientHello.client_バージョンに3、3(TLS1.2)を含んでいて。 サーバがこのバージョンをサポートしないと、ServerHelloが旧式のバージョン番号を含んでいて、それは応じるでしょう。 クライアントが、このバージョンを使用するのに同意すると、交渉は交渉されたプロトコルのために適宜続くでしょう。
If the version chosen by the server is not supported by the client (or not acceptable), the client MUST send a "protocol_version" alert message and close the connection.
サーバによって選ばれたバージョンがクライアントによってサポートされないで、(許容できない)であるなら、クライアントは、「プロトコル_バージョン」警告メッセージを送って、接続を終えなければなりません。
If a TLS server receives a ClientHello containing a version number greater than the highest version supported by the server, it MUST reply according to the highest version supported by the server.
TLSサーバがサーバによってサポートされる中で最も高いバージョンより大きいバージョン数を含むClientHelloを受けるなら、サーバによってサポートされる中で最も高いバージョンによると、それは返答しなければなりません。
A TLS server can also receive a ClientHello containing a version number smaller than the highest supported version. If the server wishes to negotiate with old clients, it will proceed as appropriate
また、TLSサーバは最も高いのがバージョンをサポートしたより少ないバージョン番号を含むClientHelloを受けることができます。 サーバが年取ったクライアントと交渉したいなら、それは適宜続くでしょう。
Dierks & Rescorla Standards Track [Page 87] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[87ページ]。
for the highest version supported by the server that is not greater than ClientHello.client_version. For example, if the server supports TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will proceed with a TLS 1.0 ServerHello. If server supports (or is willing to use) only versions greater than client_version, it MUST send a "protocol_version" alert message and close the connection.
サーバによってサポートされる中で最も高いバージョンに、それはClientHello.client_バージョンほどすばらしくはありません。 例えば、サーバがTLS1.0、1.1、および1.2をサポートして、クライアント_バージョンがTLS1.0であるなら、サーバはTLS1.0ServerHelloを続けるでしょう。 サーバがクライアント_バージョンよりすばらしいバージョンだけをサポートするなら(または、使用に望んでいます)、それは、「プロトコル_バージョン」警告メッセージを送って、接続を終えなければなりません。
Whenever a client already knows the highest protocol version known to a server (for example, when resuming a session), it SHOULD initiate the connection in that native protocol.
クライアントが既にサーバに知られている中で最も高いプロトコルバージョンを知って(例えばセッションを再開するとき)、それがSHOULDであるときはいつも、その固有のプロトコルにおける接続を開始してください。
Note: some server implementations are known to implement version negotiation incorrectly. For example, there are buggy TLS 1.0 servers that simply close the connection when the client offers a version newer than TLS 1.0. Also, it is known that some servers will refuse the connection if any TLS extensions are included in ClientHello. Interoperability with such buggy servers is a complex topic beyond the scope of this document, and may require multiple connection attempts by the client.
以下に注意してください。 いくつかのサーバ実装が不当にバージョン交渉を実装するのが知られています。 例えば、クライアントがTLS1.0より新しいバージョンを提供するとき単に接続を終えるバギーのTLS1.0サーバがあります。 また、何かTLS拡張子がClientHelloに含まれているといくつかのサーバが接続を拒否するのが知られています。 そのようなバギーのサーバがある相互運用性は、このドキュメントの範囲を超えた複雑な話題であり、クライアントで複数の接続試みを必要とするかもしれません。
Earlier versions of the TLS specification were not fully clear on
what the record layer version number (TLSPlaintext.version) should
contain when sending ClientHello (i.e., before it is known which
version of the protocol will be employed). Thus, TLS servers
compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello.
TLS仕様の以前のバージョンはClientHelloを送るとき(すなわち、プロトコルのどのバージョンが使われるかが知られている前に)記録的な層のバージョン番号(TLSPlaintext.version)が含むべきであることに関して完全に明確であったというわけではありません。 その結果、この仕様による対応することのTLSサーバは受け入れなければなりません。いずれもClientHelloの記録層のバージョン番号として03、XXを評価します。
TLS clients that wish to negotiate with older servers MAY send any
value {03,XX} as the record layer version number. Typical values
would be {03,00}, the lowest version number supported by the client,
and the value of ClientHello.client_version. No single value will
guarantee interoperability with all old servers, but this is a
complex topic beyond the scope of this document.
より古いサーバと交渉したがっているTLSクライアントは記録的な層のバージョン番号として03、XXをどんな値にも送るかもしれません。 典型的な値が03、00であるだろう、最も下位のバージョン番号はクライアント、およびClientHello.clientの値で_がバージョンであるとサポートしました。 どんなただ一つの値もすべての古いサーバで相互運用性を保証しないでしょうが、これはこのドキュメントの範囲を超えた複雑な話題です。
E.2. Compatibility with SSL 2.0
E.2。 SSL2.0との互換性
TLS 1.2 clients that wish to support SSL 2.0 servers MUST send version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST contain the same version number as would be used for ordinary ClientHello, and MUST encode the supported TLS cipher suites in the CIPHER-SPECS-DATA field as described below.
TLS1.2に、2.0のサーバをSSLにサポートしたがっているクライアントはCLIENT-HELLOメッセージが定義したバージョン2.0を送らなければなりません[SSL2]。 メッセージは、普通のClientHelloに使用されるように同じバージョン番号を含まなければならなくて、以下で説明されるようにCIPHER-SPECS-DATA分野のサポートしているTLS暗号スイートをコード化しなければなりません。
Warning: The ability to send version 2.0 CLIENT-HELLO messages will be phased out with all due haste, since the newer ClientHello format provides better mechanisms for moving to newer versions and negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0.
警告: CLIENT-HELLOメッセージをバージョン2.0に送る能力はすべての当然の迅速で段階的に廃止されるでしょう、より新しいClientHello形式が、より新しいバージョンに移行して、拡大を交渉するのにより良いメカニズムを提供するので。 TLS1.2クライアントSHOULD NOTはSSL2.0をサポートします。
Dierks & Rescorla Standards Track [Page 88] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[88ページ]。
However, even TLS servers that do not support SSL 2.0 MAY accept version 2.0 CLIENT-HELLO messages. The message is presented below in sufficient detail for TLS server implementors; the true definition is still assumed to be [SSL2].
しかしながら、SSL2.0をサポートしないTLSサーバさえバージョン2.0 CLIENT-HELLOメッセージを受け入れるかもしれません。 メッセージはTLSサーバ作成者のために以下に詳細に十分な提示されます。 本当の定義は[SSL2]であるとまだ思われています。
For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same way as a ClientHello with a "null" compression method and no extensions. Note that this message MUST be sent directly on the wire, not wrapped as a TLS record. For the purposes of calculating Finished and CertificateVerify, the msg_length field is not considered to be a part of the handshake message.
交渉目的のために、2.0CLIENT-HELLOは「ヌル」の圧縮方法にもかかわらず、拡大がないClientHelloとして同じように解釈されます。 TLSが記録するように包装されるのではなく、このメッセージを直接ワイヤに送らなければならないことに注意してください。 計算のFinishedとCertificateVerifyの目的のために、msg_長さの分野は握手メッセージの一部であると考えられません。
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;
uint8 V2CipherSpec[3]。 struct、uint16 msg_長さ; uint8 msg_タイプ; バージョンバージョン; uint16暗号_仕様_の長さ; uint16セッション_イド_の長さ; uint16の挑戦_長さ; V2CipherSpecは_仕様[V2ClientHello.cipher_仕様_の長さ]を解きます; セッション_イド[V2ClientHello.session_イド_の長さ]について不透明にしてください; 挑戦について不透明にしてください、[V2ClientHello.challenge_の長さ;、V2ClientHello。
msg_length
The highest bit MUST be 1; the remaining bits contain the length
of the following data in bytes.
最も高いのが噛み付いたmsg_長さは1であるに違いありません。 残っているビットはバイトで表現される以下のデータの長さを含んでいます。
msg_type
This field, in conjunction with the version field, identifies a
version 2 ClientHello message. The value MUST be 1.
タイプThisがバージョン分野に関連してさばくmsg_はバージョン2ClientHelloメッセージを特定します。 値は1でなければなりません。
version
Equal to ClientHello.client_version.
ClientHello.client_バージョンへのバージョンEqual。
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 for a client that claims to
support TLS 1.2.
Thisがさばくセッション_イド_の長さはTLS1.2をサポートすると主張するクライアントのためのゼロの値を持たなければなりません。
Dierks & Rescorla Standards Track [Page 89] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[89ページ]。
challenge_length
The length in bytes of the client's challenge to the server to
authenticate itself. Historically, permissible values are between
16 and 32 bytes inclusive. When using the SSLv2 backward-
compatible handshake the client SHOULD use a 32-byte challenge.
_クライアントのバイトで表現される長さがそれ自体を認証するのをサーバに挑む長さに挑戦してください。 許容値は16と32バイトの間で歴史的に、包括的です。 SSLv2の後方のコンパチブル握手を使用するとき、クライアントSHOULDは32バイトの挑戦を使用します。
cipher_specs
This is a list of all CipherSpecs the client is willing and able
to use. In addition to the 2.0 cipher specs defined in [SSL2],
this includes the TLS cipher suites normally sent in
ClientHello.cipher_suites, with each cipher suite prefixed by a
zero byte. For example, the TLS cipher suite {0x00,0x0A} would be
sent as {0x00,0x00,0x0A}.
暗号_仕様Thisはクライアントが望んでいて使用できるすべてのCipherSpecsのリストです。 [SSL2]で定義された2.0の暗号仕様に加えて、これは通常、スイートがそれぞれの暗号スイートがゼロで前に置かれているClientHello.cipher_スイートでバイトを送ったTLS暗号を含んでいます。 例えば、TLSは0×00、0x0Aが解くスイートを解きます。0×00、0×00、0x0Aとして、送ります。
session_id
This field MUST be empty.
セッション_イドThis分野は人影がないに違いありません。
challenge
Corresponds to ClientHello.random. If the challenge length is
less than 32, the TLS server will pad the data with leading (note:
not trailing) zero bytes to make it 32 bytes long.
ClientHello.randomにCorrespondsに挑戦してください。 挑戦の長さが32未満であるなら、TLSサーバは主な(引きずるのではなく、以下に注意する)ゼロでそれを32バイトにする長さバイトでデータを水増しするでしょう。
Note: Requests to resume a TLS session MUST use a TLS client hello.
以下に注意してください。 TLSセッションを再開するという要求はTLSクライアントを使用しなければなりません。こんにちは。
E.3. Avoiding Man-in-the-Middle Version Rollback
E.3。 中央の男性バージョンロールバックを避けます。
When TLS clients fall back to Version 2.0 compatibility mode, they MUST use special PKCS#1 block formatting. This is done so that TLS servers will reject Version 2.0 sessions with TLS-capable clients.
TLSクライアント秋が2.0互換性モードをバージョンに支持するとき、彼らは特別なPKCS#1ブロック形式を使用しなければなりません。 TLSサーバがTLS有能なクライアントとのバージョン2.0セッションを拒絶するように、これをします。
When a client negotiates SSL 2.0 but also supports TLS, it MUST 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).
クライアントがSSL2.0を交渉しますが、TLSをまたサポートすると、それは、PKCSの右手(最も最少に重要な)の無作為の8バイトがCLIENT-MASTER-KEYのENCRYPTED-KEY-DATA分野のRSA暗号化のために0×03にそっと歩く(詰め物の端末のヌルを含んでいない)ように設定しなければなりません(他の詰め物バイトは無作為です)。
When a TLS-capable server negotiates SSL 2.0 it SHOULD, after decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding bytes are 0x03. If they are not, the server SHOULD generate a random value for SECRET-KEY-DATA, and continue the handshake (which will eventually fail since the keys will not match). Note that reporting the error situation to the client could make the server vulnerable to attacks described in [BLEI].
TLSできるサーバがSSL2.0にそれを交渉するとき、ENCRYPTED-KEY-DATA分野を解読した後に、SHOULDは、これらの8詰め物バイトが0×03であることをチェックします。 それらがそうでないなら、サーバSHOULDはSECRET-KEY-DATAのために無作為の値を生成して、握手を続けています(キーが合わないので、結局、失敗するでしょう)。 エラー状態をクライアントに報告するのにサーバが[BLEI]で説明された攻撃に被害を受け易くなるかもしれないことに注意してください。
Dierks & Rescorla Standards Track [Page 90] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[90ページ]。
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 cipher spec 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.
握手プロトコルは暗号仕様を選択するのに原因となります、そして、マスター秘密を生成して、どれが安全なセッションに関連しているプライマリ暗号のパラメタを一緒に包括しますか? また、握手プロトコルは任意に信じられた認証局で証明書を署名させるパーティーを認証できます。
F.1.1. Authentication and Key Exchange
F.1.1。 認証と主要な交換
TLS supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. Whenever the server is authenticated, the channel is secure against man-in-the-middle attacks, but completely anonymous sessions are inherently vulnerable to such attacks. Anonymous servers cannot authenticate clients. If the server is authenticated, its certificate message must provide a valid certificate chain leading to an acceptable certificate authority. Similarly, authenticated clients must supply an acceptable certificate to the server. Each party is responsible for verifying that the other's certificate is valid and has not expired or been revoked.
TLSは3つの認証モードをサポートします: 双方、非認証されたクライアント、および総匿名によるサーバ証明の認証。 サーバが認証されるときはいつも、チャンネルは介入者攻撃に対して安全ですが、完全に匿名のセッションは本来そのような攻撃に被害を受け易いです。 匿名のサーバはクライアントを認証できません。 サーバが認証されるなら、証明書メッセージは許容できる認証局に通じる有効な証明書チェーンを提供しなければなりません。 同様に、認証されたクライアントは許容できる証明書をサーバに供給しなければなりません。各当事者は、もう片方の証明書が有効であることを確かめるのに責任があって、吐き出されるか、または取り消されていません。
The general goal of the key exchange process is to create a pre_master_secret known to the communicating parties and not to attackers. The pre_master_secret will be used to generate the master_secret (see Section 8.1). The master_secret is required to generate the Finished messages, encryption keys, and MAC keys (see Sections 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を見てください)。 マスター_秘密が、Finishedメッセージ、暗号化キー、およびMACキーを生成するのに必要です(セクション7.4 .9と6.3を見てください)。 正しいFinishedメッセージを送ることによって、その結果、パーティーは、彼らが正しい前_のマスター_秘密を知っていると立証します。
F.1.1.1. Anonymous Key Exchange
F.1.1.1。 匿名の主要な交換
Completely anonymous sessions can be established using Diffie-Hellman for key exchange. The server's public parameters are contained in the server key exchange message, and the client's are sent in the
主要な交換にディフィー-ヘルマンを使用することで完全に匿名のセッションを確立できます。 サーバの公共のパラメタはサーバの主要な交換メッセージに含まれています、そして、クライアントは送られました。
Dierks & Rescorla Standards Track [Page 91] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[91ページ]。
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.
警告: 完全に匿名の接続は受け身の盗聴に対する保護を提供するだけです。 独立している干渉防止チャンネルがFinishedメッセージが攻撃者に取り替えられなかったことを確かめるのに使用されない場合、サーバ証明が中央の活発な男性攻撃が関心である環境で必要です。
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 is contained in the server's certificate. Note that 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.
サーバの証明書について確かめた後に、クライアントはサーバの公開鍵で前_のマスター_秘密を暗号化します。 首尾よく前_のマスター_秘密を解読して、正しいFinishedメッセージを出すことによって、サーバは、サーバ証明書に対応する秘密鍵を知っているのを示します。
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 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 DSA 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.
ディフィー-ヘルマンの主要な交換が使用されているとき、サーバは、DSAか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.,
クライアントに固定ディフィー-ヘルマンパラメタを含む証明書があるなら、証明書は主要な交換を終了するのに必要である情報を含んでいます。 すなわちこの場合クライアントとサーバが同じディフィー-ヘルマン結果を生成することに注意してください、(。
Dierks & Rescorla Standards Track [Page 92] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[92ページ]。
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 DSA 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.
クライアントが標準のDSAかRSA証明書を持っているか、または非認証されるなら、1セットの一時的なパラメタをクライアントの主要な交換メッセージにおけるサーバに送って、次に、任意に、証明書がメッセージについて確かめる用途はそれ自体を認証します。
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 cipher suites 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 cipher suites.
DHE暗号スイートの1つを使用して、各握手のために新鮮なDHが秘密鍵(X)であると生成することによって、小さいサブグループ攻撃は最も容易に避けられます。 適当なベース(2などの)が選ばれているなら、非常にすぐにg^Xモッズpを計算できます。 したがって、性能費用は最小にされます。 さらに、各握手に新鮮なキーを使用すると、Perfect Forward Secrecyは提供されます。 DHE暗号スイートを使用するとき、実装SHOULDは各握手のための新しいXを生成します。
Because TLS allows the server to provide arbitrary DH groups, the client should verify that the DH group is of suitable size as defined by local policy. The client SHOULD also verify that the DH public exponent appears to be of adequate size. [KEYSIZ] provides a useful guide to the strength of various group sizes. The server MAY choose to assist the client by providing a known group, such as those defined in [IKEALG] or [MODP]. These can be verified by simple comparison.
TLSがサーバに任意のDHグループを提供させるので、クライアントは、DHグループがローカルの方針で定義されるように適当なサイズのものであることを確かめるべきです。 また、クライアントSHOULDは、DHの公共の解説者が、適切なサイズがあるように見えることを確かめます。 [KEYSIZ]は様々なグループサイズの強さに役に立つガイドを提供します。 サーバは、知られているグループを提供することによってクライアントを補助するのを選ぶかもしれません、[IKEALG]か[MODP]で定義されたものなどのように。 簡単な比較でこれらについて確かめることができます。
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. Altering the padding of the least-significant 8 bytes of the PKCS
ソリューションの使用の非無作為のPKCS#1、はタイプ2を妨げますが、メッセージ詰め物は優美ではありません、とそれが攻撃を検出するために3.0のサーバをバージョンに合理的に安全な道で前提とします。 このソリューションはアプリケーションで指定された待ち敷居が期限が切れる前に同じキー(しかし通常の詰め物で)を含む主要で代わりのa新しいENCRYPTED-KEY-DATAが通信させるブルートフォースをそうすることができる攻撃者に対して安全ではありません。 PKCSの最も最少に重要な8バイトの詰め物を変更します。
Dierks & Rescorla Standards Track [Page 93] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[93ページ]。
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.
詰め物はプロトコルに使用される署名しているハッシュと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 choose.
攻撃者は、通常、選ぶだろうよりパーティーが握手交換で異なった暗号化アルゴリズムを選択するのに影響を及ぼそうとするかもしれません。
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つ以上の握手メッセージを変えなければなりません。 これが起こると、クライアントとサーバは握手メッセージハッシュのために異価を計算するでしょう。 その結果、パーティーはそれぞれ他のもののFinishedメッセージを受け入れないでしょう。 マスター_秘密がなければ、攻撃者がFinishedメッセージを修理できないので、攻撃は発見されるでしょう。
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 keys 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.
接続がセッション、新しいClientHello.random、およびServerHello.randomを再開することによって確立されるとき、値はセッションのマスター_秘密で論じ尽くされます。 マスター_秘密が感染されていなくて、安全が操作を論じ尽くすのが以前はよく暗号化キーを生産していて、MACキーが安全であれば、接続は、安全であって、事実上、前の接続によって独立しているべきです。 攻撃者は、安全なハッシュ操作を壊さないでマスター_秘密に感染するのに知られている暗号化キーか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.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 key, the sequence number, the message length, the
発信データはトランスミッションの前のMACと共に保護されます。 メッセージ再生か変更攻撃を防ぐために、MACはMACキーから計算されます、一連番号、メッセージ長
Dierks & Rescorla Standards Track [Page 94] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[94ページ]。
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 keys. Similarly, the server write and client write keys are independent, so stream cipher keys are used only once.
メッセージ内容、および2つの固定文字列。 メッセージタイプ分野が、1人のTLSの記録的な層のクライアントのために意図するメッセージが別のものに向け直されないのを保証するのに必要です。 一連番号は、削除する試みか追加注文メッセージが検出されるのを確実にします。 一連番号が長さ64ビットであるので、それらは決してあふれるべきではありません。 独立しているMACキーを使用するので、1回のパーティーからのメッセージをもう片方の出力に挿入できません。 サーバが同様に、書いて、独立しているので、クライアントが、キーを書くストリーム暗号キーは一度だけ使用されます。
If an attacker does break an encryption key, all messages encrypted with it can be read. Similarly, compromise of a MAC key can make message-modification attacks possible. Because MACs are also encrypted, message-alteration attacks generally require breaking the encryption algorithm as well as the MAC.
攻撃者が暗号化キーを壊すなら、それで暗号化されたすべてのメッセージは読むことができます。 同様に、MACキーの感染で、メッセージ変更攻撃は可能になる場合があります。 また、MACsが暗号化されるので、一般に、メッセージ変更攻撃は、MACと同様に暗号化アルゴリズムを破るのを必要とします。
Note: MAC keys 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 cipher suite. 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は、伝えられたアプリケーションがデータであると交渉された暗号スイートで定義された左右対称の暗号化と認証機能の使用で機密保護します。 目的はネットワークにおける活発な攻撃者による悪意がある行為から保全と伝えられたデータの秘密性の両方を保護することです。 どの暗号化と認証機能がデータに適用されているかのオーダーがこの目標[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.
最も強健なメソッドであって、呼ばれる、暗号化、次に、認証する、データへの暗号化がまず最初に、適用されて、暗号文へのMACはその時、適用します。 このメソッドはMACが確実に前者が選ばれた平文攻撃に対して安全であればどんな組の暗号化とMAC機能でも保全と秘密性目標を得て、選ばれたメッセージ攻撃に対して安全になるようにします。 TLSは別のメソッドを使用します、呼ばれて認証、次に、暗号化する、最初に、a MACがどれであるかで、暗号化された平文とMACの平文と次に、連結のときに、計算されています。 このメソッドは暗号化機能とMAC機能のCERTAIN組み合わせに安全であると立証されましたが、それは、一般に、安全になるように保証されません。
Dierks & Rescorla Standards Track [Page 95] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[95ページ]。
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 cipher suites 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機能にも結合した完全に安全な暗号化機能(情報理論的な意味でさえ安全な)が存在するのが示されて、活発な攻撃に対して秘密性目標を提供しないでください。 したがって、新しい暗号スイートとオペレーションモードが分析される必要性をTLSに採用した、認証、次に、暗号化する、彼らが述べられた保全と秘密性目標を達成することを確かめるメソッド。
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 pseudorandom generator and this pad is exclusive-ORed 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 versions of TLS prior to 1.1, 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タグの連結がある排他的なORedであるストリーム暗号に関するケースです。 もう片方が安全なブロック暗号を使用するCBCモードに関するケースです。 この場合、セキュリティは、1つが1個のCBC暗号化パスを適用するかどうかを平文とMACの連結に示すことができて、平文とMACの各新しいペアに新しくて、独立していて、予測できないIVを使用します。 1.1の前のTLSのバージョンでは、前の暗号文の最後のブロックの形で予測できる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 for 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 DoS 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] or ESP [ESP].
TLSがTCPをひくので、また、それも個々の接続に対する多くのDoS攻撃に影響されやすいです。 攻撃者は特に、RSTsを鍛造して、その結果、接続を終えるか、または部分的なTLS記録を作り出して、その結果、接続が失速することを引き起こすことができます。 一般に、TCPを使用しているプロトコルはこれらの攻撃に防御できません。 このクラスの攻撃に関する作成者かユーザがIPsec 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が安全な接続を提供できるように、クライアント、サーバシステム、キー、およびアプリケーションの両方が安全でなければなりません。 さらに、実装には、セキュリティ誤りがあってはいけません。
Dierks & Rescorla Standards Track [Page 96] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[96ページ]。
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 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.
システムはサポートされた最も弱い主要な交換と単に認証アルゴリズムと同じくらい強いです、そして、信頼できる暗号の機能だけが使用されるべきです。 短い公開鍵と匿名のサーバは十分な注意と共に使用されるべきです。 どの証明書と認証局が許容できるかを決めるとき、実装とユーザは慎重であるに違いありません。 不正直な認証局は物凄い損害を与えることができます。
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] National Institute of Standards and Technology,
"Recommendation for the Triple Data Encryption Algorithm
(TDEA) Block Cipher", NIST Special Publication 800-67, May
2004.
[3DES]米国商務省標準技術局、「三重のデータ暗号化アルゴリズム(TDEA)ブロック暗号のための推薦」(NISTの特別な公表800-67)は2004がそうするかもしれません。
[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月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[MD5] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[PKCS1] イェンソン、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月)。
[SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms,
and Source Code in C, 2nd ed.", Published by John Wiley &
Sons, Inc. 1996.
[SCH]B.シュナイアー。 「適用された暗号:」 「C、2番目の教育におけるプロトコル、Algorithms、およびSource Code」、ジョン・ワイリーとソンスInc.1996によるPublished
[SHS] NIST FIPS PUB 180-2, "Secure Hash Standard", National
Institute of Standards and Technology, U.S. Department of
Commerce, August 2002.
[SHS]NIST FIPSパブ180-2、「安全なハッシュ規格」、米国商務省標準技術局、米国商務省、2002年8月。
Dierks & Rescorla Standards Track [Page 97] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[97ページ]。
[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月)。
[X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation.
[X680]ITU-T推薦X.680(2002)| ISO/IEC8824-1: 2002、情報技術--抽象的なSyntax Notation One(ASN.1): 基本的な記法の仕様。
[X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER).
[X690]ITU-T推薦X.690(2002)| ISO/IEC8825-1: 2002、情報技術--Rulesをコード化するASN.1: 基本的なコード化の仕様は(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)を統治します。
Informative References
有益な参照
[AEAD] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008.
[AEAD] マグリューと、D.と、「認証された暗号化のためのインタフェースとアルゴリズム」、RFC5116、1月2008日
[AH] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[ああ] ケント、S.、「IP認証ヘッダー」、RFC4302、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., Hiltgen, A., Vaudenay, S., and M. Vuagnoux,
"Password Interception in a SSL/TLS Channel", Advances in
Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003.
Cryptologyの[CBCTIME]CanvelとB.とHiltgenとA.とVaudenay、S.とM.Vuagnoux、「SSL/TLSチャンネルにおけるパスワード妨害」Advances--CRYPTO2003(LNCS vol.2729、2003)。
[CCM] "NIST Special Publication 800-38C: The CCM Mode for
Authentication and Confidentiality",
http://csrc.nist.gov/publications/nistpubs/800-38C/
SP800-38C.pdf
[立方センチメートル]、「NISTの特別な公表800-38C:」 「認証と秘密性のための立方センチメートルモード」、 http://csrc.nist.gov/publications/nistpubs/800-38C/ SP800-38C. pdf
[DES] National Institute of Standards and Technology, "Data
Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
[DES]米国商務省標準技術局、「データ暗号化規格(デス)」、FIPSパブ46-3、1999年10月。
Dierks & Rescorla Standards Track [Page 98] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[98ページ]。
[DSS-3] NIST FIPS PUB 186-3 Draft, "Digital Signature Standard",
National Institute of Standards and Technology, U.S.
Department of Commerce, 2006.
[DSS-3]NIST FIPSパブ186-3ドラフト、「デジタル署名基準」、米国商務省標準技術局、米国商務省、2006。
[ECDSA] American National Standards Institute, "Public Key
Cryptography for the Financial Services Industry: The
Elliptic Curve Digital Signature Algorithm (ECDSA)", ANS
X9.62-2005, November 2005.
[ECDSA]American National Standards Institut、「財政的のための公開鍵暗号は産業にサービスを提供します」。 「楕円曲線デジタル署名アルゴリズム(ECDSA)」、ANS X9.62-2005、2005年11月。
[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。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[超能力] ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based
on implementation error", ietf-openpgp@imc.org mailing
list, 27 August 2006, http://www.imc.org/ietf-openpgp/
mail-archive/msg14307.html.
[FI06]ハル・フィニー、「実装誤りに基づくBleichenbacherのRSA署名偽造」、 ietf-openpgp@imc.org メーリングリスト、2006年8月27日、 http://www.imc.org/ietf-openpgp/ メールアーカイブ/msg14307.html。
[GCM] Dworkin, M., NIST Special Publication 800-38D,
"Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC", November 2007.
[GCM] ドーキン、M.、NISTの特別な公表800-38D、「ブロックのための推薦は運転モードを解きます」。 2007年11月の「ガロア/カウンタモード(GCM)とGMAC」
[IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.
[IKEALG] シラー、J.、「インターネット・キー・エクスチェンジバージョン2(IKEv2)における使用のための暗号アルゴリズム」、RFC4307、2005年12月。
[KEYSIZ] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, April 2004.
[KEYSIZ] OrmanとH.とP.ホフマン、「対称鍵を交換するのに使用される公開鍵のために強さを測定する」BCP86、RFC3766、2004年4月。
[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/
[MODP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003.
[MODP] Kivinen、T.、およびM.Kojo、「より多くのModular Exponential(MODP)ディフィー-ヘルマンはインターネット・キー・エクスチェンジ(IKE)のために分類します」、RFC3526、2003年5月。
[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月。
Dierks & Rescorla Standards Track [Page 99] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[99ページ]。
[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。
[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
Compression Methods", RFC 3749, May 2004.
[RFC3749]Hollenbeck(S.、「トランスポート層セキュリティプロトコル圧縮方法」、RFC3749)は2004がそうするかもしれません。
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[RFC4366]ブレーク-ウィルソン、S.、ニストロム、M.、Hopwood(D.、ミッケルセン、J.、およびT.ライト)は「層のセキュリティ(TLS)拡大を輸送します」、RFC4366、2006年4月。
[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. Freier, 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] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[TCP] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
practical", USENIX Security Symposium 2003.
[TIMING] Boneh、D.、Brumley、D.、「リモートタイミング攻撃は実用的である」USENIX Security Symposium2003。
[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。
[TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006.
[TLSECC]ブレーク-ウィルソン、S.、Bolyard、N.、グプタ、V.、タカ、C.、およびB.メラー、「輸送のための楕円曲線暗号(ECC)暗号スイートはセキュリティ(TLS)を層にします」、RFC4492、2006年5月。
[TLSEXT] Eastlake, D., 3rd, "Transport Layer Security (TLS)
Extensions: Extension Definitions", Work in Progress,
February 2008.
[TLSEXT]イーストレーク、D. 3番目に、「層のセキュリティ(TLS)拡大を輸送してください」 「拡大定義」は進歩、2008年2月に働いています。
Dierks & Rescorla Standards Track [Page 100] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[100ページ]。
[TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport
Layer Security (TLS) Authentication", RFC 5081, November
2007.
[TLSPGP] Mavrogiannopoulos、N.、「トランスポート層セキュリティ(TLS)認証にOpenPGPキーを使用する」RFC5081、2007年11月。
[TLSPSK] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)", RFC
4279, December 2005.
[TLSPSK]Eronen、P.、エド、H.Tschofenig、エド、「トランスポート層セキュリティ(TLS)のためのあらかじめ共有された主要なCiphersuites」、RFC4279、12月2005日
[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について議定書の中で述べます」。
[TLS1.1] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS1.1] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[X501] ITU-T Recommendation X.501: Information Technology - Open
Systems Interconnection - The Directory: Models, 1993.
[X501]ITU-T推薦X.501: 情報技術--オープン・システム・インターコネクション--ディレクトリ: モデル、1993。
[XDR] Eisler, M., Ed., "XDR: External Data Representation
Standard", STD 67, RFC 4506, May 2006.
[XDR] アイスラー、M.、エド、「XDR:」 「外部データ表現規格」(STD67、RFC4506)は2006がそうするかもしれません。
Working Group Information
ワーキンググループ情報
The discussion list for the IETF TLS working group is located at the e-mail address <tls@ietf.org>. Information on the group and information on how to subscribe to the list is at <https://www1.ietf.org/mailman/listinfo/tls>
IETF TLSワーキンググループのための議論リストがメール address <tls@ietf.org に位置している、gt。 グループに関する情報とどうリストに加入するかの情報が<https://www1.ietf.org/郵便配達人/listinfo/tls>にあります。
Archives of the list can be found at: <http://www.ietf.org/mail-archive/web/tls/current/index.html>
以下でリストのアーカイブを見つけることができます。 <メールhttp://www.ietf.org/アーカイブ/ウェブ/tls/電流/index.html>。
Contributors
貢献者
Christopher Allen (co-editor of TLS 1.0) Alacrity Ventures ChristopherA@AlacrityManagement.com
クリストファー・アレン(TLS1.0の共同エディタ)Alacrityは ChristopherA@AlacrityManagement.com を賭けます。
Martin Abadi University of California, Santa Cruz abadi@cs.ucsc.edu
マーチンAbadiカリフォルニア大学、サンタクルス abadi@cs.ucsc.edu
Steven M. Bellovin Columbia University smb@cs.columbia.edu
スティーブンM.Bellovinコロンビア大学 smb@cs.columbia.edu
Simon Blake-Wilson BCI sblakewilson@bcisse.com
サイモンブレーク-ウィルソンBCI sblakewilson@bcisse.com
Dierks & Rescorla Standards Track [Page 101] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[101ページ]。
Ran Canetti IBM canetti@watson.ibm.com
カネッティIBM canetti@watson.ibm.com を走らせました。
Pete Chown Skygate Technology Ltd pc@skygate.co.uk
ピートChown Skygate技術Ltd pc@skygate.co.uk
Taher Elgamal taher@securify.com Securify
タヘルElgamal taher@securify.com Securify
Pasi Eronen pasi.eronen@nokia.com Nokia
パシEronen pasi.eronen@nokia.com ノキア
Anil Gangolli anil@busybuddha.org
コマツナギGangolli anil@busybuddha.org
Kipp Hickman
キップ・ヒックマン
Alfred Hoenes
アルフレッドHoenes
David Hopwood Independent Consultant david.hopwood@blueyonder.co.uk
デヴィッドHopwoodから独立しているコンサルタント david.hopwood@blueyonder.co.uk
Phil Karlton (co-author of SSLv3)
フィルKarlton(SSLv3の共著者)
Paul Kocher (co-author of SSLv3) Cryptography Research paul@cryptography.com
ポール・コッハー(SSLv3の共著者)の暗号研究 paul@cryptography.com
Hugo Krawczyk IBM hugo@ee.technion.ac.il
ユーゴーKrawczyk IBM hugo@ee.technion.ac.il
Jan Mikkelsen Transactionware janm@transactionware.com
1月のミッケルセンTransactionware janm@transactionware.com
Magnus Nystrom RSA Security magnus@rsasecurity.com
マグヌスニストロムRSA Security magnus@rsasecurity.com
Robert Relyea Netscape Communications relyea@netscape.com
ロバートレリアネットスケープ・コミュニケーションズ relyea@netscape.com
Dierks & Rescorla Standards Track [Page 102] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[102ページ]。
Jim Roskind Netscape Communications jar@netscape.com
ジムRoskindネットスケープ・コミュニケーションズ jar@netscape.com
Michael Sabin
マイケル・セービン
Dan Simon Microsoft, Inc. dansimon@microsoft.com
ダンサイモンマイクロソフトInc. dansimon@microsoft.com
Tom Weinstein
トム・ワインスタイン
Tim Wright Vodafone timothy.wright@vodafone.com
ティムライトボーダフォン timothy.wright@vodafone.com
Editors' Addresses
エディタのアドレス
Tim Dierks Independent EMail: tim@dierks.org
ティムDierksから独立しているメール: tim@dierks.org
Eric Rescorla RTFM, Inc. EMail: ekr@rtfm.com
エリックレスコラRTFM Inc.EMail: ekr@rtfm.com
Dierks & Rescorla Standards Track [Page 103] RFC 5246 TLS August 2008
DierksとレスコラStandardsはTLS2008年8月にRFC5246を追跡します[103ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を扱ってください。
Dierks & Rescorla Standards Track [Page 104]
Dierksとレスコラ標準化過程[104ページ]
一覧
スポンサーリンク
