トランスポート層セキュリティ

転送中のデータを保護するための暗号化プロトコル

トランスポート層セキュリティ（TLS）は、インターネットなどのコンピュータネットワーク上で通信のセキュリティを確保するために設計された暗号化プロトコルです。このプロトコルは、電子メール、インスタントメッセージ、Voice over IPなどのアプリケーションで広く使用されていますが、 HTTPSのセキュリティ確保における使用は、最も広く知られています。

TLSプロトコルの主な目的は、2つ以上のコンピュータアプリケーション間の通信において、証明書などの暗号化技術を用いて、プライバシー（機密性）、整合性、信頼性などのセキュリティを提供することです。TLSプロトコルはプレゼンテーション層で実行され、TLSレコードとTLSハンドシェイクプロトコルの2つの層で構成されています。

密接に関連するデータグラムトランスポート層セキュリティ（DTLS）は、データグラムベースのアプリケーションにセキュリティを提供する通信プロトコルです。技術文書では、「(D)TLS」という表現が両方のバージョンに適用される場合によく見られます。^[1]

TLS は、インターネット技術タスク フォース(IETF) が提案した標準規格で、1999 年に初めて定義され、現在のバージョンは 2018 年 8 月に定義された TLS 1.3 です。TLS は、Netscape CommunicationsがNetscape Navigator Web ブラウザーにHTTPSプロトコルを追加するために開発した、現在は廃止されたSSL ( Secure Sockets Layer ) 仕様 (1994、1995、1996)に基づいています。

説明

クライアント サーバーアプリケーションは、盗聴や改ざんを防止するように設計された方法で、TLSプロトコルを使用してネットワーク経由で通信します。

アプリケーションはTLS（またはSSL）の有無にかかわらず通信できるため、クライアントはサーバーにTLS接続の確立を要求する必要があります。 ^[2]これを実現する主な方法の一つは、TLS接続に別のポート番号を使用することです。ポート80は通常、暗号化されていないHTTPトラフィックに使用され、ポート443は暗号化されたHTTPSトラフィックに使用される一般的なポートです。もう一つの方法は、例えば一部のメールやニュースプロトコルを使用する場合など、プロトコル固有のSTARTTLSリクエストをサーバーに送信して接続をTLSに切り替えることです。

クライアントとサーバーがTLSの使用に合意すると、ハンドシェイク手順を用いてステートフル接続をネゴシエートします（§ TLSハンドシェイクを参照）。 ^{[3]これらのプロトコルは、}非対称暗号を用いたハンドシェイクを用いて、暗号設定だけでなく、以降の通信を対称暗号を用いて暗号化するためのセッション固有の共有鍵も確立します。このハンドシェイクにおいて、クライアントとサーバーは接続のセキュリティを確立するために用いられる様々なパラメータについて合意します。

• ハンドシェイクは、クライアントが TLS 対応サーバーに接続して安全な接続を要求し、サポートされている暗号スイート(暗号とハッシュ関数) のリストを提示したときに開始されます。
• サーバーはこのリストから、サポートしている暗号とハッシュ関数を選択し、その決定をクライアントに通知します。
• サーバーは通常、デジタル証明書の形で識別情報を提供します。証明書には、サーバー名、証明書の信頼性を保証する信頼できる証明機関（CA）、およびサーバーの公開暗号鍵が含まれます。
• クライアントは続行する前に証明書の有効性を確認します。
• 安全な接続に使用されるセッション キーを生成するために、クライアントは次のいずれかを実行します。
  • 乱数（PreMasterSecret ）をサーバーの公開鍵で暗号化し、その結果をサーバーに送信します（サーバーのみが秘密鍵で復号化できる必要があります）。その後、両者は乱数を使用して、セッション中のデータの後続の暗号化と復号化に使用する一意のセッション鍵を生成します。
  • Diffie–Hellman 鍵交換(またはその変形である楕円曲線 DH )を使用して、暗号化と復号化のためのランダムで一意のセッション キーを安全に生成します。このキーには前方秘匿性という追加のプロパティがあります。つまり、サーバーの秘密キーが将来公開された場合、そのセッションが第三者によって傍受され記録されたとしても、その秘密キーを使用して現在のセッションを復号化することはできません。

これによりハンドシェイクが終了し、安全な接続が開始されます。接続はセッションキーを使用して暗号化および復号化され、接続が切断されるまで継続されます。上記の手順のいずれかが失敗した場合、TLSハンドシェイクは失敗し、接続は確立されません。

TLS 1.3 では、前方秘匿性を提供する鍵交換アルゴリズムのみが許可されていることに注意してください。したがって、サーバーの公開鍵と秘密鍵を使用して PreMasterSecret を確立できるのは、TLS 1.2 以前のみです。

TLSとSSLは、 OSI参照モデルやTCP/IPモデルのいずれの層にも明確には当てはまりません。^{[4] [5] TLSは「信頼性の高いトランスポートプロトコル（例：} TCP）の上」で動作します^{[6] : §1}これは、TLSがトランスポート層の上位にあることを意味します。TLSは、通常はプレゼンテーション層の機能である上位層への暗号化を提供します。しかし、アプリケーションは一般的にTLSをトランスポート層であるかのように使用します^{[4] [5]} 。TLSを使用するアプリケーションは、TLSハンドシェイクの開始と交換された認証証明書の取り扱いを積極的に制御する必要があります。^{[6] : §1}

TLSによって保護されている場合、クライアント（例えばウェブブラウザ）とサーバー（例えばwikipedia.org）間の接続は、以下のすべての特性を持つことになります。^{[6] : §1}

• 送信されるデータの暗号化には対称鍵アルゴリズムが使用されるため、接続はプライベート（または機密性）です。この対称暗号化の鍵は、セッション開始時にネゴシエートされた共有秘密に基づいて、接続ごとに一意に生成されます。サーバーとクライアントは、最初のデータバイトが送信される前に、使用する暗号化アルゴリズムと暗号鍵の詳細についてネゴシエートします（下記参照）。共有秘密のネゴシエーションは安全（ネゴシエートされた秘密は盗聴者には利用できず、接続の中間に介入した攻撃者でさえも取得できない）かつ信頼性が高い（攻撃者はネゴシエーション中に通信を改ざんしても検出されない）です。
• 通信相手の身元は、公開鍵暗号を用いて認証できます。この認証はサーバー側では必須ですが、クライアント側ではオプションです。
• 送信される各メッセージには、送信中に検出されないデータの損失や変更を防ぐためにメッセージ認証コードを使用したメッセージ整合性チェックが含まれているため、接続は信頼できます(または整合性があります)。

TLSは、鍵交換、データの暗号化、メッセージの整合性の認証において、様々な方式をサポートしています。そのため、TLSの安全な設定には多くの設定パラメータが関係し、すべての選択肢が上記のリストで説明したプライバシー関連の特性をすべて実現できるわけではありません（以下の表「§ 鍵交換」、「§ 暗号セキュリティ」、「§ データ整合性」を参照）。

TLSが提供しようとしている通信セキュリティの側面を覆そうとする試みがなされており、これらのセキュリティ脅威に対処するために、プロトコルは何度も改訂されてきました。ウェブブラウザの開発者は、潜在的なセキュリティ上の脆弱性が発見された後、それらを防ぐために製品を繰り返し改訂してきました（ウェブブラウザのTLS/SSLサポート履歴を参照）。

データグラムトランスポート層セキュリティ

データグラムトランスポート層セキュリティ（略称DTLS）は、データグラムベースのアプリケーションにセキュリティを提供する関連通信プロトコルであり、盗聴、改ざん、またはメッセージの偽造を防止するように設計された^{[7] [8]}方法で通信することを可能にします。DTLSプロトコルは、ストリーム指向のトランスポート層セキュリティ（TLS）プロトコルに基づいており、同様のセキュリティ保証を提供することを目的としています。ただし、TLSとは異なり、ユーザーデータグラムプロトコル（UDP）、データグラム輻輳制御プロトコル（DCCP）、無線アクセスポイントの制御とプロビジョニング（CAPWAP）、ストリーム制御伝送プロトコル（SCTP）カプセル化、セキュアリアルタイムトランスポートプロトコル（SRTP）など、ほとんどのデータグラム指向プロトコルで使用できます。

DTLSプロトコルデータグラムは基盤となるトランスポートのセマンティクスを保持するため、アプリケーションはストリームプロトコルに伴う遅延の影響を受けません。ただし、アプリケーションはパケットの並べ替え、データグラムの損失、そしてデータグラムネットワークパケットのサイズを超えるデータを処理する必要はあります。DTLSはTCPではなくUDPまたはSCTPを使用するため、 VPNトンネルの作成に使用した場合のTCPメルトダウン問題[ ^{9] [10]}を回避できます。

2006年に最初にリリースされたDTLSバージョン1.0は、独立した文書ではありませんでした。TLS 1.1からの一連の差分として提供されました。^{[7] : §4}同様に、2012年にリリースされたDTLSはTLS 1.2からの差分です。TLSのバージョンに合わせて、DTLS 1.2のバージョン番号が付けられました。最後に、2022年にリリースされたDTLS 1.3はTLS 1.3からの差分です。以前の2つのバージョンと同様に、DTLS 1.3は「順序保護/非再生性を除き、TLS 1.3と同等のセキュリティ保証」を提供することを目指しています。^[11]

Cisco AnyConnect ^[12]および InterCloud Fabric、^[13]、OpenConnect ^{[14] 、} ZScaler Tunnel ^[15] 、 F5 Networks Edge VPN Client ^[16]、Citrix Systems NetScaler ^[17]など、多くのVPNクライアントはUDPトラフィックのセキュリティ保護にDTLSを使用しています。さらに、最新のウェブブラウザはすべてWebRTC用のDTLS-SRTP ^[18]をサポートしています。

歴史と発展

SSLおよびTLSプロトコル

プロトコル	出版	状態
サポート対象外:SSL 1.0	未発表	未発表
サポート対象外:SSL 2.0	1995	2011年に廃止[19]
サポート対象外:SSL 3.0	1996	2015年に廃止[20]
サポート対象外:TLS 1.0	1999	2021年に廃止[21] [22] [23] [24]
サポート対象外:TLS 1.1	2006	2021年に廃止[21] [22] [23] [24]
サポート対象:TLS 1.2	2008	2008年から使用中[25] [26]
最新バージョン: TLS 1.3	2018	2018年から使用中[26] [27]
伝説： サポートされていません サポートされている 最新バージョン プレビュー版 将来のバージョン

初期の研究プロジェクト

セキュアデータネットワークシステム

1986年8月、国家安全保障局（NSA）、国家標準局（National Bureau of Standards）、国防通信局（DCA）は、セキュア・データ・ネットワーク・システム（SDNS）と呼ばれるプロジェクトを立ち上げました。これは、公共および民間のインターネット上のアプリケーションに実装される次世代の安全なコンピュータ通信ネットワークと製品仕様を設計することを目的としています。これは、米国政府のGOSIPプロファイルと、国際的なITU-ISO JTC1インターネットの取り組みにおいて急速に発展しつつあった新しいOSIインターネット標準を補完することを目的としていました。^[28]

このプロジェクトの一環として、研究者たちはSP4（OSI参照系第4層のセキュリティプロトコル）と呼ばれるプロトコルを設計しました。これは後にトランスポート層セキュリティプロトコル（TLSP）と改名され、1995年に国際標準ITU-T X.274|ISO/IEC 10736:1995として公開されました。 ^[29]名前は似ていますが、これは今日のTLSとは異なります。

セキュアネットワークプログラミング（SNP）

トランスポート層セキュリティに向けた他の取り組みとしては、セキュア・ネットワーク・プログラミング（SNP）アプリケーション・プログラミング・インターフェース（API）が挙げられます。これは1993年に、既存のネットワークアプリケーションにセキュリティ対策を容易に後付けできるように、バークレー・ソケットに酷似したセキュア・トランスポート層APIを持つというアプローチを模索しました。SNPは1994年のUSENIXサマー・テクニカル・カンファレンスで発表されました。^{[30] [31]} SNPプロジェクトは、 1991年にNSAからテキサス大学オースティン校のサイモン・ラム教授に助成金が交付されたことで資金提供されました。^[32]セキュア・ネットワーク・プログラミングは2004年のACMソフトウェア・システム賞を受賞しました。^{[33] [34]}サイモン・ラム教授は、「1991年にセキュア・ソケットを発明し、1993年に最初のセキュア・ソケット層であるSNPを実装した」功績により、インターネットの殿堂 入りを果たしました。 ^{[35] [36]}

SSL 1.0、2.0、および 3.0

Netscape社はオリジナルのSSLプロトコルを開発し、1995年から1998年までNetscape Communications社の主任科学者を務めたTaher Elgamal氏は「SSLの父」と呼ばれています。 ^{[37] [38] [ 39] [40]} SSLバージョン1.0は、プロトコルに重大なセキュリティ上の欠陥があったため、公開されませんでした。1995年2月にリリースされたバージョン2.0は、すぐにセキュリティとユーザビリティに関する複数の欠陥があることが判明しました。メッセージ認証と暗号化に同じ暗号鍵を使用していました。秘密のプレフィックスを持つMD5ハッシュ関数を使用する脆弱なMAC構造を持っていたため、長さ拡張攻撃に対して脆弱でした。また、オープニングハンドシェイクと明示的なメッセージクローズのどちらにも保護が提供されていなかったため、中間者攻撃が検知されない可能性がありました。さらに、SSL 2.0は単一のサービスと固定ドメイン証明書を前提としており、Webサーバーで広く使用されている仮想ホスティング機能と競合したため、ほとんどのウェブサイトはSSLの使用が事実上不可能でした。

これらの欠陥により、プロトコルはSSLバージョン3.0へと全面的に再設計される必要が生じました。^{[41] [39] 1996年にリリースされたSSLバージョン3.0は、}ポール・コッチャーがNetscapeのエンジニアであるフィル・カールトンとアラン・フライアーと共同で開発し、Certicomのクリストファー・アレンとティム・ディアークスがリファレンス実装を行いました。SSL/TLSの新しいバージョンはSSL 3.0に基づいています。1996年のSSL 3.0のドラフトは、IETFによってRFC 6101として歴史的文書として公開されました。

SSL 2.0は2011年にRFC 6176によって非推奨となりました。2014年にはSSL 3.0がSSLのすべてのブロック暗号に影響を及ぼすPOODLE攻撃に対して脆弱であることが判明しました。SSL 3.0でサポートされている唯一の非ブロック暗号であるRC4も、SSL 3.0で使用されている状態では破られる可能性があります。^[42] SSL 3.0は2015年6月にRFC 7568によって非推奨となりました。

TLS 1.0

TLS 1.0は、1999年1月にSSLバージョン3.0のアップグレードとしてRFC 2246で初めて定義され、CerticomのChristopher Allen氏とTim Dierks氏によって作成されました。RFCには、「このプロトコルとSSL 3.0の違いは劇的ではありませんが、TLS 1.0とSSL 3.0の相互運用性を妨げるほど重要です」と記されています。Tim Dierks氏は後に、これらの変更と「SSL」から「TLS」への名称変更は、Microsoftの体裁を保つためのもので、「IETFがNetscapeのプロトコルを単に承認したようには見えないようにするため」だったと述べています。^[43]

PCI Councilは、組織が2018年6月30日までにTLS 1.0からTLS 1.1以上に移行することを提案しました。^{[44] [45]} 2018年10月、Apple、Google、Microsoft、Mozillaは共同で、2020年3月にTLS 1.0と1.1を廃止すると発表しました。 ^[22] TLS 1.0と1.1は、2021年3月にRFC 8996で正式に廃止されました。

TLS 1.1

TLS 1.1は2006年4月にRFC 4346で定義されました^。[46]これはTLSバージョン1.0からのアップデートです。このバージョンの主な違いは以下のとおりです。

• 暗号ブロック連鎖(CBC) 攻撃に対する保護を追加しました。
  • 暗黙的な初期化ベクトル(IV) が明示的な IV に置き換えられました。
  • パディング エラーの処理方法の変更。
• IANAパラメータ登録のサポート。 ^[47]

TLSバージョン1.0および1.1のサポートは、2020年頃にウェブサイトで広く廃止され、^[48] Firefoxバージョン24より前とChromiumベースのブラウザバージョン29より前へのアクセスが無効になりましたが、^[49] Netscape NavigatorとFirefoxの古いバージョンにサードパーティの修正を適用してTLS 1.2のサポートを追加することは可能です。^[50]

TLS 1.2

TLS 1.2は2008年8月にRFC 5246で定義されました^。[25]これは以前のTLS 1.1仕様に基づいています。主な違いは以下のとおりです。

• 疑似乱数関数(PRF)の MD5 と SHA-1 の組み合わせはSHA - 256に置き換えられ、暗号スイートで指定された PRF を使用するオプションが追加されました。
• 完成したメッセージのハッシュにおけるMD5とSHA-1の組み合わせは、暗号スイート固有のハッシュアルゴリズムを使用するオプションを備えたSHA-256に置き換えられました。ただし、完成したメッセージのハッシュのサイズは依然として少なくとも96ビットである必要があります。^{[25] : §7.4.9}
• デジタル署名要素の MD5 と SHA-1 の組み合わせは、ハンドシェイク中にネゴシエートされた単一のハッシュに置き換えられました。デフォルトでは SHA-1 になります。
• クライアントとサーバーが受け入れるハッシュと署名アルゴリズムを指定する機能が強化されました。
• 主にAdvanced Encryption Standard (AES) 暗号化のGalois/Counter Mode (GCM) およびCCM モードで使用される、認証された暗号化暗号のサポートが拡張されました。
• TLS拡張定義とAES暗号スイートが追加された。^[47]

2011年3月のRFC 6176では、すべてのTLSバージョンがさらに改良され、SSLとの下位互換性が削除されました。これにより、TLSセッションはSecure Sockets Layer（SSL）バージョン2.0の使用をネゴシエートすることはありません。2025年4月現在、TLS 1.2の廃止予定日は正式には決まっていません。TLS 1.2の仕様は、標準化過程文書RFC 8446によって再定義され、安全性を最大限に高めています。現在、TLS 1.2はフェイルオーバープロトコルとして認識されており、TLS 1.3で通信できないクライアントとのみネゴシエートすることを目的としています（TLS 1.2の元のRFC 5246の定義はそれ以降廃止されています）。

TLS 1.3

TLS 1.3は2018年8月にRFC 8446で定義されました^。[6]これは以前のTLS 1.2仕様に基づいています。TLS 1.2との主な違いは次のとおりです。^[51]

• 鍵共有と認証アルゴリズムを暗号スイートから分離する^{[47] [6] : §11}
• 弱い、あまり使われていない名前付き楕円曲線のサポートを削除する
• MD5およびSHA-224暗号ハッシュ関数のサポートの削除
• 以前の構成が使用されている場合でもデジタル署名を要求する
• HKDFと半一時的なDH提案の統合
• 再開をPSKとチケットに置き換える
• 1- RTTハンドシェイクのサポートと0- RTTの初期サポート
• （EC）DH鍵合意中に一時鍵を使用することで、完全な前方秘匿性を義務付ける
• 圧縮、再ネゴシエーション、非AEAD暗号、ヌル暗号、^[52]非PFS鍵交換（静的RSA鍵交換と静的DH鍵交換を含む）、カスタムDHEグループ、ECポイント形式ネゴシエーション、Change Cipher Specプロトコル、 HelloメッセージのUNIX時間、AEAD暗号へのAD入力の長さフィールドなど、多くの安全でない機能や廃止された機能のサポートを廃止しました。
• 下位互換性のために SSL または RC4 ネゴシエーションを禁止する
• セッションハッシュの使用を統合する
• レコード層のバージョン番号の使用を廃止し、下位互換性を向上させるために番号を固定します。
• セキュリティ関連のアルゴリズムの詳細の一部を付録から仕様に移動し、ClientKeyShare を付録に移動しました。
• Poly1305メッセージ認証コードを使用したChaCha20ストリーム暗号の追加
• Ed25519およびEd448デジタル署名アルゴリズムの追加
• x25519およびx448鍵交換プロトコルの追加
• 複数のOCSP応答の送信のサポートを追加
• ServerHello以降のすべてのハンドシェイクメッセージ（サーバー証明書を含む）を暗号化する

Mozillaが開発し、同社のウェブブラウザFirefoxで使用されている暗号化ライブラリであるネットワークセキュリティサービス（NSS）は、2017年2月にTLS 1.3をデフォルトで有効化しました。 ^{[53]その後、2017年3月にリリースされた}Firefox 52.0にTLS 1.3のサポートが追加されましたが、少数のユーザーとの互換性の問題により、自動的に有効化されませんでした。^{[54] TLS 1.3は、2018年5月に}Firefox 60.0のリリースでデフォルトで有効化されました。^[55]

Google Chromeは2017年に短期間TLS 1.3をデフォルトバージョンに設定しました。その後、Blue Coatウェブプロキシなどの互換性のないミドルボックスが原因で、デフォルトから削除されました。^[56]

TLSの新バージョンにおける不寛容性は、プロトコルの硬直化でした。ミドルボックスがプロトコルのバージョンパラメータを硬直化させてしまったのです。その結果、バージョン1.3はバージョン1.2のワイヤイメージを模倣するようになりました。この変更は設計プロセスのかなり後期に発生し、ブラウザの導入時に初めて発見されました。^[57]この不寛容性の発見により、最も適合性の高いバージョンを選択するという従来のバージョンネゴシエーション戦略も、骨化が機能不全に陥ったため放棄されました。^[58]拡張ポイントに「グリースを塗る」、つまり、プロトコル参加者の1人が存在しない拡張機能のサポートを主張することで、認識されていないが実際には存在する拡張機能を許容し、硬直化を防ぐという手法は、もともとTLSのために設計されたものですが、その後、他の用途にも採用されています。^[58]

2017年にシンガポールで開催されたIETF 100ハッカソンでは、TLSグループはオープンソースアプリケーションをTLS 1.3に対応させる取り組みを行いました。^{[59] [60]} TLSグループは、cyberstorm.muチームを通じて日本、イギリス、モーリシャス出身の個人で構成されていました。^{[60]この作業は、}ロンドンで開催されたIETF 101ハッカソン、^[61]とモントリオールで開催されたIETF 102ハッカソンでも継続されました。^[62]

wolfSSLは、2017年5月にリリースされたバージョン3.11.1からTLS 1.3の利用を可能にしました^。[63] wolfSSL 3.11.1は、最初の商用TLS 1.3実装として、ドラフト18をサポートし、現在はドラフト28（^[64]最終バージョン）に加え、多くの旧バージョンもサポートしています。TLS 1.2と1.3のパフォーマンスの違いに関するブログ記事がシリーズで公開されています。^[65]

で2018年9月2010年、人気のOpenSSLプロジェクトはライブラリのバージョン1.1.1をリリースしました。このバージョンでは、TLS 1.3のサポートが「目玉となる新機能」でした。^[66]

Windows 11およびWindows Server 2022のGAリリースでは、セキュアチャネル（schannel）にTLS 1.3のサポートが追加されました。^[67]

エンタープライズトランスポートセキュリティ

電子フロンティア財団（EFF）はTLS 1.3を称賛するとともに、TLS 1.3の重要なセキュリティ対策を意図的に無効化する変種プロトコル、エンタープライズ・トランスポート・セキュリティ（ETS）について懸念を表明した。^[68]元々はエンタープライズTLS（eTLS）と呼ばれていたETSは、「ETSI TS103523-3」（ミドルボックス・セキュリティ・プロトコル、パート3：エンタープライズ・トランスポート・セキュリティ）として知られる公開標準規格である。これは、銀行システムなどの専用ネットワーク内でのみ使用されることを目的としている。ETSは前方秘匿性をサポートしていないため、専用ネットワークに接続された第三者機関は、マルウェア検出や監査の実施を容易にするために、秘密鍵を用いてネットワークトラフィックを監視することができる。^{[69] [70]} EFFは、その利点にもかかわらず、前方秘匿性の喪失によってデータの漏洩が容易になる可能性があると警告し、トラフィックを分析するより優れた方法があると述べた。^[68]

デジタル証明書

デジタル証明書付きのウェブサイトの例

デジタル証明書は、証明書の指定された主体による公開鍵の所有権を証明し、その鍵の特定の使用法を示します。これにより、他者（証明書利用者）は、証明された公開鍵に対応する秘密鍵による署名またはアサーションを信頼できるようになります。キーストアとトラストストアは、.pem、.crt、.pfx、.jksなど、様々な形式で保存できます。

証明機関

TLSは通常、証明書の信頼性を確立するために、信頼できる第三者認証局に依存します。信頼は通常、ユーザーエージェントソフトウェアと共に配布される証明書のリスト^[71]によって確立され、証明書利用者によって変更される可能性があります。

有効なTLS証明書を監視しているNetcraftによると、市場をリードする認証局（CA）は調査開始以来シマンテック（認証サービス事業部門がシマンテックに買収される前はベリサイン）である。Netcraftの集計によると、2015年時点でシマンテックは全証明書の3分の1弱を占め、最もアクセス数の多い100万のウェブサイトで使用されている有効な証明書の44％を占めていた。^[72] 2017年、シマンテックはTLS/SSL事業をDigiCertに売却した。^[73]更新されたレポートでは、 2019年5月以降、市場シェアで上位3位の認証局はIdenTrust、DigiCert、Sectigoであることが示された。 ^[74]

X.509証明書を選択した場合、証明書とその所有者の関係を検証し、証明書の生成、署名、および有効性の管理を行うために、証明機関と公開鍵基盤（ PKI）が必要になります。これは信頼のウェブを介して本人確認を行うよりも便利ですが、2013年の大規模監視の暴露により、証明機関がセキュリティの観点から弱点であり、証明機関が協力した場合（または侵害された場合）、中間者攻撃（MITM）を許す可能性があることが広く知られるようになりました。^{[75] [76]}

2025年4月11日、CA/ブラウザフォーラムは、すべてのパブリックTLS証明書の有効期間を2029年までに段階的に47日間に短縮することを要求する投票を承認しました。 ^[77]この投票はAppleによって提案されました。^[78]

アルゴリズム

鍵交換または鍵合意

クライアントとサーバーがTLSで保護された情報を交換する前に、データの暗号化に使用する暗号化鍵と暗号方式を安全に交換または合意する必要があります（§ 暗号方式を参照）。鍵交換/合意に使用される方式には、RSA（TLSハンドシェイクプロトコルではTLS_RSAと表記）で生成された公開鍵と秘密鍵、Diffie-Hellman（TLS_DH）、一時Diffie-Hellman（TLS_DHE）、楕円曲線Diffie-Hellman（TLS_ECDH）、一時楕円曲線Diffie-Hellman（TLS_ECDHE）、匿名Diffie-Hellman （TLS_DH_anon） ^[25] 、事前共有鍵（TLS_PSK）^[79]、セキュアリモートパスワード（TLS_SRP） ^[80]などがあります。

TLS_DH_anonおよびTLS_ECDH_anon鍵合意方式は、サーバーまたはユーザーの認証を行わないため、中間者攻撃に対して脆弱であり、ほとんど使用されません。前方秘匿性を提供するのはTLS_DHEとTLS_ECDHEのみです。

交換/合意時に使用される公開鍵証明書は、交換時に使用される公開/秘密暗号鍵のサイズも異なり、それによって提供されるセキュリティの堅牢性も異なります。2013年7月、Googleは、暗号化の強度が鍵サイズに直接関係するため、ユーザーに提供するTLS暗号化のセキュリティを強化するため、1024ビットの公開鍵の使用を中止し、2048ビットの鍵に切り替えると発表しました。^{[81] [82]}

鍵交換/合意と認証

アルゴリズム	SSL 2.0	SSL 3.0	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3	状態
RSA	はい	はい	はい	はい	はい	いいえ	RFCでTLS 1.2用に定義
DH - RSA	いいえ	はい	はい	はい	はい	いいえ
DHE - RSA（前方秘匿性）	いいえ	はい	はい	はい	はい	はい
ECDH - RSA	いいえ	いいえ	はい	はい	はい	いいえ
ECDHE - RSA（前方秘匿性）	いいえ	いいえ	はい	はい	はい	はい
DH - DSS	いいえ	はい	はい	はい	はい	いいえ
DHE - DSS（前方秘匿性）	いいえ	はい	はい	はい	はい	いいえ[83]
DHE - ECDSA（前方秘匿性）	いいえ	いいえ	いいえ	いいえ	いいえ	はい
ECDH - ECDSA	いいえ	いいえ	はい	はい	はい	いいえ
ECDHE - ECDSA（前方秘匿性）	いいえ	いいえ	はい	はい	はい	はい
DHE - EdDSA（前方秘匿性）	いいえ	いいえ	いいえ	いいえ	いいえ	はい
ECDH - EdDSA	いいえ	いいえ	はい	はい	はい	いいえ
ECDHE - EdDSA（前方秘匿性）[84]	いいえ	いいえ	はい	はい	はい	はい
PSK	いいえ	いいえ	はい	はい	はい	はい
RSA - PSK	いいえ	いいえ	はい	はい	はい	いいえ
DHE - PSK（前方秘匿性）	いいえ	いいえ	はい	はい	はい	はい
ECDHE - PSK（前方秘匿性）	いいえ	いいえ	はい	はい	はい	はい
SRP	いいえ	いいえ	はい	はい	はい	いいえ
SRP - DSS	いいえ	いいえ	はい	はい	はい	いいえ
SRP - RSA	いいえ	いいえ	はい	はい	はい	いいえ
ケルベロス	いいえ	いいえ	はい	はい	はい	?
DH -ANON（安全でない）	いいえ	はい	はい	はい	はい	いいえ
ECDH -ANON (安全でない)	いいえ	いいえ	はい	はい	はい	いいえ
GOST R 34.10-2012 [85]	いいえ	いいえ	いいえ	いいえ	はい	はい	TLS 1.2 [86]および TLS 1.3 [87]で定義されています。

暗号

公に知られている実行可能な攻撃に対する暗号セキュリティ

暗号			プロトコルバージョン						状態
タイプ	アルゴリズム	公称強度（ビット）	SSL 2.0	SSL 3.0 [n 1] [n 2] [n 3] [n 4]	TLS 1.0 [n 1] [n 3]	TLS 1.1 [n 1]	TLS 1.2 [n 1]	TLS 1.3
動作モード付きブロック暗号	AES GCM [88] [89] [n 5]	256, 128	—	—	—	—	安全な	安全な	RFCでTLS 1.2用に定義
	AES CCM [90] [91] [n 5]		—	—	—	—	安全な	安全な
	AES CBC [n 6]		—	不安	緩和策次第	緩和策次第	緩和策次第	—
	カメリア GCM [92] [n 5]	256, 128	—	—	—	—	安全な	—
	カメリア CBC [93] [92] [n 6]		—	不安	緩和策次第	緩和策次第	緩和策次第	—
	ARIA GCM [94] [n 5]	256, 128	—	—	—	—	安全な	—
	ARIA CBC [94] [n 6]		—	—	緩和策次第	緩和策次第	緩和策次第	—
	シード CBC [95] [n 6]	128	—	不安	緩和策次第	緩和策次第	緩和策次第	—
	3DES EDE CBC [n 6] [n 7]	112 [注 8]	不安	不安	不安	不安	不安	—
	GOST R 34.12-2015 マグマ CTR [85] [n 7]	256	—	—	不安	不安	不安	—	RFC  4357、9189で定義
	GOST R 34.12-2015 クズニェチク CTR [85]	256	—	—	—	—	安全な	—	RFC  9189で定義
	GOST R 34.12-2015 マグマ MGM [85] [n 5] [n 7]	256	—	—	—	—	—	不安	RFC  9367で定義
	GOST R 34.12-2015 クズニェチク MGM [85] [n 5]	256	—	—	—	—	—	安全な	RFC  9367で定義
	IDEA CBC [n 6] [n 7] [n 9]	128	不安	不安	不安	不安	—	—	TLS 1.2から削除
	DES CBC [n 6] [n 7] [n 9]	0 56	不安	不安	不安	不安	—	—
		0 40 [n 10]	不安	不安	不安	—	—	—	TLS 1.1以降では禁止されています
	RC2 CBC [n 6] [n 7]	0 40 [n 10]	不安	不安	不安	—	—	—
ストリーム暗号	ChaCha20 -ポリ1305 [100] [n 5]	256	—	—	—	—	安全な	安全な	RFCでTLS 1.2用に定義
	RC4 [n 11]	128	不安	不安	不安	不安	不安	—	TLSのすべてのバージョンで禁止されている[101]
		0 40 [n 10]	不安	不安	不安	—	—	—
なし	ヌル[n 12]	–	不安	不安	不安	不安	不安	—	RFCでTLS 1.2用に定義

注記

1. RFC  5746 を実装して、このプロトコルを破損させる可能性のある再ネゴシエーションの欠陥を修正する必要があります。
2. RFC 5746に記載されている修正を実装した場合 、SSL 3.0仕様に違反することになります。SSL 3.0仕様は、TLSとは異なりIETFが変更できません。現在のほとんどのライブラリは修正を実装しており、これによって発生する違反を無視しています。
3. BEAST攻撃は、クライアントまたはサーバー側で対策を講じない限り、SSL 3.0およびTLS 1.0で使用されるすべてのブロック暗号（CBC暗号）を破ります。§ Webブラウザを参照してください。
4. POODLE攻撃は、クライアントまたはサーバー側で対策を講じない限り、SSL 3.0で使用されるすべてのブロック暗号（CBC暗号）を破ります。§ Webブラウザを参照してください。
5. AEAD暗号 ( GCMやCCMなど) は TLS 1.2 以降でのみ使用できます。
6. 、ライブラリがタイミングサイドチャネルを排除するように注意深く記述されていない場合、ラッキー 13 攻撃によって攻撃される可能性があります。
7. Sweet32攻撃は、ブロックサイズが64ビットのブロック暗号を破ります。^[96]
8. 3DESの鍵長は168ビットであるが、3DESの有効なセキュリティ強度はわずか112ビットであり、^[97]推奨される最小値の128ビットを下回っている。^[98]
9. IDEAとDESはTLS 1.2から削除されました。^[99]
10. 40ビット強度の暗号スイートは、特定の強力な暗号化アルゴリズムを含む暗号化ソフトウェアの輸出を禁止する、後に廃止された米国規制（米国からの暗号化ソフトウェアの輸出を参照）に準拠するために、意図的に鍵長を短く設計されました。これらの弱いスイートは、TLS 1.1以降では禁止されています。
11. RC4 攻撃により SSL/TLS で使用される RC4 が弱体化または破壊されるため、すべてのバージョンの TLS で RC4 を使用することは禁止されています。
12. 認証のみ、暗号化なし。

データの整合性

データの整合性を保つためにメッセージ認証コード（MAC）が用いられる。ブロック暗号のCBCモードではHMACが用いられる。GCMやCCMモードなどの認証付き暗号化（AEAD）ではAEAD統合MACが用いられ、 HMACは用いられない。^{[6] ：§8.4} HMACベースのPRF、またはHKDFはTLSハンドシェイクに用いられる。

データの整合性

アルゴリズム	SSL 2.0	SSL 3.0	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3	状態
HMAC - MD5	はい	はい	はい	はい	はい	いいえ	RFCでTLS 1.2用に定義
HMAC - SHA1	いいえ	はい	はい	はい	はい	いいえ
HMAC - SHA256/384	いいえ	いいえ	いいえ	いいえ	はい	いいえ
AEAD	いいえ	いいえ	いいえ	いいえ	はい	はい
GOST 28147-89 IMIT [85]	いいえ	いいえ	いいえ	いいえ	はい	いいえ	RFC 9189で TLS 1.2 用に定義されています 。
GOST R 34.12-2015 AEAD [85]	いいえ	いいえ	いいえ	いいえ	いいえ	はい	RFC 9367で TLS 1.3 用に定義されています 。

アプリケーションと採用

アプリケーション設計では、 TLS は通常、トランスポート層プロトコルの上に実装され、 HTTP、FTP、SMTP、NNTP、XMPPなどのプロトコルのプロトコル関連データをすべて暗号化します。

歴史的に、TLSは主に伝送制御プロトコル（TCP）などの信頼性の高いトランスポートプロトコルで使用されてきました。しかし、ユーザーデータグラムプロトコル（UDP）やデータグラム輻輳制御プロトコル（DCCP）などのデータグラム指向トランスポートプロトコルにも実装されており、これらのプロトコルの使用法はデータグラムトランスポート層セキュリティ（DTLS ）という用語を使用して独自に標準化されています。

ウェブサイト

TLSの主な用途は、HTTPプロトコルでエンコードされたウェブサイトとウェブブラウザ間のワールドワイドウェブトラフィックを保護することです。このTLSを用いたHTTPトラフィックの保護がHTTPSプロトコルです。^[102]

ウェブサイトプロトコルのサポート（2025年9月）

プロトコル バージョン	ウェブサイト サポート[103]	セキュリティ[103] [104]
サポート対象外:SSL 2.0	0.1%	不安
サポート対象外:SSL 3.0	1.0%	不安[105]
サポート対象外:TLS 1.0	23.5%	非推奨[22] [23] [24]
サポート対象外:TLS 1.1	25.2%	非推奨[22] [23] [24]
サポート対象:TLS 1.2	100%	暗号[n 1]とクライアントの緩和策[n 2]に依存する
最新バージョン: TLS 1.3	75.3%	安全な

注記

1. 上記の§暗号表を参照
2. § Webブラウザと§ TLS/SSLに対する攻撃のセクションを参照

ウェブブラウザ

2025年3月現在、 IE11^{[アップデート]}を除くすべての主要ウェブブラウザの最新バージョンは、TLS 1.2と1.3をサポートしており、デフォルトで有効になっています。TLS 1.0と1.1は、すべての主要ブラウザの最新バージョンでデフォルトで無効になっています。

既知の攻撃に対する緩和策はまだ十分ではありません。

• POODLE攻撃に対する緩和策：一部のブラウザでは既にSSL 3.0へのフォールバックを防止していますが、この緩和策はクライアントだけでなくサーバー側でもサポートする必要があります。SSL 3.0自体を無効にするか、「anti-POODLEレコード分割」を実装するか、SSL 3.0でCBC暗号を拒否する必要があります。
  • Google Chrome: 完了 (TLS_FALLBACK_SCSV はバージョン 33 以降で実装され、SSL 3.0 へのフォールバックはバージョン 39 以降で無効になっており、SSL 3.0 自体はバージョン 40 以降でデフォルトで無効になっています。SSL 3.0 自体のサポートはバージョン 44 以降で廃止されました。)
  • Mozilla Firefox: 完了 (SSL 3.0 自体のサポートはバージョン 39以降廃止されました。SSL 3.0 自体はデフォルトで無効になっており、SSL 3.0 へのフォールバックはバージョン 34以降無効になっています。TLS_FALLBACK_SCSV はバージョン 35 以降に実装されています。ESR では、SSL 3.0 自体はデフォルトで無効になっており、TLS_FALLBACK_SCSV は ESR 31.3.0 以降に実装されています。)
  • Internet Explorer: 部分的 (バージョン 11 のみ、2015 年 4 月以降、SSL 3.0 はデフォルトで無効になっています。バージョン 10 以前では、依然として POODLE に対して脆弱です。)
  • Opera : 完了 (TLS_FALLBACK_SCSV はバージョン 20 以降に実装され、クライアント側の実装でのみ有効な「anti-POODLE レコード分割」はバージョン 25 以降に実装され、SSL 3.0 自体はバージョン 27 以降、デフォルトで無効になっています。SSL 3.0 自体はバージョン 31 以降サポートされなくなります。)
  • Safari: 完全 (OS X 10.8 以降および iOS 8 のみ、SSL 3.0 へのフォールバック中に CBC 暗号が拒否されますが、これは RC4 を使用することを意味し、これも推奨されません。SSL 3.0 自体のサポートは OS X 10.11 以降および iOS 9 では廃止されています。)
• RC4攻撃に対する緩和策:
  • Google Chrome はバージョン 43 以降、フォールバックを除き RC4 を無効にしました。RC4 は Chrome 48 以降無効になっています。
  • Firefox はバージョン 36 以降、フォールバックを除き RC4 を無効にしました。Firefox 44 では、デフォルトで RC4 が無効になりました。
  • Opera はバージョン 30 以降、フォールバックを除き RC4 を無効にしました。RC4 は Opera 35 以降無効になっています。
  • Windows 7 / Server 2008 R2 およびWindows 8 / Server 2012 向けの Internet Explorer では、RC4 の優先度が最低に設定されており、レジストリ設定によりフォールバックを除き RC4 を無効にすることもできます。Windows Phone 8.1向けの Internet Explorer 11 Mobile 11 では、有効な他のアルゴリズムが機能しない場合のフォールバックを除き、RC4 が無効になります。Edge [Legacy] および IE 11 は、2016 年 8 月に RC4 を完全に無効化します。
• FREAK攻撃に対する緩和策:
  • Android 4.0以前に含まれている Android ブラウザは、依然として FREAK 攻撃に対して脆弱です。
  • Internet Explorer 11 Mobile は依然として FREAK 攻撃に対して脆弱です。
  • Google Chrome、Internet Explorer (デスクトップ)、Safari (デスクトップとモバイル)、Opera (モバイル) には、FREAK 緩和策が導入されています。
  • すべてのプラットフォーム上の Mozilla Firefox および Windows 上の Google Chrome は、FREAK の影響を受けませんでした。

図書館

SSL および TLS プログラミング ライブラリのほとんどは、無料のオープン ソース ソフトウェアです。

• BoringSSL は、Chrome/Chromium、Android、およびその他の Google アプリケーション用の OpenSSL のフォークです。
• Botan は、C++ で書かれた BSD ライセンスの暗号化ライブラリです。
• BSAFE Micro Edition Suite: FIPS認証済みの暗号モジュールを使用したC言語で書かれたTLSのマルチプラットフォーム実装
• BSAFE SSL-J: FIPS検証済みの暗号化モジュールを使用し、独自のAPIとJSSE APIの両方を提供するTLSライブラリ
• cryptlib : 移植可能なオープンソース暗号化ライブラリ (TLS/SSL 実装を含む)
• Delphiプログラマーは、 OpenSSLを利用する Indy というライブラリ、または現在 TLS 1.3 をサポートしている ICS を使用できます。
• GnuTLS : 無料の実装 (LGPL ライセンス)
• Java Secure Socket Extension (JSSE): Java APIとプロバイダ実装（SunJSSEという名称）^[106]
• LibreSSL : OpenBSD プロジェクトによる OpenSSL のフォーク。
• MatrixSSL : デュアルライセンス実装
• Mbed TLS（旧PolarSSL）：使いやすさを重視して設計された組み込みデバイス向けの小型SSLライブラリ実装
• ネットワーク セキュリティ サービス: FIPS 140認定のオープン ソース ライブラリ
• OpenSSL : 無料の実装（BSDライセンス、一部拡張機能付き）
• Schannel :パッケージの一部としてMicrosoft Windows に実装された SSL および TLS 。
• Secure Transport : OS XおよびiOSのパッケージの一部として使用される SSL および TLS の実装。
• wolfSSL (旧称 CyaSSL): 速度とサイズに重点を置いた組み込み SSL/TLS ライブラリ。

2012年のACM コンピュータ・通信セキュリティ会議で発表された論文^[107]では、多くのアプリケーションがこれらのSSLライブラリの一部を誤って使用し、脆弱性を引き起こしていることが示されました。著者らによると、

これらの脆弱性の根本的な原因の多くは、基盤となるSSLライブラリのAPIの設計が不適切であることにあります。これらのAPIは、機密性や認証といったネットワークトンネルの高度なセキュリティ特性を表現するのではなく、SSLプロトコルの低レベルの詳細をアプリケーション開発者に公開しています。その結果、開発者はSSL APIを誤って使用し、多様なパラメータ、オプション、副作用、戻り値を誤解しがちです。

その他の用途

シンプルメール転送プロトコル（SMTP）もTLSによって保護できます。これらのアプリケーションは、公開鍵証明書を使用してエンドポイントのIDを検証します。

TLSは、ネットワークスタック全体をトンネリングしてVPNを構築するためにも使用できます。OpenVPNやOpenConnectがその例です。多くのベンダーが、TLSの暗号化機能と認証機能を認可機能と統合しています。また、1990年代後半以降、クライアント/サーバーアプリケーションのサポートを可能にするために、Webブラウザ以外のクライアント技術の開発も大きく進展しました。従来のIPsec VPN技術と比較して、TLSはファイアウォールとNATトラバーサルにおいて固有の利点を備えており、大規模なリモートアクセス環境の管理を容易にします。

TLSは、セッション開始プロトコル（SIP）アプリケーションシグナリングを保護するための標準的な方法でもあります。TLSは、 VoIPやその他のSIPベースのアプリケーションに関連するSIPシグナリングの認証と暗号化を提供するために使用できます。^[108]

安全

TLS/SSLに対する攻撃

TLS/SSL に対する重大な攻撃を以下に示します。

2015年2月、IETFはTLS/SSLに対するさまざまな既知の攻撃をまとめた情報RFC ^{[109]を発行しました。}

再交渉攻撃

2009年8月、再ネゴシエーション手順の脆弱性が発見されました。この脆弱性は、SSL 3.0およびTLSの現行バージョンすべてに対してプレーンテキストインジェクション攻撃につながる可能性があります。^[110]例えば、https接続をハイジャックできる攻撃者は、クライアントとWebサーバー間の通信の冒頭に自身のリクエストを挿入することができます。攻撃者はクライアントとサーバー間の通信を実際に復号することはできないため、これは典型的な中間者攻撃とは異なります。短期的な解決策としては、Webサーバーが再ネゴシエーションを許可しないようにすることです。通常、クライアント証明書認証が使用されない限り、他の変更は必要ありません。この脆弱性を修正するために、TLSの再ネゴシエーション指示拡張が提案されました。^[111]この拡張により、クライアントとサーバーは、再ネゴシエーションのハンドシェイクに以前のハンドシェイクに関する情報を含め、検証する必要があります。^[112]この拡張は、いくつかのライブラリによって実装されています。^{[113] [114] [115]}

ダウングレード攻撃:FREAK攻撃とログジャム攻撃

プロトコルダウングレード攻撃(バージョン ロールバック攻撃とも呼ばれる) は、Web サーバーを騙して、安全でないとして長い間放棄されてきた以前のバージョンの TLS (SSLv2 など) との接続をネゴシエートさせます。

False Start ^{[116] （Google Chrome [117]}で採用・有効化）やSnap Startなど、元のプロトコルに対する以前の変更では、限定的なTLSプロトコルダウングレード攻撃^[118]を引き起こしたり、クライアントからサーバーに送信される暗号スイートリストを変更できたりしたと報告されています。これにより、攻撃者は暗号スイートの選択に影響を与え、ネゴシエートされた暗号スイートをダウングレードして、より弱い対称暗号化アルゴリズムやより弱い鍵交換を使用しようとする可能性があります。^{[119] 2012年に開催された}ACMの コンピューターおよび通信セキュリティに関する会議で発表された論文では、False Start拡張が危険にさらされていることが示されました。特定の状況下では、攻撃者がオフラインで暗号化鍵を復元し、暗号化されたデータにアクセスできるようになる可能性があります。^[120]

暗号ダウングレード攻撃は、サーバーとクライアントに暗号的に弱い鍵を用いた接続を強制的にネゴシエートさせる可能性があります。2014年には、OpenSSLスタック、 Androidのデフォルトウェブブラウザ、および一部のSafariブラウザに影響を与えるFREAKと呼ばれる中間者攻撃が発見されました。^[121]この攻撃では、サーバーを騙して、暗号的に弱い512ビットの暗号鍵を用いたTLS接続をネゴシエートさせました。

Logjamは、 2015年5月に発見されたセキュリティ脆弱性であり、 1990年代に遡る従来の「輸出グレード」 512ビットDiffie-Hellman群を使用するオプションを悪用します。 ^{[122] Logjamは、脆弱なサーバーを暗号的に脆弱な512ビットDiffie-Hellman群にダウングレードさせます。これにより、攻撃者はクライアントとサーバーが}Diffie-Hellman鍵交換を使用して決定する鍵を推測できるようになります。

クロスプロトコル攻撃：DROWN

DROWN攻撃は、最新のSSL/TLSプロトコルスイートをサポートするサーバーを攻撃するエクスプロイトです。サーバーが旧式で安全でないSSLv2プロトコルをサポートしていることを悪用し、本来であれば安全な最新プロトコルを使用した接続を攻撃します。^{[123] [124]} DROWNは、特定の実装エラーではなく、使用されているプロトコルとサーバー設定の脆弱性を悪用します。DROWNの詳細は、2016年3月にエクスプロイトに対するパッチと共に発表されました。当時、TLSで保護されたウェブサイトのうち、上位100万件のうち81,000件以上がDROWN攻撃の脆弱性を抱えていました。^[124]

ビースト攻撃

2011年9月23日、研究者の Thai Duong 氏と Juliano Rizzo 氏は、TLS 1.0の以前から知られている暗号ブロック連鎖( CBC ) の脆弱性に対し、 Java アプレットを使用して同一生成元ポリシー制約に違反するBEAST ( Browser Exploit Against SSL/TLS ) ^[125]と呼ばれる概念実証を行なった: ^{[126] [127]連続する 2 つの暗号文ブロック C0、C1 を観測する攻撃者は、次の平文ブロック}P2 = x ⊕ C0 ⊕ C1を選択することで、平文ブロック P1 が x に等しいかどうかをテストできる。CBC 演算によれば、C2 = E(C1 ⊕ P2) = E(C1 ⊕ x ⊕ C0 ⊕ C1) = E(C0 ⊕ x) となり、 x = P1であれば C1 と等しくなる。この脆弱性は2002年にフィリップ・ロガウェイ^[128]によって最初に発見されましたが、これまで実用的な攻撃方法は実証されていませんでした。攻撃の脆弱性は2006年にTLS 1.1で修正されましたが、この攻撃のデモンストレーション以前はTLS 1.1は広く採用されていませんでした。

ストリーム暗号としてのRC4はBEAST攻撃の影響を受けないため、サーバー側でのBEAST攻撃の緩和策として広く利用されていました。しかし、2013年に研究者らがRC4のさらなる脆弱性を発見したため、サーバー側でのRC4の有効化は推奨されなくなりました。^[129]

ChromeとFirefox自体はBEAST攻撃に対して脆弱ではありませんが^{[130] [131]}、MozillaはBEASTのような攻撃を軽減するためにNSSライブラリを更新しました。NSSはMozilla FirefoxとGoogle ChromeでSSLを実装するために使用されています。SSL仕様の実装に欠陥がある一部のウェブサーバーは、その結果として動作を停止する可能性があります。^[132]

マイクロソフトは2012年1月10日にセキュリティ情報MS12-006をリリースし、Windowsセキュアチャネル（ Schannel）コンポーネントがサーバー側から暗号化されたネットワークパケットを送信する方法を変更することでBEASTの脆弱性を修正しました。 ^{[133]古いバージョンのWindows（} Windows 7、Windows 8、Windows Server 2008 R2 ）で実行されるInternet Explorer（バージョン11より前）のユーザーは、TLSの使用を1.1以上に制限できます。

Appleは、2013年10月22日にリリースされたOS X Mavericksで1/n-1分割を実装し、デフォルトで有効にすることでBEASTの脆弱性を修正しました。^[134]

犯罪と侵害攻撃

BEAST攻撃の作成者は、後のCRIME攻撃の作成者でもあります。この攻撃では、 TLSとともにデータ圧縮が使用されている場合に、攻撃者がWeb Cookieの内容を復元できます。 ^{[135] [136]秘密の}認証Cookieの内容を復元するために使用されると、攻撃者は認証されたWebセッションでセッションハイジャックを実行できます。

CRIME 攻撃は、TLS に限らず、 SPDYやHTTPなどのアプリケーション層プロトコルを含む多数のプロトコルに対して効果的に機能する一般的な攻撃として提示されましたが、 TLS と SPDY に対するエクスプロイトのみがブラウザーとサーバーで実証され、大部分が緩和されました。HTTP圧縮に対する CRIME エクスプロイトは、この脆弱性が SPDY と TLS 圧縮を合わせたものよりもさらに広範囲に及ぶ可能性があると CRIME の作成者が警告しているにもかかわらず、まったく緩和されていません。 2013 年には、HTTP 圧縮に対する CRIME 攻撃の新しいインスタンスであるBREACHが発表されました。CRIME 攻撃に基づくと、BREACH 攻撃は、攻撃者が被害者をだまして悪意のある Web リンクにアクセスさせるか、ユーザーがアクセスしている有効なページ (攻撃者の制御下にあるワイヤレス ネットワークなど) にコンテンツを挿入できれば、TLS で暗号化された Web トラフィックからログイン トークン、電子メール アドレスなどの機密情報を 30 秒ほどで抽出できます (抽出するバイト数によって異なります)。^[137] TLSとSSLのすべてのバージョンは、使用されている暗号化アルゴリズムや暗号に関係なく、BREACHのリスクがあります。^[138] TLS圧縮やSPDYヘッダー圧縮をオフにすることで防御できた以前のCRIMEとは異なり、BREACHはHTTP圧縮を悪用します。HTTP圧縮は、事実上すべてのWebサーバーがユーザーのデータ転送速度を向上させるためにHTTP圧縮に依存しているため、現実的にオフにすることはできません。^[137]これはTLSの既知の制限であり、保護することを意図したアプリケーション層のデータに対する選択平文攻撃の影響を受けやすいためです。

パディングに対するタイミング攻撃

以前の TLS バージョンは、 2002 年に発見されたパディング オラクル攻撃に対して脆弱でした。2013 年には、ラッキー サーティーン攻撃と呼ばれる新たな亜種が公開されました。

一部の専門家^[98]は、トリプルDES CBCの使用を避けることを推奨しています。Windows XPのSSL/TLSライブラリを使用するプログラム（Windows XP上のInternet Explorerなど）をサポートするために開発された最後の暗号はRC4とトリプルDESであり、RC4は現在非推奨となっているため（RC4攻撃に関する議論を参照）、XP上でこのライブラリを使用するプログラムでは、いかなるバージョンのSSLもサポートすることが困難です。

2014年には、TLS仕様のEncrypt-then-MAC拡張として修正がリリースされました。^[139] TLS 1.2では、AES_GCM暗号のみを使用することでラッキー・サーティーン攻撃を軽減できますが、AES_CBCは依然として脆弱です。SSLは、クライアントとサーバー間の安全なデータ転送という本来の用途に加えて、安全でないネットワークを介した電子メール、VoIP、その他の通信を保護することができます。^[2]

プードル攻撃

2014年10月14日、Googleの研究者はSSL 3.0の設計における脆弱性を公開しました。この脆弱性により、SSL 3.0のCBCモードの動作はパディング攻撃に対して脆弱になります（CVE - 2014-3566）。研究者たちはこの攻撃をPOODLE（Padding Oracle On Downgraded Legacy Encryption）と名付けました。攻撃者は平均して256回のSSL 3.0リクエストを行うだけで、暗号化されたメッセージの1バイトを解読できます。^[105]

この脆弱性はSSL 3.0にのみ存在し、ほとんどのクライアントとサーバーはTLS 1.0以上をサポートしていますが、主要ブラウザはすべて、新しいバージョンのTLSとのハンドシェイクが失敗した場合、ユーザーまたは管理者がSSL 3.0を無効にするオプションを提供し、ユーザーまたは管理者がそれを実行しない限り、自発的にSSL 3.0にダウングレードします^[要出典]。したがって、中間者攻撃者はまずバージョンロールバック攻撃を実行し、その後この脆弱性を悪用することができます。^[105]

2014年12月8日、パディングバイト要件を適切に実施していないTLS実装に影響を与えるPOODLEの亜種が発表されました。^[140]

RC4攻撃

RC4の安全性を破る攻撃が存在したにもかかわらず、SSLとTLSで使用されている方法に基づいて、RC4に基づくSSLとTLSの暗号スイートは2013年より前まで安全であると考えられていました。2011年には、RC4スイートはBEAST攻撃の回避策として実際に推奨されました。^[141] 2013年3月に公開された新しい形式の攻撃は、TLSでRC4を破る実現可能性を決定的に実証し、BEASTの良い回避策ではなかったことを示唆しました。^[104] AlFardan、Bernstein、Paterson、Poettering、およびSchuldtによって、RC4キーテーブルで新たに発見された統計的バイアス^[142]を使用して、多数のTLS暗号化で平文の一部を復元する攻撃シナリオが提案されました。^{[143] [144]} 2013年7月8日に、TLSとSSLにおけるRC4の解読に13× ^{220回の暗号化を必要とする攻撃が発表され、その後、2013年8月の}USENIXセキュリティシンポジウムでの付随プレゼンテーションで「実行可能」と説明されました^{。[145] [146]} 2015年7月、攻撃のその後の改良により、RC4で暗号化されたTLSのセキュリティを破ることがますます現実的になりました。^[147]

多くの最新ブラウザはBEAST攻撃を阻止するように設計されているため（Mac OS X 10.7以前、iOS 6以前、Windows版Safariを除く。§ ウェブブラウザを参照）、RC4はTLS 1.0ではもはや適切な選択肢ではありません。過去にBEAST攻撃の影響を受けたCBC暗号が、保護のためのより一般的な選択肢となっています。^[98] MozillaとMicrosoftは、可能な限りRC4を無効にすることを推奨しています。^{[148] [149]} 2015年2月、RC4暗号スイートの使用はTLSのすべてのバージョンで正式に禁止されました。^[101]

2015年9月1日、マイクロソフト、グーグル、モジラは、2016年初頭に各社のブラウザ（ Microsoft Edge [レガシー]、Windows 7/8.1/10上のInternet Explorer 11 、 Firefox、Chrome ）でRC4暗号スイートをデフォルトで無効化すると発表した。 ^{[150] [151] [152]}

切り捨て攻撃

TLS（ログアウト）トランケーション攻撃は、被害者のアカウントログアウト要求をブロックし、ユーザーが気付かないうちにウェブサービスにログインしたままにします。ログアウト要求が送信されると、攻撃者は暗号化されていないTCP FINメッセージ（送信者からのデータはもうありません）を挿入して接続を閉じます。そのため、サーバーはログアウト要求を受信せず、異常終了に気付きません。^[153]

2013年7月に公開された^{[154] [155]}攻撃では、GmailやHotmailなどのウェブサービスに、ユーザーにサインアウトに成功したことを通知するページが表示され、ユーザーのブラウザがサービスに対する承認を維持していることが確認され、その後ブラウザにアクセスした攻撃者がユーザーのログインアカウントにアクセスして制御を乗っ取ることができるようになります。この攻撃は、被害者のコンピュータにマルウェアをインストールする必要はありません。攻撃者は、被害者とウェブサーバーの間に身を置くだけで済みます（たとえば、不正なワイヤレスホットスポットを設定するなど）。^[153]この脆弱性には、被害者のコンピュータへのアクセスも必要です。別の可能性として、FTPを使用する場合、データ接続のデータストリームに誤ったFINが含まれる可能性があり、close_notifyアラートを交換するためのプロトコルルールが遵守されていない場合、ファイルが切り捨てられる可能性があります。

DTLSに対する平文攻撃

2013年2月、ロンドン大学ロイヤル・ホロウェイ校の2人の研究者が、暗号ブロック連鎖モードの暗号化が使用されたDTLSのOpenSSLまたはGnuTLS実装を使用して、DTLS接続から平文（の一部）を復元できるタイミング攻撃[156]を発見しまし^た。

不道徳なPAC攻撃

2016年半ばに発見されたこの攻撃は、Webプロキシ自動検出プロトコル（WPAD）の脆弱性を悪用し、ユーザーがTLS対応のWebリンク経由でアクセスしようとしているURLを公開します。^[157] URLの公開は、アクセス先のWebサイトだけでなく、URLがユーザー認証に使用される場合もあるため、ユーザーのプライバシーを侵害する可能性があります。GoogleやDropboxなどのドキュメント共有サービスも、URLに含まれるセキュリティトークンをユーザーに送信することで機能します。このようなURLを入手した攻撃者は、被害者のアカウントやデータに完全にアクセスできる可能性があります。

このエクスプロイトは、ほぼすべてのブラウザとオペレーティング システムに対して機能します。

Sweet32攻撃

Sweet32攻撃は、誕生日攻撃と中間者攻撃、またはウェブページへの悪意のあるJavaScriptの挿入を悪用することで、TLSで使用されるCBCモードのすべての64ビットブロック暗号を破ります。中間者攻撃またはJavaScriptの挿入の目的は、攻撃者が誕生日攻撃を仕掛けるのに十分なトラフィックを捕捉できるようにすることです。^[158]

実装エラー:Heartbleedバグ、BERserk攻撃、Cloudflareのバグ

Heartbleedバグは、広く使用されているOpenSSL暗号化ソフトウェアライブラリにおけるSSL/TLS実装に特有の深刻な脆弱性で、バージョン1.0.1から1.0.1fに影響を及ぼします。2014年4月に報告されたこの脆弱性により、攻撃者は通常は保護されているはずのサーバーから秘密鍵を盗むことができます。 ^[159] Heartbleedバグにより、インターネット上の誰でも、脆弱なバージョンのOpenSSLソフトウェアによって保護されているシステムのメモリを読み取ることができます。これにより、サービスプロバイダーの識別やトラフィックの暗号化に使用される公開証明書に関連付けられた秘密鍵、ユーザー名とパスワード、実際のコンテンツが侵害されます。これにより、攻撃者は通信を盗聴し、サービスやユーザーから直接データを盗み、サービスやユーザーになりすますことが可能になります。^[160]この脆弱性は、SSLまたはTLSプロトコル仕様の欠陥ではなく、OpenSSLソフトウェアのバッファオーバーリードバグによって引き起こされます。

2014年9月、ダニエル・ブライヘンバッハー氏によるPKCS#1 v1.5 RSA署名偽造脆弱性^[161]の亜種が、Intel Security Advanced Threat Researchによって発表されました。BERserkと呼ばれるこの攻撃は、一部のSSL実装における公開鍵署名のASN.1長のデコードが不完全であることに起因しており、公開鍵署名を偽造することで中間者攻撃を可能とします。^[162]

2015年2月、一部のLenovoノートパソコンにスーパーフィッシュアドウェアが隠れてプリインストールされていることがメディアで報じられた後、 ^[163]研究者は、影響を受けるLenovoマシンの信頼されたルート証明書が安全でないことを突き止めました。これは、会社名であるKomodiaをパスフレーズとして使用してキーに簡単にアクセスできるためです。^[164] Komodiaライブラリは、ペアレンタルコントロールと監視のためにクライアント側のTLS / SSLトラフィックを傍受するように設計されていましたが、Superfishを含む多くのアドウェアプログラムでも使用されており、コンピューターユーザーに気付かれずに密かにインストールされることがよくありました。次に、これらの潜在的に迷惑なプログラムは破損したルート証明書をインストールし、攻撃者がWebトラフィックを完全に制御し、偽のWebサイトを本物であることを確認することを可能にしました。

2016年5月、Visa Inc.が所有するデンマークのHTTPSで保護されたウェブサイト数十件が攻撃に対して脆弱であり、ハッカーが悪意のあるコードや偽造コンテンツを訪問者のブラウザに挿入できるという報告がありました。^[165]攻撃が成功したのは、影響を受けたサーバーで使用されていたTLS実装が、各TLSハンドシェイクが一意であることを保証するために、一度だけ使用されることを意図した乱数（ナンス）を誤って再利用したためです。 ^[165]

2017年2月、HTMLを解析するコード内の1文字の誤入力に起因する実装エラーにより、Cloudflareサーバーでバッファオーバーフローエラーが発生しました。2014年に発見されたHeartbleedバグと同様の影響を持つこのオーバーフローエラー（通称Cloudbleed）により、サーバー上で実行されているプログラムのメモリ内のデータが、権限のない第三者によって読み取られる可能性がありました。本来はTLSで保護されるべきデータです。^[166]

攻撃に対して脆弱なウェブサイトの調査

2021年7月現在^{[アップデート]}、Trustworthy Internet MovementはTLS攻撃に対して脆弱なウェブサイトの割合を推定しました。^[103]

最も人気のあるウェブサイトのTLS脆弱性の調査

攻撃	安全
	不安	状況によります	安全な	他の
再交渉攻撃	安全でない再交渉を支持する人は0.1%未満	両方を支持：<0.1%	99.7%が 安全な再交渉を支持	0.3% サポートなし
RC4攻撃	0.2% が 最新のブラウザで使用される RC4 スイートをサポート	3.0% は一部の RC4 スイートをサポート	96.9% サポートなし	—
TLS圧縮（CRIME攻撃）	脆弱性0%	—	—	—
ハートブリード	脆弱性0%	—	—	—
ChangeCipherSpecインジェクション攻撃	脆弱性と悪用可能性< 0.1%	0.1%未満で 脆弱、悪用不可	99.5%は 脆弱ではない	0.4% 不明
TLSに対するPOODLE攻撃 （SSL 3.0に対するオリジナルのPOODLEは含まれていません）	脆弱性と悪用可能性< 0.1%	—	99.9%は 脆弱ではない	0.1% 不明
プロトコルのダウングレード	4.1% 格下げ防御は支持されない	—	80.2% 格下げの防御を支持	15.7% 不明

前方秘匿性

前方秘匿性とは、公開鍵と秘密鍵のセットから生成されたセッション鍵は、将来秘密鍵の 1 つが侵害されたとしても侵害されないことを保証する暗号化システムの特性です。^[167]前方秘匿性がないと、サーバーの秘密鍵が侵害された場合、そのサーバー証明書を使用する将来のすべての TLS 暗号化セッションが侵害されるだけでなく、それを使用した過去のセッションもすべて侵害されます (これらの過去のセッションが送信時に傍受され、保存されている場合)。^[168] TLS の実装では、セッション鍵を確立するために一時的なDiffie–Hellman 鍵交換の使用を要求することで前方秘匿性を提供でき、いくつかの有名な TLS 実装では、この方法のみを採用しています。たとえば、OpenSSLを使用するGmailやその他の Google HTTPS サービスです。^[169]ただし、TLS をサポートする多くのクライアントとサーバー (ブラウザーと Web サーバーを含む) は、このような制限を実装するように構成されていません。^{[170] [171]}実際には、ウェブサービスが前方秘匿性を実装するためにディフィー・ヘルマン鍵交換を使用しない限り、そのサービスとの間の暗号化されたウェブトラフィックはすべて、第三者がサーバーのマスター（秘密）鍵を入手すれば（例えば裁判所命令によって）、復号化される可能性がある。^[172]

Diffie-Hellman鍵交換が実装されている場合でも、サーバー側のセッション管理メカニズムが前方秘匿性に影響を与える可能性があります。TLSセッションチケット（TLS拡張機能）を使用すると、前方秘匿性暗号スイートを含む他のネゴシエートされたTLSパラメータに関係なく、セッションはAES128-CBC-SHA256によって保護されます。また、長期間有効なTLSセッションチケット鍵は、前方秘匿性の実装を阻害します。^{[173] [174] [175]}スタンフォード大学が2014年に実施した調査では、調査対象となった473,802台のTLSサーバーのうち、前方秘匿性をサポートするために一時的なDiffie-Hellman（DHE）鍵交換を導入しているサーバーの82.9%が、弱いDiffie-Hellmanパラメータを使用していたことが明らかになりました。これらの弱いパラメータの選択は、サーバーが提供しようとしている前方秘匿性の有効性を損なう可能性があります。^[176]

2011年後半以降、GoogleはGmailサービスのユーザーに対し、デフォルトでTLSによる前方秘匿性を提供しているほか、 Google Docsや暗号化検索などのサービスも提供している。^[177] 2013年11月以降、Twitterは自社サービスのユーザーにTLSによる前方秘匿性を提供している。^[178] 2019年8月現在^{[アップデート]}、TLS対応ウェブサイトの約80%が、ほとんどのウェブブラウザに前方秘匿性を提供する暗号スイートを使用するように設定されている。^[103]

TLSインターセプション

TLSインターセプション（特にHTTPSプロトコルに適用される場合、HTTPSインターセプション）とは、暗号化されたデータストリームを傍受し、復号、読み取り、場合によっては操作を行い、その後再暗号化してデータを再び送信する手法です。これは「透過プロキシ」を介して行われます。インターセプションソフトウェアは、着信TLS接続を切断し、HTTPプレーンテキストを検査した後、宛先への新たなTLS接続を確立します。^[179]

TLS / HTTPS傍受は、コンピュータウイルスやその他のマルウェアなどの悪意のあるコンテンツがネットワークに侵入するのをスキャンして防御するために、ネットワークオペレータによる情報セキュリティ対策として使用されます。^[179]このようなコンテンツは、HTTPSやその他の安全なプロトコルの日常的な使用の結果としてますます暗号化によって保護されている限り検出されません。

TLS/HTTPS 傍受の重大な欠点は、それ自体が新たなセキュリティリスクをもたらすことです。特に注目すべき制限の一つは、ネットワークトラフィックが暗号化されていない状態で利用可能になるポイントが存在することです。そのため、攻撃者は本来安全なコンテンツにアクセスするために、特にこのポイントを攻撃する動機を得ます。また、この傍受により、ネットワーク事業者、あるいはその傍受システムにアクセスした人物は、ネットワークユーザーに対して中間者攻撃を実行することも可能になります。2017年の調査では、「HTTPS 傍受は驚くほど広範に利用されており、傍受製品全体として接続セキュリティに劇的な悪影響を及ぼしている」ことが明らかになっています。^[179]

プロトコルの詳細

TLSプロトコルは、交換されるデータを特定の形式（下記参照）でカプセル化したレコードを交換します。各レコードは、接続状態に応じて、圧縮、パディング、メッセージ認証コード（MAC）の追加、または暗号化が可能です。各レコードには、カプセル化されるデータのタイプを指定するコンテンツタイプフィールド、長さフィールド、およびTLSバージョンフィールドがあります。カプセル化されるデータは、TLS自体の制御メッセージまたは手順メッセージの場合もあれば、TLSで転送する必要があるアプリケーションデータだけの場合もあります。TLSによるアプリケーションデータの交換に必要な仕様（暗号スイート、鍵など）は、データを要求するクライアントと要求に応答するサーバー間の「TLSハンドシェイク」で合意されます。したがって、このプロトコルは、TLSで転送されるペイロードの構造と、転送を確立および監視する手順の両方を定義します。

TLSハンドシェイク

タイミング情報を含む TLS 1.2 ハンドシェイク全体の簡略化された図

接続が開始されると、レコードは「制御」プロトコル、つまりハンドシェイクメッセージングプロトコル（コンテンツタイプ22）をカプセル化します。このプロトコルは、TLSによる実際のアプリケーションデータの交換において、両側で必要なすべての情報を交換するために使用されます。メッセージのフォーマットと交換順序を定義します。これらはクライアントとサーバーの要求に応じて変化する可能性があります。つまり、接続を確立するには複数の手順が考えられます。この最初の交換により、TLS接続が成功（双方がTLSによるアプリケーションデータの転送準備完了）するか、アラートメッセージ（以下に指定）が送信されます。

基本的なTLSハンドシェイク

以下に、サーバー（クライアントではない）が証明書によって認証されるハンドシェイクを示す一般的な接続例を示します。

1. 交渉段階:
   • クライアントは、サポートするTLSプロトコルの最高バージョン、乱数、推奨暗号スイートのリスト、および推奨圧縮方式のリストを指定してClientHelloメッセージを送信します。クライアントが再開ハンドシェイクを実行しようとする場合、セッションIDを送信することがあります。クライアントがアプリケーション層プロトコルネゴシエーションを使用できる場合、 HTTP/2などのサポートされるアプリケーションプロトコルのリストを含めることがあります。
   • サーバーは、クライアントが提示した選択肢から選択されたプロトコルバージョン、乱数、暗号スイート、および圧縮方式を含むServerHelloメッセージで応答します。ハンドシェイクの再開を確認または許可するために、サーバーはセッションIDを送信する場合があります。選択されるプロトコルバージョンは、クライアントとサーバーの両方がサポートする最も高いバージョンである必要があります。例えば、クライアントがTLSバージョン1.1をサポートし、サーバーがバージョン1.2をサポートしている場合、バージョン1.1を選択する必要があります。バージョン1.2は選択しないでください。
   • サーバーは証明書メッセージを送信します（選択された暗号スイートによっては、サーバーによって省略される場合があります）。^[180]
   • サーバーはServerKeyExchangeメッセージを送信します（選択された暗号スイートによっては、サーバーによって省略される場合があります）。このメッセージは、DHE、ECDHE、およびDH_anonのすべての暗号スイートに対して送信されます。^[25]
   • サーバーは、ハンドシェイク ネゴシエーションが完了したことを示すServerHelloDoneメッセージを送信します。
   • クライアントはClientKeyExchangeメッセージで応答します。このメッセージには、 PreMasterSecretまたは公開鍵が含まれる場合もあれば、何も含まれない場合もあります (これも、選択した暗号によって異なります)。このPreMasterSecret は、サーバー証明書の公開鍵を使用して暗号化されます。
   • クライアントとサーバーは、乱数とPreMasterSecretを用いて、「マスターシークレット」と呼ばれる共通秘密鍵を算出します。この接続におけるその他の鍵データ（IVなどのセッション鍵、対称暗号化鍵、MAC鍵^{[181] ）は、このマスターシークレット（およびクライアントとサーバーが生成した乱数）から導出され、慎重に設計された}疑似乱数関数を通して渡されます。
2. ここで、クライアントはChangeCipherSpecレコードを送信します。これは基本的に、サーバーに「今後送信するすべての内容は認証されます（サーバー証明書に暗号化パラメータが存在する場合は暗号化されます）」と伝えます。ChangeCipherSpec 自体は、コンテンツ タイプ 20 のレコード レベルのプロトコルです。
   • クライアントは、以前のハンドシェイク メッセージのハッシュと MAC を含む、認証され暗号化されたFinishedメッセージを送信します。
   • サーバーはクライアントのFinishedメッセージを復号し、ハッシュとMACを検証します。復号または検証に失敗した場合、ハンドシェイクは失敗したとみなされ、接続は終了されます。
3. 最後に、サーバーはChangeCipherSpecを送信し、クライアントに「今後伝える内容はすべて認証されます (暗号化がネゴシエートされた場合は暗号化されます)」と伝えます。
   • サーバーは認証され暗号化されたFinishedメッセージを送信します。
   • クライアントは、前の手順でサーバーが実行したのと同じ復号化および検証手順を実行します。
4. アプリケーションフェーズ：この時点で「ハンドシェイク」が完了し、アプリケーションプロトコルが有効になり、コンテンツタイプは23になります。クライアントとサーバー間で交換されるアプリケーションメッセージも認証され、必要に応じてFinishedメッセージと同様に暗号化されます。それ以外の場合、コンテンツタイプは25を返し、クライアントは認証されません。

クライアント認証TLSハンドシェイク

次の完全な例は、両方のピア間で交換された証明書を使用して、TLS 経由でクライアントが認証されることを示しています (上記の例のようにサーバーに加えて、相互認証を参照してください)。

1. 交渉フェーズ:
   • クライアントは、サポートする最高の TLS プロトコル バージョン、乱数、推奨される暗号スイートと圧縮方法のリストを指定してClientHelloメッセージを送信します。
   • サーバーは、クライアントが提示した選択肢の中から選択されたプロトコルバージョン、乱数、暗号スイート、圧縮方式を含むServerHelloメッセージで応答します。また、サーバーは、ハンドシェイクを再開するために、メッセージの一部としてセッションIDを送信することもあります。
   • サーバーは証明書メッセージを送信します（選択された暗号スイートによっては、サーバーによって省略される場合があります）。^[180]
   • サーバーはServerKeyExchangeメッセージを送信します（選択された暗号スイートによっては、サーバーによって省略される場合があります）。このメッセージは、DHE、ECDHE、およびDH_anonのすべての暗号スイートに対して送信されます。^[1]
   • サーバーは、クライアントに証明書を要求するために、CertificateRequestメッセージを送信します。
   • サーバーは、ハンドシェイク ネゴシエーションが完了したことを示すServerHelloDoneメッセージを送信します。
   • クライアントは証明書メッセージで応答します。このメッセージにはクライアントの証明書が含まれますが、秘密キーは含まれません。
   • クライアントはClientKeyExchangeメッセージを送信します。このメッセージには、 PreMasterSecretまたは公開鍵が含まれる場合もあれば、何も含まれない場合もあります (これも、選択した暗号によって異なります)。このPreMasterSecret は、サーバー証明書の公開鍵を使用して暗号化されます。
   • クライアントはCertificateVerifyメッセージを送信します。これは、クライアントの証明書の秘密鍵を使用して、以前のハンドシェイクメッセージに署名したものです。この署名は、クライアントの証明書の公開鍵を使用して検証できます。これにより、サーバーはクライアントが証明書の秘密鍵にアクセスでき、証明書を所有していることを通知します。
   • クライアントとサーバーは、乱数とPreMasterSecretを使用して、「マスターシークレット」と呼ばれる共通の秘密鍵を算出します。この接続におけるその他のすべての鍵データ（「セッションキー」）は、このマスターシークレット（およびクライアントとサーバーが生成した乱数）から生成され、慎重に設計された疑似乱数関数に渡されます。
2. ここで、クライアントはChangeCipherSpecレコードを送信します。これは基本的に、サーバーに「今後送信するすべての内容は認証されます (暗号化がネゴシエートされた場合は暗号化されます)」と伝えます。ChangeCipherSpec 自体はレコード レベルのプロトコルであり、タイプは 22 ではなく 20 です。
   • 最後に、クライアントは、以前のハンドシェイク メッセージのハッシュと MAC を含む暗号化されたFinishedメッセージを送信します。
   • サーバーはクライアントのFinishedメッセージを復号し、ハッシュとMACを検証します。復号または検証に失敗した場合、ハンドシェイクは失敗したとみなされ、接続は切断されます。
3. 最後に、サーバーはChangeCipherSpecを送信し、クライアントに「今後伝える内容はすべて認証されます (暗号化がネゴシエートされた場合は暗号化されます)」と伝えます。
   • サーバーは独自の暗号化されたFinishedメッセージを送信します。
   • クライアントは、前の手順でサーバーが実行したのと同じ復号化および検証手順を実行します。
4. アプリケーション フェーズ: この時点で、「ハンドシェイク」が完了し、コンテンツ タイプ 23 でアプリケーション プロトコルが有効になります。クライアントとサーバー間で交換されるアプリケーション メッセージも、Finishedメッセージとまったく同じように暗号化されます。

TLSハンドシェイクの再開

公開鍵暗号（RSAなど）は、計算能力の面で比較的コストがかかります。TLSは、ハンドシェイクメカニズムにおいてこれらの操作を回避するための安全なショートカット、すなわち再開セッションを提供します。再開セッションは、セッションIDまたはセッションチケットを使用して実装されます。

パフォーマンス上の利点に加え、再開されたセッションは、元のセッションと再開されたセッションの両方が同じクライアントから発信されることを保証するため、シングルサインオンにも使用できます。これは、FTP over TLS/SSLプロトコルにおいて特に重要です。FTP over TLS/SSLプロトコルでは、中間者攻撃（攻撃者がセカンダリデータ接続の内容を傍受する）の脅威にさらされることになります。^[182]

TLS 1.3 ハンドシェイク

TLS 1.3 ハンドシェイクは、以前のバージョンの TLS/SSL で必要だった 2 回のラウンド トリップと比較して、1 回のラウンド トリップに凝縮されました。

ハンドシェイクを開始するには、クライアントはサーバーがどの鍵交換アルゴリズムを選択するかを推測し、サポートされている暗号のリスト（クライアントの優先順位順）と、その鍵交換アルゴリズムの一部または全部に対する公開鍵を含むClientHelloメッセージをサーバーに送信します。クライアントが鍵交換アルゴリズムの推測に成功した場合、ハンドシェイクから1往復の通信が省略されます。ClientHelloを受信したサーバーは、暗号を選択し、自身の公開鍵を含むServerHelloをサーバーに送り返します。その後、サーバー証明書とFinishedメッセージが続きます。^[183]

クライアントがサーバーの完了メッセージを受信した後、どの暗号スイートを使用するかをサーバーと調整します。^[184]

セッションID

通常のフルハンドシェイクでは、サーバーはServerHelloメッセージの一部としてセッションIDを送信します。クライアントはこのセッションIDをサーバーのIPアドレスとTCPポートに関連付けます。これにより、クライアントが再度同じサーバーに接続する際に、セッションIDを使用してハンドシェイクを短縮できます。サーバー側では、セッションIDは以前にネゴシエートされた暗号パラメータ、具体的には「マスターシークレット」にマッピングされます。両サイドで同じ「マスターシークレット」が保持されていない場合、再開されたハンドシェイクは失敗します（これにより、盗聴者がセッションIDを使用することを防止します）。ClientHelloメッセージとServerHelloメッセージに含まれるランダムデータにより、生成される接続キーが以前の接続とは異なることがほぼ保証されます。RFCでは、このタイプのハンドシェイクは短縮ハンドシェイクと呼ばれています。文献では、リスタートハンドシェイクとも呼ばれています。

1. 交渉段階:
   • クライアントは、サポートするTLSプロトコルの最高バージョン、乱数、推奨される暗号スイートと圧縮方式のリストを指定してClientHelloメッセージを送信します。メッセージには、前回のTLS接続のセッションIDが含まれます。
   • サーバーは、クライアントが提示した選択肢から選択されたプロトコルバージョン、乱数、暗号スイート、圧縮方式を含むServerHelloメッセージで応答します。サーバーがクライアントから送信されたセッションIDを認識した場合、同じセッションIDで応答します。クライアントはこれを用いて、再開ハンドシェイクが実行されていることを認識します。サーバーがクライアントから送信されたセッションIDを認識しなかった場合、サーバーはセッションIDとして異なる値を送信します。これは、再開ハンドシェイクが実行されないことをクライアントに通知します。この時点で、クライアントとサーバーの両方が、この接続に使用する鍵データを生成するための「マスターシークレット」とランダムデータを保持しています。
2. サーバーはChangeCipherSpecレコードを送信し、クライアントに「これから伝える内容はすべて暗号化されます」と伝えます。ChangeCipherSpec 自体はレコードレベルのプロトコルであり、タイプは 22 ではなく 20 です。
   • 最後に、サーバーは、以前のハンドシェイク メッセージのハッシュと MAC を含む暗号化されたFinishedメッセージを送信します。
   • クライアントはサーバーのFinishedメッセージを復号し、ハッシュとMACを検証しようとします。復号または検証に失敗した場合、ハンドシェイクは失敗したとみなされ、接続は切断されます。
3. 最後に、クライアントはChangeCipherSpec を送信し、サーバーに「これから伝える内容はすべて暗号化されます」と伝えます。
   • クライアントは独自の暗号化されたFinishedメッセージを送信します。
   • サーバーは、前の手順でクライアントが実行したのと同じ復号化および検証手順を実行します。
4. アプリケーション フェーズ: この時点で、「ハンドシェイク」が完了し、コンテンツ タイプ 23 でアプリケーション プロトコルが有効になります。クライアントとサーバー間で交換されるアプリケーション メッセージも、Finishedメッセージとまったく同じように暗号化されます。

セッションチケット

セッションIDの代わりに、TLSはセッションチケットを使用して拡張することもできます。^[185]これは、セッション固有の状態がTLSサーバーに保存されることなく、TLSセッションを再開する方法を定義します。

セッションチケットを使用する場合、TLSサーバーはセッション固有の状態をセッションチケットに保存し、そのセッションチケットをTLSクライアントに送信して保存します。クライアントはセッションチケットをサーバーに送信することでTLSセッションを再開し、サーバーはチケット内のセッション固有の状態に基づいてTLSセッションを再開します。セッションチケットはサーバーによって暗号化および認証され、サーバーはその内容を使用する前にその有効性を検証します。

OpenSSLを用いたこの方法の1つの弱点は、AES128-CBC-SHA256実際のTLSセッションで他のどのようなTLSパラメータがネゴシエートされたかに関係なく、送信されるTLSセッションチケットの暗号化と認証セキュリティが常に に制限されることです。 ^[174]これは、状態情報（TLSセッションチケット）がTLSセッション自体ほど保護されていないことを意味します。特に懸念されるのは、OpenSSLがキーをアプリケーション全体のコンテキスト（SSL_CTX）に保存すること、つまりアプリケーションの存続期間中、そしてAES128-CBC-SHA256アプリケーション全体のOpenSSLコンテキストをリセットせずにTLSセッションチケットのキーを再設定できないことです（これはまれで、エラーが発生しやすく、多くの場合、手動の管理介入が必要です）。^{[175] [173]}

TLSレコード

これはすべての TLS レコードの一般的な形式です。

一般的なTLSレコード形式

オフセット	オクテット	0								1								2								3
オクテット	少し	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	コンテンツタイプ								レガシーバージョン（メジャー/マイナー）																長さ↴
4	32	↪長さ（続き）
8	64	プロトコルメッセージ
12	96
⋮	⋮
⁠ ⁠ ${\displaystyle 5+m}$	⁠ ⁠ ${\displaystyle 40+m*8}$	メッセージ認証コード（オプション）
⋮	⋮
⋮	⋮
⁠ ⁠ ${\displaystyle 5+m+q}$	⁠ ⁠ ${\displaystyle 40+(m+q)*8}$	パディング（ブロック暗号のみ）

コンテンツタイプ: 8ビット

このフィールドは、このレコードに含まれるレコード層プロトコル タイプを識別します。

コンテンツタイプ

ヘックス	12月	タイプ
0x14	20	暗号仕様の変更
0x15	21	警告
0x16	22	ハンドシェーク
0x17	23	応用
0x18	24	ハートビート

レガシーバージョン: 16ビット

このフィールドは、含まれるメッセージのTLS 1.3より前のメジャーバージョンとマイナーバージョンを示します。ClientHelloメッセージの場合、クライアントがサポートする最新バージョンである必要はありません。TLS 1.3以降の場合、このフィールドは0x0303に設定し、アプリケーションは追加のメッセージ拡張ブロックでサポートされるバージョンを送信する必要があります。

バージョン

メジャー バージョン	マイナー バージョン	バージョンタイプ
3	0	SSL 3.0
3	1	TLS 1.0
3	2	TLS 1.1
3	3	TLS 1.2
3	4	TLS 1.3

長さ: 16ビット; 長さ < 2 ¹⁴

プロトコルメッセージ、MACアドレス、パディングフィールドを合わせた長さ。長さは2 ¹⁴バイト（16 KiB）を超えてはなりません。

プロトコルメッセージ: 変数

プロトコルフィールドで識別される1つ以上のメッセージ。このフィールドは接続状態に応じて暗号化される場合があることに注意してください。すべてのメッセージの長さ（バイト単位）は文字mで示されます。

メッセージ認証コード （MAC）：16、20、または32バイト（オプション）

プロトコルメッセージフィールドに基づいて計算されたメッセージ認証コード。追加の鍵マテリアルも含まれます。SHA -256ベースのHMACの場合は32バイト、SHA-1ベースのHMACの場合は20バイト、MD5ベースのHMACの場合は16バイトです。このフィールドは、接続状態に応じて暗号化される場合や、完全に含まれない場合があります。MACの長さ（バイト単位）は、文字qで示されます。

パディング: 変数（オプション）

パディングは必要な場合にのみ追加されます。

すべての暗号アルゴリズムとパラメータがネゴシエートされ、ハンドシェイクされ、その後、同じピアによって送信されるすべての後続のレコードでこれらのパラメータが有効になることを通知する CipherStateChange レコード (以下を参照) を送信して確認されるまで、TLS レコードの末尾に MAC フィールドまたはパディング フィールドが存在することはできません。

ハンドシェイクプロトコル

TLS セッションのセットアップ中に交換されるほとんどのメッセージは、エラーまたは警告が発生し、Alert プロトコル レコードによって通知される必要がある場合 (以下を参照)、またはセッションの暗号化モードが別のレコードによって変更される場合を除き (以下のChangeCipherSpecプロトコルを参照)、このレコードに基づいています。

ハンドシェイクTLSレコード形式

オフセット	オクテット	0								1								2								3
オクテット	少し	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	コンテンツタイプ (22)								レガシーバージョン（メジャー/マイナー）																長さ↴
4	32	↪長さ（続き）								メッセージタイプ								ハンドシェイクメッセージのデータ長↴
8	64	↪ハンドシェイクの長さ（続き）
12	96	ハンドシェイクメッセージ
16	128
⋮	⋮
⋮	⋮	ハンドシェイクメッセージのデータ長
⋮	⋮	ハンドシェイクメッセージ
⋮	⋮
⋮	⋮

コンテンツタイプ: 8 ビット; == 22

このフィールドは、ハンドシェイクプロトコル タイプを示します。

メッセージタイプ: 8ビット

このフィールドは、ハンドシェイク メッセージのタイプを識別します。

メッセージの種類

コード	説明
0	こんにちはリクエスト
1	クライアントこんにちは
2	サーバーハロー
4	新しいセッションチケット
8	EncryptedExtensions（TLS 1.3のみ）
11	証明書
12	サーバーキーエクスチェンジ
13	証明書リクエスト
14	サーバーこんにちは完了
15	証明書の確認
16	クライアントキー交換
20	終了した

ハンドシェイクメッセージのデータ長: 24ビット

これは、ヘッダーを含まないハンドシェイク データの長さを示す 3 バイトのフィールドです。

ハンドシェイクメッセージ: 変数

ハンドシェイク メッセージ自体のデータ。

複数のハンドシェイク メッセージが 1 つのレコード内に結合される場合があることに注意してください。

アラートプロトコル

このレコードは通常、通常のハンドシェイクやアプリケーション間のやり取り中には送信されません。ただし、このメッセージはハンドシェイク中およびセッション終了までいつでも送信できます。このレコードが致命的なエラーを通知するために使用される場合、このレコードの送信後すぐにセッションが閉じられるため、このレコードはセッション終了の理由を示すために使用されます。アラートレベルが警告に設定されている場合、リモートはセッションの信頼性が十分でないと判断した場合、セッションを終了することができます（終了する前に、リモートは独自のシグナルを送信することもあります）。

アラートTLSレコード形式

オフセット	オクテット	0								1								2								3
オクテット	少し	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	コンテンツタイプ (21)								レガシーバージョン（メジャー/マイナー）																長さ (2)↴
4	32	↪長さ（続き）								レベル								説明
8	64	MAC（オプション）
12	96
⋮	⋮
⋮	⋮	パディング（ブロック暗号のみ）

コンテンツタイプ: 8 ビット; == 21

このフィールドは、アラートプロトコル タイプを示します。

長さ: 16ビット; == 2

残りのフィールドの長さは 2 です。

レベル: 8ビット

このフィールドはアラートのレベルを示します。レベルが致命的である場合、送信者は直ちにセッションを終了する必要があります。それ以外の場合、受信者は自ら致命的なアラートを送信し、送信後直ちにセッションを終了することで、セッション自体を終了することができます。アラートレコードの使用は任意ですが、セッション終了前にアラートレコードが存在しない場合は、セッションは自動的に（ハンドシェイクによって）再開される可能性があります。

転送されたアプリケーションの終了後にセッションが正常に終了した場合は、新しいセッションの自動再開を防ぐために、少なくともClose通知アラートタイプ（単純な警告レベル）で通知することが望ましい。セキュアセッションのトランスポート層を実際に閉じる前に、セキュアセッションの正常な終了を明示的に通知することは、攻撃（セキュアデータの受信者が想定する所定の長さや持続期間を本質的に持たない場合に、セキュアに転送されたデータを切り捨てようとする試みなど）を防止または検出するのに役立ちます。

警戒レベルの種類

コード	レベルタイプ	接続状態
1	警告	接続またはセキュリティが不安定になる可能性があります。
2	致命的	接続またはセキュリティが侵害されたか、回復不可能なエラーが発生しました。

説明: 8ビット

このフィールドは、送信されるアラートの種類を識別します。

アラートの説明の種類

コード	説明	レベルの種類	注記
0	通知を閉じる	警告/致命的
10	予期しないメッセージ	致命的
20	悪い記録MAC	致命的	おそらく SSL 実装が不良であるか、ペイロードが改ざんされています (例: FTPSサーバー上の FTP ファイアウォール ルール)。
21	復号化に失敗しました	致命的	TLSのみ、予約済み
22	レコードオーバーフロー	致命的	TLSのみ
30	減圧失敗	致命的
40	ハンドシェイク失敗	致命的
41	証明書なし	警告/致命的	SSL 3.0のみ、予約済み
42	不正な証明書	警告/致命的
43	サポートされていない証明書	警告/致命的	例えば、証明書ではサーバー認証の使用のみが有効になっており、クライアント証明書として提示されます。
44	証明書が失効しました	警告/致命的
45	証明書の有効期限が切れました	警告/致命的	サーバー証明書の有効期限を確認し、提示されたチェーン内のどの証明書も期限切れになっていないことを確認します
46	証明書が不明	警告/致命的
47	不正なパラメータ	致命的
48	不明な CA (証明機関)	致命的	TLSのみ
49	アクセスが拒否されました	致命的	TLS のみ – たとえば、クライアント証明書が提示されていない (TLS: 証明書が空白のメッセージ、または SSLv3: 証明書なしの警告) が、サーバーは証明書を要求するように構成されている場合などです。
50	デコードエラー	致命的	TLSのみ
51	復号エラー	警告/致命的	TLSのみ
60	輸出制限	致命的	TLSのみ、予約済み
70	プロトコルバージョン	致命的	TLSのみ
71	セキュリティが不十分	致命的	TLSのみ
80	内部エラー	致命的	TLSのみ
86	不適切なフォールバック	致命的	TLSのみ
90	ユーザーがキャンセルしました	致命的	TLSのみ
100	再交渉なし	警告	TLSのみ
110	サポートされていない拡張機能	警告	TLSのみ
111	証明書を取得できません	警告	TLSのみ
112	認識されない名前	警告/致命的	TLSのみ。クライアントのサーバ名インジケータがサーバでサポートされていないホスト名を指定しました
113	証明書ステータス応答が不正です	致命的	TLSのみ
114	証明書のハッシュ値が不正です	致命的	TLSのみ
115	不明なPSK ID	致命的	TLS のみ。TLS -PSKおよびTLS-SRPで使用されます。
116	証明書が必要です	致命的	TLSバージョン1.3のみ
120または255	アプリケーションプロトコルなし	致命的	TLSバージョン1.3のみ

ChangeCipherSpecプロトコル

ChangeCipherSpec TLSレコード形式

オフセット	オクテット	0								1								2								3
オクテット	少し	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	コンテンツタイプ (20)								レガシーバージョン（メジャー/マイナー）																長さ (1)↴
4	32	↪長さ（続き）								CCSプロトコルタイプ

コンテンツタイプ: 8 ビット; == 20

このフィールドは、アラートプロトコル タイプを示します。

長さ: 16ビット; == 1

残りのフィールドの長さは 1 です。

CCSプロトコルタイプ: 8ビット

このフィールドはCCSプロトコルの種類を識別します。現在は1つだけです。

アプリケーションプロトコル

アプリケーションTLSレコード形式

オフセット	オクテット	0								1								2								3
オクテット	少し	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	コンテンツタイプ (23)								レガシーバージョン（メジャー/マイナー）																長さ↴
4	32	↪長さ（続き）
8	64	アプリケーションデータ
12	96
⋮	⋮
⁠ ⁠ ${\displaystyle 5+m}$	⁠ ⁠ ${\displaystyle 40+m*8}$	メッセージ認証コード（オプション）
⋮	⋮
⋮	⋮
⁠ ⁠ ${\displaystyle 5+m+q}$	⁠ ⁠ ${\displaystyle 40+(m+q)*8}$	パディング（ブロック暗号のみ）

コンテンツタイプ: 8 ビット; == 23

このフィールドは、アプリケーションプロトコル タイプを識別します。

長さ: 16ビット; 長さ < 2 ¹⁴

アプリケーションデータ、MAC、パディングフィールドを合わせた長さ。長さは2 ¹⁴バイト（16 KiB）を超えてはなりません。

アプリケーションデータ: 変数

アプリケーションのデータ。データの長さ（バイト単位）は文字mで示されます。

メッセージ認証コード （MAC）：16、20、または32バイト（オプション）

アプリケーションデータフィールドに基づいて計算されるメッセージ認証コード。SHA -256ベースのHMACの場合は32バイト、SHA-1ベースのHMACの場合は20バイト、MD5ベースのHMACの場合は16バイトです。MACの長さ（バイト単位）は文字qで示されます。

パディング: 変数（オプション）

最後のバイトにはパディングの長さが含まれます。

名前ベースの仮想サーバーのサポート

アプリケーションプロトコルの観点から見ると、TLSは下位層に属しますが、TCP/IPモデルではそれを表現するには粗すぎます。つまり、TLSハンドシェイクは通常（STARTTLSの場合を除く）、アプリケーションプロトコルが開始する前に実行されます。アプリケーション層で提供される名前ベースの仮想サーバー機能では、サーバーがClientHelloメッセージの直後に証明書を選択して送信する必要があるため、共存するすべての仮想サーバーは同じ証明書を共有します。これは、すべての顧客で同じ証明書を共有するか、顧客ごとに異なるIPアドレスを使用する必要があるため、ホスティング環境においては大きな問題となります。

X.509によって提供される 2 つの既知の回避策があります。

• すべての仮想サーバーが同じドメインに属している場合は、ワイルドカード証明書を使用できます。^[186]ホスト名の選択範囲が広く、それが問題となるかどうかは別として、ワイルドカード証明書のマッチング方法については共通の合意がありません。使用されるアプリケーションプロトコルやソフトウェアによって異なるルールが適用されます。^[187]
• subjectAltName拡張子にすべての仮想ホスト名を追加します。大きな問題は、新しい仮想サーバーが追加されるたびに証明書を再発行する必要があることです。

サーバー名を提供するために、トランスポート層セキュリティ（TLS）拡張機能により、クライアントは拡張ClientHelloメッセージにサーバー名表示拡張機能（SNI）を含めることができます。 ^{[188] ：§3}この拡張機能は、クライアントが接続を希望する名前をサーバーに即座に通知するため、サーバーは適切な証明書を選択してクライアントに送信できます。

HTTP/1.1 アップグレードヘッダーを介してHTTPをTLSにアップグレードすることで、名前ベースの仮想ホスティングを実装する方法もあります。^[2]通常、これは一般的に使用されている「https」スキームではなく、メインの「http」URIスキーム内でHTTP over TLSを安全に実装することを意味します。これによりURI空間の分岐が回避され、使用されるポートの数も削減されますが、現在これをサポートする実装はほとんどありません。^[要出典]

参照

• アプリケーション層プロトコルネゴシエーション- SPDYおよびTLS False Startに使用されるTLS拡張機能
• ブルラン（暗号解読プログラム） – 米国国家安全保障局が運営する秘密の暗号解読プログラム
• 証明機関
• 証明書の透明性
• データグラム TLS (DTLS)
• 委任された資格情報
• HTTP 厳格なトランスポートセキュリティ– HSTS
• キーリングファイル
• プライベート通信技術(PCT) – SSL 2.0 の歴史的な Microsoft の競合
• QUIC（クイックUDPインターネット接続） - 「…TLS/SSLと同等のセキュリティ保護を提供するように設計されました」。QUICの主な目的は、現在TCPを使用している接続指向のWebアプリケーションの体感パフォーマンスを向上させることです。
• サーバーゲート暗号化
• tcpcrypt
• データグラムトランスポート層セキュリティ
• TLSアクセラレーション

さらに読む

• Wagner, David; Schneier, Bruce (1996年11月). 「SSL 3.0プロトコルの分析」(PDF) .第2回USENIX電子商取引ワークショップ議事録. USENIX Press. pp.  29– 40. 2006年10月16日時点のオリジナルよりアーカイブ(PDF) . 2006年10月12日閲覧.
• レスコーラ、エリック（2001年）『SSLとTLS：セキュアシステムの設計と構築』米国：Addison-Wesley Pub Co. ISBN 978-0-201-61598-2。
• スティーブン・A・トーマス（2000年）『SSLとTLSの基本：Webのセキュリティ確保』ニューヨーク：ワイリー、ISBN 978-0-471-38354-3。
• バード、グレゴリー (2006). 「SSLに対する困難だが実現可能なブロック適応型選択平文攻撃」国際暗号研究協会(136). 2011年9月23日時点のオリジナルよりアーカイブ。 2011年9月23日閲覧。
• Canvel, Brice. 「SSL/TLSチャネルにおけるパスワード傍受」。2016年4月20日時点のオリジナルよりアーカイブ。 2007年4月20日閲覧。
• IPsecとSSL/TLSを使用したVPNの作成 2015年4月12日アーカイブWayback Machine Linux Journalの記事 Rami Rosen
• ジョシュア・デイヴィス (2010). SSL/TLS の実装. Wiley. ISBN 978-0470920411。
• Polk, Tim; McKay, Kerry; Chokhani, Santosh (2014年4月). 「トランスポート層セキュリティ（TLS）実装の選択、設定、および使用に関するガイドライン」（PDF） . 米国国立標準技術研究所. オリジナル（PDF）から2014年5月8日にアーカイブ。 2014年5月7日閲覧。
• Abdou, AbdelRahman; van Oorschot, Paul (2017年8月). 「サーバーロケーション検証（SLV）とサーバーロケーションピンニング：TLS認証の強化」 . ACM Transactions on Privacy and Security . 21 (1): 1:1–1:26. doi :10.1145/3139294. S2CID  5869541. 2019年3月22日時点のオリジナルよりアーカイブ。 2018年1月11日閲覧。
• イヴァン・リスティッチ（2022年）『Bulletproof TLS and PKI 第2版』 ファイスティ・ダック社ISBN 978-1907117091。

外部リンク

• インターネット技術タスクフォース - TLS ワークグループ 2014年1月11日アーカイブ - Wayback Machine

IETF コメントのお願い

一次基準

現在承認されている (D)TLS のバージョンはバージョン 1.3 であり、次のとおり指定されています。

• RFC 8446 –「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」^[6] 提案標準。
• RFC 9147 –「データグラムトランスポート層セキュリティ（DTLS）プロトコルバージョン1.3」^[11] 提案標準。

現在の標準は、以下の以前のバージョンに代わるものです。

• RFC 5246 –「トランスポート層セキュリティ（TLS）プロトコルバージョン1.2」^[25] 廃止。
• RFC 6347 –「データグラムトランスポート層セキュリティバージョン1.2」^[8] 廃止。
• RFC 4346 –「トランスポート層セキュリティ（TLS）プロトコルバージョン1.1」^[46] 歴史的。
• RFC 2246 –「TLSプロトコルバージョン1.0」^[189] 歴史的。
• RFC 6101 – 「セキュアソケットレイヤー（SSL）プロトコルバージョン3.0」^[190] 歴史的。
• インターネット ドラフト (1995):「SSL プロトコル」

拡張機能

その後、他のRFCによって (D)TLS が拡張されました。

(D)TLS 1.3 の拡張機能には以下が含まれます。

• RFC 9367 – 「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3のGOST暗号スイート」^[87] 情報。

(D)TLS 1.2 の拡張機能には以下が含まれます。

• RFC 5288 – 「 TLS用AESガロアカウンターモード（GCM）暗号スイート」^[88] 提案標準。
• RFC 5289 –「SHA-256/384およびAESガロアカウンターモード（GCM）を使用したTLS楕円曲線暗号スイート」^[89] 提案標準。
• RFC 5746 –「トランスポート層セキュリティ（TLS）再ネゴシエーション指示拡張」^[111] 提案標準。
• RFC 5878 –「トランスポート層セキュリティ（TLS）認証拡張」^[191] 実験的。
• RFC 5932 – 「TLS用Camellia暗号スイート」^[93] 提案標準。
• RFC 6066 –「トランスポート層セキュリティ（TLS）拡張：拡張定義」^[188] 提案標準。
  サーバー名表示とOCSP ステープリングが含まれます。
• RFC 6091 – 「トランスポート層セキュリティ（TLS）認証のためのOpenPGPキーの使用」^[192] 情報。
• RFC 6176 –「セキュアソケットレイヤー（SSL）バージョン2.0の禁止」^[19] 提案標準。
• RFC 6209 – 「ARIA暗号スイートのトランスポート層セキュリティ（TLS）への追加」^[94] 情報。
• RFC 6347 –「データグラムトランスポート層セキュリティバージョン1.2」^[8] 廃止。
  この定義は現在、DTLS 1.3 仕様の一部となっています。
• RFC 6367 – 「トランスポート層セキュリティ（TLS）へのCamellia暗号スイートの追加」^[92] 情報。
• RFC 6460 –「トランスポート層セキュリティ（TLS）のスイートBプロファイル」^[193] 歴史的。
  Suite B 暗号化のサポートは国家安全保障局によって中止されました。
• RFC 6655 – 「トランスポート層セキュリティ（TLS）用のAES-CCM暗号スイート」^[90] 提案標準。
• RFC 7027 –「トランスポート層セキュリティ（TLS）のための楕円曲線暗号（ECC）ブレインプール曲線」^[194] 情報。
• RFC 7251 – 「 TLS用AES-CCM楕円曲線暗号（ECC）暗号スイート」^[91] 情報提供。
• RFC 7301 –「トランスポート層セキュリティ（TLS）アプリケーション層プロトコルネゴシエーション拡張」^[195] 提案標準。
• RFC 7366 – 「トランスポート層セキュリティ（TLS）とデータグラムトランスポート層セキュリティ（DTLS）のための暗号化してからMAC」^[139] 提案標準。
• RFC 7465 –「RC4暗号スイートの禁止」^[101] 提案標準。
• RFC 7507 – 「プロトコルダウングレード攻撃を防ぐためのTLSフォールバックシグナリング暗号スイート値（SCSV）」^[196] 廃止。
• RFC 7568 – 「Secure Sockets Layerバージョン3.0の廃止」^[20] 提案標準。
• RFC 7627 –「トランスポート層セキュリティ（TLS）セッションハッシュと拡張マスターシークレット拡張」^[197] 提案標準。
• RFC 7685 –「トランスポート層セキュリティ（TLS）ClientHelloパディング拡張」^[198] 提案標準。
• RFC 8422 – 「トランスポート層セキュリティ（TLS）バージョン1.2以前の楕円曲線暗号（ECC）暗号スイート」^[84] 提案標準。
• RFC 9189 – 「トランスポート層セキュリティ（TLS）プロトコルバージョン1.2のGOST暗号スイート」^[86] 情報。

(D)TLS 1.1 の拡張機能には以下が含まれます。

• RFC 4366 –「トランスポート層セキュリティ（TLS）拡張」^[199] 廃止。
  特定の拡張機能のセットと汎用的な拡張機能メカニズムの両方について説明します。
• RFC 4492 –「トランスポート層セキュリティ（TLS）のための楕円曲線暗号（ECC）暗号スイート」^[200] 廃止。
• RFC 4680 –「補足データのためのTLSハンドシェイクメッセージ」^[201] 提案標準。
• RFC 4681 –「TLSユーザーマッピング拡張」^[202] 提案標準。
• RFC 4785 – 「トランスポート層セキュリティ（TLS）のためのNULL暗号化を使用した事前共有キー（PSK）暗号スイート」^[203] 提案標準。
• RFC 5054 –「 TLS認証のためのセキュアリモートパスワード（SRP）プロトコルの使用」^[204] 情報。
  TLS-SRP暗号スイートを定義します。
• RFC 5077 –「サーバー側の状態なしでのトランスポート層セキュリティ（TLS）セッション再開」^[185] 廃止。
• RFC 5081 – 「トランスポート層セキュリティ（TLS）認証のためのOpenPGPキーの使用」^[205] 実験的。
• RFC 5216 –「EAP -TLS認証プロトコル」^[206] 提案標準。

TLS 1.0 の拡張機能には以下が含まれます。

• RFC 2595 –「IMAP、POP3、ACAPでのTLSの使用」^[207] 提案標準。
  IMAP、POP3、および ACAP サービスの拡張機能を指定します。これにより、サーバーとクライアントはトランスポート層セキュリティを使用して、インターネット経由でプライベートで認証された通信を提供できるようになります。
• RFC 2712 – 「トランスポート層セキュリティ（TLS）へのKerberos暗号スイートの追加」^[208] 提案標準。
  このメモで定義されている 40 ビットの暗号スイートは、それらの暗号スイート コードがすでに割り当てられているという事実を文書化する目的でのみ表示されます。
• RFC 2817 – 「HTTP/1.1内でのTLSへのアップグレード」^[2] 提案標準。
  HTTP/1.1のアップグレードメカニズムを使用して、既存のTCP接続上でトランスポート層セキュリティ（TLS）を開始する方法について説明します。これにより、保護されていないHTTPトラフィックと保護されたHTTPトラフィックが同じウェルノウンポート（この場合は、443のhttps:ではなく、80のhttp:）を共有できるようになります。
• RFC 2818 –「HTTP Over TLS」^[209] 廃止。
  異なる「サーバー ポート」を使用して、セキュリティ保護されたトラフィックとセキュリティ保護されていないトラフィックを区別します。
• RFC 3207 –「トランスポート層セキュリティ上の安全なSMTPのためのSMTPサービス拡張」^[210] 提案標準。
  SMTP サーバーとクライアントがトランスポート層セキュリティを使用して、インターネット経由でプライベートで認証された通信を提供できるようにする SMTP サービスの拡張機能を指定します。
• RFC 3268 – 「トランスポート層セキュリティ（TLS）のためのAdvanced Encryption Standard（AES）暗号スイート」^[211] 廃止。
  既存の対称暗号にAdvanced Encryption Standard (AES) 暗号スイートを追加します。
• RFC 3546 –「トランスポート層セキュリティ（TLS）拡張」^[212] 廃止。
  セッション初期化中にプロトコル拡張をネゴシエートするためのメカニズムを追加し、いくつかの拡張を定義します。
• RFC 3749 –「トランスポート層セキュリティプロトコル圧縮方法」^[213] 提案標準。
  圧縮方法のフレームワークとDEFLATE圧縮方法を指定します。
• RFC 3943 –「Lempel-Ziv-Stac（LZS）を使用したトランスポート層セキュリティ（TLS）プロトコル圧縮」^[214] 情報。
• RFC 4132 – 「トランスポート層セキュリティ（TLS）へのCamellia暗号スイートの追加」^[215] 廃止。
• RFC 4162 – 「トランスポート層セキュリティ（TLS）へのSEED暗号スイートの追加」^[95] 提案標準。
• RFC 4217 –「TLSによるFTPのセキュリティ保護」^[216] 提案標準。
• RFC 4279 – 「トランスポート層セキュリティ（TLS）のための事前共有キー暗号スイート」^[217] 提案標準。
  事前共有キーに基づく認証をサポートするために、TLS プロトコルに 3 セットの新しい暗号スイートを追加します。

情報RFC

• RFC 7457 – 「トランスポート層セキュリティ（TLS）とデータグラムTLS（DTLS）に対する既知の攻撃の要約」^[218] 情報提供。
• RFC 9325 –「トランスポート層セキュリティ（TLS）とデータグラムトランスポート層セキュリティ（DTLS）の安全な使用に関する推奨事項」^[219] ベストプラクティス195。

参考文献

1. ie 「(D)TLSの委任された認証情報」。IETF 。 2024年6月26日時点のオリジナルよりアーカイブ。 2024年6月26日閲覧。
2. R. Khare; S. Lawrence (2000年5月). HTTP/1.1におけるTLSへのアップグレード. IETFネットワークワーキンググループ. doi : 10.17487/RFC2817 . RFC 2817. 提案された標準。RFC 7230 および 7231 によって更新されました。RFC 2616 を更新しました。
3. 「SSL/TLSの詳細」TechNet、Microsoft Docs、2009年10月8日。2022年8月13日時点のオリジナルよりアーカイブ。 2021年10月24日閲覧。
4. Hooper, Howard (2012). CCNP Security VPN 642–648 公式認定ガイド（第2版）. Cisco Press. p. 22. ISBN 9780132966382。
5. Spott, Andrew; Leek, Tom; et al. 「TLSとはどのようなレイヤーか？」Information Security Stack Exchange . 2021年2月13日時点のオリジナルよりアーカイブ。 2017年4月13日閲覧。
6. E. Rescorla (2018年8月). トランスポート層セキュリティ (TLS) プロトコル バージョン 1.3.インターネット技術タスクフォースTLS ワークグループ. doi : 10.17487/RFC8446 . RFC 8446. 提案された標準。RFC 5077、5246、および 6961 を廃止します。RFC 5705 および 6066 を更新します。
7. E. Rescorla; N. Modadugu (2006年4月). データグラムトランスポート層セキュリティ. ネットワークワーキンググループ. doi : 10.17487/RFC4347 . RFC 4347. 廃止。RFC 6347 により廃止。RFC 5746 および 7507 により更新。
8. E. Rescorla; N. Modadugu (2012年1月). データグラムトランスポート層セキュリティ バージョン1.2.インターネット技術タスクフォース. doi : 10.17487/RFC6347 . ISSN  2070-1721. RFC 6347. 廃止。RFC 9147 により廃止。RFC 7507、7905、8996、9146 により更新。RFC 4347 は廃止。
9. Titz, Olaf (2001-04-23). 「なぜTCP Over TCPは悪い考えなのか」。2023年3月10日時点のオリジナルよりアーカイブ。 2015年10月17日閲覧。
10. 本田 修、大崎 博之、今瀬 誠、石塚 美香、村山 純一 (2005年10月). 「TCP over TCPの理解：TCPトンネリングがエンドツーエンドのスループットと遅延に与える影響」. Atiquzzaman, Mohammed; Balandin, Sergey I (編).次世代通信・センサーネットワークの性能、サービス品質、制御 III . 第6011巻.書誌コード:2005SPIE.6011..138H. CiteSeerX 10.1.1.78.5815 . doi :10.1117/12.630496. S2CID  8945952. 
11. E. Rescorla; H. Tschofenig; N. Modadugu (2022年4月). データグラムトランスポート層セキュリティ（DTLS）プロトコルバージョン1.3.インターネット技術タスクフォースTLSワークグループ. doi : 10.17487/RFC9147 . RFC 9147. 提案された標準。RFC 6347 を廃止します。
12. 「AnyConnect FAQ: トンネル、再接続動作、および非アクティビティタイマー」Cisco . 2017年2月26日時点のオリジナルよりアーカイブ。 2017年2月26日閲覧。
13. 「Cisco InterCloud アーキテクチャの概要」(PDF) . Cisco Systems . 2022年8月9日時点のオリジナルよりアーカイブ(PDF) . 2022年11月29日閲覧。
14. “OpenConnect”. OpenConnect . 2017年2月2日時点のオリジナルよりアーカイブ。 2017年2月26日閲覧。
15. “ZScaler ZTNA 2.0 Tunnel”. ZScaler . 2022年11月29日時点のオリジナルよりアーカイブ。2022年11月29日閲覧。
16. 「f5 Datagram Transport Layer Security (DTLS)」. f5 Networks . 2022年11月29日時点のオリジナルよりアーカイブ。 2022年11月29日閲覧。
17. 「DTLS仮想サーバーの構成」Citrix Systems . 2016年12月21日時点のオリジナルよりアーカイブ。2022年11月29日閲覧。
18. 「WebRTC Interop Notes」。2013年5月11日時点のオリジナルよりアーカイブ。
19. S. Turner; T. Polk (2011年3月). Secure Sockets Layer (SSL) バージョン2.0の禁止. Internet Engineering Task Force . doi : 10.17487/RFC6176 . ISSN  2070-1721. RFC 6176. 提案された標準。RFC 8996 によって更新されました。RFC 2246、5246、および 4346 を更新します。
20. R. Barnes; M. Thomson; A. Pironti; A. Langley (2015年6月). Secure Sockets Layer バージョン3.0の廃止. Internet Engineering Task Force . doi : 10.17487/RFC7568 . ISSN  2070-1721. RFC 7568. 提案された標準。RFC 8996 によって更新されました。RFC 5246 を更新します。
21. M. Nottingham (2021年3月). TLS 1.0およびTLS 1.1の廃止.インターネット技術タスクフォース. doi : 10.17487/RFC8996 . ISSN  2070-1721. BCP 195. RFC 8996. ベストカレントプラクティス195。RFC 5469および7507 を廃止。RFC 3261、3329、3436、3470、3501、3552、3568、3656、3749、3767、3856、3871、3887、3903、3943、3983、4097、4111、4162、4168、4217、4235、4261、4279、4497、4513、4531、4540、4582、4616、4642、4680、4681、4712、4732を更新。4743、4744、4785、4791、4823、4851、4964、4975、4976、4992、5018、5019、5023、5024、5049、5054、5091、5158、5216、5238、5263、5281、5364、5415、5422、5456、5734、5878、5953、6012、6042、6083、6084、6176、6347、6353、6367、6460、6614、6739、6749 、​​​​​ ​6750、7030、7465、7525、7562、7568、8261、8422 。
22. Bright, Peter (2018年10月17日). 「Apple、Google、Microsoft、MozillaがTLS 1.0の廃止に向けて協力」。2018年10月17日時点のオリジナルよりアーカイブ。 2018年10月17日閲覧。
23. 「Firefox 74.0 Stableの新機能と変更点 – gHacks Tech News」www.ghacks.net . 2020年3月10日. 2020年3月11日時点のオリジナルよりアーカイブ。 2020年3月10日閲覧。
24. 「TLS 1.0 および TLS 1.1 – Chrome プラットフォームのステータス」。chromestatus.com 。 2023年7月7日時点のオリジナルよりアーカイブ。2020年3月10日閲覧。
25. T. Dierks; E. Rescorla (2008年8月). トランスポート層セキュリティ (TLS) プロトコル バージョン 1.2. IETF TLS ワークグループ. doi : 10.17487/RFC5246 . RFC 5246. 廃止。RFC 8446 により廃止。RFC 3268、4346、4366 を廃止。RFC 4492 を更新。
26. 「TLSを使用したデータ保護」www.ncsc.gov.uk . 2021年7月21日時点のオリジナルよりアーカイブ。 2022年8月24日閲覧。
27. “TLS 1.3: 1年後”. IETF . 2020年7月8日時点のオリジナルよりアーカイブ。 2022年8月24日閲覧。
28. 「TLSの創造：ルース・ネルソンの先駆的役割」。2020年6月24日時点のオリジナルよりアーカイブ。2020年7月4日閲覧。
29. 「情報技術 - システム間の通信および情報交換 - トランスポート層セキュリティプロトコル」。2025年5月3日時点のオリジナルよりアーカイブ。 2025年5月3日閲覧。
30. Woo, Thomas YC; Bindignavle, Raghuram; Su, Shaowen; Lam, Simon S. (1994年6月). SNP: セキュアネットワークプログラミングのためのインターフェース(PDF) . Proceedings USENIX Summer Technical Conference. 2014年12月12日時点のオリジナルよりアーカイブ(PDF) . 2023年7月5日閲覧。
31. “1994 USENIX Summer Technical Conference Program, Boston, 6–10 June 1994”. 2023年10月6日時点のオリジナルよりアーカイブ。 2024年1月21日閲覧。
32. Simon S. Lam (PI/PD)、「モジュールとインタフェースの理論のセキュリティ検証への適用」、NSA INFOSEC 大学研究プログラム助成金番号 MDA 904-91-C-7046、1991 年 6 月 28 日から 1993 年 6 月 27 日。
33. “2004 ACM Software System Award 受賞歴”. ACM . 2013年6月17日時点のオリジナルよりアーカイブ。2012年7月25日閲覧。
34. “ACMプレスリリース、2005年3月15日”. ACM . 2016年1月10日時点のオリジナルよりアーカイブ。2012年7月25日閲覧。
35. “インターネットの殿堂入りサイモン・S・ラム”. 2024年2月6日時点のオリジナルよりアーカイブ。2024年3月3日閲覧。
36. “コンピュータ科学者がインターネットの殿堂入り”. 2024年3月8日時点のオリジナルよりアーカイブ。2024年3月3日閲覧。
37. メスマー、エレン. 「SSLの父、タヘル・エルガマル博士、中東で急速に発展するITプロジェクトを発見」. Network World . 2014年5月31日時点のオリジナルよりアーカイブ。 2014年5月30日閲覧。
38. Greene, Tim. 「SSLの父、攻撃にもかかわらずセキュリティの要であるSSLにはまだまだ寿命が残っている」Network World . 2014年5月31日時点のオリジナルよりアーカイブ。 2014年5月30日閲覧。
39. Oppliger, Rolf (2016). 「序論」. SSLとTLS：理論と実践（第2版）. Artech House . p. 13. ISBN 978-1-60807-999-52018年3月1日閲覧– Googleブックス経由。
40. 「THE SSL PROTOCOL」. Netscape Corporation. 2007年. 1997年6月14日時点のオリジナルよりアーカイブ。
41. レスコーラ 2001
42. “POODLE: SSLv3の脆弱性（CVE-2014-3566）”. 2014年12月5日時点のオリジナルよりアーカイブ。2014年10月21日閲覧。
43. 「ブラウザ戦争におけるセキュリティ標準と名称変更」。2020年2月29日時点のオリジナルよりアーカイブ。2020年2月29日閲覧。
44. Laura K. Gray (2015年12月18日). 「SSLおよび初期TLSからの移行に関する日付変更」. Payment Card Industry Security Standards Councilブログ. 2015年12月20日時点のオリジナルよりアーカイブ。 2018年4月5日閲覧。
45. 「PCIコンプライアンスの変更は6月30日に実施されます。あなたのeコマースビジネスは準備ができていますか？」Forbes。2018年6月21日時点のオリジナルよりアーカイブ。 2018年6月20日閲覧。
46. T. Dierks; E. Rescorla (2006年4月). トランスポート層セキュリティ (TLS) プロトコル バージョン 1.1.インターネット技術タスクフォースTLS ワークグループ. doi : 10.17487/RFC4346 . RFC 4346. 歴史的。RFC 5246 によって廃止。RFC 2246 を廃止。
47. 「トランスポート層セキュリティパラメータ - 暗号スイート」。Internet Assigned Numbers Authority (IANA)。2016年12月21日時点のオリジナルよりアーカイブ。 2022年12月16日閲覧。
48. Mackie, Kurt. 「Microsoft、TLS 1.0および1.1のサポート終了を延期」 - Microsoft Certified Professional Magazine Online . 2021年6月14日時点のオリジナルよりアーカイブ。 2021年6月14日閲覧。
49. 「TLS 1.2 FAQ – ナレッジベース」. Answers.psionline.com . 2022年2月20日時点のオリジナルよりアーカイブ。2022年2月20日閲覧。
50. “2022年のNetscape 9の使い方”. MSFN . 2022年4月22日. 2025年4月18日時点のオリジナルよりアーカイブ。 2025年4月24日閲覧。
51. 「TLS 1.2とTLS 1.3の違い（#TLS13）」WolfSSL . 2019年9月18日. 2019年9月19日時点のオリジナルよりアーカイブ。 2019年9月18日閲覧。
52. “アーカイブコピー”. 2024年3月17日時点のオリジナルよりアーカイブ。2024年3月17日閲覧。{{cite web}}: CS1 maint: アーカイブされたコピーをタイトルとして (リンク)
53. 「NSS 3.29 リリースノート」。Mozilla Developer Network。2017年2月。2017年2月22日時点のオリジナルよりアーカイブ。
54. “TLS 1.3をデフォルトで有効にする”. Bugzilla@Mozilla. 2016年10月16日. 2018年8月12日時点のオリジナルよりアーカイブ。2017年10月10日閲覧。
55. “Firefox — Notes (60.0)”. Mozilla . 2018年5月9日時点のオリジナルよりアーカイブ。2018年5月10日閲覧。
56. 「ProxySG、ASG、WSSは、TLS 1.3を使用しているクライアントが、同じくTLS 1.3を使用しているサイトにアクセスすると、SSL接続を中断します」。BlueTouch Online。2017年5月16日。2017年9月12日時点のオリジナルよりアーカイブ。 2017年9月11日閲覧。
57. Sullivan, Nick (2017年12月26日). 「なぜTLS 1.3がまだブラウザに導入されていないのか」. Cloudflareブログ. 2017年12月26日時点のオリジナルよりアーカイブ。2020年3月14日閲覧。
58. Thomson, Martin; Pauly, Tommy (2021年12月). プロトコル拡張メカニズムの長期的な実行可能性. doi : 10.17487/RFC9170 . RFC 9170.
59. “TLS 1.3 IETF 100 Hackathon”. 2018年1月15日時点のオリジナルよりアーカイブ。
60. IETF – Internet Engineering Task Force (2017-11-12), IETF Hackathon Presentations and Awards, 2021-10-28にアーカイブ, 2017-11-14取得
61. “やったー！TLS 1.3がリリースされました。いよいよ実装してソフトウェアに組み込む番です。” 2018年3月27日時点のオリジナルよりアーカイブ。 2018年3月28日閲覧。
62. IETF – Internet Engineering Task Force (2018-07-15), IETF102-HACKATHON-20180715-1400, 2021-10-28にオリジナルからアーカイブ, 2018-07-18に取得
63. “wolfSSL TLS 1.3 BETA Release Now Available”. [email protected]. 2017年5月11日. 2018年7月9日時点のオリジナルよりアーカイブ。 2017年5月11日閲覧。
64. 「TLS 1.3 プロトコルサポート」. [email protected]. 2017年8月4日. 2018年7月9日時点のオリジナルよりアーカイブ。2018年7月9日閲覧。
65. “TLS 1.3 Draft 28 Support in wolfSSL”. [email protected]. 2018年6月14日. 2018年7月9日時点のオリジナルよりアーカイブ。 2018年6月14日閲覧。
66. “OpenSSL 1.1.1 がリリースされました”. Matt Caswell. 2018年9月11日. 2018年12月8日時点のオリジナルよりアーカイブ。 2024年10月11日閲覧。
67. “TLS/SSL のプロトコル (Schannel SSP)”. Microsoft Docs . 2022年5月25日. 2023年1月25日時点のオリジナルよりアーカイブ。 2023年2月21日閲覧。
68. Hoffman-Andrews, Jacob (2019年2月26日). 「ETSはTLSではないので、使用すべきではない」. Electronic Frontier Foundation . 2019年2月26日時点のオリジナルよりアーカイブ。 2019年2月27日閲覧。
69. TS 103 523-3 – V1.1.1 – CYBER; ミドルボックスセキュリティプロトコル; パート3：エンタープライズネットワークおよびデータセンターのアクセス制御プロファイル( PDF )。ETSI .org 。 2018年11月14日時点のオリジナルからのアーカイブ(PDF) 。
70. Cory Doctorow (2019年2月26日). 「Monumental Recklessness」. Boing Boing . 2019年2月27日時点のオリジナルよりアーカイブ。
71. Rea, Scott (2013). 「安全なWebのための認証局の代替手段」(PDF) . RSA Conference Asia Pacific. 2016年10月7日時点のオリジナルよりアーカイブ(PDF) . 2016年9月7日閲覧。
72. “SSL証明書のカウント”. 2015年5月16日時点のオリジナルよりアーカイブ。2022年2月20日閲覧。
73. Raymond, Art (2017年8月3日). 「Lehi's DigiCert、ウェブセキュリティの競合企業を10億ドルで買収」Deseret News . 2018年9月29日時点のオリジナルよりアーカイブ。 2020年5月21日閲覧。
74. 「SSL証明書機関の市場シェア動向」W3Techs . 2020年5月21日閲覧。
75. Ryan Singel (2010年3月24日). 「Law Enforcement Appliance Subverts SSL」. wired.com . 2014年4月12日時点のオリジナルよりアーカイブ。
76. Seth Schoen (2010年3月24日). 「新たな研究によると、政府によるSSL証明書の偽造が疑われる」EFF .org . 2010年3月25日時点のオリジナルよりアーカイブ。
77. Schuman, Evan (2025年4月11日). 「ベンダー、ウェブサイト証明書の有効期間を大幅に短縮へ」Computerworld . 2025年7月28日閲覧。
78. Lyons, Jessica (2024年10月15日). 「システム管理者、Appleの『悪夢のような』SSL/TLS証明書の有効期限短縮計画に激怒」The Register . 2025年7月28日閲覧。
79. P. Eronen編 (2005年12月). Eronen, P; Tschofenig, H (編). トランスポート層セキュリティ (TLS) 向け事前共有鍵暗号スイート. インターネット技術タスクフォース. doi : 10.17487/RFC4279 . RFC 4279. 2013年9月9日閲覧.
80. D. Taylor編 (2007年11月). TLS認証におけるセキュアリモートパスワード（SRP）プロトコルの使用. インターネット技術特別調査委員会. doi : 10.17487/RFC5054 . RFC 5054. 2014年12月21日閲覧.
81. Gothard, Peter (2013年7月31日). 「Google、SSL証明書を2048ビット暗号化に更新」. Computing . Incisive Media. 2013年9月22日時点のオリジナルよりアーカイブ。 2013年9月9日閲覧。
82. 「2,048ビット暗号化の価値：暗号化キーの長さが重要な理由」SearchSecurity . 2018年1月16日時点のオリジナルよりアーカイブ。 2017年12月18日閲覧。
83. Sean Turner (2015年9月17日). “Consensus: remove DSA from TLS 1.3”. 2015年10月3日時点のオリジナルよりアーカイブ。
84. Y. Nir; S. Josefsson; M. Pegourie-Gonnard (2018年8月). トランスポート層セキュリティ（TLS）バージョン1.2およびそれ以前の楕円曲線暗号（ECC）暗号スイート.インターネット技術タスクフォース. doi : 10.17487/RFC8422 . ISSN  2070-1721. RFC 8422. 提案された標準。RFC 4492 を廃止します。RFC 8996 によって更新されます。
85. RFC  5830、6986、7091、7801、8891
86. D. Belyavskiy; KE. Alekseev (2022年3月). S. Smyshlyaev (編). GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2. 独立提出. doi : 10.17487/RFC9189 . RFC 9189. 情報提供。
87. E. Alekseev; E. Griboedova; A. Babueva; L. Nikiforova (2023年2月). S. Smyshlyaev (編). GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3. 独立提出. doi : 10.17487/RFC9367 . RFC 9367. 情報提供。
88. J. Salowey; A. Choudhury; D. McGrew (2008年8月). TLS用AESガロアカウンタモード（GCM）暗号スイート. ネットワークワーキンググループ. doi : 10.17487/RFC5288 . RFC 5288. 提案された標準。RFC 9325 によって更新されました。
89. E. Rescorla (2008年8月). SHA-256/384およびAESガロアカウンタモード（GCM）を用いたTLS楕円曲線暗号スイート. ネットワークワーキンググループ. doi : 10.17487/RFC5289 . RFC 5289. 提案された標準。
90. D. McGrew; D. Bailey (2012年7月). トランスポート層セキュリティ（TLS）のためのAES-CCM暗号スイート.インターネット技術タスクフォース. doi : 10.17487/RFC6655 . RFC 6655. 提案された標準。
91. D. McGrew; D. Bailey; M. Campagna; R. Dugal (2014年6月). TLS用AES-CCM楕円曲線暗号（ECC）暗号スイート.インターネット技術タスクフォース. doi : 10.17487/RFC7251 . ISSN  2070-1721. RFC 7251. 情報提供。
92. S. Kanno; M. Kanda (2011年9月). トランスポート層セキュリティ（TLS）へのCamellia暗号スイートの追加.インターネット技術タスクフォース. doi : 10.17487/RFC6367 . ISSN  2070-1721. RFC 6367. 情報提供。RFC 8996 により更新されました。
93. A. Kato; M. Kanda; S. Kanno (2010年6月). TLSのためのCamellia暗号スイート. Internet Engineering Task Force . doi : 10.17487/RFC5932 . ISSN  2070-1721. RFC 5932. 提案された標準。RFC 4132 を廃止します。
94. W. Kim; J. Lee; J. Park; D. Kwon (2011年5月). ARIA暗号スイートのトランスポート層セキュリティ（TLS）への追加.インターネット技術タスクフォース. doi : 10.17487/RFC6209 . ISSN  2070-1721. RFC 6209. 情報提供。
95. HJ Lee; JH Yoon; JI Lee (2005年8月). トランスポート層セキュリティ（TLS）へのSEED暗号スイートの追加. IETFネットワークワーキンググループ. doi : 10.17487/RFC4162 . RFC 4162. 提案された標準。RFC 8996 によって更新されました。
96. 「64ビットブロック暗号の実用的（不）安全性について — TLSおよびOpenVPN経由のHTTPに対する衝突攻撃」(PDF) 2016年10月28日. 2017年4月24日時点のオリジナルよりアーカイブ(PDF) 2017年6月8日閲覧。
97. 「NIST Special Publication 800-57 鍵管理に関する推奨事項 — パート1：一般（改訂版）」（PDF） 2007年3月8日。 2014年6月6日時点のオリジナル（PDF）からアーカイブ。 2014年7月3日閲覧。
98. Qualys SSL Labs. 「SSL/TLS導入のベストプラクティス」. 2015年7月4日時点のオリジナルよりアーカイブ。 2015年6月2日閲覧。
99. P. Eronen編 (2009年2月). DESおよびIDEA暗号スイートによるトランスポート層セキュリティ(TLS). ネットワークワーキンググループ. doi : 10.17487/RFC5469 . RFC 5469. 歴史的。RFC 8996 により廃止されました。
100. A. Langley; W. Chang; N. Mavrogiannopoulos; J. Strombergson; S. Josefsson (2016年6月). ChaCha20-Poly1305 トランスポート層セキュリティ (TLS) 用暗号スイート.インターネット技術タスクフォース. doi : 10.17487/RFC7905 . ISSN  2070-1721. RFC 7905. 提案された標準。RFC 6347 および 5246 を更新します。
101. A. Popov (2015年2月). RC4暗号スイートの禁止.インターネット技術タスクフォース. doi : 10.17487/RFC7465 . ISSN  2070-1721. RFC 7465. 提案された標準。RFC 8996 によって更新されました。RFC 2246、4346、および 5246 を更新します。
102. “Http vs https”. 2015年2月12日時点のオリジナルよりアーカイブ。2015年2月12日閲覧。
103. 2025年6月1日現在。「SSL Pulse：最も人気のあるウェブサイトのSSL実装に関する調査」Qualys。2021年3月8日時点のオリジナルよりアーカイブ。 2025年9月8日閲覧。
104. ivanr (2013年3月19日). 「TLSのRC4が破綻：今後どうする？」Qualsys Security Labs. 2013年8月27日時点のオリジナルよりアーカイブ。2013年7月30日閲覧。
105. Bodo Möller、Thai Duong、Krzysztof Kotowicz. 「This POODLE Bites: Exploiting The SSL 3.0 Fallback」（PDF） 。 2014年10月14日時点のオリジナルよりアーカイブ（PDF） 。 2014年10月15日閲覧。
106. 「Java Secure Socket Extension (JSSE)リファレンス・ガイド」。Oracleヘルプセンター。2022年1月22日時点のオリジナルよりアーカイブ。 2021年12月24日閲覧。
107. Georgiev, Martin; Iyengar, Subodh; Jana, Suman; Anubhai, Rishita; Boneh, Dan; Shmatikov, Vitaly (2012). 世界で最も危険なコード：非ブラウザソフトウェアにおけるSSL証明書の検証. 2012 ACM コンピュータおよび通信セキュリティ会議議事録(PDF) . Association for Computing Machinery. pp.  38– 49. ISBN 978-1-4503-1651-42017年10月22日時点のオリジナルよりアーカイブ（PDF）
108. Audet, F. (2009). セッション開始プロトコル（SIP）におけるSIPS URIスキームの利用. doi : 10.17487/RFC5630 . RFC 5630.
109. Sheffer, Y.; Holz, R.; Saint-Andre, P. (2015). トランスポート層セキュリティ（TLS）とデータグラムTLS（DTLS）に対する既知の攻撃のまとめ. doi : 10.17487/RFC7457 . RFC 7457.
110. “CVE – CVE-2009-3555”. 2016年1月4日時点のオリジナルよりアーカイブ。
111. E. Rescorla; M. Ray; S. Dispensa; N. Oskov (2010年2月). トランスポート層セキュリティ (TLS) 再ネゴシエーション指示拡張.インターネット技術タスクフォース. doi : 10.17487/RFC5746 . ISSN  2070-1721. RFC 5746. 提案された標準。RFC 4346、4366、2246、5246、4347 を更新します。
112. Rescorla, Eric (2009年11月5日). 「TLS再ネゴシエーション攻撃を理解する」. Educated Guesswork . 2012年2月11日時点のオリジナルよりアーカイブ。 2009年11月27日閲覧。
113. "SSL_CTX_set_options SECURE_RENEGOTIATION". OpenSSL Docs . 2010年2月25日. 2010年11月26日時点のオリジナルよりアーカイブ。2010年11月18日閲覧。
114. 「GnuTLS 2.10.0 リリース」。GnuTLSリリースノート。2010年6月25日。2015年10月17日時点のオリジナルよりアーカイブ。 2011年7月24日閲覧。
115. “NSS 3.12.6 リリースノート”. NSS リリースノート. 2010年3月3日. 2012年3月6日時点のオリジナルよりアーカイブ。 2011年7月24日閲覧。
116. A. Langley; N. Modadugu; B. Moeller (2010-06-02). 「トランスポート層セキュリティ（TLS）のFalse Start」. Internet Engineering Task Force . IETF. 2013年9月5日時点のオリジナルよりアーカイブ。 2013年7月31日閲覧。
117. Gruener, Wolfgang. 「False Start: Google Proposes Faster Web, Chrome Supports It Already」。2010年10月7日時点のオリジナルよりアーカイブ。 2011年3月9日閲覧。
118. スミス、ブライアン. 「False StartとSnap Startにおける限定的なロールバック攻撃」. 2011年5月4日時点のオリジナルよりアーカイブ。 2011年3月9日閲覧。
119. Dimcev, Adrian. 「False Start」. Random SSL/TLS 101. 2011年5月4日時点のオリジナルよりアーカイブ。 2011年3月9日閲覧。
120. Mavrogiannopoulos, Nikos; Vercautern, Frederik; Velichkov, Vesselin; Preneel, Bart (2012). TLSプロトコルに対するクロスプロトコル攻撃. 2012 ACM コンピュータと通信のセキュリティに関する会議論文集(PDF) . Association for Computing Machinery. pp.  62– 72. ISBN 978-1-4503-1651-42015年7月6日時点のオリジナルよりアーカイブ（PDF）
121. 「SMACK: State Machine AttaCKs」。2015年3月12日時点のオリジナルよりアーカイブ。
122. Goodin, Dan (2015年5月20日). 「HTTPSを悪用した攻撃が数万台のWebサーバーとメールサーバーを脅かす」Ars Technica . 2017年5月19日時点のオリジナルよりアーカイブ。
123. Leyden, John (2016年3月1日). 「HTTPSウェブサイトの3分の1がDROWN攻撃にさらされている」The Register . 2016年3月1日時点のオリジナルよりアーカイブ。2016年3月2日閲覧。
124. 「新たな暗号解読攻撃により1100万以上のHTTPSウェブサイトが危険にさらされる」Ars Technica、2016年3月。2016年3月1日時点のオリジナルよりアーカイブ。 2016年3月2日閲覧。
125. Thai Duong & Juliano Rizzo (2011年5月13日). “Here Come The ⊕ Ninjas”. 2014年6月3日時点のオリジナルよりアーカイブ。
126. Goodin, Dan (2011年9月19日). 「ハッカーが数百万のサイトで使用されているSSL暗号化を破る」The Register . 2012年2月10日時点のオリジナルよりアーカイブ。
127. 「Y Combinatorがこの件についてコメント」 2011年9月20日. 2012年3月31日時点のオリジナルよりアーカイブ。
128. 「SSL/TLSにおけるCBC暗号スイートのセキュリティ：問題点と対策」2004年5月20日。2012年6月30日時点のオリジナルよりアーカイブ。
129. Ristic, Ivan (2013年9月10日). “Is BEAST Still a Threat?”. 2014年10月12日時点のオリジナルよりアーカイブ。2014年10月8日閲覧。
130. 「Chrome 安定版リリース」。Chromeリリース. 2011年10月25日. 2015年2月20日時点のオリジナルよりアーカイブ。2015年2月1日閲覧。
131. 「TLSで保護された通信に対する攻撃」Mozillaセキュリティブログ. Mozilla. 2011年9月27日. 2015年3月4日時点のオリジナルよりアーカイブ。 2015年2月1日閲覧。
132. Smith, Brian (2011-09-30). 「(CVE-2011-3389) Rizzo/Duong による SSL/TLS 1.0 における選択平文攻撃 (BEAST) (websockets-76 による)」。2012年2月10日時点のオリジナルよりアーカイブ。 2011年11月1日閲覧。
133. MSRC (2012-01-10). SSL/TLS の脆弱性により情報漏えいが起こる可能性がある (2643584).セキュリティ情報(技術レポート). MS12-006 . 2021年10月24日閲覧– Microsoft Docsより.
134. Ristic, Ivan (2013年10月31日). 「Apple、OS X 10.9 MavericksでBEAST緩和策を有効化」. 2014年10月12日時点のオリジナルよりアーカイブ。2014年10月8日閲覧。
135. Goodin, Dan (2012年9月13日). 「インターネットの信頼基盤の亀裂により、HTTPSセッションのハイジャックが可能に」Ars Technica . 2013年8月1日時点のオリジナルよりアーカイブ。 2013年7月31日閲覧。
136. Fisher, Dennis (2012年9月13日). 「CRIME攻撃、TLSリクエストの圧縮率をサイドチャネルとして利用し、セキュアセッションを乗っ取る」ThreatPost. 2012年9月15日時点のオリジナルよりアーカイブ。 2012年9月13日閲覧。
137. Goodin, Dan (2013年8月1日). 「30秒で消える：新たな攻撃がHTTPSで保護されたページから秘密を盗む」Ars Technica . Condé Nast. 2013年8月3日時点のオリジナルよりアーカイブ。 2013年8月2日閲覧。
138. Leyden, John (2013年8月2日). 「Step into the BREACH: New attack developed to read encrypted web data. The Register . 2013年8月5日時点のオリジナルよりアーカイブ。 2013年8月2日閲覧。
139. P. Gutmann (2014年9月). トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）における暗号化後MAC.インターネット技術特別調査委員会. doi : 10.17487/RFC7366 . ISSN  2070-1721. RFC 7366. 提案された標準。
140. Langley, Adam (2014年12月8日). “The POODLE bites again”. 2014年12月8日時点のオリジナルよりアーカイブ。 2014年12月8日閲覧。
141. 「ssl – BEASTで使用する最も安全な暗号は？（TLS 1.0エクスプロイト）RC4は影響を受けないと読んだ」Serverfault.com . 2022年2月20日時点のオリジナルよりアーカイブ。 2022年2月20日閲覧。
142. Pouyan Sepehrdad、Serge Vaudenay、Martin Vuagnoux (2011). 「RC4における新たなバイアスの発見と活用」Alex Biryukov、Guang Gong、Douglas R. Stinson (編)。暗号技術の特定分野：第17回国際ワークショップ、SAC 2010、カナダ、オンタリオ州ウォータールー、2010年8月12～13日、改訂版選定論文集。Lecture Notes in Computer Science. Vol. 6544. pp.  74– 91. doi :10.1007/978-3-642-19574-7_5. ISBN 978-3-642-19573-0。
143. Green, Matthew (2013年3月12日). 「今週の攻撃：TLSのRC4はちょっと壊れている」. Cryptography Engineering . 2013年3月14日時点のオリジナルよりアーカイブ。2013年3月12日閲覧。
144. AlFardan, Nadhem; Bernstein, Dan; Paterson, Kenny; Poettering, Bertram; Schuldt, Jacob. 「TLSにおけるRC4のセキュリティについて」 ロンドン大学ロイヤル・ホロウェイ校. 2013年3月15日時点のオリジナルよりアーカイブ。 2013年3月13日閲覧。
145. AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob CN (2013年7月8日). 「TLSとWPAにおけるRC4のセキュリティについて」(PDF) . Information Security Group . 2013年9月22日時点のオリジナルよりアーカイブ(PDF) . 2013年9月2日閲覧.
146. AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob CN (2013年8月15日). On the Security of RC4 in TLS (PDF) . 22nd USENIX Security Symposium. p. 51. 2013年9月22日時点のオリジナルよりアーカイブ(PDF) . 2013年9月2日閲覧. TLSにおけるRC4に対する平文復元攻撃は、真に実用的ではないものの、実行可能である。
147. Goodin, Dan (2015年7月15日). 「かつては理論上のHTTPSに対する暗号攻撃が、今や実用化に近づいている」Ars Technica . Conde Nast. 2015年7月16日時点のオリジナルよりアーカイブ。 2015年7月16日閲覧。
148. 「Mozilla Security Server Side TLS 推奨設定」Mozilla. 2015年1月3日時点のオリジナルよりアーカイブ。 2015年1月3日閲覧。
149. 「セキュリティ アドバイザリ 2868725: RC4 を無効にすることを推奨」。Microsoft。2013年11月12日。2013年11月18日時点のオリジナルよりアーカイブ。 2013年12月4日閲覧。
150. 「Microsoft EdgeおよびInternet Explorer 11でのRC4暗号のサポート終了」。Microsoft Edgeチーム。2015年9月1日。2015年9月2日時点のオリジナルよりアーカイブ。
151. Langley, Adam (2015年9月1日). “Intent to deprecate: RC4”. 2013年5月23日時点のオリジナルよりアーカイブ。2015年9月2日閲覧。
152. Barnes, Richard (2015年9月1日). 「出荷予定：Firefox 44ではRC4がデフォルトで無効化」. 2011年1月22日時点のオリジナルよりアーカイブ。
153. John Leyden (2013年8月1日). 「Gmail、Outlook.com、電子投票が暗号回避ハックで舞台上で「乗っ取られた」」The Register . 2013年8月1日時点のオリジナルよりアーカイブ。 2013年8月1日閲覧。
154. “BlackHat USA Briefings”. Black Hat 2013. 2013年7月30日時点のオリジナルよりアーカイブ。 2013年8月1日閲覧。
155. Smyth, Ben; Pironti, Alfredo (2013). WebアプリケーションにおけるTLS接続の切断による信念違反.第7回USENIX攻撃技術ワークショップ（レポート）. 2015年11月6日時点のオリジナルよりアーカイブ。 2016年2月15日閲覧。
156. AlFardan, Nadhem; Paterson, Kenneth G (2012). データグラムTLSに対する平文復元攻撃(PDF) . ネットワークおよび分散システムセキュリティシンポジウム (NDSS 2012). 2012年1月18日時点のオリジナルよりアーカイブ。
157. Goodin, Dan (2016年7月26日). 「新たな攻撃がMac、Windows、LinuxのHTTPS保護をバイパス」Ars Technica . Condé Nast. 2016年7月27日時点のオリジナルよりアーカイブ。 2016年7月28日閲覧。
158. Goodin, Dan (2016年8月24日). 「HTTPSとOpenVPN、秘密のCookieを解読できる新たな攻撃に直面」Ars Technica . 2016年8月24日時点のオリジナルよりアーカイブ。 2016年8月24日閲覧。
159. 「なぜ『ハートブリードバグ』と呼ばれるのか？」ワシントン・ポスト2014年4月9日. 2014年10月9日時点のオリジナルよりアーカイブ。
160. 「Heartbleedバグ脆弱性 [2014年4月9日]」。Comodo Group。2014年7月5日時点のオリジナルよりアーカイブ。
161. Bleichenbacher, Daniel (2006年8月). 「実装エラーに基づくBleichenbacherのRSA署名偽造」. 2014年12月16日時点のオリジナルよりアーカイブ。
162. "BERserk". Intel Security: Advanced Threat Research. 2014年9月. 2015年1月12日時点のオリジナルよりアーカイブ。
163. Goodin, Dan (2015年2月19日). 「Lenovo PC、HTTPS接続を遮断する中間者攻撃アドウェア搭載」Ars Technica . 2017年9月12日時点のオリジナルよりアーカイブ。 2017年12月10日閲覧。
164. Valsorda, Filippo (2015年2月20日). 「Komodia/Superfish SSL検証が機能しない」. Filippo.io. 2015年2月24日時点のオリジナルよりアーカイブ。
165. Goodin, Dan (2016年5月26日). 「『禁じられた攻撃』により、数十のHTTPS Visaサイトが改ざんの危険にさらされる」Ars Technica . 2016年5月26日時点のオリジナルよりアーカイブ。 2016年5月26日閲覧。
166. Clark Estes, Adam (2017年2月24日). 「最新のインターネットセキュリティ災害、クラウドブリードについて知っておくべきことすべて」Gizmodo . 2017年2月25日時点のオリジナルよりアーカイブ。 2017年2月24日閲覧。
167. Diffie, Whitfield; van Oorschot, Paul C; Wiener, Michael J. (1992年6月). 「認証と認証鍵交換」. Designs, Codes and Cryptography . 2 (2): 107– 125. CiteSeerX 10.1.1.59.6682 . doi :10.1007/BF00124891. S2CID  7356608. 2008年3月13日時点のオリジナルよりアーカイブ。 2008年2月11日閲覧。 
168. “2007年10月のTLSメーリングリストでの議論”. 2013年9月22日時点のオリジナルよりアーカイブ。2022年2月20日閲覧。
169. 「前方秘匿性による長期的なデータ保護」。2013年5月6日時点のオリジナルよりアーカイブ。2012年11月5日閲覧。
170. Bernat, Vincent (2011年11月28日). 「SSL/TLSとPerfect Forward Secrecy」. 2012年8月27日時点のオリジナルよりアーカイブ。2012年11月5日閲覧。
171. 「SSL Labs: Forward Secrecyの導入」Qualys.com、2013年6月25日。2013年6月26日時点のオリジナルよりアーカイブ。2013年7月10日閲覧。
172. Ristic, Ivan (2013年8月5日). 「SSL Labs: Forward Secrecyの導入」. Qualsys. 2013年9月20日時点のオリジナルよりアーカイブ。 2013年8月31日閲覧。
173. Langley, Adam (2013年6月27日). 「TLS forward secrecyを失敗させる方法」. imperialviolet.org . 2013年8月8日時点のオリジナルよりアーカイブ。
174. Daignière, Florent. 「TLS "Secrets": OpenSSLに実装されたセッションチケット（RFC 5077）の導入によるセキュリティへの影響を示すホワイトペーパー」（PDF） . Matta Consulting Limited. 2013年8月6日時点のオリジナルよりアーカイブ（PDF） 。 2013年8月7日閲覧。
175. Daignière, Florent. 「TLSの「秘密」：誰もが伝え忘れていたこと…」（PDF） . Matta Consulting Limited. 2013年8月5日時点のオリジナルよりアーカイブ（PDF） 。 2013年8月7日閲覧。
176. LS Huang; S. Adhikarla; D. Boneh; C. Jackson (2014). 「TLS Forward Secrecy導入の実験的研究」. IEEE Internet Computing . 18 (6): 43– 51. Bibcode :2014IIC....18f..43H. CiteSeerX 10.1.1.663.4653 . doi :10.1109/MIC.2014.86. S2CID  11264303. 2015年9月20日時点のオリジナルよりアーカイブ。 2015年10月16日閲覧。 
177. 「前方秘匿性による長期的なデータ保護」。2014年2月12日時点のオリジナルよりアーカイブ。2014年3月7日閲覧。
178. Hoffman-Andrews, Jacob. 「Twitterにおける前方秘匿性」. Twitter. 2014年2月16日時点のオリジナルよりアーカイブ。2014年3月7日閲覧。
179. Durumeric, Zakir; Ma, Zane; Springall, Drew; Barnes, Richard; Sullivan, Nick; Bursztein, Elie; Bailey, Michael; Halderman, J. Alex; Paxson, Vern (2017年9月5日). 「HTTPSインターセプトのセキュリティへの影響」 . NDSSシンポジウム. doi :10.14722/ndss.2017.23456. ISBN 978-1-891562-46-4. 2019年3月22日時点のオリジナルよりアーカイブ。2019年3月11日閲覧。
180. これらの証明書は現在X.509ですが、RFC 6091 ではOpenPGPベースの証明書 の使用も規定されています。
181. 「tls – 「プレマスターシークレット」、「マスターシークレット」、「秘密鍵」、「共有シークレット」という用語の違いは何ですか？」Cryptography Stack Exchange . 2020年9月22日時点のオリジナルよりアーカイブ。 2020年10月1日閲覧。
182. Chris (2009-02-18). 「vsftpd-2.1.0 リリース – FTPS データ接続認証に TLS セッションレジュームを使用」. Scarybeastsecurity. blogspot.com. オリジナルから2012年7月7日アーカイブ。 2012年5月17日閲覧。
183. Rescorla, Eric (2018年8月). 「暗号化ネゴシエーション」. トランスポート層セキュリティ (TLS) プロトコル バージョン 1.3. IETF. sec. 4.1.1. doi : 10.17487/RFC8446 . RFC 8446.
184. Valsorda, Filippo (2016年9月23日). 「TLS 1.3の概要とQ&A」. Cloudflareブログ. 2019年5月3日時点のオリジナルよりアーカイブ。 2019年5月3日閲覧。
185. J. Salowey; H. Zhou; P. Eronen; H. Tschofenig (2008年1月). サーバー側状態なしのトランスポート層セキュリティ（TLS）セッション再開. ネットワークワーキンググループ. doi : 10.17487/RFC5077 . RFC 5077. 廃止。RFC 8446 により廃止。RFC 8447により更新。RFC 4507 を廃止。
186. 「マルチドメインSSL証明書とワイルドカードSSL証明書の違いと用途」Sectigo公式サイト、 2025年6月6日閲覧
187. 名前ベースのSSL仮想ホスト：問題への対処方法（PDF） 、 2012年8月3日にオリジナルからアーカイブ（PDF） 、 2012年5月17日取得
188. D. Eastlake 3rd (2010年10月). トランスポート層セキュリティ（TLS）拡張：拡張定義.インターネット技術タスクフォース（IETF）. doi : 10.17487/RFC6066 . ISSN  2070-1721. RFC 6066. 提案された標準。RFC 8446、9325、8449 によって更新されました。RFC 4366 は廃止されました。
189. T. Dierks; C. Allen (1999年1月). TLSプロトコル バージョン1.0. ネットワークワーキンググループ. doi : 10.17487/RFC2246 . RFC 2246. 歴史的。RFC 4346 により廃止。RFC 5746、6176、3546、7465、7507、7919 により更新。
190. A. Freier; P. Karlton; P. Kocher (2011年8月). Secure Sockets Layer (SSL) プロトコル バージョン3.0. Internet Engineering Task Force . doi : 10.17487/RFC6101 . ISSN  2070-1721. RFC 6101. 歴史的。
191. M. Brown; R. Housley (2010年5月). トランスポート層セキュリティ（TLS）認証拡張.インターネット技術タスクフォース. doi : 10.17487/RFC5878 . ISSN  2070-1721. RFC 5878. 実験的。RFC 8447 および 8996 により更新。RFC 5246 を更新。
192. N. Mavrogiannopoulos; D. Gillmor (2011年2月). OpenPGP鍵を用いたトランスポート層セキュリティ（TLS）認証.インターネット技術タスクフォース. doi : 10.17487/RFC6091 . ISSN  2070-1721. RFC 6091. 情報提供。RFC 5081 を廃止します。
193. M. Salter; R. Housley (2012年1月). トランスポート層セキュリティ（TLS）のSuite Bプロファイル.インターネット技術タスクフォース. doi : 10.17487/RFC6460 . ISSN  2070-1721. RFC 6460. 歴史的。NSAがSuite B暗号のサポートを停止した ため、2018年に歴史的に変更されました。RFC 8996により更新されました。RFC 5430は廃止されました。
194. J. Merkle; M. Lochter (2013年10月). 楕円曲線暗号（ECC）Brainpool Curves for Transport Layer Security (TLS). Internet Engineering Task Force . doi : 10.17487/RFC7027 . RFC 7027. 情報提供。RFC 4492 を更新します。
195. S. Friedl; A. Popov; A. Langley; E. Stephan (2014年7月). トランスポート層セキュリティ (TLS) アプリケーション層プロトコルネゴシエーション拡張.インターネット技術タスクフォース. doi : 10.17487/RFC7301 . ISSN  2070-1721. RFC 7301. 提案された標準。RFC 8447 によって更新されました。
196. B. Möller; A. Langley (2015年5月). プロトコルダウングレード攻撃を防ぐためのTLSフォールバックシグナリング暗号スイート値（SCSV）.インターネット技術タスクフォース. doi : 10.17487/RFC7507 . RFC 7507. 廃止。RFC 8996 により廃止。RFC 4347、2246、4346、5246、6347 を更新。
197. A. Delignat-Lavaud; A. Pironti; A. Langley; M. Ray (2015年9月). K. Bhargavan (編). トランスポート層セキュリティ (TLS) セッションハッシュおよび拡張マスターシークレット拡張.インターネット技術タスクフォース. doi : 10.17487/RFC7627 . ISSN  2070-1721. RFC 7627. 提案された標準。RFC 5246 を更新します。
198. A. Langley (2015年10月). トランスポート層セキュリティ (TLS) ClientHello パディング拡張.インターネット技術タスクフォース. doi : 10.17487/RFC7685 . ISSN  2070-1721. RFC 7685. 提案された標準。RFC 5246 を更新します。
199. S. Blake-Wilson; M. Nystrom; D. Hopwood; J. Mikkelsen; T. Wright (2006年4月). トランスポート層セキュリティ（TLS）拡張. IETFネットワークワーキンググループ. doi : 10.17487/RFC4366 . RFC 4366. 廃止。RFC 5246 および 6066 により廃止。RFC 5746により更新。RFC 3546 を廃止。RFC 4346 を更新。
200. S. Blake-Wilson; N. Bolyard; V. Gupta; C. Hawk; B. Moeller (2006年5月). トランスポート層セキュリティ（TLS）のための楕円曲線暗号（ECC）暗号スイート. ネットワークワーキンググループ. doi : 10.17487/RFC4492 . RFC 4492. 廃止。RFC 8422 により廃止。RFC 5246、7027、7919 により更新。
201. S. Santesson (2006年9月). 補足データのためのTLSハンドシェイクメッセージ. ネットワークワーキンググループ. doi : 10.17487/RFC4680 . RFC 4680. 提案された標準。RFC 4346 を更新します。RFC 8447 および 8996 によって更新されます。
202. S. Santesson; A. Medvinsky; J. Ball (2006年10月). TLSユーザーマッピング拡張. ネットワークワーキンググループ. doi : 10.17487/RFC4681 . RFC 4681. 提案された標準。RFC 4346 を更新します。RFC 8996 によって更新されます。
203. U. Blumenthal; P. Goel (2007年1月). トランスポート層セキュリティ（TLS）におけるNULL暗号化を用いた事前共有鍵（PSK）暗号スイート. IETFネットワークワーキンググループ. doi : 10.17487/RFC4785 . RFC 4785. 提案された標準。RFC 8996 によって更新されました。
204. D. Taylor; T. Wu; N. Mavrogiannopoulos; T. Perrin (2007年11月). TLS認証におけるセキュアリモートパスワード（SRP）プロトコルの使用. ネットワークワーキンググループ. doi : 10.17487/RFC5054 . RFC 5054. 情報提供。RFC 8996 により更新されました。
205. N. Mavrogiannopoulos (2007年11月). OpenPGP鍵を用いたトランスポート層セキュリティ（TLS）認証. Network Working Group. doi : 10.17487/RFC5081 . RFC 5081. 実験的。RFC 6091 により廃止されました。
206. B. Simon; D. Aboba; R. Hurst (2008年3月). EAP-TLS認証プロトコル. ネットワークワーキンググループ. doi : 10.17487/RFC5216 . RFC 5216. 提案された標準。RFC 9190 および 8996 によって更新されました。RFC 2716 は廃止されました。
207. C. Newman (1999年6月). IMAP、POP3、ACAPでのTLSの使用. ネットワークワーキンググループ. doi : 10.17487/RFC2595 . RFC 2595. 提案された標準。RFC 4616、7817、8314 によって更新されました。
208. A. Medvinsky; M. Hur (1999年10月). トランスポート層セキュリティ（TLS）へのKerberos暗号スイートの追加. ネットワークワーキンググループ. doi : 10.17487/RFC2712 . RFC 2712. 提案された標準。
209. E. Rescorla (2000年5月). HTTP Over TLS. IETFネットワークワーキンググループ. doi : 10.17487/RFC2818 . RFC 2818. 廃止。RFC 9110 により廃止。RFC 5785 および 7230 により更新。
210. P. Hoffman (2002年2月). 「Transport Layer Securityを介した安全なSMTPのためのSMTPサービス拡張」. Network Working Group. doi : 10.17487/RFC3207 . RFC 3207. 提案された標準。RFC 7817 によって更新されました。RFC 2487 は廃止されました。
211. P. Chown (2002年6月). トランスポート層セキュリティ（TLS）のためのAdvanced Encryption Standard（AES）暗号スイート. ネットワークワーキンググループ. doi : 10.17487/RFC3268 . RFC 3268. 廃止。RFC 5246 により廃止されました。
212. S. Blake-Wilson; M. Nystrom; D. Hopwood; J. Mikkelsen; T. Wright (2003年6月). トランスポート層セキュリティ（TLS）拡張. ネットワークワーキンググループ. doi : 10.17487/RFC3546 . RFC 3546. 廃止。RFC 4366 により廃止。RFC 2246を更新
213. S. Hollenbeck (2004年5月). トランスポート層セキュリティプロトコル圧縮方式. ネットワークワーキンググループ. doi : 10.17487/RFC3749 . RFC 3749. 提案された標準。RFC 8996 および 8447 によって更新されました。
214. R. Friend (2004年11月). Lempel-Ziv-Stac (LZS) を用いたトランスポート層セキュリティ (TLS) プロトコル圧縮. ネットワークワーキンググループ. doi : 10.17487/RFC3943 . RFC 3943. 情報提供。RFC 8996 により更新されました。
215. S. Moriai; S. Moriai; M. Kanda (2005年7月). トランスポート層セキュリティ (TLS) への Camellia 暗号スイートの追加. IETFネットワークワーキンググループ. doi : 10.17487/RFC4132 . RFC 4132. 廃止。RFC 5932 により廃止されました。
216. P. Ford-Hutchinson (2005年10月). TLSによるFTPのセキュリティ保護. Network Working Group. doi : 10.17487/RFC4217 . RFC 4217. 提案された標準。RFC 8996 によって更新されました。
217. P. Eronen; H. Tschofenig編 (2005年12月). トランスポート層セキュリティ (TLS) のための事前共有鍵暗号スイート. ネットワークワーキンググループ. doi : 10.17487/RFC4279 . RFC 4279. 提案された標準。RFC 8996 によって更新されました。
218. . Saint-Andre（2015年2月）。トランスポート層セキュリティ（TLS）とデータグラムTLS（DTLS）に対する既知の攻撃のまとめ。インターネット技術タスクフォース。doi ：10.17487/ RFC7457。ISSN 2070-1721。RFC  7457 。 情報提供。
219. Y. Sheffer; P. Saint-Andre; T. Fossati (2022年11月). トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）の安全な使用に関する推奨事項.インターネット技術タスクフォース. doi : 10.17487/RFC9325 . BCP 195. RFC 9325. 現在のベストプラクティス 195。RFC 7525 を廃止します。RFC 5288 および 6066 を更新します。

「https://en.wikipedia.org/w/index.php?title=Transport_Layer_Security&oldid=1322899919#SSL_1.0,_2.0,_and_3.0」より取得