Internet Engineering Task Force (IETF) A. Freier
Request for Comments: 6101 P. Karlton
Category: Historic Netscape Communications
ISSN: 2070-1721 P. Kocher
Independent Consultant
August 2011
The Secure Sockets Layer (SSL) Protocol Version 3.0
Abstract
抽象
This document is published as a historical record of the SSL 3.0 protocol. The original Abstract follows.
この文書は、SSL 3.0プロトコルの歴史的な記録として公開されています。オリジナルの要旨は次の通りです。
This document specifies version 3.0 of the Secure Sockets Layer (SSL 3.0) protocol, a security protocol that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.
この文書では、Secure Sockets Layer（SSL 3.0）プロトコル、インターネット上で通信プライバシーを提供するセキュリティプロトコルのバージョン3.0を指定します。プロトコルは、クライアント/サーバアプリケーションは、盗聴、改ざん、またはメッセージ偽造を防ぐために設計された方法で通信することができます。
Foreword
序文
Although the SSL 3.0 protocol is a widely implemented protocol, a pioneer in secure communications protocols, and the basis for Transport Layer Security (TLS), it was never formally published by the IETF, except in several expired Internet-Drafts. This allowed no easy referencing to the protocol. We believe a stable reference to the original document should exist and for that reason, this document describes what is known as the last published version of the SSL 3.0 protocol, that is, the November 18, 1996, version of the protocol.
SSL 3.0プロトコルが広く実装プロトコル、セキュアな通信プロトコルのパイオニア、およびTransport Layer Security（TLS）の基本であるが、それは正式に、いくつかの期限切れのインターネットドラフトを除き、IETFによって公開されていませんでした。これは、プロトコルへの簡単な参照を許可されません。私たちは、元の文書への安定した基準が存在しなければならないと信じて、その理由のために、このドキュメントでは、SSL 3.0プロトコル、つまり、1996年11月18日、プロトコルのバージョンの最後の公開バージョンとして知られているものについて説明します。
There were no changes to the original document other than trivial editorial changes and the addition of a "Security Considerations" section. However, portions of the original document that no longer apply were not included. Such as the "Patent Statement" section, the "Reserved Ports Assignment" section, and the cipher-suite registrator note in the "The CipherSuite" section. The "US export rules" discussed in the document do not apply today but are kept intact to provide context for decisions taken in protocol design. The "Goals of This Document" section indicates the goals for adopters of SSL 3.0, not goals of the IETF.
些細な編集上の変更及び「セキュリティの考慮事項」セクションの追加以外の元のドキュメントへの変更はありません。しかし、もはや適用されない元の文書の一部が含まれていませんでした。例えば「特許声明」セクション、「のCipherSuite」の「予約されたポートの割り当て」セクション、および暗号スイートレジノートとして。文書で説明した「米国輸出規則は、」今日は適用されませんが、プロトコルの設計で行われた決定のためのコンテキストを提供するために、そのまま保持されています。 「このドキュメントの目標」セクションには、SSL 3.0の採用のための目標ではなく、IETFの目標を示します。
The authors and editors were retained as in the original document. The editor of this document is Nikos Mavrogiannopoulos (nikos.mavrogiannopoulos@esat.kuleuven.be). The editor would like to thank Dan Harkins, Linda Dunbar, Sean Turner, and Geoffrey Keating for reviewing this document and providing helpful comments.
著者と編集者は、元の文書のように保持されました。このドキュメントの編集者は、ニコスMavrogiannopoulos（nikos.mavrogiannopoulos@esat.kuleuven.be）です。エディタは、この文書をレビューして有益なコメントを提供するためのダンハーキンズ、リンダ・ダンバー、ショーン・ターナー、とジェフリー・キーティングに感謝したいと思います。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for the historical record.
このドキュメントはインターネット標準化過程仕様ではありません。それは歴史的な記録のために公開されています。
This document defines a Historic Document for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのための歴史的な文書を定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6101.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6101で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................5
2. Goals ...........................................................5
3. Goals of This Document ..........................................6
4. Presentation Language ...........................................6
4.1. Basic Block Size ...........................................7
4.2. Miscellaneous ..............................................7
4.3. Vectors ....................................................7
4.4. Numbers ....................................................8
4.5. Enumerateds ................................................8
4.6. Constructed Types ..........................................9
4.6.1. Variants ...........................................10
4.7. Cryptographic Attributes ..................................11
4.8. Constants .................................................12
5. SSL Protocol ...................................................12
5.1. Session and Connection States .............................12
5.2. Record Layer ..............................................14
5.2.1. Fragmentation ......................................14
5.2.2. Record Compression and Decompression ...............15
5.2.3. Record Payload Protection and the CipherSpec .......16
5.3. Change Cipher Spec Protocol ...............................18
5.4. Alert Protocol ............................................18
5.4.1. Closure Alerts .....................................19
5.4.2. Error Alerts .......................................20
5.5. Handshake Protocol Overview ...............................21
5.6. Handshake Protocol ........................................23
5.6.1. Hello messages .....................................24
5.6.2. Server Certificate .................................28
5.6.3. Server Key Exchange Message ........................28
5.6.4. Certificate Request ................................30
5.6.5. Server Hello Done ..................................31
5.6.6. Client Certificate .................................31
5.6.7. Client Key Exchange Message ........................31
5.6.8. Certificate Verify .................................34
5.6.9. Finished ...........................................35
5.7. Application Data Protocol .................................36
6. Cryptographic Computations .....................................36
6.1. Asymmetric Cryptographic Computations .....................36
6.1.1. RSA ................................................36
6.1.2. Diffie-Hellman .....................................37
6.1.3. FORTEZZA ...........................................37
6.2. Symmetric Cryptographic Calculations and the CipherSpec ...37
6.2.1. The Master Secret ..................................37
6.2.2. Converting the Master Secret into Keys and
MAC Secrets ........................................37
7. Security Considerations ........................................39
8. Informative References .........................................40
Appendix A. Protocol Constant Values ..............................42
A.1. Record Layer ...............................................42
A.2. Change Cipher Specs Message ................................43
A.3. Alert Messages .............................................43
A.4. Handshake Protocol .........................................44
A.4.1. Hello Messages .........................................44
A.4.2. Server Authentication and Key Exchange Messages ........45
A.5. Client Authentication and Key Exchange Messages ............46
A.5.1. Handshake Finalization Message .........................47
A.6. The CipherSuite ............................................47
A.7. The CipherSpec .............................................49
Appendix B. Glossary ..............................................50
Appendix C. CipherSuite Definitions ...............................53
Appendix D. Implementation Notes ..................................56
D.1. Temporary RSA Keys .........................................56
D.2. Random Number Generation and Seeding .......................56
D.3. Certificates and Authentication ............................57
D.4. CipherSuites ...............................................57
D.5. FORTEZZA ...................................................57
D.5.1. Notes on Use of FORTEZZA Hardware ......................57
D.5.2. FORTEZZA Cipher Suites .................................58
D.5.3. FORTEZZA Session Resumption ............................58
Appendix E. Version 2.0 Backward Compatibility ....................59
E.1. Version 2 Client Hello .....................................59
E.2. Avoiding Man-in-the-Middle Version Rollback ..............61
Appendix F. Security Analysis .....................................61
F.1. Handshake Protocol .........................................61
F.1.1. Authentication and Key Exchange ........................61
F.1.2. Version Rollback Attacks ...............................64
F.1.3. Detecting Attacks against the Handshake Protocol .......64
F.1.4. Resuming Sessions ......................................65
F.1.5. MD5 and SHA ............................................65
F.2. Protecting Application Data ................................65
F.3. Final Notes ................................................66
Appendix G. Acknowledgements ......................................66
G.1. Other Contributors .........................................66
G.2. Early Reviewers ............................................67
The primary goal of the SSL protocol is to provide privacy and reliability between two communicating applications. The protocol is composed of two layers. At the lowest level, layered on top of some reliable transport protocol (e.g., TCP [RFC0793]), is the SSL record protocol. The SSL record protocol is used for encapsulation of various higher level protocols. One such encapsulated protocol, the SSL 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. One advantage of SSL is that it is application protocol independent. A higher level protocol can layer on top of the SSL protocol transparently. The SSL protocol provides connection security that has three basic properties:
SSLプロトコルの主な目的は、2つの通信アプリケーション間のプライバシーと信頼性を提供することです。プロトコルは、二つの層から構成されています。最下位レベルでは、いくつかの信頼性の高いトランスポートプロトコル（例えば、TCP [RFC0793]）の上に積層、SSLレコードプロトコルです。 SSLレコードプロトコルは、様々な上位レベルのプロトコルのカプセル化に使用されます。そのようなカプセル化されたプロトコル、SSLハンドシェイクプロトコルは、サーバーとクライアントが互いを認証し、アプリケーションプロトコルは、データの最初のバイトを送信または受信する前に、暗号化アルゴリズムと暗号鍵を交渉することを可能にします。 SSLの利点の一つは、それが独立したアプリケーションプロトコルであることです。より高いレベルのプロトコルは透過SSLプロトコルの上の層ができます。 SSLプロトコルは、3つの基本的な性質を持っている接続のセキュリティを提供します。
o The connection is private. Encryption is used after an initial handshake to define a secret key. Symmetric cryptography is used for data encryption (e.g., DES [DES], 3DES [3DES], RC4 [SCH]).
O接続はプライベートです。暗号化は、秘密鍵を定義するために最初のハンドシェイクの後に使用されています。対称暗号は、データの暗号化に使用される（例えば、DES [DES]、3DES [3DES]、RC4 [SCH]）。
o The peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA [RSA], DSS [DSS]).
Oピアのアイデンティティは、非対称、または公開鍵暗号を用いて認証することができる（例えば、RSA [RSA]、DSS [DSS]）。
o The connection is reliable. Message transport includes a message integrity check using a keyed Message Authentication Code (MAC) [RFC2104]. Secure hash functions (e.g., SHA, MD5) are used for MAC computations.
O接続は信頼性があります。メッセージトランスポートは、キー付きメッセージ認証コード（MAC）[RFC2104]を使用して、メッセージ完全性チェックを含みます。セキュアハッシュ関数（例えば、SHA、MD5）がMACの計算のために使用されます。
The goals of SSL protocol version 3.0, in order of their priority, are:
SSLプロトコルのバージョン3.0の目標は、その優先度の高い順に、以下のとおりです。
SSL should be used to establish a secure connection between
two parties.
Independent programmers should be able to develop applications
utilizing SSL 3.0 that will then be able to successfully
exchange cryptographic parameters without knowledge of one
another's code.
Note: It is not the case that all instances of SSL (even in the same application domain) will be able to successfully connect. For instance, if the server supports a particular hardware token, and the client does not have access to such a token, then the connection will not succeed.
注意：これは、（たとえ同じアプリケーションドメイン内）SSLのすべてのインスタンスが正常に接続できるようになるそうではありません。サーバーは、特定のハードウェア・トークンをサポートし、クライアントがそのようなトークンへのアクセスを持っていない場合、例えば、接続は成功しません。
SSL seeks to provide a framework into which new public key and
bulk encryption methods can be incorporated as necessary.
This will also accomplish two sub-goals: to prevent the need
to create a new protocol (and risking the introduction of
possible new weaknesses) and to avoid the need to implement an
entire new security library.
Cryptographic operations tend to be highly CPU intensive,
particularly public key operations. For this reason, the SSL
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.
The SSL protocol version 3.0 specification is intended primarily for readers who will be implementing the protocol and those doing cryptographic analysis of it. The spec 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.
SSLプロトコルバージョン3.0仕様は、主に、プロトコルと、それとはやって暗号解析を実行することになるの読者を対象としています。スペックはこれを念頭において書かれている、これら二つのグループのニーズを反映することを意図しています。そのため、アルゴリズム依存のデータ構造と規則の多くは、それらへの容易なアクセスを提供し、（付録のではなく）テキストの本文に含まれています。
This document is not intended to supply any details of service definition or interface definition, although it does cover select areas of policy as they are required for the maintenance of solid security.
この文書は、それらが固体安全の維持のために必要とされる、それは政策の選択領域をカバーんが、サービス定義またはインターフェイス定義のいずれかの詳細を提供するものではありません。
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 External Data Representation (XDR) [RFC1832] in both its syntax and intent, it
この文書は、外部表現内のデータのフォーマットを扱います。以下の非常に基本的な、ややカジュアルに定義されたプレゼンテーション構文が使用されます。構文は、その構造中にいくつかのソースから描画します。それはその構文と意図の両方で、プログラミング言語の構文で「C」および外部データ表現（XDR）[RFC1832]を似ていますが、それを
would be risky to draw too many parallels. The purpose of this presentation language is to document SSL only, not to have general application beyond that particular goal.
あまりにも多くの類似を描くのは危険だろう。このプレゼンテーション言語の目的は、その特定の目標を超えた一般的なアプリケーションを持っていない、SSLのみを文書化することです。
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];
This byte ordering for multi-byte values is the commonplace network byte order or big-endian format.
マルチバイト値のためのこのバイト順は、平凡なネットワークバイトオーダーかビッグエンディアン形式です。
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.
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
ベクター（単一寸法のアレイ）は均質のデータ要素のストリームです。ベクトルの大きさは、ドキュメンテーション時に指定されるか、または実行時まで未指定のままにすることができます。いずれの場合においても、長さは、ベクター内のバイト数ではなく、要素の数を宣言する。タイプ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はベクトルの長さを符号化ストリームに含まれていないTのサイズの複数のデータストリームにnバイトを占めます。
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.
データは9バイトの合計を消費する、三つの連続データムである次の例では、データムは、プロトコルが解釈しない三つの連続バイトであると定義されます。
opaque Datum[3]; /* three uninterpreted bytes */
Datum Data[9]; /* 3 consecutive 3 byte vectors */
Variable-length vectors are defined by specifying a subrange of legal lengths, inclusively, using the notation <floor..ceiling>. When encoded, the actual length precedes the vector's contents in the byte stream. The length will be in the form of a number consuming as many bytes as required to hold the vector's specified maximum (ceiling) length. A variable-length vector with an actual length field of zero is referred to as an empty vector.
可変長ベクトルは、表記<floor..ceiling>を使用して、包括的、法的な長さの部分範囲を指定することによって定義されます。エンコードされた場合、実際の長さはバイトストリームでベクトルのコンテンツに先行します。長さは、ベクトルの指定された最大（天井）の長さを保持するのに必要な数のバイトを消費数の形態であろう。ゼロの実際の長さフィールドを持つ可変長ベクトルは、空ベクターと呼ばれます。
T T'<floor..ceiling>;
T T '<floor..ceiling>。
In the following example, mandatory is a vector that must contain between 300 and 400 bytes of type opaque. It can never be empty. The actual length field consumes two bytes, a uint16, sufficient to represent the value 400 (see Section 4.4). On the other hand, longer can represent up to 800 bytes of data, or 400 uint16 elements, and it may be empty. Its encoding will include a two-byte actual length field prepended to the vector.
次の例では、必須では、不透明なタイプの300と400バイトの間に含んでいなければならないベクトルです。それは空になることはありません。実際の長さフィールドは、2バイト、値400を表現するのに十分なuint16のを、（4.4節を参照）を消費します。一方、長いデータの最大800バイト、または400個のuint16の要素を表すことができ、それが空であってもよいです。そのエンコーディングは、ベクターの先頭に追加2バイトの実際の長さフィールドが含まれます。
opaque mandatory<300..400>;
/* length field is 2 bytes, cannot be empty */
uint16 longer<0..800>;
/* zero to 400 16-bit unsigned integers */
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];
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 { e1(v1), e2(v2), ... , en(vn), [[(n)]] } Te;
Enumerateds occupy as much space in the byte stream as would its maximal defined ordinal value. The following definition would cause one byte to be used to carry fields of type Color.
その最大の順序値を定義したと同じように、列挙はバイトストリームのように多くのスペースを占有します。以下の定義は、1バイトのタイプ色のフィールドを運ぶために使用されることを引き起こします。
enum { red(3), blue(5), white(7) } Color;
Optionally, one may 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.
必要に応じて、一方が余分要素を定義することなく、幅の定義を強制的にその関連タグなしで値を指定することができます。以下の例では、味は、データストリーム内の2つのバイトを消費するだけの値1、2、または4をとることができます。
enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
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 */
For enumerateds that are never converted to external representation, the numerical information may be omitted.
外部表現に変換されることはない列挙に関しては、数値情報を省略してもよいです。
enum { low, medium, high } Amount;
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]];
The fields within a structure may be qualified using the type's name using a syntax much like that available for enumerateds. For example, T.f2 refers to the second field of the previous declaration. Structure definitions may be embedded.
構造内のフィールドは、列挙において利用できるように多くの構文を使用したタイプの名前を使用して修飾することができます。例えば、T.f2は、以前の宣言の2番目のフィールドを意味します。構造体の定義が埋め込まれていてもよいです。
Defined structures may have variants based on some knowledge that is available within the environment. The selector must be an enumerated type that defines the possible variants the structure defines. There must be a case arm for every element of the enumeration declared in the select. The body of the variant structure may be given a label for reference. The mechanism by which the variant is selected at runtime is not prescribed by the presentation language.
定義された構造が環境で利用できる情報に基づいたバリエーションを有することができます。セレクタは、構造が定義可能な変形を定義する列挙型でなければなりません。選択で宣言された列挙のすべての要素のためのケースアームが存在する必要があります。変異体構造の本体は、参照のためにラベルを与えることができます。バリアントは、実行時に選択されるメカニズムは、プレゼンテーションの言語で規定されていません。
struct {
T1 f1;
T2 f2;
....
Tn fn;
select (E) {
case e1: Te1;
case e2: Te2;
....
case en: Ten;
} [[fv]];
} [[Tv]];
For example,
例えば、
enum { apple, orange } VariantTag;
struct {
uint16 number;
opaque string<0..10>; /* variable length */
} V1;
struct {
uint32 number;
opaque string[10]; /* fixed length */
} V2;
struct {
select (VariantTag) { /* value of selector is implicit */
case apple: V1; /* VariantBody, tag = apple */
case orange: V2; /* VariantBody, tag = orange */
} variant_body; /* optional label on variant */
} VariantRecord;
Variant structures may be qualified (narrowed) by specifying a value for the selector prior to the type. For example, an
変異体の構造は、型の前にセレクタの値を指定して（狭く）修飾されてもよいです。たとえば、
orange VariantRecord
オレンジVariantRecord
is a narrowed type of a VariantRecord containing a variant_body of type V2.
タイプV2のvariant_bodyを含むVariantRecordの狭窄タイプです。
The four cryptographic operations digital signing, stream cipher encryption, block cipher encryption, and public key encryption are designated digitally-signed, stream-ciphered, block-ciphered, and public-key-encrypted, respectively. A field's cryptographic processing is specified by prepending an appropriate key word designation before the field's type specification. Cryptographic keys are implied by the current session state (see Section 5.1).
4つの暗号化操作のデジタル署名は、デジタル署名されたストリーム暗号、ブロック暗号、及び公開鍵で暗号化され、それぞれ指定された暗号の暗号化、ブロック暗号の暗号化、及び公開鍵暗号をストリーミングします。フィールドの暗号処理は、フィールドの型を指定する前に、適切なキーワードの指定を付加することによって特定されます。暗号化キーは、現在のセッション状態によって暗示されている（5.1節を参照してください）。
In digital signing, one-way hash functions are used as input for a signing algorithm. In RSA signing, a 36-byte structure of two hashes (one SHA and one MD5) is signed (encrypted with the private key). In DSS, the 20 bytes of the SHA hash are run directly through the Digital Signature Algorithm with no additional hashing.
デジタル署名では、一方向ハッシュ関数は署名アルゴリズムのための入力として使用されます。 RSA署名では、2つのハッシュ（一方SHAと一つMD5）の36バイト構造（秘密鍵で暗号化された）署名されます。 DSSでは、SHAハッシュの20のバイトはない、追加のハッシュとデジタル署名アルゴリズムを介して直接実行されます。
In stream cipher encryption, the plaintext is exclusive-ORed with an identical amount of output generated from a cryptographically secure keyed pseudorandom number generator.
ストリーム暗号の暗号化では、平文は、排他的論理和は、暗号的に安全なキー付き疑似乱数発生器から生成される出力の同じ量です。
In block cipher encryption, every block of plaintext encrypts to a block of ciphertext. Because it is unlikely that the plaintext (whatever data is to be sent) will break neatly into the necessary block size (usually 64 bits), it is necessary to pad out the end of short blocks with some regular pattern, usually all zeroes.
ブロック暗号の暗号化では、平文のすべてのブロックは、暗号文のブロックに暗号化します。それは（データが送信されるものは何でも）平文が必要なブロックサイズ（通常は64ビット）にきちんと壊れることはありそうもないので、それはいくつかの規則的なパターンを有するショートブロック、通常、すべてのゼロの端うちパッドに必要です。
In public key encryption, one-way functions with secret "trapdoors" are used to encrypt the outgoing data. Data encrypted with the public key of a given key pair can only be decrypted with the private key, and vice versa. In the following example:
公開鍵暗号では、秘密の「トラップドア」と一方向関数は、送信データを暗号化するために使用されています。指定されたキーペアの公開鍵で暗号化されたデータは、秘密鍵、およびその逆で復号化することができます。次の例では：
stream-ciphered struct {
uint8 field1;
uint8 field2;
digitally-signed opaque hash[20];
} UserType;
The contents of hash are used as input for the signing algorithm, then the entire structure is encrypted with a stream cipher.
ハッシュの内容物は、次いで、全体の構造は、ストリーム暗号で暗号化され、署名アルゴリズムのための入力として使用されます。
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;
Example1 ex1 = {1, 4};/* assigns f1 = 1, f2 = 4 */
SSL is a layered protocol. At each layer, messages may include fields for length, description, and content. SSL takes messages to be transmitted, fragments the data into manageable blocks, optionally compresses the data, applies a MAC, encrypts, and transmits the result. Received data is decrypted, verified, decompressed, and reassembled, then delivered to higher level clients.
SSLは、階層化プロトコルです。各レイヤでは、メッセージの長さ、説明、コンテンツのためのフィールドを含むことができます。 SSLは、メッセージを送信するのにかかる管理ブロックにデータを断片化し、必要に応じてデータを圧縮し、MACを適用し、暗号化し、結果を送信します。受信したデータは、復号化された検証、解凍、および再組み立て、その後、より高いレベルのクライアントに配信されます。
An SSL session is stateful. It is the responsibility of the SSL handshake protocol to coordinate the states of the client and server, thereby allowing the protocol state machines of each to operate consistently, despite the fact that the state is not exactly parallel. Logically, the state is represented twice, once as the current operating state and (during the handshake protocol) again as the pending state. Additionally, separate read and write states are maintained. When the client or server receives a change cipher spec message, it copies the pending read state into the current read state. When the client or server sends a change cipher spec message, it copies the pending write state into the current write state. When the handshake negotiation is complete, the client and server exchange change cipher spec messages (see Section 5.3), and they then communicate using the newly agreed-upon cipher spec.
SSLセッションは、ステートフルです。それによって、それぞれのプロトコル状態マシンは状態が正確に平行でないという事実にもかかわらず、一貫して動作することができ、クライアントとサーバーの状態を調整するためにSSLハンドシェイクプロトコルの責任です。論理的に、状態はペンディング状態として再度現在の動作状態として、二回表され、（ハンドシェイクプロトコルの間）されます。また、別の読み取りと書き込みの状態が維持されています。現在の読み取り状態にクライアントまたはサーバがChangeCipherSpecメッセージを受け取り、それをコピー保留読ん状態。現在の書き込み状態にクライアントまたはサーバがChangeCipherSpecメッセージを送信し、それをコピー保留書き込み状態。ハンドシェイクネゴシエーションが完了すると、クライアントとサーバーの交換の変化暗号仕様メッセージは、（5.3節を参照）、そして、彼らはその後、新たに合意された時に暗号スペックを使用して通信します。
An SSL session may include multiple secure connections; in addition, parties may have multiple simultaneous sessions.
SSLセッションは、複数のセキュアな接続を含むこともできます。加えて、当事者が複数の同時セッションを有することができます。
The session state includes the following elements:
セッション状態は以下の要素が含まれています。
session identifier: An arbitrary byte sequence chosen by the server to identify an active or resumable session state.
セッション識別子：アクティブまたは再開可能なセッション状態を識別するためにサーバによって選択された任意のバイトシーケンス。
peer certificate: X509.v3 [X509] certificate of the peer. This element of the state may be null.
ピア証明書ピアのX509.v3 [X509]証明書。状態のこの要素はnullの場合もあります。
compression method: The algorithm used to compress data prior to encryption.
圧縮方法：暗号化の前にデータを圧縮するために使用されるアルゴリズム。
cipher spec: Specifies the bulk data encryption algorithm (such as null, DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also defines cryptographic attributes such as the hash_size. (See Appendix A.7 for formal definition.)
暗号仕様はバルクデータ暗号化アルゴリズムと（例えばMD5やSHAのような）MACアルゴリズム（例えばヌル、DESなど）を指定します。また、hash_sizeなどの暗号属性を定義します。 （正式な定義については付録A.7を参照してください。）
master secret: 48-byte secret shared between the client and server.
マスターシークレット：クライアントとサーバの間で共有される48バイトの秘密。
is resumable: A flag indicating whether the session can be used to initiate new connections.
再開可能である：フラグは、セッションが新しい接続を開始するために使用することができるかどうかを示します。
The connection state includes the following elements:
接続状態は、以下の要素を含みます。
server and client random: Byte sequences that are chosen by the server and client for each connection.
サーバとクライアントランダム：接続ごとに、サーバーとクライアントによって選択されたバイトシーケンス。
server write MAC secret: The secret used in MAC operations on data written by the server.
サーバ書き出しMACの秘密：サーバーによって書き込まれたデータのMAC操作で使われる秘密。
client write MAC secret: The secret used in MAC operations on data written by the client.
クライアントによって書き込まれたデータのMAC操作で使われる秘密：クライアントは秘密MACを書きます。
server write key: The bulk cipher key for data encrypted by the server and decrypted by the client.
サーバー・ライト・キー：クライアントによって、サーバが送信データを暗号化するのキー。
client write key: The bulk cipher key for data encrypted by the client and decrypted by the server.
クライアントの書き込みキー：サーバーにより、クライアントが送信データを暗号化するのキー。
initialization vectors: When a block cipher in Cipher Block Chaining (CBC) mode is used, an initialization vector (IV) is maintained for each key. This field is first initialized by the SSL handshake protocol. Thereafter, the final ciphertext block from each record is preserved for use with the following record.
初期化ベクトルは：暗号ブロック連鎖（CBC）モードでブロック暗号を使用した場合、初期化ベクトル（IV）は、各キーのために維持されます。このフィールドは、最初のSSLハンドシェイクプロトコルによって初期化されます。その後、各レコードから、最終的な暗号文ブロックは、次のレコードで使用するために保存されます。
sequence numbers: Each party maintains separate sequence numbers for transmitted and received messages for each connection. When a party sends or receives a change cipher spec message, the appropriate sequence number is set to zero. Sequence numbers are of type uint64 and may not exceed 2^64-1.
シーケンス番号：各当事者は、接続ごとに送受信されたメッセージのために個別のシーケンス番号を維持します。パーティーがChangeCipherSpecメッセージを送信または受信すると、適切なシーケンス番号はゼロに設定されています。シーケンス番号は、タイプUINT64のものであり、2 ^ 64-1を超えてはなりません。
The SSL record layer receives uninterpreted data from higher layers in non-empty blocks of arbitrary size.
SSLレコード層は、任意のサイズの空でないブロック内の上位層からの未解釈のデータを受信します。
The record layer fragments information blocks into SSLPlaintext records 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 SSLPlaintext record).
記録層は2 ^ 14バイト以下のSSLPlaintextのレコードに情報ブロックを断片化します。クライアントメッセージの境界は、記録層に保存されていない（すなわち、同一のContentTypeの複数のクライアントメッセージは、単一のSSLPlaintextレコードに合体されてもよいです）。
struct {
uint8 major, minor;
} ProtocolVersion;
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[SSLPlaintext.length];
} SSLPlaintext;
type: The higher level protocol used to process the enclosed fragment.
タイプ：囲まれたフラグメントを処理するために使用されるより高いレベルのプロトコル。
version: The version of protocol being employed. This document describes SSL version 3.0 (see Appendix A.1).
バージョン：使用されているプロトコルのバージョン。この文書では、SSLバージョン3.0を（付録A.1を参照）について説明します。
length: The length (in bytes) of the following SSLPlaintext.fragment. The length should not exceed 2^14.
長さ：以下SSLPlaintext.fragmentの長さ（バイト単位）。長さが2 ^ 14を超えてはなりません。
fragment: The application data. This data is transparent and treated as an independent block to be dealt with by the higher level protocol specified by the type field.
フラグメント：アプリケーションデータ。このデータは、透明で、タイプフィールドで指定されたより高いレベルのプロトコルによって対処される独立したブロックとして扱われます。
Note: Data of different SSL record layer content types may be interleaved. Application data is generally of lower precedence for transmission than other content types.
注意：異なるSSLレコード層コンテンツタイプのデータをインターリーブすることができます。アプリケーションデータは、一般に、他のコンテンツタイプより送信に対して低い優先順位のものです。
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 an SSLPlaintext structure into an SSLCompressed structure. Compression functions erase their state information whenever the CipherSpec is replaced.
すべてのレコードは、現在のセッション状態に定義された圧縮アルゴリズムを使用して圧縮されています。アクティブな圧縮アルゴリズムは常にあります。しかし、当初はCompressionMethod.nullと定義されます。圧縮アルゴリズムはSSLCompressed構造にSSLPlaintext構造を変換します。 CipherSpecを交換するたびに、圧縮機能は、それらの状態の情報を消去します。
Note: The CipherSpec is part of the session state described in Section 5.1. References to fields of the CipherSpec are made throughout this document using presentation syntax. A more complete description of the CipherSpec is shown in Appendix A.7.
注意：のCipherSpecはセクション5.1で説明したセッション状態の一部です。 CipherSpecのフィールドへの参照は、プレゼンテーションの構文を使用して、この文書を通して作られています。 CipherSpecのより完全な説明は、付録A.7に示されています。
Compression must be lossless and may not increase the content length by more than 1024 bytes. If the decompression function encounters an SSLCompressed.fragment that would decompress to a length in excess of 2^14 bytes, it should issue a fatal decompression_failure alert (Section 5.4.2).
圧縮はロスレスでなければならず、1024バイト以上で、コンテンツの長さを増加させないかもしれません。解凍機能は、2 ^ 14バイトを超える長さに解凍しますSSLCompressed.fragmentに遭遇した場合、それは致命的なdecompression_failure警告（5.4.2）を発行する必要があります。
struct {
ContentType type; /* same as SSLPlaintext.type */
ProtocolVersion version;/* same as SSLPlaintext.version */
uint16 length;
opaque fragment[SSLCompressed.length];
} SSLCompressed;
length: The length (in bytes) of the following SSLCompressed.fragment. The length should not exceed 2^14 + 1024.
長さ：以下SSLCompressed.fragmentの長さ（バイト単位）。長さは、+ 1024年2 ^ 14を超えてはなりません。
fragment: The compressed form of SSLPlaintext.fragment.
断片：SSLPlaintext.fragmentの圧縮形式。
Note: A CompressionMethod.null operation is an identity operation; no fields are altered (see Appendix A.4.1.)
注意：CompressionMethod.null操作は一致演算です。何のフィールドが変更されていません（付録A.4.1を参照してください。）
Implementation note: Decompression functions are responsible for ensuring that messages cannot cause internal buffer overflows.
実装上の注意：解凍機能は、メッセージが内部バッファオーバーフローを引き起こさないことを保証する責任があります。
All records are protected using the encryption and MAC algorithms defined in the current CipherSpec. There is always an active CipherSpec; however, initially it is SSL_NULL_WITH_NULL_NULL, which does not provide any security.
すべてのレコードは、現在のCipherSpecに定義された暗号化とMACアルゴリズムを使用して保護されています。アクティブのCipherSpecは常にあります。しかし、最初はそれがどのようなセキュリティを提供しないSSL_NULL_WITH_NULL_NULL、です。
Once the handshake is complete, the two parties have shared secrets that are used to encrypt records and compute keyed Message Authentication Codes (MACs) on their contents. The techniques used to perform the encryption and MAC operations are defined by the CipherSpec and constrained by CipherSpec.cipher_type. The encryption and MAC functions translate an SSLCompressed structure into an SSLCiphertext. The decryption functions reverse the process. Transmissions also include a sequence number so that missing, altered, or extra messages are detectable.
ハンドシェイクが完了すると、両者は、レコードを暗号化し、その内容をキーメッセージ認証コード（MAC）を計算するために使用される共有秘密を持っています。暗号化及びMAC操作を実行するために使用される技術は、のCipherSpecによって定義され、CipherSpec.cipher_typeによって制約されます。暗号化とMAC機能はSSLCiphertextにSSLCompressed構造を翻訳します。復号化機能は、プロセスを逆転します。欠落している、改変された、または余分なメッセージが検出されるように送信はまた、シーケンス番号を含みます。
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
} fragment;
} SSLCiphertext;
type: The type field is identical to SSLCompressed.type.
タイプ：タイプフィールドがSSLCompressed.typeと同じです。
version: The version field is identical to SSLCompressed.version.
バージョン：バージョンフィールドはSSLCompressed.versionと同じです。
length: The length (in bytes) of the following SSLCiphertext.fragment. The length may not exceed 2^14 + 2048.
長さ：以下SSLCiphertext.fragmentの長さ（バイト単位）。長さは、+ 2048年2 ^ 14を超えてはなりません。
fragment: The encrypted form of SSLCompressed.fragment, including the MAC.
フラグメント：MAC含むSSLCompressed.fragmentの暗号化された形式、。
Stream ciphers (including BulkCipherAlgorithm.null; see Appendix A.7) convert SSLCompressed.fragment structures to and from stream SSLCiphertext.fragment structures.
ストリーム暗号（BulkCipherAlgorithm.nullを含むが、付録A.7を参照）とストリームSSLCiphertext.fragment構造からSSLCompressed.fragment構造を変換します。
stream-ciphered struct {
opaque content[SSLCompressed.length];
opaque MAC[CipherSpec.hash_size];
} GenericStreamCipher;
The MAC is generated as:
MACは次のように生成されます。
hash(MAC_write_secret + pad_2 +
hash(MAC_write_secret + pad_1 + seq_num +
SSLCompressed.type + SSLCompressed.length +
SSLCompressed.fragment));
where "+" denotes concatenation.
ここで、「+」連結を意味します。
pad_1: The character 0x36 repeated 48 times for MD5 or 40 times for SHA.
pad_1：MD5やSHAのために40回48回繰り返し0x36文字。
pad_2: The character 0x5c repeated 48 times for MD5 or 40 times for SHA.
pad_2：MD5やSHAのために40回48回繰り返すコードに5C文字。
seq_num: The sequence number for this message.
SEQ_NUM：このメッセージのシーケンス番号。
hash: Hashing algorithm derived from the cipher suite.
ハッシュ：暗号スイート由来ハッシュアルゴリズム。
Note that the MAC is computed before encryption. The stream cipher encrypts the entire block, including the MAC. For stream ciphers that do not use a synchronization vector (such as RC4), the stream cipher state from the end of one record is simply used on the subsequent packet. If the CipherSuite is SSL_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). SSLCiphertext.length is SSLCompressed.length plus CipherSpec.hash_size.
MACは、暗号化の前に計算されることに注意してください。ストリーム暗号はMACを含むブロック全体を、暗号化します。 （例えば、RC4など）同期ベクトルを使用しないストリーム暗号のために、一つのレコードの終わりからストリーム暗号状態は、単に次のパケットに使用されます。 CipherSuiteがSSL_NULL_WITH_NULL_NULLである場合、暗号化は同一の動作で構成され（すなわち、データは暗号化及びMACのサイズにはMACが使用されないことを意味ゼロでない場合）。 SSLCiphertext.lengthはSSLCompressed.lengthプラスCipherSpec.hash_sizeです。
For block ciphers (such as RC2 or DES), the encryption and MAC functions convert SSLCompressed.fragment structures to and from block SSLCiphertext.fragment structures.
（例えばRC2またはDESなどの）ブロック暗号は、暗号化とMAC機能ブロックSSLCiphertext.fragment構造へとからSSLCompressed.fragment構造を変換します。
block-ciphered struct {
opaque content[SSLCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
The MAC is generated as described in Section 5.2.3.1.
セクション5.2.3.1に記載されるようにMACが生成されます。
padding: Padding that is added to force the length of the plaintext to be a multiple of the block cipher's block length.
パディング：ブロック暗号のブロック長の倍数であることが、平文の長さを強制するために添加されるパディング。
padding_length: The length of the padding must be less than the cipher's block length and may be zero. The padding length should be such that the total size of the GenericBlockCipher structure is a multiple of the cipher's block length.
するpadding_length：パディングの長さは、暗号のブロック長さ未満でなければならず、ゼロであってもよいです。パディング長がのGenericBlockCipher構造体の合計サイズが暗号のブロック長の倍数であるようなものであるべきです。
The encrypted data length (SSLCiphertext.length) is one more than the sum of SSLCompressed.length, CipherSpec.hash_size, and padding_length.
暗号化されたデータ長（SSLCiphertext.length）は、SSLCompressed.length、CipherSpec.hash_sizeとするpadding_lengthの和より1です。
Note: With CBC, the initialization vector (IV) for the first record is provided by the handshake protocol. The IV for subsequent records is the last ciphertext block from the previous record.
注：CBCと、最初のレコードのための初期化ベクトル（IV）は、ハンドシェイクプロトコルによって提供されます。後続のレコードのためのIVは、前のレコードから最後の暗号文ブロックです。
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) CipherSpec. The message consists of a single byte of value 1.
変化暗号仕様プロトコルは、暗号化戦略の遷移を通知するために存在しています。プロトコルは、現在の（いない保留中）のCipherSpec下で暗号化され、圧縮された単一のメッセージからなります。メッセージは、値1の単一バイトから成ります。
struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
The change cipher spec message is sent by both the client and server to notify the receiving party that subsequent records will be protected under the just-negotiated CipherSpec and keys. Reception of this message causes the receiver to copy the read pending state into the read current state. The client sends a change cipher spec message following handshake key exchange and certificate verify messages (if any), and the server sends one after successfully processing the key exchange message it received from the client. An unexpected change cipher spec message should generate an unexpected_message alert (Section 5.4.2). When resuming a previous session, the change cipher spec message is sent after the hello messages.
変化暗号仕様メッセージは、後続のレコードだけの交渉のCipherSpecと鍵の下で保護されます受信者に通知するために、クライアントとサーバの両方で送信されます。このメッセージの受信は、受信機は、読み出し電流状態に読み取り保留状態をコピーする原因となります。クライアントは握手鍵交換と証明書が（もしあれば）メッセージを確認し、次のChangeCipherSpecメッセージを送信し、サーバーは1つが成功した後、それはクライアントから受け取った鍵交換メッセージを処理して送信します。予期せぬ変化暗号仕様メッセージはunexpected_message警告（5.4.2）を生成する必要があります。前のセッションを再開する場合、ChangeCipherSpecメッセージは、helloメッセージの後に送信されます。
One of the content types supported by the SSL record layer is the alert type. Alert messages convey the severity of the message and a description of the alert. Alert messages with a level of fatal result in the immediate termination of the connection. In this case, other connections corresponding to the session may continue, but the session identifier must be invalidated, preventing the failed session from being used to establish new connections. Like other messages, alert messages are encrypted and compressed, as specified by the current connection state.
SSLレコード層によってサポートされているコンテンツの種類の一つは、アラートタイプです。アラートメッセージには、メッセージの重要度やアラートの説明を伝えます。接続の即時終了で致命的な結果のレベルにアラートメッセージ。この場合、セッションに対応する他の接続が継続してもよいが、セッション識別子を無効にする必要があり、新しい接続を確立するために使用されるの失敗したセッションを防止します。現在の接続状態によって指定された他のメッセージと同様に、警告メッセージは、暗号化および圧縮されています。
enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decompression_failure(30),
handshake_failure(40),
no_certificate(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter (47)
(255)
} AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
The client and the server must share knowledge that the connection is ending in order to avoid a truncation attack. Either party may initiate the exchange of closing messages.
クライアントとサーバーの接続がトランケーション攻撃を避けるために終了しているという知識を共有しなければなりません。いずれの当事者から終了メッセージの交換を開始することができます。
close_notify: This message notifies the recipient that the sender will not send any more messages on this connection. The session becomes unresumable if any connection is terminated without proper close_notify messages with level equal to warning.
close_notify：このメッセージは、送信者がこの接続上の任意の複数のメッセージを送信しません受信者に通知します。任意の接続が警告に等しいレベルで適切なは、close_notifyメッセージなしで終了した場合、セッションはunresumableになります。
Either party may initiate a close by sending a close_notify alert. Any data received after a closure alert is ignored.
いずれの当事者は、は、close_notifyを送信することにより、クローズを開始することができます。閉鎖警報後に受信したデータはすべて無視されます。
Each party is required to send a close_notify alert before closing the write side of the connection. It is required that the other party respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes. It is not required for the initiator of the close to wait for the responding close_notify alert before closing the read side of the connection.
各当事者は、接続の書き込み側を閉じる前には、close_notifyを送信するために必要とされます。他の当事者は、独自のは、close_notifyで応答し、すぐにコネクションを閉じ、保留中の書き込みを捨てることが必要とされます。接続の読み取り側を閉じる前に、応答は、close_notifyを待つために近くのイニシエータは必要ありません。
NB: It is assumed that closing a connection reliably delivers pending data before destroying the transport.
NB：確実な接続を閉じると輸送を破壊する前に、保留中のデータを配信するものとします。
Error handling in the SSL 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 are required to forget any session identifiers, keys, and secrets associated with a failed connection. The following error alerts are defined:
SSLハンドシェイクプロトコルにおけるエラー処理は非常に簡単です。エラーが検出されると、検出当事者が他の当事者にメッセージを送信します。致命的な警告メッセージの送信または受信すると、両当事者は、直ちに接続を閉じます。サーバとクライアントは、失敗した接続に関連付けられているすべてのセッション識別子、キー、および秘密を忘れるために必要とされています。次のエラーアラートが定義されています。
unexpected_message: An inappropriate message was received. This alert is always fatal and should never be observed in communication between proper implementations.
unexpected_message：不適切なメッセージを受信しました。このアラートは常にfatalである。適切な実装間の通信に観察すべきではありません。
bad_record_mac: This alert is returned if a record is received with an incorrect MAC. This message is always fatal.
bad_record_mac：レコードが不正なMACで受信されている場合、この警告が返されます。このメッセージは常に致命的です。
decompression_failure: The decompression function received improper input (e.g., data that would expand to excessive length). This message is always fatal.
decompression_failure：圧縮解除機能は、不適切な入力（過剰な長さに拡大する、例えば、データ）を受け取りました。このメッセージは常に致命的です。
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: A no_certificate alert message may be sent in response to a certification request if no appropriate certificate is available.
no_certificate：NO適切な証明書が利用可能でない場合no_certificate警告メッセージは、認証要求に応答して送信されてもよいです。
bad_certificate: A certificate was corrupt, contained signatures that did not verify correctly, etc.
bad_certificate：証明書が壊れていたが、正しく検証しませんでした署名などが含まれてい
unsupported_certificate: A certificate was of an unsupported type.
unsupported_certificate：証明書はサポートされていないタイプでした。
certificate_revoked: A certificate was revoked by its signer.
certificate_revoked：証明書はその署名者によって取り消されました。
certificate_expired: A certificate has expired or is not currently valid.
certificate_expired：証明書の有効期限が切れたり、現在有効ではありませんしました。
certificate_unknown: Some other (unspecified) issue arose in processing the certificate, rendering it unacceptable.
certificate_unknownは他にもいくつかあります（詳細不明）問題は容認できない、それをレンダリング、証明書の処理で生じました。
illegal_parameter: A field in the handshake was out of range or inconsistent with other fields. This is always fatal.
illegal_parameter：ハンドシェイクでのフィールドが範囲外だったか、他のフィールドと矛盾。これは、常に致命的です。
The cryptographic parameters of the session state are produced by the SSL handshake protocol, which operates on top of the SSL record layer. When an SSL 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. These processes are performed in the handshake protocol, which can be summarized as follows: the client sends a client hello message to which the server must respond with a server hello message, or else a fatal error will occur and the connection will fail. The client hello and server hello are used to establish security enhancement capabilities between client and server. The client hello and server hello establish the following attributes: Protocol Version, Session ID, Cipher Suite, and Compression Method. Additionally, two random values are generated and exchanged: ClientHello.random and ServerHello.random.
セッション状態の暗号パラメータは、SSLレコード層の上で動作するSSLハンドシェイクプロトコルによって生成されます。 SSLクライアントとサーバが最初に通信を開始すると、彼らは、必要に応じて相互に認証、暗号化アルゴリズムを選択し、共有秘密を生成するために、公開鍵暗号化技術を使用し、プロトコルバージョンについては同意します。これらのプロセスは、以下のように要約することができるハンドシェイクプロトコルで実行されます。クライアントは、サーバがサーバハローメッセージで応答しなければならない、または他の致命的なエラーが発生しますと、接続が失敗する先のクライアントhelloメッセージを送信します。クライアントハローとサーバハローは、クライアントとサーバ間のセキュリティ強化機能を確立するために使用されています。プロトコルバージョン、セッションID、暗号スイート、および圧縮方法：クライアントハローとサーバはハロー次の属性を確立します。さらに、2つのランダムな値が生成され、交換される：ClientHello.randomとしてServerHello.randomを。
Following the hello messages, the server will send its certificate, if it is to be authenticated. Additionally, a server key exchange message may be sent, if it is required (e.g., if their server has no certificate, or if its certificate is for signing only). If the server is authenticated, it may request a certificate from the client, if that is appropriate to the cipher suite selected. Now the server will send the server hello done message, indicating that the hello-message phase of the handshake is complete. The server will then wait for a client response. If the server has sent a certificate request message, the client must send either the certificate message or a no_certificate alert. The client key exchange message is now sent, and the content of that message will depend on the public key algorithm selected between the client hello and the server hello. If the client has sent a certificate with signing ability, a digitally-signed certificate verify message is sent to explicitly verify the certificate.
それが認証される場合はhelloメッセージに続き、サーバは、その証明書を送信します。それが必要な場合、さらに、サーバーキー交換メッセージは、送信されてもよい（例えば、それらのサーバは全く証明書を持たない場合、またはその証明書が署名のみのためのものである場合）。サーバーが認証された場合には、選択された暗号スイートに適切であれば、それは、クライアントからの証明書を要求することができます。今、サーバは、サーバのハローがハンドシェイクのハロー・メッセージフェーズが完了したことを示す、メッセージを行って送信します。その後、サーバーはクライアントの応答を待ちます。サーバが証明書要求メッセージを送信した場合、クライアントは、証明書のメッセージまたはno_certificate警告のいずれかを送信する必要があります。クライアント鍵交換メッセージは、現在送信され、そのメッセージの内容は、クライアントハローとサーバハローの間で選択された公開鍵アルゴリズムに依存します。クライアントが署名能力を持つ証明書を送信した場合、デジタル署名された証明書は、メッセージが明示的に証明書を検証するために送信されることを確認します。
At this point, a change cipher spec message is sent by the client, and the client copies the pending CipherSpec into the current CipherSpec. The client then immediately sends the finished message under the new algorithms, keys, and secrets. In response, the server will send its own change cipher spec message, transfer the pending to the current CipherSpec, and send its finished message under the new CipherSpec. At this point, the handshake is complete and the client and server may begin to exchange application layer data. (See flow chart below.)
この時点で、ChangeCipherSpecメッセージは、クライアントによって送信され、現在のCipherSpecにクライアントをコピーし、保留中のCipherSpec。その後、クライアントは、直ちに新しいアルゴリズム、鍵、および秘密の下に完成したメッセージを送信します。それに応答して、サーバは、自身のChangeCipherSpecメッセージを送信します現在のCipherSpecに保留を転送し、新しいCipherSpecの下で完成したメッセージを送信します。この時点で、ハンドシェイクが完了し、クライアントとサーバは、アプリケーション層のデータを交換し始めるかもしれません。 （以下のフローチャートを参照してください）。
Client Server
クライアントサーバー
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
* Indicates optional or situation-dependent messages that are not always sent.
*常に送信されていないオプションや状況依存のメッセージを示します。
Note: To help avoid pipeline stalls, ChangeCipherSpec is an independent SSL protocol content type, and is not actually an SSL handshake message.
注意：パイプラインの停止を避けるために、ChangeCipherSpecを、独立したSSLプロトコルコンテンツタイプであり、実際のSSLハンドシェイクメッセージではありません。
When the client and server decide to resume a previous session or duplicate an existing session (instead of negotiating new security parameters) the message flow is as follows:
クライアントとサーバーは、メッセージ・フローを、前のセッションを再開するか、（代わりに新しいセキュリティパラメータを交渉の）既存のセッションを複製することを決定した場合は、次のとおりです。
The client sends a ClientHello using the session ID of the session to be resumed. The server then checks its session cache for a match. If a match is found, and the server is willing to re-establish the connection under the specified session state, it will send a ServerHello with the same session ID value. At this point, both client and server must send change cipher spec messages and proceed directly to finished messages. Once the re-establishment is complete, the client and server may begin to exchange application layer data. (See flow chart below.) If a session ID match is not found, the server generates a new session ID and the SSL client and server perform a full handshake.
クライアントが再開されるセッションのセッションIDを使用してClientHelloを送信します。その後、サーバーは、一致するセッションキャッシュをチェックします。一致するものが見つかった、とサーバーが指定されたセッション状態の下でコネクションを再確立しようとする場合は、同じセッションID値を含めたServerHelloメッセージを送信します。この時点で、クライアントとサーバの両方は、ChangeCipherSpecメッセージを送信する必要があり、完成したメッセージに直接進みます。再確立が完了すると、クライアントとサーバは、アプリケーション層のデータを交換し始めるかもしれません。セッションIDの一致が見つからない場合（下のフローチャートを参照してください。）、サーバーは新しいセッションIDを生成し、SSLクライアントとサーバーは、完全なハンドシェイクを行います。
Client Server
クライアントサーバー
ClientHello -------->
ServerHello
[change cipher spec]
<-------- Finished
change cipher spec
Finished -------->
Application Data <-------> Application Data
The contents and significance of each message will be presented in detail in the following sections.
コンテンツ及び各メッセージの意味は、以下のセクションで詳細に提示されるであろう。
The SSL handshake protocol is one of the defined higher level clients of the SSL record protocol. This protocol is used to negotiate the secure attributes of a session. Handshake messages are supplied to the SSL record layer, where they are encapsulated within one or more SSLPlaintext structures, which are processed and transmitted as specified by the current active session state.
SSLハンドシェイクプロトコルは、SSLレコードプロトコルの定義された高いレベルのクライアントの一つです。このプロトコルは、セッションの安全な属性を交渉するために使用されます。ハンドシェークメッセージは、それらが現在アクティブなセッション状態によって指定されるように処理され、送信される1つまたは複数のSSLPlaintext構造内にカプセル化されたSSLレコード層に供給されます。
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; /* 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;
The handshake protocol messages are presented in the order they must be sent; sending handshake messages in an unexpected order results in a fatal error.
握手プロトコルメッセージは、それらが送られなければならないために提示されています。致命的なエラーで予期しないため結果にハンドシェイクメッセージを送信します。
The hello phase messages are used to exchange security enhancement capabilities between the client and server. When a new session begins, the CipherSpec encryption, hash, and compression algorithms are initialized to null. The current CipherSpec is used for renegotiation messages.
ハロー位相メッセージは、クライアントとサーバ間のセキュリティ強化機能を交換するために使用されています。新しいセッションが始まると、のCipherSpec暗号化、ハッシュ、および圧縮アルゴリズムはnullに初期化されます。現在のCipherSpecは、再交渉メッセージに使用されます。
The hello request message may be sent by the server at any time, but will be ignored by the client if the handshake protocol is already underway. It is a simple notification that the client should begin the negotiation process anew by sending a client hello message when convenient.
ハロー要求メッセージは、いつでも、サーバーによって送信されてもよいが、ハンドシェイクプロトコルがすでに進行中である場合は、クライアントによって無視されます。これは、クライアントが都合のよいときに、クライアントのhelloメッセージを送信することにより、新たに交渉プロセスを開始する必要があり、単純な通知です。
Note: Since handshake messages are intended to have transmission precedence over application data, it is expected that the negotiation begin in no more than one or two times the transmission time of a maximum-length application data message.
注：ハンドシェイクメッセージは、アプリケーションデータに対する送信優先度を有することが意図されているので、交渉がせいぜい1回または2回で最大長アプリケーションデータメッセージの送信時刻を開始することが予想されます。
After sending a hello request, servers should not repeat the request until the subsequent handshake negotiation is complete. A client that receives a hello request while in a handshake negotiation state should simply ignore the message.
その後の握手交渉が完了するまでのhello要求を送信した後、サーバはリクエストを繰り返すべきではありません。ハンドシェイクネゴシエーション状態で、単にメッセージを無視する必要がありながら、ハロー要求を受信するクライアント。
The structure of a hello request message is as follows:
次のようにハロー要請メッセージの構造は以下の通りであります：
struct { } HelloRequest;
When a client first connects to a server it is required to send the client hello as its first message. The client can also send a client hello in response to a hello request or on its own initiative in order to renegotiate the security parameters in an existing connection. The client hello message includes a random structure, which is used later in the protocol.
クライアントが最初のサーバに接続するときには、その最初のメッセージとして、クライアントのhelloを送信するために必要とされます。また、クライアントは、ハロー要求したり、既存の接続におけるセキュリティパラメータを再交渉するために、自らに応じて、クライアントのhelloを送信することができます。クライアントハローメッセージは、プロトコルの後半で使用されるランダム構造を含みます。
struct {
uint32 gmt_unix_time;
opaque random_bytes[28];
} Random;
gmt_unix_time: The current time and date in standard UNIX 32-bit format according to the sender's internal clock. Clocks are not required to be set correctly by the basic SSL protocol; higher level or application protocols may define additional requirements.
gmt_unix_time：送信者の内部クロックに応じて、標準のUNIX 32ビットフォーマットで現在の日付と時刻。時計は、基本的なSSLプロトコルによって正しく設定されている必要はありません。より高いレベルまたはアプリケーションプロトコルが追加要件を定義してもよいです。
random_bytes: 28 bytes generated by a secure random number generator.
random_bytes：安全な乱数ジェネレータによって生成された28バイト。
The client hello message includes a variable-length session identifier. If not empty, the value identifies a session between the same client and server whose security parameters the client wishes to reuse. The session identifier may be from an earlier connection, this connection, or another currently active connection. The second option is useful if the client only wishes to update the random structures and derived values of a connection, while the third option makes it possible to establish several simultaneous independent secure connections without repeating the full handshake protocol. The actual contents of the SessionID are defined by the server.
クライアントハローメッセージは、可変長のセッション識別子を含みます。空でない場合、値は、セキュリティパラメータ、クライアントが再利用しようと、同じクライアントとサーバ間のセッションを識別する。セッション識別子は、以前の接続、これに関連し、または別の現在アクティブな接続からのものであってもよいです。第三の選択肢は、完全なハンドシェイクプロトコルを繰り返さずに、いくつかの同時の独立した安全な接続を確立することを可能にする一方で、クライアントはのみ、ランダム構造および接続の派生値を更新したい場合は、2番目のオプションが便利です。セッションIDの実際の内容はサーバーによって定義されています。
opaque SessionID<0..32>;
不透明なセッションID <0 32>。
Warning: Servers must not place confidential information in session identifiers or let the contents of fake session identifiers cause any breach of security.
警告：サーバはセッション識別子に秘密情報を置くか、偽のセッション識別子の内容は、セキュリティの違反を起こさせてはなりません。
The CipherSuite list, passed from the client to the server in the client hello message, contains the combinations of cryptographic algorithms supported by the client in order of the client's preference (first choice first). Each CipherSuite defines both a key exchange algorithm and a CipherSpec. The server will select a cipher suite or, if no acceptable choices are presented, return a handshake failure alert and close the connection.
クライアントのhelloメッセージでクライアントからサーバに渡されたのCipherSuiteのリストは、クライアントの好み（最初の最初の選択肢）のために、クライアントでサポートされている暗号アルゴリズムの組み合わせが含まれています。各CipherSuiteには、鍵交換アルゴリズムとCipherSpecの両方を定義します。サーバーは、暗号スイートを選択するか、受け入れ可能な選択肢が提示されていない場合、handshake_failureアラートを返して接続を閉じます。
uint8 CipherSuite[2]; /* Cryptographic suite selector */
The client hello includes a list of compression algorithms supported by the client, ordered according to the client's preference. If the server supports none of those specified by the client, the session must fail.
クライアントのhelloが、クライアントの好みに応じて注文したクライアントでサポートされている圧縮アルゴリズムのリストが含まれています。サーバがクライアントによって指定されたもののどれをサポートしていない場合、セッションは失敗しなければなりません。
enum { null(0), (255) } CompressionMethod;
Issue: Which compression methods to support is under investigation.
問題：サポートするための圧縮方法が検討されています。
The structure of the client hello is as follows.
次のようにクライアントハローの構造があります。
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
client_version: The version of the SSL protocol by which the client wishes to communicate during this session. This should be the most recent (highest valued) version supported by the client. For this version of the specification, the version will be 3.0 (see Appendix E for details about backward compatibility).
クライアント_：クライアントがこのセッションの間に通信しようとすることで、SSLプロトコルのバージョン。これは、クライアントでサポートされている最新の（最高のもの）であるべきです。仕様のこのバージョンでは、バージョン3.0が（後方互換性の詳細については、付録Eを参照してください）となります。
random: A client-generated random structure.
ランダム：クライアントが生成したランダム構造。
session_id: The ID of a session the client wishes to use for this connection. This field should be empty if no session_id is available or the client wishes to generate new security parameters.
SESSION_ID：クライアントは、この接続のために使用したいセッションのID。 session_idが利用可能でない場合、またはクライアントが新しいセキュリティパラメータを生成することを希望する場合は、このフィールドは空でなければなりません。
cipher_suites: This is a list of the cryptographic options supported by the client, sorted 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.6.
cipher_suites：これは最初のクライアントの最初の嗜好にソートし、クライアントによってサポートされている暗号オプションのリストです。 SESSION_IDフィールドは、（セッション再開要求を含意して）空でない場合は、このベクターは、少なくともそのセッションから暗号_スイートを含まなければなりません。値は付録A.6で定義されています。
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), this vector must include at least the compression_method from that session. All implementations must support CompressionMethod.null.
圧縮_：これはクライアントの好みによってソートし、クライアントによってサポートされている圧縮方法のリストです。 SESSION_IDフィールドは、（セッション再開要求を含意して）空でない場合は、このベクターは、少なくとも、そのセッションのcompression_methodを含まなければなりません。すべての実装はCompressionMethod.nullをサポートしている必要があります。
After sending the client hello message, the client waits for a server hello message. Any other handshake message returned by the server except for a hello request is treated as a fatal error.
クライアントのhelloメッセージを送信した後、クライアントは、サーバのhelloメッセージを待機します。ハロー要求を除いて、サーバから返された任意の他の握手メッセージは致命的なエラーとして扱われます。
Implementation note: Application data may not be sent before a finished message has been sent. Transmitted application data is known to be insecure until a valid finished message has been received. This absolute restriction is relaxed if there is a current, non-null encryption on this connection.
実装上の注意：完成したメッセージが送信される前にアプリケーションデータが送信されない場合があります。送信されたアプリケーションデータは、有効なFinishedメッセージが受信されるまで安全ではないことが知られています。この接続の現在、非ヌル暗号化がある場合には、この絶対的な制限が緩和されます。
Forward compatibility note: In the interests of forward compatibility, it is permitted for a client hello message to include extra data after the compression methods. This data must be included in the handshake hashes, but must otherwise be ignored.
前方互換性に関する注意：上位互換性の利益では、圧縮方法の後に余分なデータが含まれるように、クライアントのhelloメッセージのために許可されています。このデータは握手ハッシュに含まれなければならないが、それ以外は無視されなければなりません。
The server processes the client hello message and responds with either a handshake_failure alert or server hello message.
サーバーは、クライアントのhelloメッセージを処理し、handshake_failureアラートとまたはサーバハローメッセージのいずれかで応答します。
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
} 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 will be 3.0 (see Appendix E for details about backward compatibility).
SERVER_VERSION：このフィールドは、クライアントハロー内のクライアントによって提案されたものの下、最高のサーバーでサポートされているが含まれます。仕様のこのバージョンでは、バージョン3.0が（後方互換性の詳細については、付録Eを参照してください）となります。
random: This structure is generated by the server and must be different from (and independent of) ClientHello.random.
ランダム：この構造は、サーバーによって生成され、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.
SESSION_ID：これは、この接続に対応するセッションのIDです。 ClientHello.session_idが空だった場合、サーバーは、一致のためにそのセッションキャッシュになります。一致するものが見つかったと、サーバーは、指定されたセッション状態を使用して新しい接続を確立するために喜んでいる場合は、サーバはクライアントによって供給されたのと同じ値で応答します。これは再開しているセッションを示し、当事者が完成メッセージへ進まなければなりません。それ以外の場合、このフィールドには、新しいセッションを特定する別の値が含まれます。サーバーは、セッションがキャッシュされませんので、再開できないことを示すために、空のsession_idを返す場合があります。
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_メソッドのリストから、サーバによって選択された単一の圧縮アルゴリズム。再開したセッションの場合、このフィールドは再開セッション状態からの値です。
If the server is to be authenticated (which is generally the case), the server sends its certificate immediately following the server hello message. The certificate type must be appropriate for the selected cipher suite's key exchange algorithm, and is generally an X.509.v3 certificate (or a modified X.509 certificate in the case of FORTEZZA(tm) [FOR]). The same message type will be used for the client's response to a certificate request message.
サーバは、（一般的ケースである）に認証する場合、サーバは、サーバハローメッセージの直後にその証明書を送信します。証明書の種類は、選択された暗号スイートの鍵交換アルゴリズムに適切である、と一般的に（[FOR] FORTEZZA（登録商標）の場合、または修飾されたX.509証明書）X.509.v3証明書である必要があります。同じメッセージタイプは、証明書要求メッセージに対するクライアントの応答のために使用されます。
opaque ASN.1Cert<1..2^24-1>;
struct {
ASN.1Cert certificate_list<1..2^24-1>;
} Certificate;
certificate_list: This is a sequence (chain) of X.509.v3 certificates, ordered with the sender's certificate first followed by any certificate authority certificates proceeding sequentially upward.
certificate_list：これは最初の上昇順次進めて任意の認証局の証明書に続く送信者の証明書と一緒に注文、X.509.v3証明書のシーケンス（連鎖）です。
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は、リストを解析する作業がより困難に、セットではなく、シーケンスを定義します。
The server key exchange message is sent by the server if it has no certificate, has a certificate only used for signing (e.g., DSS [DSS] certificates, signing-only RSA [RSA] certificates), or FORTEZZA KEA key exchange is used. This message is not used if the server certificate contains Diffie-Hellman [DH1] parameters.
それは、何の証明書を持っていないだけ（例えば、DSS [DSS]証明書、署名のみRSA [RSA]証明書）を署名するために使用される証明書を持っている場合、サーバーキー交換メッセージは、サーバによって送信され、またはFORTEZZA KEA鍵交換が使用されます。サーバ証明書は、ディフィー - ヘルマン[DH1]パラメータが含まれている場合、このメッセージは使用されません。
Note: According to current US export law, RSA moduli larger than 512 bits may not be used for key exchange in software exported from the US. With this message, larger RSA keys may be used as signature-only certificates to sign temporary shorter RSA keys for key exchange.
注意：現在の米国輸出法によると、RSAは、512ビットが米国からエクスポートソフトウェアでの鍵交換のために使用することはできませんよりも大きなモジュラスを。このメッセージでは、より大きなRSA鍵は、鍵交換のための一時的な短いRSA鍵を署名する署名証明書のみに使用することができます。
enum { rsa, diffie_hellman, fortezza_kea }
KeyExchangeAlgorithm;
struct {
opaque rsa_modulus<1..2^16-1>;
opaque rsa_exponent<1..2^16-1>;
} ServerRSAParams;
rsa_modulus: The modulus of the server's temporary RSA key.
RSAモジュラス：サーバーの一時的RSA鍵のモジュラス。
rsa_exponent: The public exponent of the server's temporary RSA key.
rsa_exponent：サーバーの一時的RSA鍵の公開指数。
struct {
opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>;
} ServerDHParams; /* Ephemeral DH parameters */
dh_p: The prime modulus used for the Diffie-Hellman operation.
dh_p：Diffie-Hellman演算に使用されるプライムモジュラス。
dh_g: The generator used for the Diffie-Hellman operation.
dh_g：Diffie-Hellman演算に使用される発電機。
dh_Ys: The server's Diffie-Hellman public value (gX mod p).
dh_Ys：サーバのディフィー-Hellman公開値（GX＆MOD P）。
struct {
opaque r_s [128];
} ServerFortezzaParams;
r_s: Server random number for FORTEZZA KEA (Key Exchange Algorithm).
R_S：FORTEZZA KEA（鍵交換アルゴリズム）用のサーバーの乱数。
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params;
case fortezza_kea:
ServerFortezzaParams params;
};
} ServerKeyExchange;
params: The server's key exchange parameters.
params：サーバーの鍵交換パラメータ。
signed_params: A hash of the corresponding params value, with the signature appropriate to that hash applied.
signed_params：そのハッシュに適切な署名を有する対応のparams値のハッシュは、適用しました。
md5_hash: MD5(ClientHello.random + ServerHello.random + ServerParams);
md5_hash：MD5（ClientHello.randomと+ ServerHello.random + ServerParams）。
sha_hash: SHA(ClientHello.random + ServerHello.random + ServerParams);
sha_hash：SHA（ClientHello.randomと+ ServerHello.random + ServerParams）。
enum { anonymous, rsa, dsa } SignatureAlgorithm;
digitally-signed struct {
select(SignatureAlgorithm) {
case anonymous: struct { };
case rsa:
opaque md5_hash[16];
opaque sha_hash[20];
case dsa:
opaque sha_hash[20];
};
} Signature;
A non-anonymous server can optionally request a certificate from the client, if appropriate for the selected cipher suite.
選択された暗号スイートのために適切であれば、非匿名のサーバは、クライアントからの要求に証明書をオプションすることができます。
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh(5), dss_ephemeral_dh(6), fortezza_kea(20),
(255)
} ClientCertificateType;
opaque DistinguishedName<1..2^16-1>;
不透明な識別名<1..2 ^ 16-1>;
struct {
ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<3..2^16-1>;
} CertificateRequest;
certificate_types: This field is a list of the types of certificates requested, sorted in order of the server's preference.
証明書_：このフィールドは、サーバの優先順にソートし、要求された証明書の種類の一覧です。
certificate_authorities: A list of the distinguished names of acceptable certificate authorities.
証明して：許容できる認証局の識別名のリスト。
Note: DistinguishedName is derived from [X509].
注：識別名は[X509]から誘導されます。
Note: It is a fatal handshake_failure alert for an anonymous server to request client identification.
注意：これは、クライアントの識別を要求する匿名サーバーのための致命的なhandshake_failureアラートとなります。
The server hello done message is sent by the server to indicate the end of the server hello and associated messages. After sending this message, the server will wait for a client response.
サーバハロー行わメッセージがサーバハローと関連するメッセージの終わりを示すために、サーバによって送信されます。このメッセージを送信した後、サーバーは、クライアントの応答を待ちます。
struct { } ServerHelloDone;
Upon receipt of the server hello done message the client should verify that the server provided a valid certificate if required and check that the server hello parameters are acceptable.
サーバ・ハロー行ってメッセージを受信すると、クライアントは、必要に応じて、サーバーが有効な証明書を提供していることを確認し、サーバーのhelloパラメータが許容可能であることを確認する必要があります。
This is the first message the client can send after receiving a server hello done message. This message is only sent if the server requests a certificate. If no suitable certificate is available, the client should send a no_certificate alert instead. This alert is only a warning; however, the server may respond with a fatal handshake failure alert if client authentication is required. Client certificates are sent using the certificate defined in Section 5.6.2.
これは、クライアントがサーバハロー行ってメッセージを受信した後、送信することができます最初のメッセージです。サーバーが証明書を要求した場合、このメッセージにのみ送信されます。もし適切な証明書が利用できない場合、クライアントは代わりにno_certificateアラートを送信する必要があります。このアラートは警告のみです。クライアント認証が必要な場合しかし、サーバーは、致命的な握手故障警報で応答することができます。クライアント証明書は、セクション5.6.2で定義された証明書を使用して送信されます。
Note: Client Diffie-Hellman certificates must match the server specified Diffie-Hellman parameters.
注意：クライアントのDiffie-Hellman証明書はのDiffie-Hellmanパラメータを指定したサーバーと一致する必要があります。
The choice of messages depends on which public key algorithm(s) has (have) been selected. See Section 5.6.3 for the KeyExchangeAlgorithm definition.
メッセージの選択は、公開鍵アルゴリズム（複数可）（持っている）選択されているに依存します。 KeyExchangeAlgorithmの定義については5.6.3項を参照してください。
struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
case fortezza_kea: FortezzaKeys;
} exchange_keys;
} ClientKeyExchange;
The information to select the appropriate record structure is in the pending session state (see Section 5.1).
適切なレコード構造を選択するための情報が保留セッション状態である（5.1節を参照してください）。
If RSA is being used for key agreement and authentication, the client generates a 48-byte premaster secret, encrypts it under the public key from the server's certificate or temporary RSA key from a server key exchange message, and sends the result in an encrypted premaster secret message.
RSAが主要な協定と認証に使用されている場合、クライアントはサーバ鍵交換メッセージからサーバーの証明書または一時的RSA鍵から公開鍵の下でそれを暗号化し、48バイトのpremaster_secretを生成し、暗号化されたプリマスターに結果を送信します秘密のメッセージ。
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret;
client_version: The latest (newest) version supported by the client. This is used to detect version roll-back attacks.
クライアント_：クライアントがサポートする最新バージョン。これは、バージョンロールバック攻撃を検出するために使用されます。
random: 46 securely-generated random bytes.
ランダム：安全に生成された46バイトの乱数。
struct {
public-key-encrypted PreMasterSecret pre_master_secret;
} EncryptedPreMasterSecret;
pre_master_secret: This random value is generated by the client and is used to generate the master secret, as specified in Section 6.1.
前_のマスター_秘密：このランダム値は6.1節で指定されているように、クライアントによって生成され、マスターシークレットを生成するために使用されます。
Under FORTEZZA, the client derives a token encryption key (TEK) using the FORTEZZA Key Exchange Algorithm (KEA). The client's KEA calculation uses the public key in the server's certificate along with private parameters in the client's token. The client sends public parameters needed for the server to generate the TEK, using its own private parameters. The client generates session keys, wraps them using the TEK, and sends the results to the server. The client generates IVs for the session keys and TEK and sends them also. The client generates a random 48-byte premaster secret, encrypts it using the TEK, and sends the result:
FORTEZZAの下では、クライアントはFORTEZZA鍵交換アルゴリズム（KEA）を使用して、トークンの暗号化キー（TEK）を導出します。クライアントのKEA計算では、クライアントのトークンの民間パラメータとともに、サーバの証明書の公開鍵を使用しています。クライアントは、独自のプライベート・パラメータを使用して、TEKを生成するために、サーバーに必要な公開パラメータを送信します。クライアントは、セッション鍵を生成し、TEKを使用してそれらをラップして、サーバーに結果を送信します。クライアントは、セッション鍵とTEKのためのIVを生成し、また、それらを送信します。クライアントは、ランダムな48バイトのpremaster_secretを生成TEKを使用してそれを暗号化し、その結果を送信します。
struct {
opaque y_c<0..128>;
opaque r_c[128];
opaque y_signature[40];
opaque wrapped_client_write_key[12];
opaque wrapped_server_write_key[12];
opaque client_write_iv[24];
opaque server_write_iv[24];
opaque master_secret_iv[24];
block-ciphered opaque encrypted_pre_master_secret[48];
} FortezzaKeys;
y_signature: y_signature is the signature of the KEA public key, signed with the client's DSS private key.
y_signature：y_signatureは、クライアントのDSS秘密鍵で署名KEA公開鍵の署名です。
y_c: The client's Yc value (public key) for the KEA calculation. If the client has sent a certificate, and its KEA public key is suitable, this value must be empty since the certificate already contains this value. If the client sent a certificate without a suitable public key, y_c is used and y_signature is the KEA public key signed with the client's DSS private key. For this value to be used, it must be between 64 and 128 bytes.
y_c：KEA計算のためのクライアントのYcの値（公開鍵）。クライアントが証明書を送信した、とそのKEA公開鍵が適している場合は、証明書がすでにこの値が含まれているため、この値は空でなければなりません。クライアントは、適切な公開鍵なしで証明書を送信した場合、y_c使用とy_signatureは、クライアントのDSS秘密鍵で署名KEA公開鍵です。この値を使用するためには、64と128バイトの間でなければなりません。
r_c: The client's Rc value for the KEA calculation.
R_C：KEA計算のためのクライアントのRC値。
wrapped_client_write_key: This is the client's write key, wrapped by the TEK.
wrapped_client_write_key：これはTEKによって包まれ、クライアントの書き込みキー、です。
wrapped_server_write_key: This is the server's write key, wrapped by the TEK.
wrapped_server_write_key：これはTEKによって包まれ、サーバーの書き込みキー、です。
client_write_iv: The IV for the client write key.
client_write_iv：クライアントの書き込みキーのIV。
server_write_iv: The IV for the server write key.
server_write_iv：サーバー・ライト・キーのIV。
master_secret_iv: This is the IV for the TEK used to encrypt the premaster secret.
master_secret_iv：これはTEKのためのIVは、プレマスターの秘密を暗号化するために使用されます。
pre_master_secret: A random value, generated by the client and used to generate the master secret, as specified in Section 6.1. In the above structure, it is encrypted using the TEK.
前_のマスター_秘密：ランダムな値、クライアントによって生成され、第6.1節で指定されるように、マスターシークレットを生成するために使用されます。上記構成では、TEKを使用して暗号化されます。
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.
それはすでにクライアントの証明書に含まれていなかった場合は、この構造はクライアントのディフィー-Hellman公開値（YC）を伝えます。 Ycのために使用される符号化は、列挙型のPublicValueEncodingによって決定されます。
enum { implicit, explicit } PublicValueEncoding;
implicit: If the client certificate already contains the public value, then it is implicit and Yc does not need to be sent again.
暗黙的：クライアント証明書がすでに公開値が含まれている場合、それは暗黙的であると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;
dh_Yc: The client's Diffie-Hellman public value (Yc).
dh_Yc：クライアントのディフィー-Hellman公開値（YC）。
This message is used to provide explicit verification of a client certificate. This message is only sent following any client certificate that has signing capability (i.e., all certificates except those containing fixed Diffie-Hellman parameters).
このメッセージは、クライアント証明書の明示的な検証を提供するために使用されます。このメッセージは、機能のみに署名している任意のクライアント証明書下記送信される（すなわち、それらを含有する固定のDiffie-Hellmanパラメータを除くすべての証明書）。
struct {
Signature signature;
} CertificateVerify;
CertificateVerify.signature.md5_hash
MD5(master_secret + pad_2 +
MD5(handshake_messages + master_secret + pad_1));
Certificate.signature.sha_hash
SHA(master_secret + pad_2 +
SHA(handshake_messages + master_secret + pad_1));
pad_1: This is identical to the pad_1 defined in Section 5.2.3.1.
pad_1：これは、セクション5.2.3.1で定義されたpad_1と同じです。
pad_2: This is identical to the pad_2 defined in Section 5.2.3.1.
pad_2：これは、セクション5.2.3.1で定義されたpad_2と同じです。
Here, handshake_messages refers to all handshake messages starting at client hello up to but not including this message.
ここでは、握手は、このメッセージを含むハローまでではなく、クライアントから始まるすべての握手メッセージを指します。
A finished message is always sent immediately after a change cipher spec message to verify that the key exchange and authentication processes were successful. The finished message is the first protected with the just-negotiated algorithms, keys, and secrets. No acknowledgment of the finished message is required; parties may begin sending encrypted data immediately after sending the finished message. Recipients of finished messages must verify that the contents are correct.
完成したメッセージは、常に鍵交換と認証プロセスが成功したことを確認するために、変更暗号仕様メッセージの直後に送信されます。完成したメッセージはただ交渉アルゴリズム、鍵、および秘密で保護最初です。完成したメッセージの確認応答は必要ありません。当事者は、完成したメッセージを送信した直後に暗号化されたデータの送信を開始することができます。完成したメッセージの受信者は、内容が正しいことを確認する必要があります。
enum { client(0x434C4E54), server(0x53525652) } Sender;
struct {
opaque md5_hash[16];
opaque sha_hash[20];
} Finished;
md5_hash: MD5(master_secret + pad2 + MD5(handshake_messages + Sender + master_secret + pad1));
md5_hash：MD5（マスター_ + PAD2 + MD5（握手+センダ+マスター_ + PAD1））。
sha_hash: SHA(master_secret + pad2 + SHA(handshake_messages + Sender + master_secret + pad1));
sha_hash：SHA（マスター_ + PAD2 + SHA（握手+センダ+マスター_ + PAD1））。
handshake_messages: All of the data from all handshake messages up to but not including this message. This is only data visible at the handshake layer and does not include record layer headers.
握手：このメッセージを含むすべてのハンドシェイクメッセージまでではなく、データのすべて。これは、ハンドシェイク層における可視データのみであり、記録層ヘッダを含んでいません。
It is a fatal error if a finished message is not preceeded by a change cipher spec message at the appropriate point in the handshake.
完成したメッセージが握手で適切なポイントでChangeCipherSpecメッセージに先行されていない場合は、致命的なエラーです。
The hash contained in finished messages sent by the server incorporate Sender.server; those sent by the client incorporate Sender.client. The value handshake_messages includes all handshake messages starting at client hello up to but not including this finished message. This may be different from handshake_messages in Section 5.6.8 because it would include the certificate verify message (if sent).
サーバー組み込むSender.serverによって送信され、完成したメッセージに含まれるハッシュ。クライアントによって送信されるものにはSender.clientを組み込みます。値の握手は、この完成メッセージを含むハローまでではなく、クライアントから始まるすべての握手メッセージを含んでいます。 （送信された場合）は、証明書検証メッセージを含むことになるので、これは、セクション5.6.8に握手異なっていてもよいです。
Note: Change cipher spec messages are not handshake messages and are not included in the hash computations.
注意：メッセージはハンドシェイクされていない暗号仕様メッセージを変更し、ハッシュ計算に含まれていません。
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.
アプリケーションデータメッセージが記録層によって運ばれ、断片化され、圧縮され、現在の接続状態に基づいて暗号化されています。メッセージは、記録層への透過的なデータとして扱われます。
The key exchange, authentication, encryption, and MAC algorithms are determined by the cipher_suite selected by the server and revealed in the server hello message.
鍵交換、認証、暗号化、およびMACアルゴリズムがサーバハローメッセージ内のサーバによって選択されたと明らかにした暗号_スイートによって決定されます。
The asymmetric algorithms are used in the handshake protocol to authenticate parties and to generate shared keys and secrets.
非対称アルゴリズムは、当事者を認証し、共有鍵と秘密を生成するために、ハンドシェイクプロトコルで使用されています。
For Diffie-Hellman, RSA, and FORTEZZA, 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.
ディフィー - ヘルマン、RSA、およびFORTEZZAのために、同じアルゴリズムがマスター_前_のマスター_秘密に変換するために使用されます。 master_secretが計算されると、pre_master_secretはメモリから削除されなければなりません。
master_secret =
MD5(pre_master_secret + SHA('A' + pre_master_secret +
ClientHello.random + ServerHello.random)) +
MD5(pre_master_secret + SHA('BB' + pre_master_secret +
ClientHello.random + ServerHello.random)) +
MD5(pre_master_secret + SHA('CCC' + pre_master_secret +
ClientHello.random + ServerHello.random));
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-バイトのpre_master_secretは、クライアントによって生成されたサーバの公開鍵で暗号化し、サーバーに送信されます。サーバーは、前_のマスター_秘密を解読するためにその秘密鍵を使用しています。両当事者は、その後、上記のような方法でmaster_secretに前_のマスター_秘密に変換します。
RSA digital signatures are performed using PKCS #1 [PKCS1] block type 1. RSA public key encryption is performed using PKCS #1 block type 2.
RSAデジタル署名は、PKCS＃1を使用して行われる[PKCS1ブロックタイプ1 RSA公開鍵暗号は、PKCS＃1ブロックタイプ2を使用して実行されます。
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.
従来のDiffie-Hellman計算が行われます。ネゴシエートされたキー（Z）は、前_のマスター_秘密として使用され、上記指定されるように、マスター_に変換されます。
Note: Diffie-Hellman parameters are specified by the server, and may be either ephemeral or contained within the server's certificate.
注意：のDiffie-Hellmanパラメータは、サーバによって指定され、一時的またはサーバーの証明書に含まれるのいずれであってもよいです。
A random 48-byte pre_master_secret is sent encrypted under the TEK and its IV. The server decrypts the pre_master_secret and converts it into a master_secret, as specified above. Bulk cipher keys and IVs for encryption are generated by the client's token and exchanged in the key exchange message; the master_secret is only used for MAC computations.
ランダムな48バイトのpre_master_secretはTEKとそのIVの下で暗号化されて送信されます。サーバは、前_のマスター_秘密を解読し、上記指定されるように、マスター_に変換します。バルク暗号鍵と暗号化のためのIVは、クライアントのトークンによって生成され、鍵交換メッセージで交換されています。 、マスター_はMACの計算に使用されています。
The technique used to encrypt and verify the integrity of SSL records is specified by the currently active CipherSpec. A typical example would be to encrypt data using DES and generate authentication codes using MD5. The encryption and MAC algorithms are set to SSL_NULL_WITH_NULL_NULL at the beginning of the SSL handshake protocol, indicating that no message authentication or encryption is performed. The handshake protocol is used to negotiate a more secure CipherSpec and to generate cryptographic keys.
暗号化SSLレコードの整合性を検証するために使用される技術は、現在アクティブなCipherSpecによって指定されます。典型的な例は、DESを使用してデータを暗号化し、MD5を使用して認証コードを生成することであろう。暗号化およびMACアルゴリズムには、メッセージ認証または暗号化が行われないことを示す、SSLハンドシェイクプロトコルの開始時SSL_NULL_WITH_NULL_NULLに設定されています。ハンドシェークプロトコルは、より安全のCipherSpecをネゴシエートし、暗号鍵を生成するために使用されます。
Before secure encryption or integrity verification can be performed on records, the client and server need to generate shared secret information known only to themselves. This value is a 48-byte quantity called the master secret. The master secret is used to generate keys and secrets for encryption and MAC computations. Some algorithms, such as FORTEZZA, may have their own procedure for generating encryption keys (the master secret is used only for MAC computations in FORTEZZA).
安全な暗号化または整合性の検証は、レコード上で実行する前に、クライアントとサーバは、自分自身だけに知られている共有秘密情報を生成する必要があります。この値は、マスターシークレットと呼ばれる48バイトの量です。マスターシークレットは、暗号化とMACの計算のための鍵と秘密を生成するために使用されます。このようFORTEZZAなどのいくつかのアルゴリズムは、暗号化キー（マスターシークレットはFORTEZZAにのみMACの計算に使用されている）を生成するための、独自の手順を有することができます。
The master secret is hashed into a sequence of secure bytes, which are assigned to the MAC secrets, keys, and non-export IVs required by the current CipherSpec (see Appendix A.7). CipherSpecs require a client write MAC secret, a server write MAC secret, a client write key, a server write key, a client write IV, and a server write IV, which are generated from the master secret in that order. Unused values, such as FORTEZZA keys communicated in the KeyExchange message, are empty. The following inputs are available to the key definition process:
マスターシークレットは、現在のCipherSpecで必要とされるMACシークレット、キー、および非輸出のIV（付録A.7を参照）に割り当てられている安全なバイトのシーケンスにハッシュされます。 CipherSpecは、クライアントが、サーバが、クライアントの書き込みキー、サーバーの書き込みキー、クライアントの書き込みIV、及びそのために、マスターシークレットから生成されているサーバーの書き込みIVを、MACの秘密を書き、MACの秘密を書く必要があります。そのようなKeyExchangeメッセージで通信FORTEZZAキーとして使用されていない値は、空です。以下の入力はキー定義プロセスに使用できます。
opaque MasterSecret[48]
ClientHello.random
ServerHello.random
When generating keys and MAC secrets, the master secret is used as an entropy source, and the random values provide unencrypted salt material and IVs for exportable ciphers.
鍵とMACシークレットを生成する際に、マスターシークレットは、エントロピー源として使用され、ランダムな値をエクスポート暗号のための暗号化されていない塩材料及びIVを提供します。
To generate the key material, compute
キーマテリアルを生成するには、計算
key_block =
MD5(master_secret + SHA(`A' + master_secret +
ServerHello.random +
ClientHello.random)) +
MD5(master_secret + SHA(`BB' + master_secret +
ServerHello.random +
ClientHello.random)) +
MD5(master_secret + SHA(`CCC' + master_secret +
ServerHello.random +
ClientHello.random)) + [...];
until enough output has been generated. Then, the key_block is partitioned as follows.
まで十分な出力が生成されています。その後、次のようになkey_blockが仕切られています。
client_write_MAC_secret[CipherSpec.hash_size]
server_write_MAC_secret[CipherSpec.hash_size]
client_write_key[CipherSpec.key_material]
server_write_key[CipherSpec.key_material]
client_write_IV[CipherSpec.IV_size] /* non-export ciphers */
server_write_IV[CipherSpec.IV_size] /* non-export ciphers */
Any extra key_block material is discarded.
余分なkey_block材料が破棄されます。
Exportable encryption algorithms (for which CipherSpec.is_exportable is true) require additional processing as follows to derive their final write keys:
輸出可能な暗号化アルゴリズム（CipherSpec.is_exportableが真である）以下のように最終的な書き込み鍵を導出するために追加の処理が必要です。
final_client_write_key = MD5(client_write_key +
ClientHello.random +
ServerHello.random);
final_server_write_key = MD5(server_write_key +
ServerHello.random +
ClientHello.random);
Exportable encryption algorithms derive their IVs from the random messages:
輸出可能な暗号化アルゴリズムは、ランダムなメッセージから自分のIVを導き出します：
client_write_IV = MD5(ClientHello.random + ServerHello.random);
server_write_IV = MD5(ServerHello.random + ClientHello.random);
MD5 outputs are trimmed to the appropriate size by discarding the least-significant bytes.
MD5の出力は、最下位バイトを破棄することにより、適切なサイズにトリミングされています。
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for each of the two encryption keys and 16 bytes for each of the MAC keys, for a total of 42 bytes of key material. MD5 produces 16 bytes of output per call, so three calls to MD5 are required. The MD5 outputs are concatenated into a 48-byte key_block with the first MD5 call providing bytes zero through 15, the second providing bytes 16 through 31, etc. The key_block is partitioned, and the write keys are salted because this is an exportable encryption algorithm.
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5は、鍵材料の42バイトの合計で、2つの暗号化鍵とMAC鍵のそれぞれについて16バイトのそれぞれのための5つのランダムバイトを必要とします。 MD5は、コール当たりの出力の16バイトなので、必要とされているMD5への3つの呼び出しを生成します。 MD5の出力は、第MD5コールがなkey_blockが区画されている等、第31を通してバイト16を提供する、15を介してバイトゼロを提供して48バイトなkey_blockに連結され、これはエクスポート暗号化アルゴリズムであるため、ライトキーは塩漬けされ。
client_write_MAC_secret = key_block[0..15]
server_write_MAC_secret = key_block[16..31]
client_write_key = key_block[32..36]
server_write_key = key_block[37..41]
final_client_write_key = MD5(client_write_key +
ClientHello.random +
ServerHello.random)[0..15];
final_server_write_key = MD5(server_write_key +
ServerHello.random +
ClientHello.random)[0..15];
client_write_IV = MD5(ClientHello.random +
ServerHello.random)[0..7];
server_write_IV = MD5(ServerHello.random +
ClientHello.random)[0..7];
See Appendix F.
付録F.を参照してください。
[DH1] Diffie, W. and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory V. IT-22, n. 6, pp. 74-84, June 1977.
[DH1]ディフィー、W.とM.ヘルマン、 "暗号に関する新"、情報理論V. IT-22、nは上のIEEEトランザクション。 6頁74-84、1977年6月。
[SSL-2] Hickman, K., "The SSL Protocol", February 1995.
[SSL-2]ヒックマン、K.、 "SSLプロトコル"、1995年2月。
[3DES] Tuchman, W., "Hellman Presents No Shortcut Solutions To DES", IEEE Spectrum, v. 16, n. 7, pp 40-41, July 1979.
[3DES] Tuchman、W.、 "ヘルマンはDESへの近道のソリューションを提示していない"、IEEEスペクトラム、V。16、N。 7頁40-41、1979年7月。
[DES] ANSI X3.106, "American National Standard for Information Systems-Data Link Encryption", American National Standards Institute, 1983.
[DES] ANSI X3.106、「情報のためのアメリカ国立標準システム、データリンク暗号化」、米国規格協会、1983。
[DSS] NIST FIPS PUB 186, "Digital Signature Standard", National Institute of Standards and Technology U.S. Department of Commerce, May 1994.
[DSS] NIST FIPS PUB 186、「デジタル署名標準」、国立標準研究所コマースの技術、米国部門、1994年5月。
[FOR] NSA X22, "FORTEZZA: Application Implementers Guide", Document # PD4002103-1.01, April 1995.
NSA X22、 "FORTEZZA：アプリケーション実装者ガイド" [FOR]、ドキュメント＃PD4002103-1.01、1995年4月。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC0959]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル"、STD 9、RFC 959、1985年10月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC1945]バーナーズ=リー、T.、フィールディング、R.、およびH.ニールセン、 "ハイパーテキスト転送プロトコル - HTTP / 1.0"、RFC 1945、1996年5月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[RFC0854]ポステル、J.、およびJ.レイノルズ、 "テルネットプロトコル仕様"、STD 8、RFC 854、1983年5月。
[RFC1832] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
[RFC1832]スリニバサン、R.、 "XDR：外部データ表現標準"、RFC 1832、1995年8月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[IDEA] Lai, X., "On the Design and Security of Block Ciphers", ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.
[IDEA] "デザインオンとブロック暗号のセキュリティ" ライ、X.、情報処理におけるETHシリーズ、V 1、コンスタンツ：。アルトゥング-Gorre Verlag社、1992。
[PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard version 1.5", November 1993.
[PKCS1] RSA Laboratories社、 "PKCS＃1：RSA暗号化規格バージョン1.5"、1993年11月。
[PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax Standard version 1.5", November 1993.
[PKCS6] RSA Laboratories社、 "PKCS＃6：RSA証明書構文規格バージョン1.5拡張"、1993年11月に。
[PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax Standard version 1.5", November 1993.
[PKCS7] RSA Laboratories社、 "PKCS＃7：RSA暗号メッセージ構文規格バージョン1.5"、1993年11月。
[RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM v. 21, n. 2 pp. 120-126., February 1978.
[RSA]リベスト、R.、シャミル、A.、およびL.エーデルマン、 "デジタル署名と公開鍵暗号を得るための方法"、ACM V。21、n個の通信。 2頁120-126。、1978年2月。
[SCH] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and Source Code in C", John Wiley & Sons, 1994.
[SCH]シュナイアー、B.、 "応用暗号：Cにおけるプロトコル、アルゴリズム、およびソースコード"、ジョン・ウィリー＆サンズ、1994。
[SHA] NIST FIPS PUB 180-1, "Secure Hash Standard", May 1994.
[SHA] NIST FIPS PUB 180-1の、 "セキュアハッシュ標準"、1994年月。
National Institute of Standards and Technology, U.S.
Department of Commerce, DRAFT
[X509] CCITT, "The Directory - Authentication Framework", Recommendation X.509 , 1988.
[X509] CCITT、 "ディレクトリ - 認証フレームワーク"、勧告X.509、1988。
[RSADSI] RSA Data Security, Inc., "Unpublished works".
[RSADSI] RSA Data Security社、 "未発表作品"。
Appendix A. Protocol Constant Values
付録A.プロトコル定数値
This section describes protocol types and constants.
このセクションでは、プロトコルの種類と定数について説明します。
A.1. Record Layer
A.1。レコード層
struct {
uint8 major, minor;
} ProtocolVersion;
ProtocolVersion version = { 3,0 };
protocolVersionバージョン= {3,0}。
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[SSLPlaintext.length];
} SSLPlaintext;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[SSLCompressed.length];
} SSLCompressed;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
} fragment;
} SSLCiphertext;
stream-ciphered struct {
opaque content[SSLCompressed.length];
opaque MAC[CipherSpec.hash_size];
} GenericStreamCipher;
block-ciphered struct {
opaque content[SSLCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
A.2. Change Cipher Specs Message
A.2。変更暗号仕様メッセージ
struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
A.3. Alert Messages
A.3。警告メッセージ
enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decompression_failure(30),
handshake_failure(40),
no_certificate(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter (47),
(255)
} AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
A.4. Handshake Protocol
A.4。ハンドシェイクプロトコル
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_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_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
} Handshake;
A.4.1. Hello Messages
A.4.1。 helloメッセージ
struct { } HelloRequest;
struct {
uint32 gmt_unix_time;
opaque random_bytes[28];
} Random;
opaque SessionID<0..32>;
不透明なセッションID <0 32>。
uint8 CipherSuite[2];
UINT8のCipherSuite [2]。
enum { null(0), (255) } CompressionMethod;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<0..2^16-1>;
CompressionMethod compression_methods<0..2^8-1>;
} ClientHello;
ClientHello}。
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
} ServerHello;
A.4.2. Server Authentication and Key Exchange Messages
A.4.2。サーバー認証と鍵交換のメッセージ
opaque ASN.1Cert<2^24-1>;
不透明ASN.1Cert <2 ^ 24-1>;
struct {
ASN.1Cert certificate_list<1..2^24-1>;
} Certificate;
enum { rsa, diffie_hellman, fortezza_kea } KeyExchangeAlgorithm;
struct {
opaque RSA_modulus<1..2^16-1>;
opaque RSA_exponent<1..2^16-1>;
} ServerRSAParams;
struct {
opaque DH_p<1..2^16-1>;
opaque DH_g<1..2^16-1>;
opaque DH_Ys<1..2^16-1>;
} ServerDHParams;
struct {
opaque r_s [128]
} ServerFortezzaParams
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params;
case fortezza_kea:
ServerFortezzaParams params;
};
} ServerKeyExchange;
enum { anonymous, rsa, dsa } SignatureAlgorithm;
digitally-signed struct {
select(SignatureAlgorithm) {
case anonymous: struct { };
case rsa:
opaque md5_hash[16];
opaque sha_hash[20];
case dsa:
opaque sha_hash[20];
};
} Signature;
enum {
RSA_sign(1), DSS_sign(2), RSA_fixed_DH(3),
DSS_fixed_DH(4), RSA_ephemeral_DH(5), DSS_ephemeral_DH(6),
FORTEZZA_MISSI(20), (255)
} CertificateType;
opaque DistinguishedName<1..2^16-1>;
不透明な識別名<1..2 ^ 16-1>;
struct {
CertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<3..2^16-1>;
} CertificateRequest;
struct { } ServerHelloDone;
A.5. Client Authentication and Key Exchange Messages
A.5。クライアント認証と鍵交換のメッセージ
struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: DiffieHellmanClientPublicValue;
case fortezza_kea: FortezzaKeys;
} exchange_keys;
} ClientKeyExchange;
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret;
struct {
public-key-encrypted PreMasterSecret pre_master_secret;
} EncryptedPreMasterSecret;
struct {
opaque y_c<0..128>;
opaque r_c[128];
opaque y_signature[40];
opaque wrapped_client_write_key[12];
opaque wrapped_server_write_key[12];
opaque client_write_iv[24];
opaque server_write_iv[24];
opaque master_secret_iv[24];
opaque encrypted_preMasterSecret[48];
} FortezzaKeys;
enum { implicit, explicit } PublicValueEncoding;
struct {
select (PublicValueEncoding) {
case implicit: struct {};
case explicit: opaque DH_Yc<1..2^16-1>;
} dh_public;
} ClientDiffieHellmanPublic;
struct {
Signature signature;
} CertificateVerify;
A.5.1. Handshake Finalization Message
A.5.1。握手ファイナライズのメッセージ
struct {
opaque md5_hash[16];
opaque sha_hash[20];
} Finished;
A.6. The CipherSuite
A.6。 CipherSuite
The following values define the CipherSuite codes used in the client hello and server hello messages.
次の値は、クライアントハローとサーバのhelloメッセージに使用されるのCipherSuiteコードを定義します。
A CipherSuite defines a cipher specifications supported in SSL version 3.0.
CipherSuiteは、SSLバージョン3.0でサポートされる暗号仕様を定義します。
CipherSuite SSL_NULL_WITH_NULL_NULL = { 0x00,0x00 };
CipherSuite SSL_NULL_WITH_NULL_NULL = {0x00,0x00}。
The following CipherSuite definitions require that the server provide an RSA certificate that can be used for key exchange. The server may request either an RSA or a DSS signature-capable certificate in the certificate request message.
以下のCipherSuite定義は、サーバーが鍵交換のために使用することができるRSA証明書を提供する必要があります。サーバは、RSAまたは証明書要求メッセージにおけるDSS署名可能な証明書のいずれかを要求することができます。
CipherSuite SSL_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
CipherSuite SSL_RSA_WITH_NULL_SHA = { 0x00,0x02 };
CipherSuite SSL_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 };
CipherSuite SSL_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
CipherSuite SSL_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
CipherSuite SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };
CipherSuite SSL_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
CipherSuite SSL_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };
CipherSuite SSL_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };
CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
The following CipherSuite definitions are used for server-authenticated (and optionally client-authenticated) Diffie-Hellman. DH denotes cipher suites in which the server's certificate contains the Diffie-Hellman parameters signed by the certificate authority (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman parameters are signed by a DSS or RSA certificate, which has been signed by the CA. The signing algorithm used is specified after the DH or DHE parameter. In all cases, the client must have the same type of certificate, and must use the Diffie-Hellman parameters chosen by the server.
以下のCipherSuite定義は、サーバ認証（および必要に応じてクライアント認証）のDiffie-Hellmanのために使用されます。 DHは、サーバーの証明書は、認証局（CA）によって署名のDiffie-Hellmanパラメータが含まれている暗号スイートを示しています。 DHEはのDiffie-Hellmanパラメータは、CAによって署名されたDSSまたはRSA証明書によって署名され短命ディフィー - ヘルマンを示し使用署名アルゴリズムは、DHまたはDHEパラメータの後に指定されています。すべての場合において、クライアントは、証明書の同じ型を持つ必要があり、サーバによって選ばれたのDiffie-Hellmanパラメータを使用する必要があります。
CipherSuite SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B };
CipherSuite SSL_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C };
CipherSuite SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
CipherSuite SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E };
CipherSuite SSL_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F };
CipherSuite SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
CipherSuite SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
CipherSuite SSL_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 };
CipherSuite SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
CipherSuite SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
CipherSuite SSL_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };
CipherSuite SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
The following cipher suites are used for completely anonymous Diffie-Hellman communications in which neither party is authenticated. Note that this mode is vulnerable to man-in-the-middle attacks and is therefore strongly discouraged.
次の暗号スイートは、いずれの当事者が認証されている完全に匿名のDiffie-Hellman通信に使用されています。このモードでは、man-in-the-middle攻撃に対して脆弱であるため、強く推奨されていることに注意してください。
CipherSuite SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
CipherSuite SSL_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
CipherSuite SSL_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
CipherSuite SSL_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
The final cipher suites are for the FORTEZZA token.
最後の暗号スイートは、FORTEZZAトークンのためのものです。
CipherSuite SSL_FORTEZZA_KEA_WITH_NULL_SHA = { 0X00,0X1C };
CipherSuite SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA = { 0x00,0x1D };
CipherSuite SSL_FORTEZZA_KEA_WITH_RC4_128_SHA = { 0x00,0x1E };
Note: All cipher suites whose first byte is 0xFF are considered private and can be used for defining local/experimental algorithms. Interoperability of such types is a local matter.
注：その最初のバイト0xFFであるすべての暗号スイートは、プライベートとみなされ、ローカル/実験的アルゴリズムを定義するために使用することができます。このようなタイプの相互運用性は、ローカルの問題です。
A.7. The CipherSpec
A.7。 CipherSpec
A cipher suite identifies a CipherSpec. These structures are part of the SSL session state. The CipherSpec includes:
暗号スイートはCipherSpecのを識別します。これらの構造は、SSLセッション状態の一部です。 CipherSpecが含まれています：
enum { stream, block } CipherType;
enum { true, false } IsExportable;
enum { null, rc4, rc2, des, 3des, des40, fortezza }
BulkCipherAlgorithm;
enum { null, md5, sha } MACAlgorithm;
struct {
BulkCipherAlgorithm bulk_cipher_algorithm;
MACAlgorithm mac_algorithm;
CipherType cipher_type;
IsExportable is_exportable
uint8 hash_size;
uint8 key_material;
uint8 IV_size;
} CipherSpec;
Appendix B. Glossary
付録B.用語集
application protocol: An application protocol is a protocol that normally layers directly on top of the transport layer (e.g., TCP/IP [RFC0793]/[RFC0791]). Examples include HTTP [RFC1945], TELNET [RFC0959], FTP [RFC0854], and SMTP.
アプリケーションプロトコル：アプリケーションプロトコルを直接、トランスポート層（例えば、TCP / IP [RFC0793] / [RFC0791]）の上にその通常層プロトコルです。例としては、HTTP [RFC1945]、TELNET [RFC0959]、FTP [RFC0854]、およびSMTPを含みます。
asymmetric cipher: See public key cryptography.
非対称暗号：公開鍵暗号を参照してください。
authentication: Authentication is the ability of one entity to determine the identity of another entity.
認証：認証は別のエンティティの同一性を決定する一つのエンティティの能力です。
block cipher: A block cipher is an algorithm that operates on plaintext in groups of bits, called blocks. 64 bits is a typical block size.
ブロック暗号：ブロック暗号は、ブロックと呼ばれる、ビットのグループに平文で動作するアルゴリズムです。 64ビットは、典型的なブロックサイズです。
bulk cipher: A symmetric encryption algorithm used to encrypt large quantities of data.
バルク暗号：大量のデータを暗号化するのに使用される対称暗号化アルゴリズム。
cipher block chaining (CBC) mode: CBC is a mode in which every plaintext block encrypted with the block cipher is first exclusive-ORed with the previous ciphertext block (or, in the case of the first block, with the initialization vector).
暗号ブロック連鎖（CBC）モード：CBCは、（初期化ベクトルを用いて、または、最初のブロックの場合）ブロック暗号で暗号化されたすべての平文ブロックは、前の暗号文ブロックと第一の排他的論理和するモードです。
certificate: As part of the X.509 protocol (a.k.a. ISO Authentication framework), certificates are assigned by a trusted certificate authority and provide verification of a party's identity and may also supply its public key.
証明書：X.509プロトコル（別称、ISO認証フレームワーク）の一環として、証明書が信頼できる認証局によって割り当てられ、党のアイデンティティの検証を提供し、また、その公開鍵を供給することができます。
client: The application entity that initiates a connection to a server.
クライアント：サーバーへの接続を開始するアプリケーションエンティティ。
client write key: The key used to encrypt data written by the client.
クライアントの書き込みキー：クライアントによって書き込まれたデータを暗号化するために使用されるキー。
client write MAC secret: The secret data used to authenticate data written by the client.
クライアントの書き込みMACの秘密：クライアントによって書き込まれたデータを認証するために使用される秘密のデータ。
connection: A connection is a transport (in the OSI layering model definition) that provides a suitable type of service. For SSL, such connections are peer-to-peer relationships. The connections are transient. Every connection is associated with one session.
接続：接続（OSI階層化モデルの定義で）輸送され、サービスの適切なタイプを提供します。 SSLの場合は、そのような接続は、ピア・ツー・ピア関係です。接続が一時的なものです。すべての接続は、1つのセッションに関連付けられています。
Data Encryption Standard (DES): DES is a very widely used symmetric encryption algorithm. DES is a block cipher [DES] [3DES].
データ暗号化規格（DES）：DESは非常に広く使われている対称暗号化アルゴリズムです。 DESはブロック暗号[DES] [3DES]です。
Digital Signature Standard: (DSS) A standard for digital signing, including the Digital Signature Algorithm, approved by the National Institute of Standards and Technology, defined in NIST FIPS PUB 186, "Digital Signature Standard," published May, 1994 by the U.S. Dept. of Commerce.
デジタル署名標準（DSS）NIST FIPSのPUB 186で定義された米国国立標準技術研究所によって承認されたデジタル署名アルゴリズム、を含むデジタル署名のための標準的な、「デジタル署名標準、」米国部門が月、1994年に公開コマースの。
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.
デジタル署名：デジタル署名を認証することができるデータの署名を生成するために公開鍵暗号と一方向ハッシュ関数を利用して、偽造又は否認することは困難です。
FORTEZZA: A PCMCIA card that provides both encryption and digital signing.
FORTEZZA：暗号化とデジタル署名の両方を提供してPCMCIAカード。
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.
初期化ベクトル（IV）：ブロック暗号がCBCモードで使用される場合、初期化ベクトルは、暗号化の前に最初の平文ブロックとの排他的論理和です。
IDEA: A 64-bit block cipher designed by Xuejia Lai and James Massey [IDEA].
IDEA：ズージア・レイとジェームス・マッセイ[IDEA]によって設計された64ビットのブロック暗号。
Message Authentication Code (MAC): A Message Authentication Code is a one-way hash computed from a message and some secret data. Its purpose is to detect if the message has been altered.
メッセージ認証コード（MAC）メッセージ認証コードメッセージおよび何らかの秘密データから計算された一方向ハッシュです。その目的は、メッセージが変更されたかどうかを検出することです。
master secret: Secure secret data used for generating encryption keys, MAC secrets, and IVs.
マスターシークレット：暗号化キー、MACシークレット、IVを生成するために使用される秘密データを保護します。
MD5: MD5 [RFC1321] is a secure hashing function that converts an arbitrarily long data stream into a digest of fixed size.
MD5：MD5 [RFC1321]は、固定サイズのダイジェストに任意の長さのデータストリームを変換するセキュアハッシュ関数です。
public key cryptography: A class of cryptographic techniques employing two-key ciphers. Messages encrypted with the public key can only be decrypted with the associated private key. Conversely, messages signed with the private key can be verified with the public key.
公開鍵暗号：2個の鍵を使用する暗号技術のクラス。公開鍵で暗号化されたメッセージにのみ関連する秘密鍵で復号化することができます。逆に、秘密鍵で署名されたメッセージは、公開鍵で検証することができます。
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.
一方向ハッシュ関数：固定長のハッシュへのデータの任意の量を変換する一方向変換。変換を逆にするか、衝突を発見するのは困難です。 MD5とSHAは、一方向ハッシュ関数の例です。
RC2, RC4: Proprietary bulk ciphers from RSA Data Security, Inc. (There is no good reference to these as they are unpublished works; however, see [RSADSI]). RC2 is a block cipher and RC4 is a stream cipher.
RC2は、RC4：RSA Data Security社から独自のバルク暗号（彼らは未発表作品です、これらには良いの参照はありませんが、[RSADSI]を参照します）。 RC2はブロック暗号であるとRC4はストリーム暗号です。
RSA: A very widely used public key algorithm that can be used for either encryption or digital signing.
RSA：暗号化、デジタル署名のどちらにも使用することができ非常に広く使用されている公開鍵アルゴリズム。
salt: Non-secret random data used to make export encryption keys resist precomputation attacks.
塩：輸出暗号化キーを作成するために使用される非秘密のランダムなデータは事前計算攻撃に抵抗します。
server: The server is the application entity that responds to requests for connections from clients. The server is passive, waiting for requests from clients.
サーバー：サーバーがクライアントからの接続のための要求に応答するアプリケーションエンティティです。サーバは、クライアントからの要求を待って、受動的です。
session: An SSL session is an association between a client and a server. Sessions are created by the handshake protocol. Sessions define a set of cryptographic security parameters, which can be shared among multiple connections. Sessions are used to avoid the expensive negotiation of new security parameters for each connection.
セッション：SSLセッションは、クライアントとサーバの間の関連付けです。セッションはハンドシェイクプロトコルによって作成されます。セッションは、複数の接続の間で共有することができる暗号化セキュリティパラメータのセットを定義します。セッションは、接続ごとに新しいセキュリティパラメータの高価な交渉を回避するために使用されています。
session identifier: A session identifier is a value generated by a server that identifies a particular session.
セッションID：セッション識別子は、特定のセッションを識別するサーバによって生成された値です。
server write key: The key used to encrypt data written by the server.
サーバ・ライト・キー：サーバーによって書き込まれたデータを暗号化するために使用されるキー。
server write MAC secret: The secret data used to authenticate data written by the server.
サーバ書き出しMACの秘密：サーバーによって書き込まれたデータを認証するために使用される秘密のデータ。
SHA: The Secure Hash Algorithm is defined in FIPS PUB 180-1. It produces a 20-byte output [SHA].
SHA：アルゴリズムは、FIPS PUB 180-1の中で定義されているセキュアハッシュ。これは、20バイトの出力[SHA]を生成します。
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.
対称暗号：バルク暗号を参照してください。
Appendix C. CipherSuite Definitions
付録C.のCipherSuite定義
CipherSuite Is Key Cipher Hash Exportable Exchange
CipherSuiteは鍵暗号ハッシュエクスポート可能な交換であります
SSL_NULL_WITH_NULL_NULL * NULL NULL NULL SSL_RSA_WITH_NULL_MD5 * RSA NULL MD5 SSL_RSA_WITH_NULL_SHA * RSA NULL SHA SSL_RSA_EXPORT_WITH_RC4_40_MD5 * RSA_EXPORT RC4_40 MD5 SSL_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 SSL_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 * RSA_EXPORT RC2_CBC_40 MD5 SSL_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA SSL_RSA_EXPORT_WITH_DES40_CBC_SHA * RSA_EXPORT DES40_CBC SHA SSL_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA * DH_DSS_EXPORT DES40_CBC SHA SSL_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA * DH_RSA_EXPORT DES40_CBC SHA SSL_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC SHA SSL_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC SHA SSL_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 * DH_anon_EXPORT RC4_40 MD5 SSL_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA DH_anon DES40_CBC SHA SSL_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA SSL_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA SSL_FORTEZZA_KEA_WITH_NULL_SHA FORTEZZA_KEA NULL SHA SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA FORTEZZA_KEA FORTEZZA_CBC SHA SSL_FORTEZZA_KEA_WITH_RC4_128_SHA FORTEZZA_KEA RC4_128 SHA
SSL_NULL_WITH_NULL_NULL * NULL NULL NULL SSL_RSA_WITH_NULL_MD5 * RSA NULL MD5 SSL_RSA_WITH_NULL_SHA * RSA NULL SHA SSL_RSA_EXPORT_WITH_RC4_40_MD5 * RSA_EXPORT RC4_40 MD5 SSL_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 SSL_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 * RSA_EXPORT RC2_CBC_40 MD5 SSL_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA SSL_RSA_EXPORT_WITH_DES40_CBC_SHA * RSA_EXPORT DES40_CBC SHA SSL_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA * DH_DSS_EXPORT DES40_CBC SHA SSL_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA * DH_RSA_EXPORT DES40_CBC SHA SSL_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC SHA SSL_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC _SHA DHE_DSS 3DES_EDE_CBC SHA SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC SHA SSL_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 * DH_anon_EXPORT RC4_40 MD5 SSL_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA DH_anon DES40_CBC SHA SSL_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA SSL_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA SSL_FORTEZZA_KEA_WITH_NULL_SHA FORTEZZA_KEA NULL SHA SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA FORTEZZA_KEA FORTEZZA_CBC SHA SSL_FORTEZZA_KEA_WITH_RC4_128_SHA FORTEZZA_KEA RC4_128 SHA
+----------------+------------------------------+-------------------+
| Key Exchange | Description | Key Size Limit |
| Algorithm | | |
+----------------+------------------------------+-------------------+
| DHE_DSS | Ephemeral DH with DSS | None |
| | signatures | |
| DHE_DSS_EXPORT | Ephemeral DH with DSS | DH = 512 bits |
| | signatures | |
| DHE_RSA | Ephemeral DH with RSA | None |
| | signatures | |
| DHE_RSA_EXPORT | Ephemeral DH with RSA | DH = 512 bits, |
| | signatures | RSA = none |
| DH_anon | Anonymous DH, no signatures | None |
| DH_anon_EXPORT | Anonymous DH, no signatures | DH = 512 bits |
| DH_DSS | DH with DSS-based | None |
| | certificates | |
| DH_DSS_EXPORT | DH with DSS-based | DH = 512 bits |
| | certificates | |
| DH_RSA | DH with RSA-based | None |
| | certificates | |
| DH_RSA_EXPORT | DH with RSA-based | DH = 512 bits, |
| | certificates | RSA = none |
| FORTEZZA_KEA | FORTEZZA KEA. Details | N/A |
| | unpublished | |
| NULL | No key exchange | N/A |
| RSA | RSA key exchange | None |
| RSA_EXPORT | RSA key exchange | RSA = 512 bits |
+----------------+------------------------------+-------------------+
Table 1
表1
Key size limit: The key size limit gives the size of the largest public key that can be legally used for encryption in cipher suites that are exportable.
キーサイズ制限：キーサイズ制限が法的にエクスポートされている暗号スイートに暗号化のために使用することができる最大の公開鍵のサイズを与えます。
+--------------+--------+-----+-------+-------+-------+------+------+
| Cipher | Cipher | IsE | Key | Exp. | Effec | IV | Bloc |
| | Type | xpo | Mater | Key | tive | Size | k |
| | | rta | ial | Mater | Key | | Size |
| | | ble | | ial | Bits | | |
+--------------+--------+-----+-------+-------+-------+------+------+
| NULL | Stream | * | 0 | 0 | 0 | 0 | N/A |
| FORTEZZA_CBC | Block | | NA | 12 | 96 | 20 | 8 |
| | | | (**) | (**) | (**) | (**) | |
| IDEA_CBC | Block | | 16 | 16 | 128 | 8 | 8 |
| RC2_CBC_40 | Block | * | 5 | 16 | 40 | 8 | 8 |
| RC4_40 | Stream | * | 5 | 16 | 40 | 0 | N/A |
| RC4_128 | Stream | | 16 | 16 | 128 | 0 | N/A |
| DES40_CBC | Block | * | 5 | 8 | 40 | 8 | 8 |
| DES_CBC | Block | | 8 | 8 | 56 | 8 | 8 |
| 3DES_EDE_CBC | Block | | 24 | 24 | 168 | 8 | 8 |
+--------------+--------+-----+-------+-------+-------+------+------+
* Indicates IsExportable is true.
** FORTEZZA uses its own key and IV generation algorithms.
Table 2
表2
Key Material: The number of bytes from the key_block that are used for generating the write keys.
主な材質：ライト・キーを生成するために使用されているなkey_blockからのバイト数。
Expanded Key Material: The number of bytes actually fed into the encryption algorithm.
拡大鍵素材：実際の暗号化アルゴリズムに供給されたバイト数。
Effective Key Bits: How much entropy material is in the key material being fed into the encryption routines.
ビットの有効鍵：エントロピー材料は暗号化ルーチンに供給されるキーマテリアルであるどのくらいの。
+---------------+-----------+--------------+
| Hash Function | Hash Size | Padding Size |
+---------------+-----------+--------------+
| NULL | 0 | 0 |
| MD5 | 16 | 48 |
| SHA | 20 | 40 |
+---------------+-----------+--------------+
Table 3
表3
Appendix D. Implementation Notes
付録D.実装ノート
The SSL protocol cannot prevent many common security mistakes. This section provides several recommendations to assist implementers.
SSLプロトコルは、多くの一般的なセキュリティ上のミスを防ぐことはできません。このセクションでは、実装を支援するために、いくつかの提言を提供します。
D.1. Temporary RSA Keys
D.1。一時的RSA鍵
US export restrictions limit RSA keys used for encryption to 512 bits, but do not place any limit on lengths of RSA keys used for signing operations. Certificates often need to be larger than 512 bits, since 512-bit RSA keys are not secure enough for high-value transactions or for applications requiring long-term security. Some certificates are also designated signing-only, in which case they cannot be used for key exchange.
米国の輸出規制は、512ビットに暗号化に使用されるRSA鍵を制限しますが、署名の操作に使用されるRSA鍵の長さは上の任意の制限を置かないでください。 512ビットのRSA鍵は、高価値のトランザクションまたは長期的なセキュリティを必要とするアプリケーションのために十分に確保されないので、証明書は、多くの場合、512ビットよりも大きくする必要があります。いくつかの証明書はまた、彼らは鍵交換に使用することはできません、その場合には、署名のみ指定されています。
When the public key in the certificate cannot be used for encryption, the server signs a temporary RSA key, which is then exchanged. In exportable applications, the temporary RSA key should be the maximum allowable length (i.e., 512 bits). Because 512-bit RSA keys are relatively insecure, they should be changed often. For typical electronic commerce applications, it is suggested that keys be changed daily or every 500 transactions, and more often if possible. Note that while it is acceptable to use the same temporary key for multiple transactions, it must be signed each time it is used.
証明書の公開鍵は、暗号化に使用することができない場合は、サーバーは、交換され、一時的RSA鍵を、署名します。エクスポート用途において、一時的RSA鍵は、最大許容長（すなわち、512ビット）であるべきです。 512ビットのRSA鍵は比較的安全ではないので、彼らはしばしば変更する必要があります。典型的な電子商取引アプリケーションでは、可能な場合は、キーをより頻繁に、毎日変更またはすべての500件の取引、およびすることが示唆されます。それは複数のトランザクションのために同じ一時的鍵を使用することが許容されている間、それが使用されるたびに署名しなければならないことに留意されたいです。
RSA key generation is a time-consuming process. In many cases, a low-priority process can be assigned the task of key generation. Whenever a new key is completed, the existing temporary key can be replaced with the new one.
RSAキーの生成は時間のかかるプロセスです。多くの場合、優先度の低いプロセスは、鍵生成のタスクを割り当てることができます。新しいキーが完了するたびに、既存の一時鍵は新しいものと交換することができます。
D.2. Random Number Generation and Seeding
D.2。乱数生成と播種
SSL requires a cryptographically secure pseudorandom number generator (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs based on secure hash operations, most notably MD5 and/or SHA, are acceptable, but cannot provide more security than the size of the random number generator state. (For example, MD5-based PRNGs usually provide 128 bits of state.)
SSLは暗号論的擬似乱数生成器（PRNG）が必要です。ケアのPRNGの設計と播種に注意する必要があります。セキュアハッシュ操作に基づいのPRNG、最も顕著にはMD5および/またはSHAは、許容可能であるが、乱数発生器の状態のサイズよりも多くのセキュリティを提供することができません。 （例えば、MD5ベースのPRNGは、通常状態の128ビットを提供します。）
To estimate the amount of seed material being produced, add the number of bits of unpredictable information in each seed byte. For example, keystroke timing values taken from a PC-compatible's 18.2 Hz timer provide 1 or 2 secure bits each, even though the total size of the counter value is 16 bits or more. To seed a 128-bit PRNG, one would thus require approximately 100 such timer values.
生産されたシード材料の量を推定するために、各シードバイトの予測不可能な情報のビット数を追加します。例えば、PC互換の18.2 Hzのタイマーから採取したキーストロークタイミング値は、カウンタ値の合計サイズが16ビット以上であっても、1つの又は2の安全なビットそれぞれを提供します。 128ビットのPRNGをシードするためには、このようにして、約100そのようなタイマ値を必要とするであろう。
Note: The seeding functions in RSAREF and versions of BSAFE prior to 3.0 are order independent. For example, if 1000 seed bits are supplied, one at a time, in 1000 separate calls to the seed function, the PRNG will end up in a state that depends only on the number of 0 or 1 seed bits in the seed data (i.e., there are 1001 possible final states). Applications using BSAFE or RSAREF must take extra care to ensure proper seeding.
注：RSAREFとBSAFEのバージョンで播種機能は、前3.0ために独立しています。 1000個のシードビットが供給される場合、例えば、一度に1つずつは、シード関数1000回の別々の呼び出しで、PRNGは、シード・データに0又は1種ビットの数（すなわち、に依存する状態になってしまいます、1001の可能な最終状態）があります。 BSAFEまたはRSAREFを使用するアプリケーションは、適切な播種を保証するために、余分な世話をする必要があります。
D.3. Certificates and Authentication
D.3。証明書と認証
Implementations are responsible for verifying the integrity of certificates and should generally support certificate revocation messages. Certificates should always be verified to ensure proper signing by a trusted certificate authority (CA). The selection and addition of trusted CAs should be done very carefully. Users should be able to view information about the certificate and root CA.
実装は、証明書の有効性について検証する責任があり、一般的に証明書失効メッセージをサポートする必要があります。証明書は常に信頼できる認証局（CA）によって適切な署名を確認するために検証する必要があります。信頼できるCAの選択や追加は非常に慎重に行われるべきです。ユーザーは、証明書とルートCAの情報を閲覧することができるはずです
D.4. CipherSuites
D.4。 CipherSuites
SSL supports a range of key sizes and security levels, including some that provide no or minimal security. A proper implementation will probably not support many cipher suites. For example, 40-bit encryption is easily broken, so implementations requiring strong security should not allow 40-bit keys. Similarly, anonymous Diffie-Hellman is strongly discouraged because it cannot prevent man-in-the-middle attacks. Applications should also enforce minimum and maximum key sizes. For example, certificate chains containing 512-bit RSA keys or signatures are not appropriate for high-security applications.
SSLはないか、最小限のセキュリティを提供することも含め、キーのサイズとセキュリティレベルの範囲をサポートしています。適切な実装は、おそらく多くの暗号スイートをサポートしていません。強力なセキュリティを必要とする実装が40ビットのキーを許可してはならないので、例えば、40ビットの暗号化を容易に破壊されます。それはman-in-the-middle攻撃を防ぐことができないので、同様に、匿名のDiffie-Hellmanは強くお勧めします。また、アプリケーションは、最小と最大のキーサイズを強制する必要があります。例えば、512ビットのRSAキーまたは署名を含む証明書チェーンは、高セキュリティアプリケーションに適していません。
D.5. FORTEZZA
D.5。 FORTRESS
This section describes implementation details for cipher suites that make use of the FORTEZZA hardware encryption system.
このセクションでは、FORTEZZAハードウェア暗号化システムを利用する暗号スイートのための実装の詳細を説明します。
D.5.1. Notes on Use of FORTEZZA Hardware
D.5.1。 FORTEZZAハードウェアの使用上のご注意
A complete explanation of all issues regarding the use of FORTEZZA hardware is outside the scope of this document. However, there are a few special requirements of SSL that deserve mention.
FORTEZZAハードウェアの使用に関するすべての問題の完全な説明は、この文書の範囲外です。しかし、言及に値するSSLのいくつかの特別な要件があります。
Because SSL is a full duplex protocol, two crypto states must be maintained, one for reading and one for writing. There are also a number of circumstances that can result in the crypto state in the FORTEZZA card being lost. For these reasons, it's recommended that the current crypto state be saved after processing a record, and loaded before processing the next.
SSLは、全二重プロトコルであるため、2つの暗号の状態は、読み取り用と書き込みのための1つを維持しなければなりません。失われFORTEZZAカードでの暗号化状態になることが多くの状況もあります。これらの理由から、現在の暗号状態がレコードを処理した後に保存され、次の処理をする前にロードされることをお勧めします。
After the client generates the TEK, it also generates two message encryption keys (MEKs), one for reading and one for writing. After generating each of these keys, the client must generate a corresponding IV and then save the crypto state. The client also uses the TEK to generate an IV and encrypt the premaster secret. All three IVs are sent to the server, along with the wrapped keys and the encrypted premaster secret in the client key exchange message. At this point, the TEK is no longer needed, and may be discarded.
クライアントがTEKを生成した後、それはまた、2つのメッセージの暗号化キー（のMEK）、読み取り用と書き込みのための1つを生成します。これらの各キーを生成した後、クライアントは、対応するIVを生成し、暗号状態を保存する必要があります。また、クライアントはIVを生成し、プリマスターシークレットを暗号化するためにTEKを使用しています。すべての3つのIVは、クライアント鍵交換メッセージに包まれたキーと暗号化されたプレマスターの秘密とともに、サーバに送信されます。この時点で、TEKは不要になり、かつ、廃棄することができます。
On the server side, the server uses the master IV and the TEK to decrypt the premaster secret. It also loads the wrapped MEKs into the card. The server loads both IVs to verify that the IVs match the keys. However, since the card is unable to encrypt after loading an IV, the server must generate a new IV for the server write key. This IV is discarded.
サーバー側では、サーバは、プリマスターシークレットを解読するために、マスターIVおよびTEKを使用しています。また、カードの中に包まれたMEKをロードします。サーバーの負荷の両方のIVは、IVをキーと一致していることを確認します。カードはIVをロードした後に暗号化することができないので、サーバは、サーバ・ライト・キーのための新たなIVを生成する必要があります。このIVは破棄されます。
When encrypting the first encrypted record (and only that record), the server adds 8 bytes of random data to the beginning of the fragment. These 8 bytes are discarded by the client after decryption. The purpose of this is to synchronize the state on the client and server resulting from the different IVs.
第1の暗号化レコード（およびそのレコードだけを）暗号化する場合、サーバーは、フラグメントの先頭にランダムな8バイトのデータを追加します。これらの8つのバイトは、復号化した後、クライアントによって破棄されています。この目的は、さまざまなIVの結果、クライアントとサーバー上の状態を同期させることです。
D.5.2. FORTEZZA Cipher Suites
D.5.2。 FORTEZZA暗号スイート
5) FORTEZZA_NULL_WITH_NULL_SHA: Uses the full FORTEZZA key exchange, including sending server and client write keys and IVs.
5）FORTEZZA_NULL_WITH_NULL_SHA：サーバとクライアントのライトキーとIVを送信するなど、完全なFORTEZZA鍵交換を使用しています。
D.5.3. FORTEZZA Session Resumption
D.5.3。 FORTEZZAセッション再開
There are two possibilities for FORTEZZA session restart: 1) Never restart a FORTEZZA session. 2) Restart a session with the previously negotiated keys and IVs.
1）FORTEZZAセッションを再起動しません：FORTEZZAセッションの再起動には2つの可能性があります。 2）以前にネゴシエートされたキーおよびIVを有するセッションを再起動します。
Never restarting a FORTEZZA session:
FORTEZZAセッションを再開することはありません。
Clients who never restart FORTEZZA sessions should never send session IDs that were previously used in a FORTEZZA session as part of the ClientHello. Servers who never restart FORTEZZA sessions should never send a previous session id on the ServerHello if the negotiated session is FORTEZZA.
FORTEZZAセッションを再起動したことがないクライアントは、以前のClientHelloの一部としてFORTEZZAセッションで使用されたセッションIDを送信することはありません。交渉されたセッションがFORTEZZAある場合FORTEZZAセッションを再起動することはありませんサーバはServerHelloメッセージに、以前のセッションIDを送信することはありません。
Restart a session:
セッションを再起動します。
You cannot restart FORTEZZA on a session that has never done a complete FORTEZZA key exchange (that is, you cannot restart FORTEZZA if the session was an RSA/RC4 session renegotiated for FORTEZZA). If you wish to restart a FORTEZZA session, you must save the MEKs and
あなたは完全なFORTEZZA鍵交換を（つまり、セッションはFORTEZZAのために再交渉RSA / RC4セッションだった場合は、FORTEZZAを再起動することはできません）行われたことのないセッションでFORTEZZAを再起動することはできません。あなたはFORTEZZAセッションを再起動したい場合は、のMEKを保存する必要がありますし、
IVs from the initial key exchange for this session and reuse them for any new connections on that session. This is not recommended, but it is possible.
このセッションの最初の鍵交換からのIVおよびそのセッション上の任意の新しい接続のためにそれらを再利用します。これは推奨されませんが、それは可能です。
Appendix E. Version 2.0 Backward Compatibility
付録E.バージョン2.0の下位互換
Version 3.0 clients that support version 2.0 servers must send version 2.0 client hello messages [SSL-2]. Version 3.0 servers should accept either client hello format. The only deviations from the version 2.0 specification are the ability to specify a version with a value of three and the support for more ciphering types in the CipherSpec.
バージョン2.0のサーバーをサポートバージョン3.0のクライアントは、バージョン2.0クライアントのhelloメッセージ[SSL-2]を送信する必要があります。バージョン3.0のサーバーは、クライアントのhello形式のいずれかを受け入れる必要があります。バージョン2.0仕様からのみ偏差が3の値とのCipherSpecにおいてより暗号化タイプをサポートするバージョンを指定する機能です。
Warning: The ability to send version 2.0 client hello messages will be phased out with all due haste. Implementers should make every effort to move forward as quickly as possible. Version 3.0 provides better mechanisms for transitioning to newer versions.
警告：helloメッセージをバージョン2.0クライアントを送信する機能は、すべての原因急いで段階的に廃止されます。実装者は可能な限り迅速に前進するためにあらゆる努力をするべきです。バージョン3.0は、新しいバージョンに移行するための優れたメカニズムを提供します。
The following cipher specifications are carryovers from SSL version 2.0. These are assumed to use RSA for key exchange and authentication.
以下の暗号仕様は、SSLバージョン2.0から引き継がれたものです。これらは、鍵交換と認証にRSAを使用することを想定しています。
V2CipherSpec SSL_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 };
V2CipherSpec SSL_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
V2CipherSpec SSL_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };
V2CipherSpec SSL_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
= { 0x04,0x00,0x80 };
V2CipherSpec SSL_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };
V2CipherSpec SSL_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };
V2CipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
Cipher specifications introduced in version 3.0 can be included in version 2.0 client hello messages using the syntax below. Any V2CipherSpec element with its first byte equal to zero will be ignored by version 2.0 servers. Clients sending any of the above V2CipherSpecs should also include the version 3.0 equivalent (see Appendix A.6):
バージョン3.0で導入された暗号仕様は、以下の構文を使用して、バージョン2.0クライアントのhelloメッセージに含めることができます。ゼロに等しく、その最初のバイトを有する任意V2CipherSpec要素は、バージョン2.0のサーバによって無視されます。上記V2CipherSpecsのいずれかを送信するクライアントは、バージョン3.0当量（付録A.6を参照）を含める必要があります。
V2CipherSpec (see Version 3.0 name) = { 0x00, CipherSuite };
V2CipherSpec（バージョン3.0名前を参照）= {0x00で、のCipherSuite}。
E.1. Version 2 Client Hello
E.1。バージョン2クライアントこんにちは
The version 2.0 client hello message is presented below using this document's presentation model. The true definition is still assumed to be the SSL version 2.0 specification.
バージョン2.0クライアントのhelloメッセージは、このドキュメントのプレゼンテーションモデルを用いて以下に提示されます。真の定義は、まだSSLバージョン2.0の仕様を想定しています。
uint8 V2CipherSpec[3];
UINT8 V2CipherSpec [3]。
struct {
unit8 msg_type;
Version version;
uint16 cipher_spec_length;
uint16 session_id_length;
uint16 challenge_length;
V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
opaque session_id[V2ClientHello.session_id_length];
Random challenge;
} V2ClientHello;
session msg_type: This field, in conjunction with the version field, identifies a version 2 client hello message. The value should equal one (1).
セッションMSG_TYPE：このフィールドは、バージョンフィールドと連動して、バージョン2クライアントのhelloメッセージを識別します。値は1（1）に等しくなければなりません。
version: The highest version of the protocol supported by the client (equals ProtocolVersion.version; see Appendix A.1).
バージョン：クライアントでサポートされているプロトコルの最も高いバージョン（はProtocolVersion.versionに等しい。付録A.1を参照してください）。
cipher_spec_length: This field is the total length of the field cipher_specs. It cannot be zero and must be a multiple of the V2CipherSpec length (3).
cipher_spec長さ：このフィールドは、フィールドcipher_specsの長さの合計です。それはゼロにすることはできず、V2暗号スペック長さ（3）の倍数でなければなりません。
session_id_length: This field must have a value of either zero or 16. If zero, the client is creating a new session. If 16, the session_id field will contain the 16 bytes of session identification.
session_id_length：ゼロの場合、このフィールドは、クライアントが新しいセッションを作成して、ゼロまたは16のいずれかの値を持っている必要があります。 16場合は、SESSION_IDフィールドは、セッション識別の16のバイトが含まれています。
challenge_length: The length in bytes of the client's challenge to the server to authenticate itself. This value must be 32.
challenge_length：自分自身を認証するためのクライアントからサーバーへの挑戦のバイト単位の長さ。この値は32でなければなりません。
cipher_specs: This is a list of all CipherSpecs the client is willing and able to use. There must be at least one CipherSpec acceptable to the server.
cipher_specs：これは、クライアントが喜んでと使用することができ、すべてのCipherSpecのリストです。サーバーへの許容可能な少なくとも一つのCipherSpecがなければなりません。
session_id: If this field's length is not zero, it will contain the identification for a session that the client wishes to resume.
SESSION_ID：このフィールドの長さがゼロでない場合は、クライアントが再開することを望んでいること、それはセッションの識別が含まれています。
challenge: The client's challenge to the server for the server to identify itself is a (nearly) arbitrary length random. The version 3.0 server will right justify the challenge data to become the ClientHello.random data (padded with leading zeroes, if necessary), as specified in this version 3.0 protocol. If the length of the challenge is greater than 32 bytes, then only the last 32 bytes are used. It is legitimate (but not necessary) for a V3 server to reject a V2 ClientHello that has fewer than 16 bytes of challenge data.
課題：自分自身を識別するためのサーバのサーバへのクライアントの課題は、ランダム（ほぼ）任意の長さです。バージョン3.0のサーバーは、右のこのバージョン3.0プロトコルで指定され、（必要に応じて、先行ゼロで埋め）のClientHello.randomデータになるためにチャレンジデータを正当化します。チャレンジの長さが32バイトを超える場合は、最後の32のバイトが使用されます。 V3サーバーは、チャレンジデータの16のバイトよりも少ないを持っているV2のClientHelloを拒絶することが（必要ではない）正当なものです。
Note: Requests to resume an SSL 3.0 session should use an SSL 3.0 client hello.
注意：SSL 3.0セッションを再開するためのリクエストは、SSL 3.0のクライアントのhelloを使用する必要があります。
E.2. Avoiding Man-in-the-Middle Version Rollback
E.2。マン・イン・ザ・ミドル・バージョンのロールバックを回避
When SSL version 3.0 clients fall back to version 2.0 compatibility mode, they use special PKCS #1 block formatting. This is done so that version 3.0 servers will reject version 2.0 sessions with version 3.0-capable clients.
SSLバージョン3.0のクライアントは、バージョン2.0互換性モードにフォールバックするとき、彼らは特別なPKCS＃1ブロックフォーマットを使用します。バージョン3.0のサーバーがバージョン3.0対応のクライアントとバージョン2.0セッションを拒絶するように行われます。
When version 3.0 clients are in version 2.0 compatibility mode, they set the right-hand (least-significant) 8 random bytes of the PKCS padding (not including the terminal null of the padding) for the RSA encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY to 0x03 (the other padding bytes are random). After decrypting the ENCRYPTED-KEY-DATA field, servers that support SSL 3.0 should issue an error if these eight padding bytes are 0x03. Version 2.0 servers receiving blocks padded in this manner will proceed normally.
バージョン3.0クライアントは、バージョン2.0互換モードである場合、それらは暗号化-KEY-DATAのRSA暗号化のため（パディングの端子ヌルを含まない）PKCSパディングの（最下位）8ランダムバイト右側を設定しました0×03にCLIENT-MASTER-KEYのフィールド（他のパディングバイトがランダムです）。これら8つのパディングバイトが0x03であればENCRYPTED-KEY-DATAフィールドを復号化した後、SSL 3.0をサポートするサーバーはエラーを発行する必要があります。このように埋められたブロックを受けるバージョン2.0のサーバーが正常に進行します。
Appendix F. Security Analysis
付録F.セキュリティ分析
The SSL 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 SSL has been designed to resist a variety of attacks.
SSLプロトコルは、クライアントと安全でないチャネルを介して通信サーバ間の安全な接続を確立するために設計されています。この文書では、攻撃者が実質的な計算リソースを持っており、プロトコル外部ソースから秘密情報を得ることができないことを含め、いくつかの伝統的な仮定を行います。攻撃者は、キャプチャ、変更、削除、再生、およびそれ以外の通信チャネルを介して送信されたメッセージを改ざんする能力を持っていると想定されています。この付録では、SSLがさまざまな攻撃に耐えるように設計されている方法について説明します。
F.1. Handshake Protocol
F.1。ハンドシェイクプロトコル
The handshake protocol is responsible for selecting a CipherSpec and generating a MasterSecret, which together comprise the primary cryptographic parameters associated with a secure session. The handshake protocol can also optionally authenticate parties who have certificates signed by a trusted certificate authority.
ハンドシェイクプロトコルは、のCipherSpecを選択し、一緒に安全なセッションに関連付けられたプライマリ暗号パラメータを含むMasterSecretを生成する責任があります。ハンドシェイクプロトコルはまた、必要に応じて、信頼できる認証局によって署名された証明書を持って、当事者を認証することができます。
F.1.1. Authentication and Key Exchange
F.1.1。認証と鍵交換
SSL supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. Whenever the server is authenticated, the channel should be secure against man-in-the-middle attacks, but completely anonymous sessions are inherently vulnerable to such attacks.
両当事者の認証、認証されていないクライアントとサーバー認証、および総匿名：SSLは、3つの認証モードをサポートしています。サーバーが認証されるたびに、チャネルは、man-in-the-middle攻撃に対して安全である必要がありますが、完全に匿名のセッションはそのような攻撃にさらされやすいです。
Anonymous servers cannot authenticate clients, since the client signature in the certificate verify message may require a server certificate to bind the signature to a particular server. 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.
証明書でクライアントの署名が特定のサーバに署名をバインドするために、サーバー証明書が必要な場合がありますメッセージを確認するため、匿名のサーバは、クライアントを認証することはできません。サーバーが認証されている場合は、その証明書のメッセージは許容できる認証局につながる有効な証明書チェーンを提供する必要があります。同様に、認証されたクライアントは、サーバーへの許容可能な証明書を提供する必要があります。各当事者は、他の証明書が有効で、期限が切れていないか、取り消されていることを検証する責任があります。
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 6.1). The master_secret is required to generate the finished messages, encryption keys, and MAC secrets (see Sections 5.6.9 and 6.2.2). By sending a correct finished message, parties thus prove that they know the correct pre_master_secret.
鍵交換プロセスの一般的な目標は、通信相手にしていない攻撃者に知られている前_のマスター_秘密を作成することです。前_のマスター_秘密をmaster_secretを生成するのに使用されます（6.1節を参照してください）。でマスター_が完成したメッセージ、暗号化キー、およびMAC秘密を（セクション5.6.9と6.2.2を参照）を生成するために必要とされます。正しいFinishedメッセージを送信することにより、関係者は、このように、彼らは正しい前_のマスター_秘密を知っていることを証明します。
F.1.1.1. Anonymous Key Exchange
F.1.1.1。匿名の鍵交換
Completely anonymous sessions can be established using RSA, Diffie-Hellman, or FORTEZZA for key exchange. With anonymous RSA, the client encrypts a pre_master_secret with the server's uncertified public key extracted from the server key exchange message. The result is sent in a client key exchange message. Since eavesdroppers do not know the server's private key, it will be infeasible for them to decode the pre_master_secret.
完全に匿名のセッションは、鍵交換のためにRSA、ディフィー・ヘルマン、またはFORTEZZAを使用して確立することができます。匿名RSAでは、クライアントは、サーバ鍵交換メッセージから抽出されたサーバーの未認定公開鍵で前_のマスター_秘密を暗号化します。結果は、クライアント鍵交換メッセージで送信されます。盗聴者は、サーバの秘密鍵を知らないので、彼らはpre_master_secretを復号することは実行不可能になります。
With Diffie-Hellman or FORTEZZA, the server's public parameters are contained in the server key exchange message and the client's are sent in the client key exchange message. Eavesdroppers who do not know the private values should not be able to find the Diffie-Hellman result (i.e., the pre_master_secret) or the FORTEZZA token encryption key (TEK).
ディフィー・ヘルマンまたはFORTEZZAを使用すると、サーバーの公開パラメータは、サーバ鍵交換メッセージに含まれており、クライアントのは、クライアント鍵交換メッセージで送信されます。民間の値を知らない盗聴者は、Diffie-Hellman結果（すなわち、前_のマスター_秘密）またはFORTEZZAトークン暗号化キー（TEK）を見つけることができないようにする必要があり。
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.
警告：完全に匿名接続のみ受動的盗聴に対する保護を提供します。独立した改ざん防止チャンネルが完成し、メッセージが攻撃者に取り替えられなかったことを確認するために使用されていない限り、サーバー認証がアクティブman-in-the-middle攻撃が懸念されている環境で必要とされます。
F.1.1.2. RSA Key Exchange and Authentication
F.1.1.2。 RSA鍵交換と認証
With RSA, key exchange and server authentication are combined. The public key either may be contained in the server's certificate or may be a temporary RSA key sent in a server key exchange message. When temporary RSA keys are used, they are signed by the server's RSA or DSS certificate. The signature includes the current
RSAでは、鍵交換およびサーバー認証が組み合わされています。公開鍵は、いずれかのサーバーの証明書に含まれていてもよいか、サーバ鍵交換メッセージで送信された一時的RSA鍵かもしれません。一時的RSA鍵が使用される場合、それらはサーバのRSAまたはDSS証明書によって署名されています。署名は、現在を含みます
ClientHello.random, so old signatures and temporary keys cannot be replayed. Servers may use a single temporary RSA key for multiple negotiation sessions.
ClientHello.randomと、とても古い署名や一時的なキーが再生することはできません。サーバは、複数の交渉セッションのための単一の一時的RSA鍵を使用することができます。
Note: The temporary RSA key option is useful if servers need large certificates but must comply with government-imposed size limits on keys used for key exchange.
注意：サーバが大規模な証明書が必要ですが、鍵交換のために使用されるキーに関する政府・サイズ制限を遵守しなければならない場合は、一時的なRSAキーオプションが便利です。
After verifying the server's certificate, the client encrypts a pre_master_secret with the server's public key. By successfully decoding the pre_master_secret and producing a correct finished message, the server demonstrates that it knows the private key corresponding to the server certificate.
サーバーの証明書を検証した後、クライアントは、サーバの公開鍵で前_のマスター_秘密を暗号化します。首尾よく前_のマスター_秘密を解読し、正しいFinishedメッセージを出すことによって、サーバは、サーバ証明書に対応する秘密鍵を知っていることを示しています。
When RSA is used for key exchange, clients are authenticated using the certificate verify message (see Section 5.6.8). The client signs a value derived from the master_secret and all preceding handshake messages. These handshake messages include the server certificate, which binds the signature to the server, and ServerHello.random, which binds the signature to the current handshake process.
RSAは、鍵交換に使用されている場合、クライアントは証明書（セクション5.6.8を参照）のメッセージを確認するを使用して認証されます。クライアントは、マスター_と先行するすべてのハンドシェイクメッセージから得られた値に署名します。これらのハンドシェイクメッセージは、現在のハンドシェイクプロセスへの署名をバインドするサーバーサーバーへの署名を結合した証明書、およびServerHello.randomが含まれます。
F.1.1.3. Diffie-Hellman Key Exchange with Authentication
F.1.1.3。認証を使ってDiffie-Hellman鍵交換
When Diffie-Hellman key exchange is used, the server either can supply a certificate containing fixed Diffie-Hellman parameters or can use the server key exchange message to send a set of temporary Diffie-Hellman parameters signed with a DSS or RSA certificate. Temporary parameters are hashed with the hello.random values before signing to ensure that attackers do not replay old parameters. In either case, the client can verify the certificate or signature to ensure that the parameters belong to the server.
Diffie-Hellman鍵交換を使用した場合、サーバは、固定のDiffie-Hellmanパラメータを含む証明書を供給することができ、またはDSSまたはRSA証明書で署名された一時的なディフィー - ヘルマンパラメータのセットを送信するためにサーバ鍵交換メッセージを使用しますか。一時的なパラメータは、攻撃者が古いパラメータを再生していないことを保証するために署名する前のhello.random値でハッシュ化されています。いずれの場合も、クライアントは、パラメータがサーバーに属していることを確認するために証明書または署名を検証することができます。
If the client has a certificate containing fixed Diffie-Hellman parameters, its certificate contains the information required to complete the key exchange. Note that in this case, the client and server will generate the same Diffie-Hellman result (i.e., pre_master_secret) every time they communicate. To prevent the pre_master_secret from staying in memory any longer than necessary, it should be converted into the master_secret as soon as possible. Client Diffie-Hellman parameters must be compatible with those supplied by the server for the key exchange to work.
クライアントが固定Diffie-Hellmanパラメータを含む証明書を持っている場合は、その証明書は、鍵交換を完了するために必要な情報が含まれています。この場合、クライアントとサーバが同一のDiffie-Hellman結果（すなわち、前_のマスター_秘密）は、それらが通信するたびに発生することに注意してください。もはや必要以上にメモリに滞在から前_のマスター_秘密を防止するためには、できるだけ早くmaster_secretへ変換する必要があります。クライアントのDiffie-Hellmanパラメータは、鍵交換を行うために、サーバによって提供されたものと互換性がなければなりません。
If the client has a standard DSS or RSA certificate or is unauthenticated, it sends a set of temporary parameters to the server in the client key exchange message, then optionally uses a certificate verify message to authenticate itself.
クライアントが標準DSSまたはRSA証明書を持っているか、認証されていない場合には、それはクライアント鍵交換メッセージでサーバーに一時的なパラメータのセットを送信し、その後、必要に応じて自分自身を認証するためのメッセージを確認し、証明書を使用しています。
F.1.1.4. FORTEZZA
F.1.1.4。 FORTRESS
FORTEZZA's design is classified, but at the protocol level it is similar to Diffie-Hellman with fixed public values contained in certificates. The result of the key exchange process is the token encryption key (TEK), which is used to wrap data encryption keys, client write key, server write key, and master secret encryption key. The data encryption keys are not derived from the pre_master_secret because unwrapped keys are not accessible outside the token. The encrypted pre_master_secret is sent to the server in a client key exchange message.
FORTEZZAのデザインは分類しますが、プロトコルレベルでそれが証明書に含まれる固定公開値とのDiffie-Hellmanのに似ていています。鍵交換プロセスの結果は、データ暗号化キー、クライアントの書き込みキー、サーバーの書き込みキー、およびマスター秘密の暗号化キーをラップするために使用されるトークンの暗号化キー（TEK）、です。開封されたキーは、トークンの外にアクセスできないため、データの暗号化キーは、前_のマスター_秘密に由来していません。暗号化されたpre_master_secretは、クライアント鍵交換メッセージでサーバーに送信されます。
F.1.2. Version Rollback Attacks
F.1.2。バージョンロールバック攻撃
Because SSL version 3.0 includes substantial improvements over SSL version 2.0, attackers may try to make version 3.0-capable clients and servers fall back to version 2.0. This attack is occurring if (and only if) two version 3.0-capable parties use an SSL 2.0 handshake.
SSLバージョン3.0は、SSLバージョン2.0以上のかなりの改良を含んでいるため、攻撃者は、バージョン3.0対応のクライアントとサーバがバージョン2.0に戻すようにさせるかもしれません。 2バージョン3.0対応の当事者はSSL 2.0ハンドシェイクを使用（および場合のみ）場合は、この攻撃が発生しています。
Although the solution using non-random PKCS #1 block type 2 message padding is inelegant, it provides a reasonably secure way for version 3.0 servers to detect the attack. This solution is not secure against attackers who can brute force the key and substitute a new ENCRYPTED-KEY-DATA message containing the same key (but with normal padding) before the application specified wait threshold has expired. Parties concerned about attacks of this scale should not be using 40- bit encryption keys anyway. Altering the padding of the least significant 8 bytes of the PKCS padding does not impact security, since this is essentially equivalent to increasing the input block size by 8 bytes.
非ランダムPKCS＃1ブロックタイプ2メッセージパディングを使用して溶液を洗練であるが、それは攻撃を検出するために、バージョン3.0サーバを合理的に安全な方法を提供します。このソリューションでは、キーをブルートフォースし、アプリケーション指定の待機しきい値が経過する前に同じキーを（ただし、通常のパディングを持つ）を含む新しいENCRYPTED-KEY-DATAメッセージを置き換えることができ、攻撃者に対して安全ではありません。この規模の攻撃を懸念締約国はとにかく40-ビットの暗号化キーを使用するべきではありません。これは8バイトの入力ブロックサイズを大きくすると本質的に同等であるので、PKCSパディングの最下位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. Because many implementations will support 40-bit exportable encryption and some may even support null encryption or MAC algorithms, this attack is of particular concern.
攻撃者は、当事者が、彼らは通常、選ぶだろうとは異なる暗号化アルゴリズムを選択するためにハンドシェイク交換に影響を与えることを試みるかもしれません。多くの実装は、40ビットのエクスポート暗号化をサポートし、いくつかのもヌル暗号化やMACアルゴリズムをサポートする可能性があるので、この攻撃は特に懸念されます。
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 other's finished messages. Without the master_secret, the attacker cannot repair the finished messages, so the attack will be discovered.
この攻撃では、攻撃者が積極的に一つ以上のハンドシェイクメッセージを変更する必要があります。この問題が発生した場合、クライアントとサーバーはハンドシェイクメッセージのハッシュに異なる値を計算します。その結果、当事者は互いの完成のメッセージを受け付けません。攻撃が検出されますので、マスター_がなければ、攻撃者は、完成したメッセージを修復することはできません。
F.1.4. Resuming Sessions
F.1.4。セッションを再開
When a connection is established by resuming a session, new ClientHello.random and ServerHello.random values are hashed with the session's master_secret. Provided that the master_secret has not been compromised and that the secure hash operations used to produce the encryption keys and MAC secrets are secure, the connection should be secure and effectively independent from previous connections. Attackers cannot use known encryption keys or MAC secrets to compromise the master_secret without breaking the secure hash operations (which use both SHA and MD5).
接続がセッションを再開することによって確立されたとき、新しいClientHello.randomととServerHello.random値はセッションのマスター_秘密で論じ尽くされます。マスター_が損なわれていないことと、暗号化鍵とMACシークレットを生成するために使用されるセキュアハッシュ操作が安全であることを条件とする、接続は、以前の接続から安全かつ効果的に独立であるべきです。攻撃者は、（SHAとMD5の両方を使用）、セキュアハッシュ演算を壊すことなくでマスター_を損なうことが知られている暗号化キーまたはMAC秘密を使用することはできません。
Sessions cannot be resumed unless both the client and server agree. If either party suspects that the session may have been compromised, or that certificates may have expired or been revoked, it should force a full handshake. An upper limit of 24 hours is suggested for session ID lifetimes, since an attacker who obtains a master_secret may be able to impersonate the compromised party until the corresponding session ID is retired. Applications that may be run in relatively insecure environments should not write session IDs to stable storage.
クライアントとサーバの両方が同意しない限り、セッションは再開できません。いずれかの当事者が、セッションが侵害された可能性があること、または証明書の期限が切れたか、取り消されていることを疑った場合、それは完全なハンドシェイクを強制する必要があります。対応するセッションIDがリタイアするまでmaster_secretを入手した攻撃者は妥協がパーティを偽装することができる可能性があるため、24時間の上限は、セッションIDの寿命のために提案されます。比較的安全でない環境で実行されるアプリケーションは、安定したストレージにセッションIDを書くべきではありません。
F.1.5. MD5 and SHA
F.1.5。 MD5とSHA
SSL uses hash functions very conservatively. Where possible, both MD5 and SHA are used in tandem to ensure that non-catastrophic flaws in one algorithm will not break the overall protocol.
SSLは、非常に保守的ハッシュ関数を使用しています。可能であれば、MD5とSHAの両方を1つのアルゴリズムにおける非致命的な欠陥が、全体的なプロトコルを壊さないようにするためにタンデムで使用されています。
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. FORTEZZA encryption keys are generated by the token, and are not derived from the master_secret.
でマスター_は、接続ごとに固有のデータ暗号化鍵とMACシークレットを生成するためのClientHello.randomとServerHello.randomでハッシュされます。 FORTEZZA暗号化キーは、トークンによって生成され、そして、マスター_由来ではありません。
Outgoing data is protected with a MAC before transmission. To prevent message replay or modification attacks, the MAC is computed from the MAC secret, the sequence number, the message length, the message contents, and two fixed-character strings. The message type field is necessary to ensure that messages intended for one SSL record layer client are not redirected to another. The sequence number ensures that attempts to delete or reorder messages will be detected. Since sequence numbers are 64 bits long, they should never overflow. Messages from one party cannot be inserted into the other's output, since they use independent MAC secrets. Similarly, the server-write and client-write keys are independent so stream cipher keys are used only once.
送信データが送信される前にMACで保護されています。メッセージの再生または変更攻撃を防ぐために、MACはMACの秘密、シーケンス番号、メッセージ長、メッセージの内容、および2つの固定文字列から計算されます。メッセージタイプフィールドは1つのSSLレコード層クライアント向けのメッセージを別のにリダイレクトされていないことを確認する必要があります。シーケンス番号は、メッセージを削除したり、並べ替えしようとする試みが検出されることを保証します。シーケンス番号は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キーの妥協は、メッセージ変更攻撃を可能にすることができます。 MACのも暗号化されているので、メッセージ改ざん攻撃は、一般的に、暗号化アルゴリズムと同様にMACを破る必要があります。
Note: MAC secrets may be larger than encryption keys, so messages can remain tamper resistant even if encryption keys are broken.
注意：メッセージは暗号化キーが壊れている場合でも、耐タンパ残ることができるようにMACの秘密は、暗号化キーより大きいかもしれません。
F.3. Final Notes
F.3。最終的な注意事項
For SSL 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.
SSLは、安全な接続を提供することができるようにするには、クライアントとサーバシステム、キー、およびアプリケーションの両方が安全でなければなりません。また、実装は、セキュリティエラーがあってはなりません。
The system is only as strong as the weakest key exchange and authentication algorithm supported, and only trustworthy cryptographic functions should be used. Short public keys, 40-bit bulk encryption keys, and anonymous servers should be used with great caution. Implementations and users must be careful when deciding which certificates and certificate authorities are acceptable; a dishonest certificate authority can do tremendous damage.
システムは、最も弱いキー交換および認証アルゴリズムがサポートされる唯一のような強く、唯一信頼できる暗号化機能を使用すべきです。短い公開鍵、40ビットバルク暗号化キー、および匿名のサーバは十分に注意して使用する必要があります。証明書と認証局が許容されるかを決めるとき、実装し、ユーザーが注意しなければなりません。不正認証局は多大なダメージを与えることができます。
Appendix G. Acknowledgements
付録G.謝辞
G.1. Other Contributors
G.1。他の貢献者
Martin Abadi Robert Relyea Digital Equipment Corporation Netscape Communications ma@pa.dec.com relyea@netscape.com
マーティン・アバディロバートRelyeaディジタル・イクイップメント・コーポレーションネットスケープ・コミュニケーションズma@pa.dec.com relyea@netscape.com
Taher Elgamal Jim Roskind Netscape Communications Netscape Communications elgamal@netscape.com jar@netscape.com
タハー・エルガマルジムRoskindネットスケープコミュニケーションズネットスケープ・コミュニケーションズelgamal@netscape.com jar@netscape.com
Anil Gangolli Micheal J. Sabin, Ph.D. Netscape Communications Consulting Engineer gangolli@netscape.com msabin@netcom.com
アニルJ Gangoli micelli。セービン博士ネットスケープkammyunikesansಗಂಗೊಳ್ಳಿ@ನೆಟ್ಸ್ಕೇಪ್.ಕಂでエンジニアコンサルティングಮಸಬೀನ್@ನೆಟಿಕಂ.ಕಂ
Kipp E.B. Hickman Tom Weinstein Netscape Communications Netscape Communications kipp@netscape.com tomw@netscape.com
キップE.B.ヒックマントム・ワインスタインネットスケープコミュニケーションズネットスケープ・コミュニケーションズkipp@netscape.com tomw@netscape.com
G.2. Early Reviewers
G.2。初期のレビュー
Robert Baldwin Clyde Monma RSA Data Security, Inc. Bellcore baldwin@rsa.com clyde@bellcore.com
ロバート・ボールドウィンクライド門馬RSA Data Security社のBellcore baldwin@rsa.com clyde@bellcore.com
George Cox Eric Murray Intel Corporation ericm@lne.com cox@ibeam.jf.intel.com
ジョージコックスエリック・マレーインテルコーポレーションericm@lne.com cox@ibeam.jf.intel.com
Cheri Dowell Avi Rubin Sun Microsystems Bellcore cheri@eng.sun.com rubin@bellcore.com
シェリーダウエルアビ・ルービンSun MicrosystemsのBellcoreのcheri@eng.sun.com rubin@bellcore.com
Stuart Haber Don Stephenson Bellcore Sun Microsystems stuart@bellcore.com don.stephenson@eng.sun.com
スチュアート・ハーバードン・スティーブンソンのBellcore Sun Microsystemsのstuart@bellcore.com don.stephenson@eng.sun.com
Burt Kaliski Joe Tardo RSA Data Security, Inc. General Magic burt@rsa.com tardo@genmagic.com
バート・カリスキージョーTardo RSA Data Security社のゼネラル・マジックburt@rsa.com tardo@genmagic.com
Authors' Addresses
著者のアドレス
Alan O. Freier Netscape Communications
アラン・O.無料ネットスケープ・コミュニケーションズ
Philip Karlton Netscape Communications
フィリップKarltonネットスケープ・コミュニケーションズ
Paul C. Kocher Independent Consultant
ポール・C.コッヘル独立コンサルタント