RFC 7568 - Deprecating Secure Sockets Layer Version 3.0 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7568
タイトル : RFC 7568 - Secure Sockets Layerバージョン3.0の廃止
翻訳編集 : 自動生成

[要約] RFC 7568は、セキュリティの脆弱性が明らかになったため、Secure Sockets Layer (SSL) バージョン3.0の使用を非推奨とすることを目的としています。この文書は、より安全な代替手段、特にTransport Layer Security (TLS) プロトコルの使用を推奨しています。SSL 3.0の使用を非推奨とすることで、インターネットのセキュリティを強化し、中間者攻撃などのリスクを減少させることを目指しています。関連するRFCには、TLSプロトコルを定義するRFC 5246（TLS 1.2）や、その後のバージョンを更新するRFCが含まれます。

Internet Engineering Task Force (IETF)                         R. Barnes
Request for Comments: 7568                                    M. Thomson
Updates: 5246                                                    Mozilla
Category: Standards Track                                     A. Pironti
ISSN: 2070-1721                                                    INRIA
                                                              A. Langley
                                                                  Google
                                                               June 2015

Deprecating Secure Sockets Layer Version 3.0

Secure Sockets Layerバージョン3.0の廃止

Abstract

概要

The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC 6101, is not sufficiently secure. This document requires that SSLv3 not be used. The replacement versions, in particular, Transport Layer Security (TLS) 1.2 (RFC 5246), are considerably more secure and capable protocols.

RFC 6101で指定されているSecure Sockets Layerバージョン3.0（SSLv3）は、十分に安全ではありません。このドキュメントでは、SSLv3を使用しないことを要求しています。代替バージョン、特にトランスポート層セキュリティ（TLS）1.2（RFC 5246）は、はるかに安全で対応可能なプロトコルです。

This document updates the backward compatibility section of RFC 5246 and its predecessors to prohibit fallback to SSLv3.

このドキュメントでは、SSLv3へのフォールバックを禁止するために、RFC 5246とその前身の下位互換性セクションを更新しています。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

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). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc7568.

このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7568で入手できます。

著作権表示

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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Do Not Use SSL Version 3.0  . . . . . . . . . . . . . . . . .   3
   4.  SSLv3 Is Comprehensively Broken . . . . . . . . . . . . . . .   3
     4.1.  Record Layer  . . . . . . . . . . . . . . . . . . . . . .   3
     4.2.  Key Exchange  . . . . . . . . . . . . . . . . . . . . . .   4
     4.3.  Custom Cryptographic Primitives . . . . . . . . . . . . .   4
   5.  Limited Capabilities  . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1. Introduction

1. はじめに

Since it was released in 1996, the SSLv3 protocol [RFC6101] has been subject to a long series of attacks, both on its key exchange mechanism and on the encryption schemes it supports. Despite being replaced by TLS 1.0 [RFC2246] in 1999, and subsequently TLS 1.1 in 2002 [RFC4346] and 1.2 in 2006 [RFC5246], availability of these replacement versions has not been universal. As a result, many implementations of TLS have permitted the negotiation of SSLv3.

1996年にリリースされて以来、SSLv3プロトコル[RFC6101]は、その鍵交換メカニズムとそれがサポートする暗号化スキームの両方で、一連の長い攻撃を受けてきました。 1999年にはTLS 1.0 [RFC2246]に、2002年にはTLS 1.1 [RFC4346]に、2006年には1.2 [RFC5246]に置き換えられましたが、これらの代替バージョンの可用性は普遍的ではありませんでした。その結果、TLSの多くの実装でSSLv3のネゴシエーションが許可されています。

The predecessor of SSLv3, SSL version 2, is no longer considered sufficiently secure [RFC6176]. SSLv3 now follows.

SSLv3の前身であるSSLバージョン2は、十分に安全であるとはもはや見なされていません[RFC6176]。 SSLv3が続きます。

2. Terminology

2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

3. Do Not Use SSL Version 3.0

3. SSLバージョン3.0を使用しない

SSLv3 MUST NOT be used. Negotiation of SSLv3 from any version of TLS MUST NOT be permitted.

SSLv3を使用してはなりません。 TLSの任意のバージョンからのSSLv3のネゴシエーションは許可されてはなりません。

Any version of TLS is more secure than SSLv3, though the highest version available is preferable.

TLSのどのバージョンもSSLv3よりも安全ですが、利用可能な最も高いバージョンが望ましいです。

Pragmatically, clients MUST NOT send a ClientHello with ClientHello.client_version set to {03,00}. Similarly, servers MUST NOT send a ServerHello with ServerHello.server_version set to {03,00}. Any party receiving a Hello message with the protocol version set to {03,00} MUST respond with a "protocol_version" alert message and close the connection.

実用的には、クライアントはClientHello.client_versionを{03,00}に設定してClientHelloを送信してはなりません（MUST NOT）。同様に、サーバーはServerHello.server_versionを{03,00}に設定してServerHelloを送信してはなりません（MUST NOT）。プロトコルバージョンが{03,00}に設定されたHelloメッセージを受信するすべてのパーティは、「protocol_version」アラートメッセージで応答し、接続を閉じる必要があります。

Historically, TLS specifications were not clear on what the record layer version number (TLSPlaintext.version) could contain when sending ClientHello. Appendix E of [RFC5246] notes that TLSPlaintext.version could be selected to maximize interoperability, though no definitive value is identified as ideal. That guidance is still applicable; therefore, TLS servers MUST accept any value {03,XX} (including {03,00}) as the record layer version number for ClientHello, but they MUST NOT negotiate SSLv3.

これまで、ClientHelloの送信時にレコード層のバージョン番号（TLSPlaintext.version）に何が含まれるかについて、TLS仕様は明確ではありませんでした。 [RFC5246]の付録Eは、相互運用性を最大化するためにTLSPlaintext.versionを選択できると述べていますが、理想的な値は特定されていません。そのガイダンスは引き続き適用されます。したがって、TLSサーバーは、ClientHelloのレコードレイヤーバージョン番号として{03、XX}（{03,00}を含む）の値を受け入れる必要がありますが、SSLv3をネゴシエートしてはなりません。

4. SSLv3 Is Comprehensively Broken

4. SSLv3は包括的に壊れています

4.1. Record Layer

4.1. レコード層

The non-deterministic padding used in the Cipher Block Chaining (CBC) construction of SSLv3 trivially permits the recovery of plaintext [POODLE]. More generally, the CBC modes of SSLv3 use a flawed MAC-then-encrypt construction that has subsequently been replaced in TLS versions [RFC7366]. Unfortunately, the mechanism to correct this flaw relies on extensions: a feature added in TLS 1.0. SSLv3 cannot be updated to correct this flaw in the same way.

SSLv3のCipher Block Chaining（CBC）構築で使用される非決定的パディングは、平文[POODLE]の回復を簡単に許可します。より一般的には、SSLv3のCBCモードは欠陥のあるMAC-then-encrypt構造を使用しますが、これはその後TLSバージョン[RFC7366]で置き換えられました。残念ながら、この欠陥を修正するメカニズムは、TLS 1.0で追加された拡張機能に依存しています。 SSLv3を更新して、同じ方法でこの欠陥を修正することはできません。

The flaws in the CBC modes in SSLv3 are mirrored by the weakness of the stream ciphers it defines. Of those defined, only RC4 is currently in widespread use. RC4, however, exhibits serious biases and is also no longer fit for use [RFC7465].

SSLv3のCBCモードの欠陥は、SSLv3が定義するストリーム暗号の弱点によって反映されています。定義されているもののうち、現在広く使用されているのはRC4のみです。ただし、RC4には深刻なバイアスがあり、使用には適していません[RFC7465]。

This leaves SSLv3 with no suitable record protection mechanism.

これにより、SSLv3には適切なレコード保護メカニズムがなくなります。

4.2. Key Exchange

4.2. 鍵交換

The SSLv3 key exchange is vulnerable to man-in-the-middle attacks when renegotiation [RFC5746] or session resumption [TRIPLE-HS] are used. Each flaw has been fixed in TLS by means of extensions. Again, SSLv3 cannot be updated to correct these flaws.

再ネゴシエーション[RFC5746]またはセッション再開[TRIPLE-HS]が使用されている場合、SSLv3キー交換は中間者攻撃に対して脆弱です。各欠陥は、拡張機能によってTLSで修正されました。この場合も、SSLv3を更新してこれらの欠陥を修正することはできません。

4.3. Custom Cryptographic Primitives

4.3. カスタム暗号プリミティブ

SSLv3 defines custom constructions for Pseudorandom Function (PRF), Hashed Message Authentication Code (HMAC), and digital signature primitives. Such constructions lack the deep cryptographic scrutiny that standard constructions used by TLS have received. Furthermore, all SSLv3 primitives rely on SHA-1 [RFC3174] and MD5 [RFC1321]: these hash algorithms are considered weak and are being systematically replaced with stronger hash functions, such as SHA-256 [FIPS180-4].

SSLv3は、疑似ランダム関数（PRF）、ハッシュメッセージ認証コード（HMAC）、およびデジタル署名プリミティブのカスタム構成を定義します。このような構造は、TLSで使用される標準の構造が受けた深い暗号の精査に欠けています。さらに、すべてのSSLv3プリミティブはSHA-1 [RFC3174]およびMD5 [RFC1321]に依存しています。これらのハッシュアルゴリズムは脆弱であると見なされ、SHA-256 [FIPS180-4]などの強力なハッシュ関数に体系的に置き換えられています。

5. Limited Capabilities

5. 限られた機能

SSLv3 is unable to take advantage of the many features that have been added to recent TLS versions. This includes the features that are enabled by ClientHello extensions, which SSLv3 does not support.

SSLv3は、最近のTLSバージョンに追加された多くの機能を利用できません。これには、SSLv3がサポートしていないClientHello拡張機能によって有効になる機能が含まれます。

Though SSLv3 can benefit from new cipher suites, it cannot benefit from new cryptographic modes and features. Of these, the following are particularly prominent:

SSLv3は新しい暗号スイートから利益を得ることができますが、新しい暗号化モードと機能から利益を得ることができません。これらのうち、次のものが特に顕著です。

o Authenticated Encryption with Additional Data (AEAD) modes are added in [RFC5246].

o Authenticated Encryption with Additional Data（AEAD）モードが[RFC5246]に追加されました。

o Elliptic Curve Diffie-Hellman (ECDH) and Digital Signature Algorithm (ECDSA) are added in [RFC4492].

o 楕円曲線Diffie-Hellman（ECDH）とデジタル署名アルゴリズム（ECDSA）が[RFC4492]に追加されました。

o Stateless session tickets [RFC5077].

o ステートレスセッションチケット[RFC5077]。

o A datagram mode of operation, DTLS [RFC6347].

o データグラム操作モード、DTLS [RFC6347]。

o Application-layer protocol negotiation [RFC7301].

o アプリケーション層プロトコルネゴシエーション[RFC7301]。

6. Security Considerations

6. セキュリティに関する考慮事項

This entire document aims to improve security by prohibiting the use of a protocol that is not secure.

このドキュメント全体は、安全でないプロトコルの使用を禁止することにより、セキュリティを向上させることを目的としています。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, DOI 10.17487/RFC2246, January 1999, <http://www.rfc-editor.org/info/rfc2246>.

[RFC2246] Dierks、T。およびC. Allen、「The TLS Protocol Version 1.0」、RFC 2246、DOI 10.17487 / RFC2246、1999年1月、<http://www.rfc-editor.org/info/rfc2246>。

[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/RFC4346, April 2006, <http://www.rfc-editor.org/info/rfc4346>.

[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.1」、RFC 4346、DOI 10.17487 / RFC4346、2006年4月、<http://www.rfc-editor.org/info / rfc4346>。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.

[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。

[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, DOI 10.17487/RFC6101, August 2011, <http://www.rfc-editor.org/info/rfc6101>.

[RFC6101] Freier、A.、Karlton、P。、およびP. Kocher、「Secure Sockets Layer（SSL）Protocol Version 3.0」、RFC 6101、DOI 10.17487 / RFC6101、2011年8月、<http：//www.rfc -editor.org/info/rfc6101>。

[RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, <http://www.rfc-editor.org/info/rfc7366>.

[RFC7366] Gutmann、P。、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）の暗号化後MAC」、RFC 7366、DOI 10.17487 / RFC7366、2014年9月、<http：//www.rfc -editor.org/info/rfc7366>。

[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, DOI 10.17487/RFC7465, February 2015, <http://www.rfc-editor.org/info/rfc7465>.

[RFC7465] Popov、A。、「Prohibiting RC4 Cipher Suites」、RFC 7465、DOI 10.17487 / RFC7465、2015年2月、<http://www.rfc-editor.org/info/rfc7465>。

7.2. Informative References

7.2. 参考引用

[FIPS180-4] U.S. National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-4, March 2012.

[FIPS180-4]米国国立標準技術研究所、「Secure Hash Standard」、FIPS 180-4、2012年3月。

[POODLE] Moeller, B., "This POODLE bites: exploiting the SSL 3.0 fallback", October 2014, <http://googleonlinesecurity.blogspot.com/2014/10/ this-poodle-bites-exploiting-ssl-30.html>.

[POODLE] Moeller、B。、「This POODLE bites：Exploit the SSL 3.0 fallback」、2014年10月、<http://googleonlinesecurity.blogspot.com/2014/10/ this-poodle-bites-exploiting-ssl-30。 html>。

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <http://www.rfc-editor.org/info/rfc1321>.

[RFC1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、DOI 10.17487 / RFC1321、1992年4月、<http://www.rfc-editor.org/info/rfc1321>。

[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, <http://www.rfc-editor.org/info/rfc3174>.

[RFC3174] Eastlake 3rd、D。およびP. Jones、「US Secure Hash Algorithm 1（SHA1）」、RFC 3174、DOI 10.17487 / RFC3174、2001年9月、<http://www.rfc-editor.org/info/ rfc3174>。

[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, <http://www.rfc-editor.org/info/rfc4492>.

[RFC4492] Blake-Wilson、S.、Bolyard、N.、Gupta、V.、Hawk、C。、およびB. Moeller、「Elliptic Curve Cryptography（ECC）Cipher Suites for Transport Layer Security（TLS）」、RFC 4492 、DOI 10.17487 / RFC4492、2006年5月、<http://www.rfc-editor.org/info/rfc4492>。

[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <http://www.rfc-editor.org/info/rfc5077>.

[RFC5077] Salowey、J.、Zhou、H.、Eronen、P。、およびH. Tschofenig、「Transport Layer Security（TLS）Session Resumption without server-Side State」、RFC 5077、DOI 10.17487 / RFC5077、January 2008、 <http://www.rfc-editor.org/info/rfc5077>。

[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, <http://www.rfc-editor.org/info/rfc5746>.

[RFC5746] Rescorla、E.、Ray、M.、Dispensa、S。、およびN. Oskov、「Transport Layer Security（TLS）Renegotiation Indication Extension」、RFC 5746、DOI 10.17487 / RFC5746、2010年2月、<http：/ /www.rfc-editor.org/info/rfc5746>。

[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 2011, <http://www.rfc-editor.org/info/rfc6176>.

[RFC6176]ターナー、S。およびT.ポーク、「Prohibiting Secure Sockets Layer（SSL）Version 2.0」、RFC 6176、DOI 10.17487 / RFC6176、2011年3月、<http://www.rfc-editor.org/info/ rfc6176>。

[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.

[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<http://www.rfc-editor.org/info/rfc6347>。

[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <http://www.rfc-editor.org/info/rfc7301>.

[RFC7301] Friedl、S.、Popov、A.、Langley、A。、およびE. Stephan、「Transport Layer Security（TLS）Application-Layer Protocol Negotiation Extension」、RFC 7301、DOI 10.17487 / RFC7301、2014年7月、< http://www.rfc-editor.org/info/rfc7301>。

[TRIPLE-HS] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, A., and P-Y. Strub, "Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS", IEEE Symposium on Security and Privacy, 2014.

[TRIPLE-HS] Bhargavan、K.、Delignat-Lavaud、A.、Fournet、C.、Pironti、A。、およびP-Y。 Strub、「Triple Handshake and Cookie Cutters：Breaking and Fixing authentication over TLS over」、IEEE Symposium on Security and Privacy、2014年。

Authors' Addresses

著者のアドレス

Richard Barnes Mozilla

リチャードバーンズモジラ

   EMail: rlb@ipv.sx

Martin Thomson Mozilla

マーティン・トムソン・モジラ

   EMail: martin.thomson@gmail.com

Alfredo Pironti INRIA

アルフレドピロンティINRIA

   EMail: alfredo@pironti.eu

Adam Langley Google

アダムラングレーGoogle

   EMail: agl@google.com