[要約] RFC 6101は、SSLプロトコルバージョン3.0に関する仕様書であり、セキュアな通信を提供するためのプロトコルの標準化を目的としています。
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
Secure Socketsレイヤー（SSL）プロトコルバージョン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レイヤー（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プロトコルは、広く実装されているプロトコルであり、安全な通信プロトコルの先駆者であり、輸送層のセキュリティ（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.
些細な編集上の変更と「セキュリティ上の考慮事項」セクションの追加以外の元のドキュメントに変更はありませんでした。ただし、適用されなくなった元のドキュメントの一部は含まれていません。「パテントステートメント」セクション、「予約済みポート割り当て」セクション、「The Ciphersuite」セクションのCipher-Suite登録者ノートなど。このドキュメントで議論されている「米国の輸出規則」は、今日は適用されませんが、プロトコル設計で行われた決定のコンテキストを提供するためにそのままに保たれています。「このドキュメントの目標」セクションは、IETFの目標ではなく、SSL 3.0の採用者の目標を示しています。
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.
著者と編集者は、元のドキュメントのように保持されていました。このドキュメントの編集者は、Nikos Mavrogiannopoulos（nikos.mavrogiannopoulos@esat.kuleuven.be）です。編集者は、このドキュメントをレビューし、有益なコメントを提供してくれたDan Harkins、Linda Dunbar、Sean Turner、Geoffrey Keatingに感謝します。
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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つの通信アプリケーション間でプライバシーと信頼性を提供することです。プロトコルは2つのレイヤーで構成されています。最低レベルでは、信頼できる輸送プロトコル（TCP [RFC0793など）の上に階層化されているのは、SSLレコードプロトコルです。SSLレコードプロトコルは、さまざまな高レベルプロトコルのカプセル化に使用されます。そのようなカプセル化されたプロトコルの1つであるSSLハンドシェイクプロトコルにより、サーバーとクライアントは互いに認証され、アプリケーションプロトコルがデータの最初のバイトを送信または受信する前に、暗号化アルゴリズムと暗号化キーを交渉できます。SSLの利点の1つは、アプリケーションプロトコルに依存しないことです。より高いレベルのプロトコルは、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の目標は、優先順位の順に次のとおりです。
1. Cryptographic security
1. 暗号化セキュリティ
SSL should be used to establish a secure connection between two parties.
SSLを使用して、2つの関係者間の安全な接続を確立する必要があります。
2. Interoperability
2. 相互運用性
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.
独立したプログラマーは、SSL 3.0を利用してアプリケーションを開発できるはずで、互いのコードを知らずに暗号化パラメーターを正常に交換できるようになります。
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のすべてのインスタンス（同じアプリケーションドメインであっても）が正常に接続できるということではありません。たとえば、サーバーが特定のハードウェアトークンをサポートし、クライアントがそのようなトークンにアクセスできない場合、接続は成功しません。
3. Extensibility
3. 拡張性
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.
SSLは、必要に応じて新しい公開キーとバルク暗号化方法を組み込むことができるフレームワークを提供しようとしています。これにより、2つのサブゴールも達成されます。新しいプロトコルを作成する必要性（および可能な新しい弱点の導入を危険にさらす）と、新しいセキュリティライブラリ全体を実装する必要性を回避するためです。
4. Relative efficiency
4. 相対効率
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.
暗号化の操作は、CPU集約型、特に公開操作である傾向があります。このため、SSLプロトコルには、ゼロから確立する必要がある接続の数を減らすためのオプションのセッションキャッシュスキームが組み込まれています。さらに、ネットワークアクティビティを減らすために注意が払われています。
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仕様は、主にプロトコルを実装する読者とそれの暗号化分析を行っている読者向けです。スペックはこれを念頭に置いて書かれており、これら2つのグループのニーズを反映することを目的としています。そのため、アルゴリズム依存のデータ構造とルールの多くは、付録ではなくテキストの本文に含まれており、それらに簡単にアクセスできます。
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 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.
このドキュメントでは、外部表現でのデータのフォーマットを扱います。以下の非常に基本的でやや定義されたプレゼンテーション構文が使用されます。構文は、その構造内のいくつかのソースから引き出されます。構文と意図の両方で、その構文と外部データ表現（XDR）[RFC1832]のプログラミング言語「C」に似ていますが、あまりにも多くの類似点を描くのは危険です。このプレゼンテーション言語の目的は、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バイトを占有します。ここで、nはTのサイズの倍数です。ベクトルの長さはエンコードされたストリームに含まれていません。
In the following example, Datum is defined to be three consecutive bytes that the protocol does not interpret, while Data is three consecutive Datum, consuming a total of nine bytes.
次の例では、データムはプロトコルが解釈しない3つの連続したバイトであると定義されていますが、データは3つの連続したデータムであり、合計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>;
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バイトのタイプ不透明を含める必要があるベクトルです。空になることはありません。実際の長さフィールドは、値400を表すのに十分な2バイト、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と呼ばれる追加のスパースデータ型が利用可能です。タイプの列挙のフィールドは、定義で宣言された値のみを想定できます。各定義は異なるタイプです。同じタイプの列挙された列挙のみを割り当てるか比較できます。列挙されたすべての要素には、次の例で示されているように、値を割り当てる必要があります。列挙された要素は順序付けられていないため、任意の順序で一意の値を割り当てることができます。
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.
オプションで、関連するタグなしで値を指定して、余分な要素を定義せずに幅定義を強制することができます。次の例では、Tasteはデータストリームで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
バリアント構造は、タイプの前にセレクターの値を指定することにより、適格（絞り込まれます）。たとえば、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つのハッシュ（1つのSHAと1つの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.
Stream Cipher暗号化では、プレーンテキストは、暗号化されたキードランム番号ジェネレーターから生成された同一の量の出力を備えた排他的なものです。
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ハンドシェイクプロトコルの責任であり、それにより、状態が正確に平行ではないという事実にもかかわらず、それぞれのプロトコル状態マシンが一貫して動作できるようにします。論理的には、状態は現在の動作状態として1回、（握手プロトコル中に）再び保留中の状態として2回表されます。さらに、個別の読み取りおよび書き込み状態が維持されます。クライアントまたはサーバーがChange Cipher Specメッセージを受信すると、保留中の読み取り状態を現在の読み取り状態にコピーします。クライアントまたはサーバーがChange Cipher Specメッセージを送信すると、保留中の書き込み状態を現在の書き込み状態にコピーします。握手交渉が完了すると、クライアントとサーバーの交換が暗号仕様メッセージを変更し（セクション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]ピアの証明書。状態のこの要素はヌルかもしれません。
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.)
暗号仕様：バルクデータ暗号化アルゴリズム（NULL、DESなど）とMACアルゴリズム（MD5やSHAなど）を指定します。また、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.
シーケンス番号：各パーティは、各接続に対して送信されたメッセージと受信メッセージの個別のシーケンス番号を維持します。パーティーがChange Cipher Specメッセージを送信または受信すると、適切なシーケンス番号がゼロに設定されます。シーケンス番号はタイプ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バイト以下のSSLPLINTEXTレコードにブロックされます。クライアントメッセージの境界はレコードレイヤーに保存されていません（つまり、同じContentTypeの複数のクライアントメッセージが単一のsslplintextレコードに合体される場合があります）。
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.
長さ：次のsslplantext.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として定義されます。圧縮アルゴリズムは、SSLPLINTEXT構造をSSLが抑制された構造に変換します。圧縮関数は、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に遭遇する場合、致命的な減圧_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の長さ（バイト単位）。長さは2^14 1024を超えてはなりません。
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操作はID操作です。フィールドは変更されていません（付録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.
握手が完了すると、2つの当事者は、レコードを暗号化し、その内容でキー付きメッセージ認証コード（MAC）を計算するために使用される秘密を共有しました。暗号化とMAC操作の実行に使用される手法は、CiphersPecによって定義され、Cipherspec.cipher_typeによって制約されます。暗号化とMAC関数は、SSLが抑制された構造をSSLCiphertextに変換します。復号化関数はプロセスを逆転させます。トランスミッションには、欠落、変更された、または追加のメッセージが検出可能なシーケンス番号も含まれています。
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の長さ（バイト単位）。長さは2^14 2048を超えない場合があります。
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を参照）は、sslcompressed.fragment structuresをstream sslciphertext.fragment structuresに変換します。
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：キャラクター0x36は、MD5で48回繰り返され、SHAで40回繰り返されました。
pad_2: The character 0x5c repeated 48 times for MD5 or 40 times for SHA.
PAD_2：キャラクター0x5Cは、MD5で48回、SHAで40回繰り返されました。
seq_num: The sequence number for this message.
SEQ_NUM：このメッセージのシーケンス番号。
hash: Hashing algorithm derived from the cipher suite.
ハッシュ：Cipherスイートに由来するハッシュアルゴリズム。
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など）を使用しないストリーム暗号の場合、1つのレコードの最後からのストリーム暗号状態は、後続のパケットで単純に使用されます。ciphersuiteがSSL_NULL_WITH_NULL_NULLの場合、暗号化はID操作で構成されます（つまり、データは暗号化されておらず、MACサイズはMACが使用されないことを意味します）。sslciphertext.lengthはsslcompressed.length plus 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関数は、sslCompressed.fragment構造をブロックsslciphertext.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.
Macは、セクション5.2.3.1で説明されているように生成されます。
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の合計を超えています。
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.
Cipher Specプロトコルの変更は、暗号化戦略における遷移を信号するために存在します。プロトコルは、電流（保留中ではなく）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.
Change cipher Specメッセージは、クライアントとサーバーの両方から送信され、その後の記録がちょうど関連したCipherspecとキーの下で保護されることを受信者に通知します。このメッセージの受信により、受信者は読み取り保留中の状態を読み取り電流状態にコピーします。クライアントは、ハンドシェイクキーエクスチェンジと証明書を確認した後にCipher Specメッセージを変更します。予期しない変更暗号スペックメッセージは、予期しない_Messageアラートを生成するはずです（セクション5.4.2）。前のセッションを再開するとき、Helloメッセージの後にCipher Specメッセージの変更が送信されます。
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レコードレイヤーでサポートされているコンテンツタイプの1つは、アラートタイプです。アラートメッセージは、メッセージの重大度とアラートの説明を伝えます。接続の即時終了時の致命的な結果のレベルのアラートメッセージ。この場合、セッションに対応する他の接続は継続する可能性がありますが、セッション識別子は無効にする必要があり、失敗したセッションが新しい接続を確立するために使用されないようにします。他のメッセージと同様に、アラートメッセージは、現在の接続状態で指定されているように、暗号化および圧縮されます。
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メッセージなしで接続が終了すると、セッションは返信できなくなります。
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 alertを送信する必要があります。相手はclose_notify独自のアラートで応答し、すぐに接続を閉じて、保留中の書き込みを破棄する必要があります。接続の読み取り側を閉じる前に、Closeのイニシエーターが応答する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.
予期しない_message：不適切なメッセージが受信されました。このアラートは常に致命的であり、適切な実装間のコミュニケーションでは決して観察されるべきではありません。
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.
減圧_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.
handshake_failure：handshake_failureの受信アラートメッセージは、送信者が利用可能なオプションを考慮して許容可能なセキュリティパラメーターのセットを交渉できなかったことを示しています。これは致命的なエラーです。
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_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.
cermost_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とServer Helloは、クライアントとサーバー間のセキュリティ強化機能を確立するために使用されます。クライアントのHelloとServer 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メッセージに続いて、サーバーは認証されている場合は証明書を送信します。さらに、必要な場合は、サーバーキー交換メッセージが送信される場合があります（たとえば、サーバーに証明書がない場合、または証明書が署名のみである場合）。サーバーが認証されている場合、選択したCipherスイートに適している場合、クライアントから証明書を要求する場合があります。これで、サーバーはサーバーのhello doneメッセージを送信し、握手のhello-messageフェーズが完了したことを示します。サーバーは、クライアントの応答を待ちます。サーバーが証明書要求メッセージを送信した場合、クライアントは証明書メッセージまたはNO_Certificateアラートのいずれかを送信する必要があります。クライアントキー交換メッセージが送信され、そのメッセージの内容は、クライアントHelloとServer Helloの間で選択された公開キーアルゴリズムに依存します。クライアントが署名機能を備えた証明書を送信した場合、デジタル署名証明書確認メッセージが送信され、証明書を明示的に確認します。
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.)
この時点で、Cipher Specメッセージがクライアントによって送信され、クライアントは保留中のCiphersPecを現在のCiphersPecにコピーします。その後、クライアントはすぐに新しいアルゴリズム、キー、秘密の下で完成したメッセージを送信します。これに応じて、サーバーは独自のCipher Specメッセージを送信し、保留中のCifersPecに保留中の送信を送信し、新しい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が送信されます。この時点で、クライアントとサーバーの両方がChange Cipher Specメッセージを送信し、完成したメッセージに直接進める必要があります。再確立が完了すると、クライアントとサーバーはアプリケーションレイヤーデータを交換し始めることがあります。（以下のフローチャートを参照してください。）セッション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つです。このプロトコルは、セッションの安全な属性をネゴシエートするために使用されます。ハンドシェイクメッセージは、SSLレコードレイヤーに提供され、1つまたは複数のSSLPLINTEXT構造内にカプセル化され、現在のアクティブセッション状態で指定されているように処理および送信されます。
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 Requestメッセージはいつでもサーバーによって送信される場合がありますが、ハンドシェイクプロトコルがすでに進行中である場合、クライアントは無視されます。クライアントが便利なときにクライアントの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.
ハローリクエストを送信した後、サーバーは、その後の握手交渉が完了するまでリクエストを繰り返さないでください。握手交渉状態でハローリクエストを受け取ったクライアントは、単にメッセージを無視する必要があります。
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に送信することもできます。クライアントの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番目のオプションは、クライアントがランダム構造と接続の派生値を更新することを希望する場合に役立ちますが、3番目のオプションにより、完全なハンドシェイクプロトコルを繰り返すことなく、いくつかの同時独立した安全な接続を確立することができます。SessionIDの実際の内容は、サーバーによって定義されます。
opaque SessionID<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リストには、クライアントの好みの順にクライアントがサポートする暗号化アルゴリズムの組み合わせが含まれています（First Choice First）。各ciphersuiteは、キーエクスチェンジアルゴリズムとcipherspecの両方を定義します。サーバーは暗号スイートを選択するか、許容可能な選択肢が表示されない場合は、ハンドシェイク障害アラートを返して接続を閉じます。
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).
client_version：クライアントがこのセッション中に通信したい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。セッション_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フィールドが空でない場合（セッション再開リクエストを暗示しています）、このベクトルは少なくともそのセッションのcipher_suiteを含める必要があります。値は付録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.
Compression_Methods：これは、クライアントの好みでソートされたクライアントがサポートする圧縮方法のリストです。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.
実装注：完成したメッセージが送信される前に、アプリケーションデータを送信できません。送信されたアプリケーションデータは、有効な完了メッセージが受信されるまで不安定であることが知られています。この接続に現在の非ヌル暗号化がある場合、この絶対的な制限は緩和されます。
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.
フォワード互換性メモ：Forward Compatibilityの利益のために、クライアントのHelloメッセージが圧縮方法の後に追加のデータを含めることが許可されています。このデータは握手のハッシュに含める必要がありますが、それ以外の場合は無視する必要があります。
The server processes the client hello message and responds with either a handshake_failure alert or server hello message.
サーバーはクライアントのhelloメッセージを処理し、handshake_failureアラートまたはサーバーのHelloメッセージのいずれかで応答します。
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：このフィールドには、クライアントのクライアントが提案した低いフィールドは、helloとサーバーによってサポートされている最高のものを含みます。このバージョンの仕様では、バージョンは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が空だった場合、サーバーは一致のセッションキャッシュを調べます。一致が見つかり、サーバーが指定されたセッション状態を使用して新しい接続を確立する意思がある場合、サーバーはクライアントが提供したのと同じ値で応答します。これは、再開されたセッションを示し、当事者が完成したメッセージに直接進む必要があることを指示します。それ以外の場合、このフィールドには、新しいセッションを識別する異なる値が含まれます。サーバーは、空のセッション_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.
cipher_suite：clienthello.cipher_suitesのリストからサーバーによって選択された単一の暗号スイート。再開されたセッションの場合、このフィールドは、再開されるセッションの状態からの価値です。
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.
Compression_Method：clienthello.compression_methodsのリストからサーバーによって選択された単一の圧縮アルゴリズム。再開されたセッションの場合、このフィールドは再開されたセッション状態からの値です。
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.
サーバーが認証される場合（通常はそうです）、サーバーはサーバーHelloメッセージの直後に証明書を送信します。証明書の種類は、選択した暗号スイートのキーエクスチェンジアルゴリズムに適している必要があり、通常はX.509.V3証明書（またはFortezza（TM）[for]の場合の修正X.509証明書）です。同じメッセージタイプが、証明書要求メッセージに対するクライアントの応答に使用されます。
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 [PKCS7]は、PKCS＃6 [PKCS6]拡張証明書を使用していないため、証明書ベクトルの形式として使用されません。また、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キーエクスチェンジが使用されます。サーバー証明書にdiffie-hellman [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.
注：現在の米国輸出法によると、512ビットを超えるRSAモジュリは、米国からエクスポートされたソフトウェアの主要な交換には使用できない場合があります。このメッセージを使用すると、より大きな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_MODULUS：サーバーの一時的な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：サーバーのdiffie-hellman public Value（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.
パラメーション：サーバーの重要な交換パラメーター。
signed_params: A hash of the corresponding params value, with the signature appropriate to that hash applied.
signed_params：対応するパラメーション値のハッシュ、そのハッシュに適した署名が適用されます。
md5_hash: MD5(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>;
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_types：このフィールドは、サーバーの好みの順にソートされた要求された証明書の種類のリストです。
certificate_authorities: A list of the distinguished names of acceptable certificate authorities.
certificate_authorities：許容可能な証明書当局の著名な名前のリスト。
Note: DistinguishedName is derived from [X509].
注：distinguishedNameは[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.
サーバーHello Doneメッセージは、サーバーによって送信され、サーバーの端と関連するメッセージの終了を示します。このメッセージを送信した後、サーバーはクライアントの応答を待ちます。
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 doneメッセージは、クライアントが必要に応じて有効な証明書を提供していることをクライアントに確認し、サーバーのハローパラメーターが許容できることを確認する必要があります。
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.
これは、サーバーHello Doneメッセージを受信した後にクライアントが送信できる最初のメッセージです。このメッセージは、サーバーが証明書を要求した場合にのみ送信されます。適切な証明書が利用できない場合、クライアントは代わりに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がキー契約と認証に使用されている場合、クライアントは48バイトのPremaster Secretを生成し、サーバーの証明書またはサーバーキー交換メッセージから一時的なRSAキーから公開キーの下で暗号化し、結果を暗号化されたPrepreasterに送信します秘密のメッセージ。
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.
client_version：クライアントがサポートする最新（最新）バージョン。これは、バージョンロールバック攻撃の検出に使用されます。
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.
pre_master_secret：このランダム値は、クライアントによって生成され、セクション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キーExchangeアルゴリズム（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.
lapped_client_write_key：これは、クライアントの書き込みキーであり、tekに巻き付けられています。
wrapped_server_write_key: This is the server's write key, wrapped by the TEK.
lapped_server_write_key：これは、Tekに包まれたサーバーの書き込みキーです。
client_write_iv: The IV for the client write key.
client_write_iv：クライアントのiv writeキー。
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：これは、Prepreaster Secretを暗号化するために使用される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.
pre_master_secret：セクション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.
この構造は、クライアントの証明書にまだ含まれていない場合、クライアントのdiffie-hellman public Value（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：クライアントのDiffie-Hellman Public Value（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.
ここで、Handshake_Messagesとは、クライアントから始まるすべての握手メッセージを指します。
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.
Change Cipher Specメッセージの直後に完成したメッセージは、常にキー交換と認証プロセスが成功したことを確認するために常に送信されます。完成したメッセージは、ちょうど関連するアルゴリズム、キー、および秘密で最初に保護されたものです。完成したメッセージの承認は必要ありません。パーティーは、完成したメッセージを送信した直後に暗号化されたデータの送信を開始する場合があります。完成したメッセージの受信者は、内容が正しいことを確認する必要があります。
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));
sha_hash: SHA(master_secret + pad2 + SHA(handshake_messages + Sender
+ master_secret + 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.
handshake_messages：すべてのハンドシェイクメッセージのすべてのデータは、このメッセージまでは含まれていません。これは、握手層に見えるデータのみであり、レコードレイヤーヘッダーは含まれていません。
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.
完成したメッセージの前に、握手の適切なポイントでChange cipher仕様メッセージが前に行われない場合、致命的なエラーです。
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を組み込みます。Value Handshake_Messagesには、クライアントから始まるすべてのハンドシェイクメッセージが含まれます。これは、セクション5.6.8のHandshake_Messagesとは異なる場合があります。これは、証明書検証メッセージ（送信された場合）を含むためです。
Note: Change cipher spec messages are not handshake messages and are not included in the hash computations.
注：Cipher Specメッセージの変更は、ハンドシェイクメッセージではなく、ハッシュ計算に含まれていません。
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アルゴリズムは、サーバーによって選択され、サーバーHelloメッセージで明らかにされたCIPHER_SUITEによって決定されます。
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.
Diffie-Hellman、RSA、およびFortezzaの場合、同じアルゴリズムを使用して、pre_master_secretをmaster_secretに変換します。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がクライアントによって生成され、サーバーの公開キーの下で暗号化され、サーバーに送信されます。サーバーは秘密鍵を使用して、pre_master_secretを復号化します。両当事者は、上記で指定したように、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）は、pre_master_secretとして使用され、上記で指定されているようにmaster_secretに変換されます。
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-byte pre_master_secretは、TekとそのIVの下で暗号化されたものです。サーバーは、pre_master_secretを復号化し、上記のようにMaster_secretに変換します。暗号化用のバルク暗号キーとIVは、クライアントのトークンによって生成され、キー交換メッセージで交換されます。Master_Secretは、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などの一部のアルゴリズムには、暗号化キーを生成するための独自の手順がある場合があります（Master Secretは、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を参照）。CiphersPecsには、クライアントの書き込みMACシークレット、サーバーの書き込みMACシークレット、クライアントの書き込みキー、サーバーの書き込みキー、クライアントの書き込みIV、およびサーバー書き込みIVが必要です。KeyExchangeメッセージで通信されたFortezzaキーなどの未使用の値は空です。キー定義プロセスでは、次の入力が利用できます。
opaque MasterSecret[48] ClientHello.random ServerHello.random
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には、2つの暗号化キーのそれぞれに5つのランダムバイトと、Macキーごとに16バイトが必要で、合計42バイトのキー材料が必要です。MD5はコールごとに16バイトの出力を生成するため、MD5への3つの呼び出しが必要です。MD5出力は、最初のMD5コールをゼロから15、2番目のMD5コールを提供する最初のMD5コールで48バイトのキー_Blockに連結され、2番目はバイト16から31などを提供します。。
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] Diffie、W。およびM. Hellman、「暗号化の新しい方向」、情報理論V. IT-22、n。6、pp。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。、「HellmanはDESのショートカットソリューションを提示しません」、IEEE Spectrum、v。16、n。7、pp 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、「Digital Signature Standard」、国立標準技術研究所米国商務省、1994年5月。
[FOR] NSA X22, "FORTEZZA: Application Implementers Guide", Document # PD4002103-1.01, April 1995.
[For] NSA X22、「Fortezza：Application Explenters Guide」、Document＃PD4002103-1.01、1995年4月。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC0959] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、1985年10月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、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] Berners-Lee、T.、Fielding、R。、およびH. Nielsen、「HyperText Transfer Protocol-HTTP/1.0」、RFC 1945、1996年5月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[RFC0854] Postel、J。およびJ. Reynolds、「Telnetプロトコル仕様」、STD 8、RFC 854、1983年5月。
[RFC1832] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
[RFC1832] Srinivasan、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.、Bellare、M。、およびR. CaNetti、「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.
[アイデア] Lai、X。、「ブロック暗号の設計とセキュリティについて」、情報処理のETHシリーズ、v。1、Konstanz：Hartung-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] Rivest、R.、Shamir、A。、およびL. Adleman、「デジタル署名とパブリックキー暗号システムを取得する方法」、ACMv。21、n。2pp。120-126。、1978年2月。
[SCH] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and Source Code in C", John Wiley & Sons, 1994.
[Sch] Schneier、B。、「適用された暗号化：プロトコル、アルゴリズム、およびcのソースコード」、John Wiley＆Sons、1994。
[SHA] NIST FIPS PUB 180-1, "Secure Hash Standard", May 1994.
[Sha] Nist Fips Pub 180-1、「Secure Hash Standard」、1994年5月。
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、Inc。、「未発表の作品」。
This section describes protocol types and constants.
このセクションでは、プロトコルの種類と定数について説明します。
struct {
uint8 major, minor;
} ProtocolVersion;
ProtocolVersion version = { 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;
struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
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;
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;
struct { } HelloRequest;
struct {
uint32 gmt_unix_time;
opaque random_bytes[28];
} Random;
opaque SessionID<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;
opaque 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>;
struct {
CertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<3..2^16-1>;
} CertificateRequest;
struct { } ServerHelloDone;
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;
struct {
opaque md5_hash[16];
opaque sha_hash[20];
} Finished;
The following values define the CipherSuite codes used in the client hello and server hello messages.
次の値は、クライアントのhello and server 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 };
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パラメーターがDSSまたはRSA証明書によって署名され、CAによって署名されているDiffie-Hellmanパラメーターが署名されます。使用される署名アルゴリズムは、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コミュニケーションに使用されます。このモードは中間の攻撃に対して脆弱であり、したがって強く落胆していることに注意してください。
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 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;
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.
認証：認証とは、あるエンティティが別のエンティティのIDを決定する能力です。
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は、ブロックCipherで暗号化されたすべてのプレーンテキストブロックが、以前の暗号文字ブロック（または、最初のブロックの場合、初期化ベクトルを使用）を使用して最初に排他的であるモードです。
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 Secret：クライアントが作成したデータを認証するために使用される秘密データ。
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、「Digital Signature Standard」で定義された国立標準技術研究所によって承認されたデジタル署名アルゴリズムを含むデジタル署名の標準、米国部によって1994年5月に発行されました。コマース。
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].
アイデア：Xuejia LaiとJames Massey [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、Inc。の独自のバルク暗号（未発表の作品であるため、これらについての適切な参照はありません。ただし、[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.
セッション識別子：セッション識別子は、特定のセッションを識別するサーバーによって生成される値です。
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 Secret：サーバーによって記述されたデータの認証に使用される秘密データ。
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.
Stream Cipher：キーを暗号化的に強力なキーストリームに変換する暗号化アルゴリズム。これは、プレーンテキストを備えた排他的なものです。
symmetric cipher: See bulk cipher.
対称暗号：バルク暗号を参照してください。
CipherSuite Is Key Cipher Hash
Exportable Exchange
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.
* exportableが真実であることを示します。** Fortezzaは、独自のキーおよびIV生成アルゴリズムを使用しています。
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
The SSL protocol cannot prevent many common security mistakes. This section provides several recommendations to assist implementers.
SSLプロトコルは、多くの一般的なセキュリティの間違いを防ぐことはできません。このセクションでは、実装者を支援するためのいくつかの推奨事項を提供します。
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.
米国の輸出制限により、暗号化に使用されるRSAキーが512ビットに制限されていますが、操作に署名するために使用される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キー生成は、時間のかかるプロセスです。多くの場合、主要生成のタスクを割り当てることができます。新しいキーが完了するたびに、既存のキーキーを新しいキーに置き換えることができます。
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）が必要です。PRNGSの設計と播種には注意が必要です。安全なハッシュ操作、特にMD5および/またはSHAに基づくPRNGは許容されますが、乱数ジェネレーター状態のサイズよりも多くのセキュリティを提供することはできません。（たとえば、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の播種機能と3.0より前のBSAFEのバージョンは、Order Independentです。たとえば、1000個の種子ビットが一度に1つずつ供給されている場合、シード関数への1000個の個別の呼び出しで、PRNGは種子データの0または1種子ビットの数のみにのみ依存する状態になります（つまり、、1001の可能な最終状態があります）。BSAFEまたはRSAREFを使用したアプリケーションは、適切な播種を確保するために特別な注意を払う必要があります。
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に関する情報を表示できる必要があります。
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ビットキーを許可しないはずです。同様に、匿名のdiffie-hellmanは、中間の攻撃を防ぐことができないため、強く落胆しています。アプリケーションは、最小および最大のキーサイズを実施する必要があります。たとえば、512ビットのRSAキーまたは署名を含む証明書チェーンは、高セキュリティアプリケーションには適していません。
This section describes implementation details for cipher suites that make use of the FORTEZZA hardware encryption system.
このセクションでは、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つは読書用、もう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つは読書用、もう1つは執筆用です。これらの各キーを生成した後、クライアントは対応するIVを生成し、暗号状態を保存する必要があります。また、クライアントはTEKを使用してIVを生成し、Premaster Secretを暗号化します。3つのIVすべてがサーバーに送信され、クライアントキーエクスチェンジメッセージにラップされたキーと暗号化されたPrepreaster Secretが送信されます。この時点で、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.
サーバー側では、サーバーはMaster IVとTekを使用してPremaster Secretを復号化します。また、ラップされたミークをカードにロードします。サーバーは両方の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.
最初の暗号化されたレコード（およびそのレコードのみ）を暗号化するとき、サーバーはフラグメントの先頭に8バイトのランダムデータを追加します。これらの8バイトは、復号化後にクライアントによって破棄されます。これの目的は、異なるIVから生じるクライアントとサーバーの状態を同期することです。
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キーエクスチェンジを使用します。
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.
Fortezzaセッションの再起動には2つの可能性があります。1）Fortezzaセッションを再起動しないでください。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 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.
完全なFortezzaキー交換を行ったことがないセッションでFortezzaを再開することはできません（つまり、FortezzaのRSA/RC4セッションが再交渉された場合、Fortezzaを再起動することはできません）。Fortezzaセッションを再起動する場合は、このセッションの最初のキー交換からMEKSとIVを保存し、そのセッションの新しい接続について再利用する必要があります。これは推奨されませんが、可能です。
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クライアントハローメッセージ[SSL-2]を送信する必要があります。バージョン3.0サーバーは、いずれかのクライアントハロー形式を受け入れる必要があります。バージョン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.
警告：バージョン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クライアントハローメッセージに含めることができます。ゼロに等しい最初のバイトを持つV2CiphersPec要素は、バージョン2.0サーバーによって無視されます。上記のv2cipherspecsのいずれかを送信するクライアントには、バージョン3.0等価物も含める必要があります（付録A.6を参照）：
V2CipherSpec (see Version 3.0 name) = { 0x00, CipherSuite };
The version 2.0 client hello message is presented below using this document's presentation model. The true definition is still assumed to be the SSL version 2.0 specification.
バージョン2.0クライアントのハローメッセージは、このドキュメントのプレゼンテーションモデルを使用して以下に表示されます。真の定義は、まだSSLバージョン2.0仕様であると想定されています。
uint8 V2CipherSpec[3];
uint8 v2cipherspec [3];
struct {
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つに等しくなければなりません。
version: The highest version of the protocol supported by the client (equals ProtocolVersion.version; see Appendix A.1).
バージョン：クライアントによってサポートされるプロトコルの最高版（プロトコルバージョンのバージョンに等しい;付録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_LENGTH：このフィールドは、フィールドCIPHER_SPECSの全長です。ゼロにすることはできず、v2cipherspecの長さの倍数でなければなりません（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：これは、クライアントが喜んで使用できるすべてのcipherspecsのリストです。サーバーには少なくとも1つの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を使用する必要があります。
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互換モードにある場合、それらは、暗号化されたキーダタのRSA暗号化のために、PKCSパディングの右側（最小重要な）8ランダムバイト（パディングの端子ヌルを含まない）を設定しますクライアントマスターキーのフィールド0x03（他のパディングバイトはランダムです）。暗号化されたキーデータフィールドを復号化した後、SSL 3.0をサポートするサーバーは、これらの8つのパディングバイトが0x03の場合、エラーを発行するはずです。この方法でパディングされたブロックを受信するバージョン2.0サーバーは、正常に進行します。
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がどのように設計されているかを概説しています。
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を生成する責任があります。ハンドシェイクプロトコルは、信頼できる証明書当局によって署名された証明書を持っている当事者をオプションで認証することもできます。
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つの認証モード、両当事者の認証、認証されていないクライアントによるサーバー認証、および総匿名性の3つの認証をサポートしています。サーバーが認証されるたびに、チャネルは中間の攻撃に対して安全である必要がありますが、完全に匿名のセッションは本質的にそのような攻撃に対して脆弱です。
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.
主要な交換プロセスの一般的な目標は、攻撃者ではなく通信当事者に知られているpre_master_secretを作成することです。pre_master_secretは、master_secretを生成するために使用されます（セクション6.1を参照）。Master_Secretは、完成したメッセージ、暗号化キー、およびMacシークレットを生成するために必要です（セクション5.6.9および6.2.2を参照）。したがって、正しい完成したメッセージを送信することにより、当事者は、正しいpre_master_secretを知っていることを証明します。
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、Diffie-Hellman、またはFortezzaを使用して、完全に匿名のセッションを確立できます。匿名のRSAを使用すると、クライアントは、サーバーキーエクスチェンジメッセージから抽出されたサーバーの認定されていない公開キーを使用して、pre_master_secretを暗号化します。結果は、クライアントキーエクスチェンジメッセージで送信されます。盗聴者はサーバーの秘密鍵を知らないため、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).
diffie-hellmanまたはfortezzaを使用すると、サーバーの公開パラメーターがサーバーキー交換メッセージに含まれ、クライアントのパラメーターがクライアントキーエクスチェンジメッセージに送信されます。プライベートバリューを知らない盗聴者は、Diffie-Hellmanの結果（つまり、pre_master_secret）または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.
警告：完全に匿名の接続は、受動的な盗聴に対する保護のみを提供します。独立した改ざん防止チャネルを使用して、完成したメッセージが攻撃者に置き換えられていないことを確認しない限り、アクティブな中間攻撃が懸念事項である環境でサーバー認証が必要です。
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 ClientHello.random, so old signatures and temporary keys cannot be replayed. Servers may use a single temporary RSA key for multiple negotiation sessions.
RSAを使用すると、キーエクスチェンジとサーバー認証が組み合わされます。公開キーは、サーバーの証明書に含まれているか、サーバーキー交換メッセージに送信される一時的なRSAキーである場合があります。一時的なRSAキーを使用すると、サーバーのRSAまたはDSS証明書によって署名されます。署名には現在のclienthello.randomが含まれているため、古い署名と一時的なキーを再生できません。サーバーは、複数のネゴシエーションセッションに単一の一時的なRSAキーを使用する場合があります。
Note: The temporary RSA key option is useful if servers need large certificates but must comply with government-imposed size limits on keys used for key exchange.
注：一時的なRSAキーオプションは、サーバーが大規模な証明書が必要であるが、キー交換に使用されるキーの政府が課したサイズ制限を遵守する必要がある場合に役立ちます。
After verifying the server's certificate, the client encrypts a pre_master_secret with the server's public key. By successfully decoding the pre_master_secret and producing a correct finished message, the server demonstrates that it knows the private key corresponding to the server certificate.
サーバーの証明書を確認した後、クライアントはサーバーの公開キーを使用してpre_master_secretを暗号化します。pre_master_secretを正常にデコードし、正しい完成メッセージを作成することにより、サーバーはサーバー証明書に対応する秘密鍵を知っていることを示します。
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を参照）。クライアントは、Master_Secretとすべての先行するハンドシェイクメッセージから派生した値に署名します。これらのハンドシェイクメッセージには、サーバーに署名をバインドするサーバー証明書と、署名を現在のハンドシェイクプロセスにバインドするserverhello.randomが含まれます。
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証明書で署名された一時的なDiffie-Hellmanパラメーターのセットを送信できます。攻撃者が古いパラメーターを再生しないように署名する前に、一時的なパラメーターは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の結果（つまり、pre_master_secret）を生成することに注意してください。pre_master_secretが必要以上にメモリにとどまるのを防ぐために、できるだけ早く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証明書を持っている場合、または認証されていない場合、クライアントキーエクスチェンジメッセージ内のサーバーに一時パラメーターのセットを送信し、オプションで証明書確認メッセージを使用して自らを認証します。
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から派生していません。暗号化されたpre_master_secretは、クライアントキーエクスチェンジメッセージでサーバーに送信されます。
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サーバーが攻撃を検出するための合理的に安全な方法を提供します。このソリューションは、キーを強制的に強制的に、同じキー（ただし通常のパディングを含む）を含む新しい暗号化されたキーダタメッセージを、指定された待機しきい値が切れる前に、新しい暗号化されたキーデータメッセージを置き換えることができる攻撃者に対して安全ではありません。とにかく、この規模の攻撃を懸念している当事者は、40ビット暗号化キーを使用すべきではありません。PKCSパディングの最も重要な8バイトのパディングを変更すると、セキュリティには影響しません。これは、入力ブロックサイズを8バイト増加させることに基本的に同等であるためです。
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.
この攻撃では、攻撃者は1つ以上の握手メッセージを積極的に変更する必要があります。これが発生した場合、クライアントとサーバーは、ハンドシェイクメッセージのハッシュの異なる値を計算します。その結果、当事者はお互いの完成したメッセージを受け入れません。Master_Secretがなければ、攻撃者は完成したメッセージを修復できないため、攻撃が発見されます。
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の値がセッションのmaster_secretでハッシュされます。Master_Secretが侵害されておらず、暗号化キーとMACシークレットの生成に使用される安全なハッシュ操作が安全であることが限り、接続は安全で効果的に独立している必要があります。攻撃者は、既知の暗号化キーまたはMACシークレットを使用して、安全なハッシュ操作を破ることなくMaster_Secretを侵害することはできません（SHAとMD5の両方を使用）。
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.
クライアントとサーバーの両方が同意しない限り、セッションを再開することはできません。いずれかの当事者が、セッションが侵害された可能性があると疑っている場合、または証明書が期限切れになったり、取り消されたりする可能性がある場合、完全な握手を強制する必要があります。Master_Secretを取得した攻撃者は、対応するセッションIDが廃止されるまで侵害されたパーティーになりすますことができるため、セッションIDのライフタイムには24時間の上限が提案されます。比較的不安定な環境で実行される可能性のあるアプリケーションは、セッションIDを安定したストレージに記述しないでください。
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つのアルゴリズムの非触媒的な欠陥が全体的なプロトコルを破らないようにします。
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.
Master_Secretは、clienthello.randomとserverhello.randomにハッシュされ、各接続の一意のデータ暗号化キーとMacシークレットを作成します。Fortezza暗号化キーはトークンによって生成され、Master_Secretから派生していません。
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つの固定文字文字列から計算されます。メッセージタイプフィールドは、あるSSLレコードレイヤークライアントを対象としたメッセージが別のSSLレイヤークライアントを対象としていることを確認するために必要です。シーケンス番号は、メッセージを削除または再注文しようとする試みが検出されることを保証します。シーケンス番号は64ビットの長さであるため、決してオーバーフローしないでください。独立したMACシークレットを使用するため、ある当事者からのメッセージを他方の出力に挿入することはできません。同様に、サーバーワイトとクライアントワイトキーは独立しているため、ストリーム暗号キーは一度だけ使用されます。
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シークレットは暗号化キーよりも大きい場合があるため、暗号化キーが壊れていても、メッセージは抵抗を改ざんのままにすることができます。
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ビットのバルク暗号化キー、および匿名サーバーは、非常に注意して使用する必要があります。実装とユーザーは、どの証明書と証明書当局が受け入れられるかを決定する際に注意する必要があります。不正な認証局は、大きな損害を与える可能性があります。
Martin Abadi Robert Relyea
Digital Equipment Corporation Netscape Communications
ma@pa.dec.com relyea@netscape.com
Taher Elgamal Jim Roskind
Netscape Communications Netscape Communications
elgamal@netscape.com jar@netscape.com
Anil Gangolli Micheal J. Sabin, Ph.D. Netscape Communications Consulting Engineer gangolli@netscape.com msabin@netcom.com
Anil Gangolli Micheal J. Sabin、Ph.D。Netscape Communications Consulting Engineer Gangolli@netscape.com msabin@netcom.com
Kipp E.B. Hickman Tom Weinstein
Netscape Communications Netscape Communications
kipp@netscape.com tomw@netscape.com
Robert Baldwin Clyde Monma
RSA Data Security, Inc. Bellcore
baldwin@rsa.com clyde@bellcore.com
George Cox Eric Murray
Intel Corporation ericm@lne.com
cox@ibeam.jf.intel.com
Cheri Dowell Avi Rubin
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
Burt Kaliski Joe Tardo
RSA Data Security, Inc. General Magic
burt@rsa.com tardo@genmagic.com
Authors' Addresses
著者のアドレス
Alan O. Freier Netscape Communications
Alan O. Freier Netscape Communications
Philip Karlton Netscape Communications
フィリップカールトンネットスケープコミュニケーションズ
Paul C. Kocher Independent Consultant
Paul C. Kocher Independent Consultant