Loading article…
トランスポート層セキュリティ( TLS ) は、インターネットなどのコンピュータ ネットワーク上で通信のセキュリティを確保するために設計された暗号化プロトコルです。このプロトコルは、電子メール、インスタント メッセージング、Voice over IPなどのアプリケーションで広く使用されていますが、 HTTPS のセキュリティ保護における使用が最も広く知られています。
TLS プロトコルの主な目的は、通信する 2 つ以上のコンピュータ アプリケーション間で、証明書の使用などの暗号化を使用して、プライバシー(機密性)、整合性、信頼性などのセキュリティを提供することです。これはプレゼンテーション層で実行され、それ自体が TLS レコードと TLSハンドシェイク プロトコルの 2 つの層で構成されています。
密接に関連するデータグラムトランスポート層セキュリティ（DTLS）は、データグラムベースのアプリケーションにセキュリティを提供する通信プロトコルです。技術文書では、両方のバージョンに適用される場合に「（ D）TLS 」という参照がよく見られます。[1]
TLS は、1999 年に初めて定義されたインターネット技術タスク フォース(IETF) の提案標準であり、現在のバージョンは 2018 年 8 月に定義された TLS 1.3 です。TLS は、Netscape CommunicationsがNetscape Navigator Web ブラウザーに HTTPS プロトコルを追加するために開発した、現在は廃止されたSSL ( Secure Sockets Layer ) 仕様 (1994、1995、1996)に基づいています。
説明
クライアント サーバーアプリケーションは、盗聴や改ざんを防止するように設計された方法で、 TLSプロトコルを使用してネットワーク経由で通信します。
アプリケーションはTLS（またはSSL）の有無にかかわらず通信できるため、クライアントはサーバーにTLS接続を設定するように要求する必要があります。 [2]これを実現する主な方法の1つは、TLS接続に別のポート番号を使用することです。ポート80は通常、暗号化されていないHTTPトラフィックに使用され、ポート443は暗号化されたHTTPSトラフィックに使用される一般的なポートです。別のメカニズムは、たとえばメールやニュースプロトコルを 使用する場合、サーバーにプロトコル固有のSTARTTLS要求を送信して接続をTLSに切り替えることです。
クライアントとサーバーがTLSの使用に同意すると、ハンドシェイク手順を使用してステートフル接続をネゴシエートします（§ TLSハンドシェイクを参照）。 [3]プロトコルは、非対称暗号を使用したハンドシェイクを使用して、暗号設定だけでなく、それ以降の通信が対称暗号を使用して暗号化されるセッション固有の共有キーも確立します。このハンドシェイク中に、クライアントとサーバーは接続のセキュリティを確立するために使用されるさまざまなパラメータに同意します。
- ハンドシェイクは、クライアントが TLS 対応サーバーに接続して安全な接続を要求し、サポートされている暗号スイート(暗号とハッシュ関数)のリストを提示したときに開始されます。
- サーバーはこのリストから、サポートしている暗号とハッシュ関数を選択し、その決定をクライアントに通知します。
- サーバーは通常、デジタル証明書の形式で ID を提供します。証明書には、サーバー名、証明書の信頼性を保証する信頼できる証明機関(CA)、およびサーバーの公開暗号化キーが含まれています。
- クライアントは続行する前に証明書の有効性を確認します。
- 安全な接続に使用されるセッション キーを生成するには、クライアントは次のいずれかを実行します。
- 乱数（PreMasterSecret ）をサーバーの公開鍵で暗号化し、その結果をサーバーに送信します（サーバーのみが秘密鍵で復号化できる必要があります）。その後、両者は乱数を使用して、セッション中のデータのその後の暗号化と復号化のための一意のセッションキーを生成します。
- Diffie-Hellman 鍵交換(またはその変形である楕円曲線 DH )を使用して、暗号化と復号化のためのランダムで一意のセッション キーを安全に生成します。このセッション キーには、前方秘匿性という追加のプロパティがあります。つまり、サーバーの秘密鍵が将来公開された場合、その秘密鍵を使用して現在のセッションを復号化することはできません。たとえセッションが第三者によって傍受され、記録されたとしてもです。
これによりハンドシェイクが終了し、安全な接続が開始されます。接続が終了するまで、セッション キーを使用して暗号化および復号化が行われます。上記の手順のいずれかが失敗すると、TLS ハンドシェイクは失敗し、接続は作成されません。
TLSとSSLは、OSIモデルやTCP/IPモデルのどの層にもきちんと当てはまりません。[4] [5] TLSは「信頼できるトランスポートプロトコル（TCPなど）の上」で実行されます。[6] : §1 これは、TLSがトランスポート層の上にあることを意味します。TLSは、通常、プレゼンテーション層の機能である上位層に暗号化を提供します。ただし、アプリケーションは一般にTLSをトランスポート層のように使用します。[4] [5] TLSを使用するアプリケーションは、TLSハンドシェイクの開始と交換された認証証明書の処理を積極的に制御する必要があります。[6] : §1
TLSによって保護されている場合、クライアント（例：Webブラウザ）とサーバー（例：wikipedia.org）間の接続には、次のすべての特性があります。[6] ：§1
- 送信されるデータの暗号化に対称鍵アルゴリズムが使用されるため、接続はプライベート(または機密性)です。この対称暗号化の鍵は、セッションの開始時にネゴシエートされた共有シークレットに基づいて、接続ごとに一意に生成されます。サーバーとクライアントは、データの最初のバイトが送信される前に、使用する暗号化アルゴリズムと暗号化キーの詳細をネゴシエートします (以下を参照)。共有シークレットのネゴシエーションは安全 (ネゴシエートされたシークレットは盗聴者には利用できず、接続の途中に介入した攻撃者でさえも取得できない) かつ信頼性があります (攻撃者はネゴシエーション中に通信を変更しても検出されません)。
- 通信相手の ID は、公開鍵暗号化を使用して認証できます。この認証はサーバーでは必須ですが、クライアントではオプションです。
- 送信される各メッセージには、送信中に検出されないデータの損失や変更を防ぐためにメッセージ認証コードを使用したメッセージ整合性チェックが含まれているため、接続は信頼できます(または整合性があります)。
TLS は、キーの交換、データの暗号化、メッセージの整合性の認証を行うためのさまざまな方法をサポートしています。その結果、TLS の安全な構成には多くの構成可能なパラメータが関係し、すべての選択肢が上記のリストで説明したプライバシー関連のプロパティをすべて提供するわけではありません (以下の表「§ キー交換」、「§ 暗号セキュリティ」、および「§ データの整合性」を参照してください)。
TLS が提供しようとしている通信セキュリティの側面を破壊しようとする試みが行われており、これらのセキュリティ脅威に対処するためにプロトコルは数回改訂されています。Web ブラウザーの開発者は、潜在的なセキュリティの弱点が発見された後、それらから防御するために製品を繰り返し改訂してきました (Web ブラウザーの 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の一連のデルタとして提供されました。[11]同様に、2012年にリリースされたDTLSは、TLS 1.2のデルタです。TLSバージョンに合わせて、DTLS 1.2のバージョン番号が付けられました。最後に、2022年のDTLS 1.3は、TLS 1.3のデルタです。前の2つのバージョンと同様に、DTLS 1.3は、「順序保護/非再生可能性を除いて、[TLS 1.3と]同等のセキュリティ保証」を提供することを目的としています。[12]
Cisco AnyConnect [13]および InterCloud Fabric、[14] OpenConnect、[15] ZScalerトンネル、[16] F5 Networks Edge VPN Client、[17]およびCitrix Systems NetScaler [18]を含む多くのVPNクライアントは、UDPトラフィックのセキュリティ保護にDTLSを使用しています。さらに、すべての最新のWebブラウザはWebRTC用のDTLS-SRTP [19]をサポートしています。
歴史と発展
セキュアデータネットワークシステム
トランスポート層セキュリティプロトコル（TLS）は、他のいくつかの基本的なネットワークセキュリティプラットフォームとともに、1986年8月に国家安全保障局、国立標準局、国防通信局、および12の通信およびコンピュータ企業が共同で開発し、セキュアデータネットワークシステム（SDNS）と呼ばれる特別プロジェクトを立ち上げました。[26]このプログラムは、1987年9月に第10回全国コンピュータセキュリティ会議で発表された一連の論文で説明されました。
この革新的な研究プログラムは、パブリックおよびプライベート インターネット上のアプリケーションに実装される、次世代の安全なコンピュータ通信ネットワークと製品仕様の設計に重点を置いていました。このプログラムは、米国政府の GOSIP プロファイルと、国際的な大規模な ITU-ISO JTC1 インターネット活動の両方で急速に発展している新しい OSI インターネット標準を補完することを目的としていました。当初は SP4 プロトコルとして知られていましたが、TLS に改名され、その後 1995 年に国際標準 ITU-T X.274|ISO/IEC 10736:1995 として公開されました。
セキュア ネットワーク プログラミング (SNP)
トランスポート層セキュリティに向けた初期の研究には、セキュア ネットワーク プログラミング(SNP)アプリケーション プログラミング インターフェイス(API) が含まれていました。これは、1993 年に、既存のネットワーク アプリケーションにセキュリティ対策を後から簡単に組み込めるように、バークレー ソケットによく似たセキュア トランスポート層 API を使用するアプローチを研究したものです。SNP は 1994 年のUSENIXサマー テクニカル カンファレンスで公開され、発表されました。 [27] [28] SNP プロジェクトは、 1991 年にNSAからテキサス大学オースティン校のサイモン ラム教授に提供された助成金によって資金提供されました。 [29]セキュア ネットワーク プログラミングは、 2004 年のACM ソフトウェア システム賞を受賞しました。[30] [ 31]サイモン ラムは、「1993 年にセキュア ソケットを発明し、SNP という最初のセキュア ソケット レイヤーを実装した」ことでインターネットの殿堂 入りを果たしました。 [32] [33]
SSL 1.0、2.0、3.0
Netscape はオリジナルの SSL プロトコルを開発し、 1995 年から 1998 年までNetscape Communicationsの主任科学者を務めたTaher Elgamal は「SSL の父」と呼ばれています。[34] [35] [36] [37] SSL バージョン 1.0 は、プロトコルに重大なセキュリティ上の欠陥があったため、公開されませんでした。バージョン 2.0 は、1995 年 2 月にリリースされた後、すぐにセキュリティとユーザビリティに関する欠陥がいくつかあることがわかりました。メッセージ認証と暗号化に同じ暗号キーを使用していました。秘密のプレフィックスを持つ MD5 ハッシュ関数を使用する弱い MAC 構造であったため、長さ拡張攻撃に対して脆弱でした。また、オープニング ハンドシェイクと明示的なメッセージ クローズのどちらにも保護が提供されていなかったため、中間者攻撃が検出されない可能性がありました。さらに、SSL 2.0 は単一のサービスと固定ドメイン証明書を想定していたため、Web サーバーで広く使用されている仮想ホスティング機能と競合し、ほとんどの Web サイトは SSL の使用を事実上妨げられていました。
これらの欠陥により、プロトコルをSSLバージョン3.0に完全に再設計する必要が生じました。[38] [36] 1996年にリリースされたこのバージョンは、ポール・コッチャーが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で使用されている方法では破られる可能性があります。[39] SSL 3.0は2015年6月にRFC 7568によって非推奨となりました 。
TLS1.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 のプロトコルを承認しただけのようには見えないようにするため」だったと書いています。[40]
PCI Councilは、組織が2018年6月30日までにTLS 1.0からTLS 1.1以上に移行することを提案しました。 [41] [42] 2018年10月、Apple、Google、Microsoft、Mozillaは共同で、2020年3月にTLS 1.0と1.1を廃止すると発表しました。 [20] TLS 1.0と1.1は、2021年3月にRFC 8996 で正式に廃止されました。
TLS1.1 について
TLS 1.1は2006年4月にRFC 4346で定義されました。[43]これはTLSバージョン1.0からのアップデートです。このバージョンの重要な違いは次のとおりです。
TLSバージョン1.0および1.1のサポートは2020年頃にウェブサイトで広く廃止され、Firefoxバージョン24より前とChromiumベースのブラウザ29より前へのアクセスが無効になりました。 [45] [46]
TLS1.2 について
TLS 1.2は2008年8月にRFC 5246で定義されました。 [23]これは以前のTLS 1.1仕様に基づいています。主な違いは次のとおりです。
- 疑似乱数関数( PRF) の MD5とSHA -1 の組み合わせがSHA-256に置き換えられ、暗号スイートで指定された PRF を使用するオプションが追加されました。
- 完成したメッセージのハッシュにおけるMD5とSHA-1の組み合わせは、暗号スイート固有のハッシュアルゴリズムを使用するオプションを備えたSHA-256に置き換えられました。ただし、完成したメッセージのハッシュのサイズは、依然として少なくとも96ビットである必要があります。[23] ：§7.4.9
- デジタル署名要素の MD5 と SHA-1 の組み合わせは、ハンドシェイク中にネゴシエートされた単一のハッシュに置き換えられました。このハッシュのデフォルトは SHA-1 です。
- クライアントとサーバーが受け入れるハッシュと署名アルゴリズムを指定する機能が強化されました。
- 主にAdvanced Encryption Standard (AES) 暗号化のGalois/Counter Mode (GCM) およびCCM モードで使用される、認証された暗号化暗号のサポートが拡張されました。
- TLS拡張定義とAES暗号スイートが追加された。[44]
すべての TLS バージョンは、2011 年 3 月にRFC 6176でさらに改良され 、SSL との下位互換性が削除されたため、TLS セッションでは Secure Sockets Layer (SSL) バージョン 2.0 の使用がネゴシエートされることはなくなりました。現在、TLS 1.2 が廃止される正式な日付はありません。TLS 1.2 の仕様は、可能な限り安全に保つために、標準化過程文書RFC 8446 によっても再定義されました。現在、TLS 1.3 で通信できないクライアントとのみネゴシエートすることを目的としたフェイルオーバー プロトコルと見なされています (TLS 1.2 の元の RFC 5246 定義はそれ以降廃止されています)。
TLS1.3 について
TLS 1.3は2018年8月にRFC 8446で定義されました。[6]これは以前のTLS 1.2仕様に基づいています。TLS 1.2との主な違いは次のとおりです。[47]
- 鍵共有と認証アルゴリズムを暗号スイートから分離する[44] [6] : §11
- 弱い楕円曲線やあまり使われていない名前付き楕円曲線のサポートを削除する
- MD5およびSHA-224暗号化ハッシュ関数のサポートの削除
- 以前の構成が使用されている場合でもデジタル署名を要求する
- HKDFと半一時的なDH提案の統合
- 再開をPSKとチケットに置き換える
- 1- RTTハンドシェイクのサポートと0- RTTの初期サポート
- (EC)DH鍵合意中に一時鍵を使用することで、完全な前方秘匿性を義務付ける
- 圧縮、再ネゴシエーション、非AEAD暗号、ヌル暗号、[48]非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をデフォルトで有効化しました。[49]その後、TLS 1.3のサポートは、少数のユーザーとの互換性の問題により、自動的に有効化されませんでしたが[50] 、2017年3月にリリースされたFirefox 52.0に追加されました。TLS 1.3は、2018年5月にFirefox 60.0のリリースでデフォルトで有効化されました。[51]
Google Chromeは2017年に短期間TLS 1.3をデフォルトバージョンに設定しました。その後、Blue Coatウェブプロキシなどの互換性のないミドルボックスが原因で、デフォルトから削除されました。[52]
TLS の新バージョンが許容できない点は、プロトコルの硬直化です。ミドルボックスがプロトコルのバージョンパラメータを硬直化させてしまったのです。その結果、バージョン 1.3 はバージョン 1.2 のワイヤイメージを模倣しています。この変更は設計プロセスのかなり後期に発生し、ブラウザの展開中に初めて発見されました。[53]この許容できない点の発見により、最も一致するバージョンを選択するという以前のバージョンネゴシエーション戦略も、硬直化のレベルが機能しないために放棄されました。[54] 'グリース' 拡張ポイントは、プロトコル参加者の 1 人が存在しない拡張機能のサポートを主張することで、認識されていないが実際には存在する拡張機能が許容され、硬直化を防ぐもので、もともと TLS 用に設計されたものですが、その後他の場所でも採用されています。[54]
2017年にシンガポールで開催されたIETF 100ハッカソンでは、TLSグループはオープンソースアプリケーションをTLS 1.3に対応させる取り組みを行いました。[55] [56] TLSグループは、cyberstorm.muチームを通じて日本、イギリス、モーリシャスからの参加者で構成されていました。[56]この作業はロンドンのIETF 101ハッカソン、[57]とモントリオールのIETF 102ハッカソンでも継続されました。 [58]
wolfSSLは、2017年5月にリリースされたバージョン3.11.1からTLS 1.3の使用を可能にしました。 [59] TLS 1.3の最初の商用実装として、wolfSSL 3.11.1はドラフト18をサポートし、現在は最終バージョンのドラフト28 [60]と多くの古いバージョンをサポートしています。TLS 1.2と1.3のパフォーマンスの違いに関する一連のブログが公開されました。[61]
で2010年、人気のOpenSSLプロジェクトはライブラリのバージョン1.1.1をリリースし、その中でTLS 1.3のサポートが「目玉となる新機能」となった。[62]
Windows 11およびWindows Server 2022のGAリリースでは、セキュアチャネル（schannel）にTLS 1.3のサポートが追加されました。[63]
エンタープライズトランスポートセキュリティ
電子フロンティア財団は、 TLS 1.3 を賞賛し、TLS 1.3 の重要なセキュリティ対策を意図的に無効にするバリアント プロトコルである Enterprise Transport Security (ETS) について懸念を表明しました。[64]元々 Enterprise TLS (eTLS) と呼ばれていた ETS は、「ETSI TS103523-3」(「ミドルボックス セキュリティ プロトコル、パート 3: Enterprise Transport Security」) として知られる公開標準です。これは、銀行システムなどの専用ネットワーク内でのみ使用することを目的としています。ETS は、専用ネットワークに接続されたサードパーティ組織が秘密鍵を使用してネットワーク トラフィックを監視し、マルウェアを検出したり、監査を容易にしたりできるようにするための前方秘匿性をサポートしていません。[65] [66]主張されている利点にもかかわらず、EFF は前方秘匿性が失われると、データが露出しやすくなる可能性があると警告し、トラフィックを分析するより優れた方法があると述べています。[64]
デジタル証明書
デジタル証明書は、証明書の指定された主体による公開鍵の所有権を証明し、その鍵の特定の予想される使用法を示します。これにより、他のユーザー (信頼当事者) は、証明された公開鍵に対応する秘密鍵による署名またはアサーションに依存できるようになります。キーストアと信頼ストアは、.pem、.crt、.pfx、.jksなど、さまざまな形式にすることができます。
認証局
TLSは通常、証明書の信頼性を確立するために信頼できるサードパーティの証明機関に依存しています。信頼は通常、ユーザーエージェントソフトウェアとともに配布される証明書のリストに固定されており、[67]信頼する当事者によって変更される可能性があります。
有効なTLS証明書を監視しているNetcraftによると、市場をリードする認証局（CA）は調査開始以来ずっとSymantec （認証サービス事業部門がSymantecに買収される前はVeriSign）である。Netcraftが数えたところによると、2015年の時点でSymantecは全証明書の3分の1弱を占め、最もアクセス数の多い100万のウェブサイトで使用されている有効な証明書の44％を占めていた。[68] 2017年、SymantecはTLS/SSL事業をDigiCertに売却した。[69]更新されたレポートでは、 2019年5月以降、 IdenTrust、DigiCert、Sectigoが市場シェアでトップ3の認証局であることが示された。 [70]
X.509証明書を選択した場合、証明書とその所有者の関係を検証し、証明書の生成、署名、有効性の管理を行うために、証明機関と公開鍵基盤が必要になります。これは信頼のウェブを介してIDを確認するよりも便利ですが、2013年の大量監視の暴露により、証明機関がセキュリティの観点から弱点であり、証明機関が協力した場合（または侵害された場合）、中間者攻撃（MITM）を許す可能性があることが広く知られるようになりました。[71] [72]
SSL証明書の重要性
- 暗号化: SSL 証明書は、Web サーバーとユーザーのブラウザー間で送信されるデータを暗号化し、送信中も機密情報が保護されるようにします。この暗号化技術により、権限のない第三者がデータを傍受したり解釈したりすることが防止され、ハッキングやデータ侵害などのリスクから保護されます。
- 認証: SSL 証明書は認証も提供し、Web サイトの整合性を証明し、訪問者が悪意のある偽者ではなく正しいサーバーに接続していることを証明します。この認証方法は、消費者が信頼できる安全な Web サイトを扱っていることを保証することで、信頼を得るのに役立ちます。
- 整合性: SSL 証明書のもう 1 つの重要な役割は、データの整合性を確保することです。SSL は暗号化技術を使用して、サーバーとブラウザー間で通信されるデータが転送中に無傷で変更されていないことを確認します。これにより、悪意のある人物がデータに干渉するのを防ぎ、データの整合性と信頼性を確保します。
アルゴリズム
鍵交換または鍵合意
クライアントとサーバーが 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)、[23] 事前共有キー(TLS_PSK) [73]、およびセキュア リモート パスワード(TLS_SRP) [74]などがあります。
TLS_DH_anon および TLS_ECDH_anon 鍵合意方式は、サーバーまたはユーザーを認証しないため、中間者攻撃に対して脆弱であるため、ほとんど使用されません。TLS_DHE と TLS_ECDHE のみが前方秘匿性を提供します。
交換/合意時に使用される公開鍵証明書は、交換時に使用される公開/秘密暗号化キーのサイズも異なり、提供されるセキュリティの堅牢性も異なります。2013年7月、Googleは、暗号化の強度がキーサイズに直接関係するため、ユーザーに提供するTLS暗号化のセキュリティを強化するために、1024ビットの公開鍵の使用をやめ、代わりに2048ビットのキーに切り替えると発表しました。[75] [76]
暗号
- 注記
- ^ abcd RFC 5746 を実装して、このプロトコルを破損する可能性のある再ネゴシエーションの欠陥を修正する必要があります。
- ^ライブラリが RFC 5746に記載されている修正を実装すると 、SSL 3.0 仕様に違反することになります。SSL 3.0 仕様は、TLS とは異なり IETF では変更できません。現在のほとんどのライブラリは修正を実装し、これによって発生する違反を無視します。
- ^ ab BEAST 攻撃は、クライアントまたはサーバーによって軽減されない限り、SSL 3.0 および TLS 1.0 で使用されるすべてのブロック暗号 (CBC 暗号) を破ります。§ Web ブラウザーを参照してください。
- ^ POODLE攻撃は、クライアントまたはサーバーによって軽減されない限り、SSL 3.0 で使用されるすべてのブロック暗号 (CBC 暗号) を破ります。§ Web ブラウザーを参照してください。
- ^ abcdefg AEAD暗号 ( GCMやCCMなど) は TLS 1.2 以降でのみ使用できます。
- ^ abcdefgh CBC 暗号は 、ライブラリがタイミングサイドチャネルを排除するように注意深く記述されていない場合、ラッキー サーティーン攻撃によって攻撃される可能性があります。
- ^ abcdef Sweet32攻撃は、ブロックサイズが64ビットのブロック暗号を破ります。[86]
- ^ 3DESの鍵長は168ビットであるが、3DESの有効なセキュリティ強度は112ビットに過ぎず、[87]推奨される最小値の128ビットを下回っている。[88]
- ^ ab IDEAとDESはTLS 1.2から削除されました。[89]
- ^ abc 40 ビット強度の暗号スイートは、特定の強力な暗号化アルゴリズムを含む暗号化ソフトウェアの輸出を禁止する米国の規制（米国からの暗号化の輸出を参照）に準拠するために、意図的にキーの長さを短くして設計されました。これらの弱いスイートは、TLS 1.1 以降では禁止されています。
- ^ RFC 7465では、TLS のすべてのバージョンで RC4 を使用することが禁止されています (RC4 攻撃により、SSL/TLS で使用される RC4 が弱体化または破壊されるため)。
- ^ 認証のみ、暗号化なし。
データの整合性
データの整合性にはメッセージ認証コード（MAC）が使用されます。ブロック暗号のCBCモードではHMACが使用されます。GCMやCCMモードなどの認証暗号化（AEAD）ではAEAD統合MACが使用され、 HMACは使用されません。[6] ：§8.4 HMACベースのPRF、またはHKDFはTLSハンドシェイクに使用されます。
アプリケーションと採用
アプリケーション設計では、 TLS は通常、トランスポート層プロトコルの上に実装され、 HTTP、FTP、SMTP、NNTP、XMPPなどのプロトコルのプロトコル関連データをすべて暗号化します。
歴史的に、TLS は主に、伝送制御プロトコル(TCP)などの信頼性の高いトランスポート プロトコルで使用されてきました。ただし、ユーザー データグラム プロトコル(UDP) やデータグラム輻輳制御プロトコル(DCCP)などのデータグラム指向のトランスポート プロトコルでも実装されており、その使用法は、データグラムトランスポート層セキュリティ( DTLS )という用語を使用して独自に標準化されています。
ウェブサイト
TLSの主な用途は、HTTPプロトコルでエンコードされたWebサイトとWebブラウザ間のワールドワイドウェブトラフィックを保護することです。このTLSを使用したHTTPトラフィックの保護がHTTPSプロトコルです。[91]
- 注記
- ^ 上記の§暗号表を参照
- ^ § Webブラウザおよび§ TLS/SSLに対する攻撃のセクションを参照
ウェブブラウザ
2016年4月現在[アップデート]、すべての主要ウェブブラウザの最新バージョンはTLS 1.0、1.1、1.2をサポートしており、デフォルトで有効になっています。ただし、サポートされているすべてのMicrosoftオペレーティングシステムが最新バージョンのIEをサポートしているわけではありません。さらに、多くのMicrosoftオペレーティングシステムは現在複数のバージョンのIEをサポートしていますが、MicrosoftのInternet ExplorerサポートライフサイクルポリシーFAQ Archived 2023-06-20 at the Wayback Machineによると、これは変更されています。「2016年1月12日以降、サポートされているオペレーティングシステムで利用可能な最新バージョンのInternet Explorerのみがテクニカルサポートとセキュリティ更新プログラムを受け取ります。」このページには、その日付でサポートされている各オペレーティングシステムのIEの最新バージョンがリストされています。次の重要な日付は、オペレーティングシステムがサポート終了段階に達したときです。2022年6月15日以降、Internet Explorer 11は、Microsoftのモダンライフサイクルポリシーに従うWindows 10エディションのサポートを終了しました。[95] [96]
既知の攻撃に対する緩和策はまだ十分ではありません。
- POODLE 攻撃に対する軽減策: 一部のブラウザでは、すでに SSL 3.0 へのフォールバックを防止していますが、この軽減策はクライアントだけでなくサーバーでもサポートされる必要があります。SSL 3.0 自体を無効にするか、「アンチ 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 および 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という名称）[97]
- 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 コンピュータおよび通信セキュリティ会議で発表された論文[98]では、多くのアプリケーションがこれらの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シグナリングの認証と暗号化を提供するために使用できます。[99]
安全
TLS/SSLに対する攻撃
TLS/SSL に対する重大な攻撃を以下に示します。
2015年2月、IETFはTLS/SSLに対するさまざまな既知の攻撃をまとめた情報RFC [100]を発行しました。
再交渉攻撃
2009 年 8 月に、SSL 3.0 および TLS の現在のすべてのバージョンに対するプレーンテキスト インジェクション攻撃につながる可能性がある再ネゴシエーション手順の脆弱性が発見されました。[101]たとえば、https 接続をハイジャックできる攻撃者は、クライアントと Web サーバー間の通信の冒頭に独自のリクエストを差し込むことができます。攻撃者は実際にはクライアントとサーバーの通信を復号化できないため、一般的な中間者攻撃とは異なります。短期的な修正は、Web サーバーが再ネゴシエーションを許可しないようにすることです。通常、クライアント証明書認証が使用されない限り、他の変更は必要ありません。この脆弱性を修正するために、TLS の再ネゴシエーション指示拡張が提案されました。これにより、クライアントとサーバーは、再ネゴシエーション ハンドシェイクに以前のハンドシェイクに関する情報を含めて検証する必要があります。[102]この拡張は提案された標準となり、 RFC 5746という番号が割り当てられました 。この RFC はいくつかのライブラリによって実装されています。[103] [104] [105]
ダウングレード攻撃:フリーク攻撃とログジャム攻撃
プロトコルダウングレード攻撃(バージョン ロールバック攻撃とも呼ばれる) は、Web サーバーを騙して、安全でないとして長い間放棄されてきた以前のバージョンの TLS (SSLv2 など) との接続をネゴシエートさせます。
元のプロトコルに対する以前の変更、例えばFalse Start [106] (Google Chrome [107]で採用され有効化されている) やSnap Start は、限定的なTLSプロトコルダウングレード攻撃[108]を引き起こしたり、クライアントからサーバーに送信される暗号スイートリストの変更を可能にしたりしたと報告されている。そうすることで、攻撃者は暗号スイートの選択に影響を与え、ネゴシエートされた暗号スイートをダウングレードして、より弱い対称暗号化アルゴリズムまたはより弱い鍵交換のいずれかを使用するように試みることができるかもしれない。[109] 2012年にコンピューターと通信のセキュリティに関するACM 会議で発表された論文は、False Start拡張が危険にさらされていることを示した。特定の状況下では、攻撃者がオフラインで暗号化キーを復元し、暗号化されたデータにアクセスできるようになる可能性がある。[110]
暗号化ダウングレード攻撃は、サーバーとクライアントに暗号的に弱いキーを使用して接続をネゴシエートさせる可能性があります。2014年に、OpenSSLスタック、デフォルトのAndroidウェブブラウザ、および一部のSafariブラウザに影響を与えるFREAKと呼ばれる中間者攻撃が発見されました。[111]この攻撃では、サーバーを騙して暗号的に弱い512ビットの暗号化キーを使用してTLS接続をネゴシエートさせます。
Logjamは2015年5月に発見されたセキュリティ上の脆弱性であり、 1990年代に遡る従来の「輸出グレード」 512ビットDiffie-Hellmanグループを使用するオプションを悪用します。 [112]これにより、脆弱なサーバーは暗号的に弱い512ビットDiffie-Hellmanグループにダウングレードされます。攻撃者は、クライアントとサーバーがDiffie-Hellman鍵交換を使用して決定する鍵を推測できます。
クロスプロトコル攻撃: DROWN
DROWN攻撃は、最新のSSL/TLSプロトコルスイートをサポートするサーバーを攻撃するエクスプロイトであり、時代遅れで安全でないSSLv2プロトコルのサポートを悪用して、本来は安全な最新のプロトコルを使用した接続を攻撃します。[113] [114] DROWNは、特定の実装エラーではなく、使用されているプロトコルとサーバーの構成の脆弱性を悪用します。DROWNの詳細は、エクスプロイトのパッチとともに2016年3月に発表されました。当時、最も人気のある上位100万のWebサイトのうち81,000を超えるWebサイトが、DROWN攻撃に対して脆弱なTLS保護Webサイトでした。[114]
ビースト攻撃
2011 年 9 月 23 日、研究者の Thai Duong 氏と Juliano Rizzo 氏は、TLS 1.0 の長年知られている暗号ブロック連鎖 (CBC) の脆弱性に対して、Java アプレットを使用して同一生成元ポリシー制約に違反する BEAST (Browser Exploit Against SSL/TLS ) [ 115 ]と呼ばれる概念実証を行ないました: [116] [117]連続する 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年にフィリップ・ロガウェイ[118]によって最初に発見されましたが、これまで実用的な悪用方法は実証されていませんでした。この攻撃の脆弱性は2006年にTLS 1.1で修正されましたが、この攻撃のデモンストレーション以前はTLS 1.1は広く採用されていませんでした。
ストリーム暗号としてのRC4はBEAST攻撃の影響を受けません。そのため、RC4はサーバー側でBEAST攻撃を軽減する方法として広く使用されていました。しかし、2013年に研究者はRC4のさらなる弱点を発見しました。それ以来、サーバー側でRC4を有効にすることは推奨されなくなりました。[119]
ChromeとFirefox自体はBEAST攻撃に対して脆弱ではないが[120] [121]、MozillaはBEASTのような攻撃を軽減するためにNSSライブラリを更新した。NSSはMozilla FirefoxとGoogle ChromeでSSLを実装するために使用されている。SSL仕様の実装が壊れている一部のウェブサーバーは、その結果動作しなくなる可能性がある。[122]
マイクロソフトは2012年1月10日にセキュリティ情報MS12-006をリリースし、Windows Secure Channel（Schannel）コンポーネントがサーバー側から暗号化されたネットワークパケットを送信する方法を変更することでBEASTの脆弱性を修正しました。[123]古いバージョンの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の脆弱性を修正しました。[124]
犯罪と侵入攻撃
BEAST攻撃の作成者は、後のCRIME攻撃の作成者でもあります。CRIME攻撃では、 TLSとともにデータ圧縮が使用されている場合に、攻撃者がWeb Cookieの内容を復元することができます。 [125] [126]秘密の認証Cookieの内容を復元するために使用されると、攻撃者は認証されたWebセッションで セッションハイジャックを実行できます。
CRIME 攻撃は、TLS や、 SPDYまたはHTTPなどのアプリケーション層プロトコルを含むがこれに限定されない多数のプロトコルに対して効果的に機能する一般的な攻撃として提示されましたが、TLSと SPDY に対するエクスプロイトのみが実証され、ブラウザーとサーバーで大部分が緩和されました。CRIMEの作成者は、この脆弱性が SPDY と TLS 圧縮を合わせたよりもさらに広範囲に及ぶ可能性があると警告しているにもかかわらず、HTTP 圧縮に対する CRIME エクスプロイトはまったく緩和されていません。2013 年には、HTTP 圧縮に対する CRIME 攻撃の新しいインスタンスであるBREACHが発表されました。CRIME 攻撃に基づく BREACH 攻撃は、攻撃者が被害者をだまして悪意のある Web リンクにアクセスさせるか、ユーザーがアクセスしている有効なページ (攻撃者の制御下にあるワイヤレス ネットワークなど) にコンテンツを挿入できれば、TLS で暗号化された Web トラフィックからログイン トークン、電子メール アドレス、またはその他の機密情報を 30 秒ほどで抽出できます (抽出するバイト数によって異なります)。[127] TLSとSSLのすべてのバージョンは、使用されている暗号化アルゴリズムや暗号に関係なく、BREACHのリスクがあります。[128] TLS圧縮またはSPDYヘッダー圧縮をオフにすることで防御できる以前のCRIMEとは異なり、BREACHはHTTP圧縮を悪用します。HTTP圧縮は、事実上すべてのWebサーバーがユーザーのデータ転送速度を向上させるためにHTTP圧縮に依存しているため、現実的にオフにすることはできません。[127]これはTLSの既知の制限であり、保護することを意図したアプリケーション層のデータに対する 選択平文攻撃の影響を受けやすいためです。
パディングに対するタイミング攻撃
以前の TLS バージョンは、2002 年に発見されたパディング オラクル攻撃に対して脆弱でした。2013年には、 ラッキー サーティーン攻撃と呼ばれる新しい亜種が公開されました。
一部の専門家[88]は、トリプルDES CBCを避けることを推奨しています。Windows XPのSSL/TLSライブラリを使用するプログラム（Windows XP上のInternet Explorerなど）をサポートするために開発された最新の暗号はRC4とトリプルDESですが、RC4は現在非推奨となっているため（RC4攻撃の説明を参照）、XP上でこのライブラリを使用するプログラムでSSLのどのバージョンもサポートすることは困難です。
修正は、TLS仕様のEncrypt-then-MAC拡張としてRFC 7366としてリリースされました。 [129] 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バイトを明らかにできます。[94]
この脆弱性はSSL 3.0にのみ存在し、ほとんどのクライアントとサーバーはTLS 1.0以上をサポートしていますが、すべての主要ブラウザは、ユーザーまたは管理者がSSL 3.0を無効にするオプションを提供し、ユーザーまたは管理者がそれを実行しない限り、新しいバージョンのTLSとのハンドシェイクが失敗した場合にSSL 3.0に自発的にダウングレードします[引用が必要]。したがって、中間者はまずバージョンロールバック攻撃を実行し、次にこの脆弱性を悪用することができます。[94]
2014年12月8日、パディングバイト要件を適切に実施していないTLS実装に影響を与えるPOODLEの亜種が発表されました。[130]
RC4攻撃
RC4の安全性を破る攻撃が存在したにもかかわらず、SSL と TLS の RC4 に基づく暗号スイートは、SSL と TLS での使用方法に基づいて、2013 年より前は依然として安全であると考えられていました。2011 年には、RC4 スイートは実際にBEAST攻撃の回避策として推奨されていました。[131] 2013 年 3 月に公開された新しい形式の攻撃は、TLS で RC4 を破る実現可能性を決定的に実証し、BEAST の良い回避策ではないことを示唆しました。[93] AlFardan、Bernstein、Paterson、Poettering、および Schuldt によって、RC4 キー テーブルで新たに発見された統計的バイアス[132]を使用して、多数の TLS 暗号化で平文の一部を復元する攻撃シナリオが提案されました。[133] [134] TLSとSSLのRC4に対する攻撃では、RC4を破るために13× 220の暗号化が必要であり、2013年7月8日に発表され、後に2013年8月のUSENIXセキュリティシンポジウムでの付随プレゼンテーションで「実行可能」と説明されました。[135] [136] 2015年7月、攻撃のその後の改良により、RC4で暗号化されたTLSのセキュリティを破ることがますます現実的になりました。[137]
最近のブラウザの多くはBEAST攻撃を阻止するように設計されているため（Mac OS X 10.7以前、iOS 6以前、Windows用のSafariは除く。§ ウェブブラウザを参照）、RC4はTLS 1.0にはもはや適していません。過去にBEAST攻撃の影響を受けたCBC暗号は、保護のためのより一般的な選択肢となっています。[88] MozillaとMicrosoftは、可能であればRC4を無効にすることを推奨しています。[138] [139] RFC 7465は、すべてのバージョンのTLSでRC4暗号スイートの使用を禁止しています。
2015年9月1日、マイクロソフト、グーグル、モジラは、2016年初頭に各社のブラウザ（ Microsoft Edge、Windows 7/8.1/10上のInternet Explorer 11 、 Firefox、Chrome ）でRC4暗号スイートをデフォルトで無効にすると発表した。 [140] [141] [142]
切り捨て攻撃
TLS（ログアウト）トランケーション攻撃は、被害者のアカウントログアウト要求をブロックし、ユーザーが知らないうちにウェブサービスにログインしたままにします。サインアウト要求が送信されると、攻撃者は暗号化されていないTCP FINメッセージ（送信者からのデータはもうありません）を挿入して接続を閉じます。そのため、サーバーはログアウト要求を受信せず、異常終了に気付きません。[143]
2013年7月に公開された[144] [145]この攻撃では、 GmailやHotmailなどのウェブサービスに、ユーザーに正常にサインアウトしたことを通知するページが表示され、ユーザーのブラウザがサービスに対する認証を維持していることが確認され、その後ブラウザにアクセスした攻撃者がユーザーのログインアカウントにアクセスして制御を乗っ取ることができるようになります。この攻撃は、被害者のコンピュータにマルウェアをインストールすることに依存していません。攻撃者は、被害者とウェブサーバーの間に身を置くだけで済みます（たとえば、不正なワイヤレスホットスポットを設定するなど）。[143]この脆弱性には、被害者のコンピュータへのアクセスも必要です。別の可能性として、FTPを使用する場合、データ接続のデータストリームに偽のFINが含まれる可能性があり、close_notifyアラートを交換するためのプロトコルルールが遵守されていない場合、ファイルが切り捨てられる可能性があります。
DTLSに対する平文攻撃
2013年2月、ロンドン大学ロイヤル・ホロウェイ校の2人の研究者が、暗号ブロック連鎖モードの暗号化が使用されたDTLSのOpenSSLまたはGnuTLS実装を使用して、 DTLS接続から平文（の一部）を復元できるタイミング攻撃[146]を発見しました。
不道徳なPAC攻撃
2016年半ばに発見されたこの攻撃は、Webプロキシ自動検出プロトコル（WPAD）の脆弱性を悪用し、TLS対応のWebリンク経由でWebユーザーがアクセスしようとしているURLを公開します。[147] URLの公開は、アクセスしたWebサイトだけでなく、URLがユーザー認証に使用されることもあるため、ユーザーのプライバシーを侵害する可能性があります。GoogleやDropboxなどのドキュメント共有サービスも、URLに含まれるセキュリティトークンをユーザーに送信することで機能します。このようなURLを入手した攻撃者は、被害者のアカウントやデータに完全にアクセスできる可能性があります。
このエクスプロイトは、ほぼすべてのブラウザとオペレーティング システムに対して機能します。
Sweet32 攻撃
Sweet32攻撃は、誕生日攻撃と中間者攻撃またはWebページへの悪意のあるJavaScriptの挿入を悪用して、TLSで使用されるCBCモードで使用されるすべての64ビットブロック暗号を破ります。中間者攻撃またはJavaScript挿入の目的は、攻撃者が誕生日攻撃を仕掛けるのに十分なトラフィックをキャプチャできるようにすることです。[148]
実装エラー:Heartbleedバグ、BERserk 攻撃、Cloudflare のバグ
Heartbleedバグは、人気のあるOpenSSL暗号化ソフトウェアライブラリのSSL/TLS実装に特有の深刻な脆弱性で、バージョン1.0.1から1.0.1fに影響します。2014年4月に報告されたこの弱点により、攻撃者は通常は保護されているはずのサーバーから秘密鍵を盗むことができます。 [149] Heartbleedバグにより、インターネット上の誰もが、脆弱なバージョンのOpenSSLソフトウェアによって保護されているシステムのメモリを読み取ることができます。これにより、サービスプロバイダーを識別し、トラフィック、ユーザーの名前とパスワード、および実際のコンテンツを暗号化するために使用される公開証明書に関連付けられた秘密の秘密鍵が危険にさらされます。これにより、攻撃者は通信を盗聴し、サービスやユーザーから直接データを盗み、サービスやユーザーになりすますことができます。 [150]この脆弱性は、SSLまたはTLSプロトコル仕様の欠陥ではなく、OpenSSLソフトウェアの バッファオーバーリードバグによって発生します。
2014年9月、ダニエル・ブライヘンバッハのPKCS#1 v1.5 RSA署名偽造脆弱性[151]の亜種がIntel Security Advanced Threat Researchによって発表されました。BERserkと呼ばれるこの攻撃は、一部のSSL実装における公開鍵署名の不完全なASN.1長さのデコードの結果であり、公開鍵署名を偽造することで中間者攻撃を可能にします。[152]
2015年2月、一部のLenovoノートパソコンにスーパーフィッシュアドウェアが隠れてプリインストールされていることがメディアで報じられた後、 [153]研究者は、影響を受けるLenovoマシンの信頼されたルート証明書が安全でないことを突き止めました。これは、会社名であるKomodiaをパスフレーズとして使用してキーに簡単にアクセスできるためです。[154] Komodiaライブラリは、ペアレンタルコントロールと監視のためにクライアント側のTLS / SSLトラフィックを傍受するように設計されていましたが、Superfishを含む多数のアドウェアプログラムでも使用されており、コンピューターユーザーに知られずに密かにインストールされることがよくありました。次に、これらの潜在的に迷惑なプログラムは破損したルート証明書をインストールし、攻撃者がWebトラフィックを完全に制御し、偽のWebサイトを本物として確認できるようにしました。
2016年5月、 Visa Inc.のデンマークのHTTPSで保護されたウェブサイト数十件が攻撃に対して脆弱であり、ハッカーが悪意のあるコードや偽造コンテンツを訪問者のブラウザに挿入できると報告されました。[155]攻撃が成功したのは、影響を受けたサーバーで使用されていたTLS実装が、各TLSハンドシェイクが一意であることを保証するために、一度だけ使用されることを意図した乱数（ナンス）を誤って再利用したためです。[155]
2017年2月、HTMLを解析するコード内の1文字の誤入力によって引き起こされた実装エラーにより、Cloudflareサーバーでバッファオーバーフローエラーが発生しました。2014年に発見されたHeartbleedバグと同様の影響を持つこのオーバーフローエラーは、Cloudbleedとして広く知られており、サーバー上で実行されているプログラムのメモリ内のデータを、権限のない第三者が読み取ることを可能にしました。本来はTLSで保護されているはずのデータです。[156]
攻撃に対して脆弱なウェブサイトの調査
2021年7月現在[アップデート]、Trustworthy Internet MovementはTLS攻撃に対して脆弱なウェブサイトの割合を推定しました。[92]
前方秘匿性
前方秘匿性とは、暗号システムの特性であり、公開鍵と秘密鍵のセットから生成されたセッション鍵は、将来、秘密鍵の 1 つが侵害された場合でも侵害されないことを保証します。[157]前方秘匿性がなければ、サーバーの秘密鍵が侵害された場合、そのサーバー証明書を使用する将来のすべての TLS 暗号化セッションが侵害されるだけでなく、それを使用した過去のセッションも侵害されます (これらの過去のセッションが送信時に傍受され、保存されている場合)。[158] TLS の実装では、セッション鍵を確立するために一時的なDiffie–Hellman 鍵交換の使用を要求することで前方秘匿性を提供できます。いくつかの有名な TLS 実装では、この方法のみを採用しています。たとえば、OpenSSL を使用するGmailやその他の Google HTTPS サービスなどです。[159]ただし、TLS をサポートする多くのクライアントとサーバー (ブラウザーと Web サーバーを含む) は、このような制限を実装するように構成されていません。[160] [161]実際には、ウェブサービスが前方秘匿性を実装するためにディフィー・ヘルマン鍵交換を使用しない限り、そのサービスとの間の暗号化されたウェブトラフィックはすべて、第三者がサーバーのマスター（秘密）鍵を入手すれば（例えば裁判所命令によって）、復号化される可能性がある。[162]
Diffie-Hellman 鍵交換が実装されている場合でも、サーバー側のセッション管理メカニズムが前方秘匿性に影響を与える可能性があります。TLS セッション チケット (TLS 拡張機能) を使用すると、前方秘匿性暗号スイートを含む他のネゴシエートされた TLS パラメータに関係なく、セッションは AES128-CBC-SHA256 によって保護され、TLS セッション チケットの長寿命キーにより前方秘匿性を実装する試みが阻止されます。[163] [ 164] [165]スタンフォード大学の 2014 年の調査では、調査対象となった 473,802 台の TLS サーバーのうち、前方秘匿性をサポートするために一時的な Diffie-Hellman (DHE) 鍵交換を導入しているサーバーの 82.9% が弱い Diffie-Hellman パラメータを使用していたことも判明しました。これらの弱いパラメータの選択は、サーバーが提供しようとしている前方秘匿性の有効性を損なう可能性があります。[166]
2011年後半から、GoogleはGmailサービスのユーザー、Google Docs、暗号化検索などのサービスにデフォルトでTLSによる前方秘匿性を提供している。[167] 2013年11月以来、TwitterはサービスのユーザーにTLSによる前方秘匿性を提供している。[168] 2019年8月現在[アップデート]、TLS対応のウェブサイトの約80％が、ほとんどのウェブブラウザに前方秘匿性を提供する暗号スイートを使用するように設定されている。[92]
TLS 傍受
TLS 傍受 (または、特にそのプロトコルに適用される場合、HTTPS傍受) は、暗号化されたデータ ストリームを傍受して、それを復号化し、読み取り、場合によっては操作し、その後、再度暗号化して、データを再び送信する手法です。これは、「透過プロキシ」によって行われます。傍受ソフトウェアは、着信 TLS 接続を終了し、HTTP プレーン テキストを検査し、宛先への新しい TLS 接続を作成します。[169]
TLS/HTTPS傍受は、コンピュータウイルスやその他のマルウェアなどの悪意のあるコンテンツがネットワークに侵入するのをスキャンして防止するために、ネットワークオペレータによる情報セキュリティ対策として使用されます。[169]このようなコンテンツは、HTTPSやその他の安全なプロトコルの日常的な使用の結果としてますます暗号化によって保護されている限り、検出されません。
TLS/HTTPS 傍受の重大な欠点は、それ自体が新たなセキュリティ リスクをもたらすことです。注目すべき制限の 1 つは、ネットワーク トラフィックが暗号化されていない状態で利用できるポイントを提供することです。これにより、攻撃者は特にこのポイントを攻撃して、本来は安全なコンテンツにアクセスしようとする動機を得ます。また、傍受により、ネットワーク オペレーター、またはその傍受システムにアクセスした人物は、ネットワーク ユーザーに対して中間者攻撃を実行できます。2017 年の調査では、「HTTPS 傍受は驚くほど広まっており、傍受製品の種類は接続セキュリティに劇的な悪影響を及ぼしている」ことがわかっています。[169]
プロトコルの詳細
TLS プロトコルは、交換されるデータを特定の形式 (下記参照) でカプセル化するレコードを交換します。各レコードは、接続の状態に応じて、圧縮、パディング、メッセージ認証コード(MAC) の追加、または暗号化が可能です。各レコードには、カプセル化されるデータのタイプを指定するコンテンツ タイプフィールド、長さフィールド、および TLS バージョン フィールドがあります。カプセル化されるデータは、TLS 自体の制御メッセージまたは手順メッセージの場合もあれば、TLS で転送される必要のあるアプリケーション データだけの場合もあります。TLS でアプリケーション データを交換するために必要な仕様 (暗号スイート、キーなど) は、データを要求するクライアントと要求に応答するサーバーの間の「TLS ハンドシェイク」で合意されます。したがって、このプロトコルは、TLS で転送されるペイロードの構造と、転送を確立して監視する手順の両方を定義します。
TLSハンドシェイク
接続が開始されると、レコードは「制御」プロトコル、つまりハンドシェイク メッセージング プロトコル (コンテンツ タイプ22) をカプセル化します。このプロトコルは、TLS による実際のアプリケーション データの交換のために両側で必要なすべての情報を交換するために使用されます。メッセージの形式と交換の順序を定義します。これらは、クライアントとサーバーの要求に応じて異なる場合があります。つまり、接続を確立するには複数の手順が考えられます。この最初の交換により、TLS 接続が成功 (双方が TLS でアプリケーション データを転送する準備が整う) するか、警告メッセージ (以下に指定) が表示されます。
基本的なTLSハンドシェイク
以下に、サーバー（クライアントではない）が証明書によって認証される ハンドシェイクを示す典型的な接続例を示します。
- 交渉段階:
- クライアントは、サポートしている最高の TLS プロトコル バージョン、乱数、推奨される暗号スイートのリスト、推奨される圧縮方法を指定してClientHelloメッセージを送信します。クライアントが再開されたハンドシェイクを実行しようとしている場合は、セッション ID を送信することがあります。クライアントがアプリケーション層プロトコル ネゴシエーションを使用できる場合は、サポートされているアプリケーションプロトコルのリスト ( HTTP/2など) を含めることができます。
- サーバーは、クライアントが提供した選択肢から選択されたプロトコル バージョン、乱数、暗号スイート、および圧縮方法を含むServerHelloメッセージで応答します。再開されたハンドシェイクを確認または許可するために、サーバーはセッション ID を送信する場合があります。選択されたプロトコル バージョンは、クライアントとサーバーの両方がサポートする最高のバージョンである必要があります。たとえば、クライアントが TLS バージョン 1.1 をサポートし、サーバーがバージョン 1.2 をサポートしている場合、バージョン 1.1 を選択する必要があります。バージョン 1.2 は選択しないでください。
- サーバーは証明書メッセージを送信します（選択された暗号スイートによっては、サーバーによって省略される場合があります）。[170]
- サーバーはServerKeyExchangeメッセージを送信します（選択された暗号スイートによっては、サーバーによって省略される場合があります）。このメッセージは、すべてのDHE、ECDHE、DH_anon暗号スイートに対して送信されます。[23]
- サーバーは、ハンドシェイクネゴシエーションが完了したことを示すServerHelloDoneメッセージを送信します。
- クライアントはClientKeyExchangeメッセージで応答します。このメッセージにはPreMasterSecretまたは公開鍵が含まれる場合もあれば、何も含まれない場合もあります (これも、選択した暗号によって異なります)。このPreMasterSecret は、サーバー証明書の公開鍵を使用して暗号化されます。
- 次に、クライアントとサーバーは乱数とPreMasterSecretを使用して、「マスターシークレット」と呼ばれる共通の秘密を計算します。この接続のその他のすべてのキーデータ（IVなどのセッションキー、対称暗号化キー、MACキー[171]）は、このマスターシークレット（およびクライアントとサーバーが生成したランダム値）から派生し、慎重に設計された疑似ランダム関数を介して渡されます。
- ここで、クライアントはChangeCipherSpecレコードを送信し、基本的にサーバーに「これから伝える内容はすべて認証されます (サーバー証明書に暗号化パラメータが存在する場合は暗号化されます)」と伝えます。ChangeCipherSpec 自体は、コンテンツ タイプが 20 のレコード レベルのプロトコルです。
- クライアントは、以前のハンドシェイク メッセージのハッシュと MAC を含む、認証され暗号化されたFinishedメッセージを送信します。
- サーバーはクライアントのFinishedメッセージを復号化し、ハッシュと MAC を検証しようとします。復号化または検証が失敗した場合、ハンドシェイクは失敗したとみなされ、接続は終了する必要があります。
- 最後に、サーバーはChangeCipherSpec を送信し、クライアントに「これから伝える内容はすべて認証されます (暗号化がネゴシエートされた場合は暗号化されます)」と伝えます。
- サーバーは認証され暗号化されたFinishedメッセージを送信します。
- クライアントは、前の手順でサーバーが実行したのと同じ復号化および検証手順を実行します。
- アプリケーション フェーズ: この時点で、「ハンドシェイク」が完了し、コンテンツ タイプ 23 でアプリケーション プロトコルが有効になります。クライアントとサーバー間で交換されるアプリケーション メッセージも認証され、Finishedメッセージとまったく同じようにオプションで暗号化されます。それ以外の場合、コンテンツ タイプは 25 を返し、クライアントは認証されません。
クライアント認証 TLS ハンドシェイク
次の完全な例は、両方のピア間で交換された証明書を使用して、TLS 経由でクライアントが認証される様子を示しています (上記の例のようにサーバーに加えて、相互認証を参照してください)。
- 交渉フェーズ:
- クライアントは、サポートする最高の TLS プロトコル バージョン、乱数、推奨される暗号スイートと圧縮方法のリストを指定してClientHelloメッセージを送信します。
- サーバーは、クライアントが提供した選択肢から選択されたプロトコル バージョン、乱数、暗号スイート、および圧縮方法を含むServerHelloメッセージで応答します。サーバーは、再開されたハンドシェイクを実行するために、メッセージの一部としてセッション ID を送信することもあります。
- サーバーは証明書メッセージを送信します（選択された暗号スイートによっては、サーバーによって省略される場合があります）。[170]
- サーバーはServerKeyExchangeメッセージを送信します（選択された暗号スイートによっては、サーバーによって省略される場合があります）。このメッセージは、すべてのDHE、ECDHE、およびDH_anon暗号スイートに対して送信されます。[1]
- サーバーは、クライアントに証明書を要求するために、CertificateRequestメッセージを送信します。
- サーバーは、ハンドシェイクネゴシエーションが完了したことを示すServerHelloDoneメッセージを送信します。
- クライアントは証明書メッセージで応答します。このメッセージにはクライアントの証明書が含まれますが、秘密鍵は含まれません。
- クライアントはClientKeyExchangeメッセージを送信します。このメッセージには、 PreMasterSecret 、公開キー、または何も含まれない場合があります(これも、選択した暗号によって異なります)。このPreMasterSecret は、サーバー証明書の公開キーを使用して暗号化されます。
- クライアントは、クライアントの証明書の秘密キーを使用して、以前のハンドシェイク メッセージに署名したCertificateVerifyメッセージを送信します。この署名は、クライアントの証明書の公開キーを使用して検証できます。これにより、サーバーは、クライアントが証明書の秘密キーにアクセスでき、証明書を所有していることを知ることができます。
- 次に、クライアントとサーバーは、乱数とPreMasterSecret を使用して、「マスター シークレット」と呼ばれる共通のシークレットを計算します。この接続のその他のすべてのキー データ (「セッション キー」) は、このマスター シークレット (およびクライアントとサーバーが生成したランダム値) から派生し、慎重に設計された疑似ランダム関数を介して渡されます。
- ここで、クライアントはChangeCipherSpecレコードを送信し、基本的にサーバーに「これから伝える内容はすべて認証されます (暗号化がネゴシエートされた場合は暗号化されます)」と伝えます。ChangeCipherSpec 自体はレコード レベルのプロトコルであり、タイプは 22 ではなく 20 です。
- 最後に、クライアントは、以前のハンドシェイク メッセージのハッシュと MAC を含む暗号化されたFinishedメッセージを送信します。
- サーバーはクライアントのFinishedメッセージを復号化し、ハッシュと MAC を検証しようとします。復号化または検証が失敗した場合、ハンドシェイクは失敗したとみなされ、接続を切断する必要があります。
- 最後に、サーバーはChangeCipherSpec を送信し、クライアントに「これから伝える内容はすべて認証されます (暗号化がネゴシエートされた場合は暗号化されます)」と伝えます。
- サーバーは独自の暗号化されたFinishedメッセージを送信します。
- クライアントは、前の手順でサーバーが実行したのと同じ復号化および検証手順を実行します。
- アプリケーション フェーズ: この時点で、「ハンドシェイク」が完了し、コンテンツ タイプ 23 でアプリケーション プロトコルが有効になります。クライアントとサーバー間で交換されるアプリケーション メッセージも、Finishedメッセージとまったく同じように暗号化されます。
TLSハンドシェイクを再開しました
公開鍵操作 (RSA など) は、計算能力の点で比較的高価です。TLS は、これらの操作を回避するために、ハンドシェイク メカニズムで安全なショートカット (再開セッション) を提供します。再開セッションは、セッション ID またはセッション チケットを使用して実装されます。
パフォーマンス上の利点以外にも、再開されたセッションは、元のセッションと再開されたセッションの両方が同じクライアントから発信されることを保証するため、シングルサインオンにも使用できます。これは、 FTP over TLS/SSLプロトコルにとって特に重要です。そうしないと、攻撃者がセカンダリデータ接続の内容を傍受できる中間者攻撃の影響を受けることになります。[172]
TLS 1.3 ハンドシェイク
TLS 1.3 ハンドシェイクは、TLS/SSL の以前のバージョンで必要だった 2 回の往復と比較して、1 回の往復に短縮されました。
ハンドシェイクを開始するには、クライアントはサーバーがどの鍵交換アルゴリズムを選択するかを推測し、サポートされている暗号のリスト（クライアントの好みの順）と、一部またはすべての鍵交換推測の公開鍵を含むClientHelloメッセージをサーバーに送信します。クライアントが鍵交換アルゴリズムを推測できた場合、ハンドシェイクから 1 回の往復が省略されます。ClientHello を受信したサーバーは暗号を選択し、独自の公開鍵を含むServerHello を返信し、その後にサーバー証明書とFinishedメッセージを送信します。[173]
クライアントがサーバーの完了メッセージを受信した後、どの暗号スイートを使用するかをサーバーと調整します。[174]
セッションID
通常のフルハンドシェイクでは、サーバーはServerHelloメッセージの一部としてセッション ID を送信します。クライアントはこのセッション ID をサーバーの IP アドレスと TCP ポートに関連付けます。これにより、クライアントがそのサーバーに再度接続するときに、セッション ID を使用してハンドシェイクを短縮できます。サーバーでは、セッション ID は以前にネゴシエートされた暗号化パラメータ、具体的には「マスター シークレット」にマップされます。両方の側が同じ「マスター シークレット」を持っている必要があります。そうでない場合、再開されたハンドシェイクは失敗します (これにより、盗聴者がセッション ID を使用できなくなります)。ClientHelloおよびServerHelloメッセージ内のランダムデータにより、生成される接続キーが以前の接続とは異なることが事実上保証されます。RFC では、このタイプのハンドシェイクは短縮ハンドシェイクと呼ばれています。文献では、再開ハンドシェイクとも呼ばれています。
- 交渉段階:
- クライアントは、サポートしている最高の TLS プロトコル バージョン、乱数、推奨される暗号スイートと圧縮方法のリストを指定してClientHelloメッセージを送信します。メッセージには、以前の TLS 接続からのセッション IDが含まれます。
- サーバーは、クライアントが提示した選択肢から選択されたプロトコル バージョン、乱数、暗号スイート、および圧縮方法を含むServerHelloメッセージで応答します。サーバーがクライアントから送信されたセッション ID を認識すると、同じセッション IDで応答します。クライアントはこれを使用して、再開されたハンドシェイクが実行されていることを認識します。サーバーがクライアントから送信されたセッション ID を認識しない場合は、セッション IDに別の値を送信します。これにより、再開されたハンドシェイクは実行されないことがクライアントに通知されます。この時点で、クライアントとサーバーの両方が、この接続に使用されるキー データを生成するための「マスター シークレット」とランダム データを持っています。
- サーバーはChangeCipherSpecレコードを送信し、基本的にクライアントに「これから伝える内容はすべて暗号化されます」と伝えます。ChangeCipherSpec 自体はレコード レベルのプロトコルであり、タイプは 22 ではなく 20 です。
- 最後に、サーバーは、以前のハンドシェイク メッセージのハッシュと MAC を含む暗号化されたFinishedメッセージを送信します。
- クライアントはサーバーのFinishedメッセージを復号化し、ハッシュと MAC を検証しようとします。復号化または検証が失敗した場合、ハンドシェイクは失敗したとみなされ、接続を切断する必要があります。
- 最後に、クライアントはChangeCipherSpec を送信し、サーバーに「これから伝える内容はすべて暗号化されます」と伝えます。
- クライアントは独自の暗号化されたFinishedメッセージを送信します。
- サーバーは、前の手順でクライアントが実行したのと同じ復号化および検証手順を実行します。
- アプリケーション フェーズ: この時点で、「ハンドシェイク」が完了し、コンテンツ タイプ 23 でアプリケーション プロトコルが有効になります。クライアントとサーバー間で交換されるアプリケーション メッセージも、Finishedメッセージとまったく同じように暗号化されます。
セッションチケット
RFC 5077 は、セッション ID の代わりにセッション チケットを使用することで TLS を拡張します。セッション固有の状態が TLS サーバーに保存されることなく、TLS セッションを再開する方法を定義します。
セッション チケットを使用する場合、TLS サーバーはセッション固有の状態をセッション チケットに保存し、保存のためにセッション チケットを TLS クライアントに送信します。クライアントはセッション チケットをサーバーに送信して TLS セッションを再開し、サーバーはチケット内のセッション固有の状態に従って TLS セッションを再開します。セッション チケットはサーバーによって暗号化および認証され、サーバーはその内容を使用する前にその有効性を検証します。
OpenSSLでのこの方法の 1 つの弱点は、AES128-CBC-SHA256実際の TLS セッションで他のどのような TLS パラメータがネゴシエートされたかに関係なく、送信される TLS セッション チケットの暗号化と認証のセキュリティが常に に制限されることです。 [164]これは、状態情報 (TLS セッション チケット) が TLS セッション自体ほど保護されていないことを意味します。特に懸念されるのは、OpenSSL がキーをアプリケーション全体のコンテキスト ( SSL_CTX) に格納すること、つまりアプリケーションの存続期間中、またアプリケーションAES128-CBC-SHA256全体の OpenSSL コンテキストをリセットせずに TLS セッション チケットのキーを再設定できないことです (これはまれで、エラーが発生しやすく、多くの場合、手動の管理介入が必要です)。[165] [163]
TLSレコード
これはすべての TLS レコードの一般的な形式です。
- コンテンツタイプ
- このフィールドは、このレコードに含まれるレコード層プロトコル タイプを識別します。
- レガシーバージョン
- このフィールドは、含まれるメッセージの TLS 1.3 より前の TLS のメジャー バージョンとマイナー バージョンを識別します。ClientHello メッセージの場合、これはクライアントがサポートする最高バージョンである必要はありません。TLS 1.3 以降の場合、これは 0x0303 に設定する必要があり、アプリケーションは追加のメッセージ拡張ブロックでサポートされているバージョンを送信する必要があります。
- 長さ
- 「プロトコルメッセージ」、「MAC」、および「パディング」フィールドを合わせた長さ（つまり、q −5）は、2 14バイト（16 KiB）を超えません。
- プロトコルメッセージ
- プロトコル フィールドによって識別される 1 つ以上のメッセージ。このフィールドは、接続の状態に応じて暗号化される場合があることに注意してください。
- MACとパディング
- 「プロトコル メッセージ」フィールドに基づいて計算されたメッセージ認証コード。追加のキー マテリアルが含まれています。接続の状態によっては、このフィールドが暗号化されるか、完全に含まれない可能性があることに注意してください。
- すべての暗号アルゴリズムとパラメータがネゴシエートされ、ハンドシェイクされ、その後、同じピアによって送信されるすべての後続のレコードでこれらのパラメータが有効になることを通知する CipherStateChange レコード (以下を参照) を送信して確認されるまで、TLS レコードの末尾に「MAC」または「パディング」フィールドが存在することはできません。
ハンドシェイクプロトコル
TLS セッションのセットアップ中に交換されるほとんどのメッセージは、エラーまたは警告が発生し、Alert プロトコル レコードによって通知される必要がある場合 (以下を参照)、またはセッションの暗号化モードが別のレコードによって変更される場合を除き (以下の ChangeCipherSpec プロトコルを参照)、このレコードに基づいています。
- メッセージタイプ
- このフィールドはハンドシェイク メッセージのタイプを識別します。
- ハンドシェイクメッセージのデータ長
- これは、ヘッダーを含まないハンドシェイク データの長さを示す 3 バイトのフィールドです。
複数のハンドシェイク メッセージが 1 つのレコード内に結合される場合があることに注意してください。
アラートプロトコル
このレコードは通常のハンドシェイクまたはアプリケーション交換中には送信されません。ただし、このメッセージはハンドシェイク中およびセッションの終了までいつでも送信できます。これが致命的なエラーを通知するために使用される場合、このレコードの送信後すぐにセッションが閉じられるため、このレコードは終了の理由を示すために使用されます。アラート レベルが警告としてフラグ付けされている場合、リモートはセッションがニーズに対して十分に信頼できないと判断した場合、セッションを終了することができます (終了する前に、リモートは独自の信号を送信することもできます)。
- レベル
- このフィールドはアラートのレベルを識別します。レベルが致命的である場合、送信者はセッションを直ちに終了する必要があります。それ以外の場合、受信者は独自の致命的なアラートを送信し、送信後すぐにセッションを終了することで、セッション自体を終了することができます。アラート レコードの使用はオプションですが、セッション終了前にアラート レコードがない場合、セッションは自動的に再開されます (ハンドシェイクを使用)。
- 転送されたアプリケーションの終了後のセッションの通常の終了は、新しいセッションの自動再開を防ぐために、少なくともClose 通知アラート タイプ (単純な警告レベル) で警告することが望ましいです。トランスポート層を効果的に閉じる前に、セキュア セッションの通常の終了を明示的に通知することは、攻撃 (セキュア データの受信者が期待する所定の長さや期間が本質的にない場合に、セキュアに転送されたデータを切り捨てようとする試みなど) を防止または検出するのに役立ちます。
- 説明
- このフィールドは、送信されるアラートの種類を識別します。
ChangeCipherSpec プロトコル
- CCSプロトコルタイプ
- 現在は1つのみです。
アプリケーションプロトコル
- 長さ
- アプリケーション データの長さ (プロトコル ヘッダーは除く、MAC とパディング トレーラーを含む)
- マック
- SHA-256ベースのHMACの場合は 32 バイト、SHA-1ベースの HMAC の場合は 20 バイト、 MD5ベースの HMACの場合は 16 バイト。
- パディング
- 可変長。最後のバイトにはパディングの長さが含まれます。
名前ベースの仮想サーバーのサポート
アプリケーション プロトコルの観点から見ると、TLS は下位層に属しますが、TCP/IP モデルは粗すぎてそれを示すことができません。つまり、TLS ハンドシェイクは通常 ( STARTTLSの場合を除く)、アプリケーション プロトコルが開始する前に実行されます。アプリケーション層によって提供される名前ベースの仮想サーバー機能では、サーバーが ClientHello メッセージの直後に証明書を選択して送信する必要があるため、共同ホストされているすべての仮想サーバーは同じ証明書を共有します。これは、すべての顧客間で同じ証明書を共有するか、顧客ごとに異なる IP アドレスを使用することを意味するため、ホスティング環境では大きな問題となります。
X.509によって提供される 2 つの既知の回避策があります。
- すべての仮想サーバーが同じドメインに属している場合は、ワイルドカード証明書を使用できます。[175]問題になるかどうかわからない緩いホスト名の選択を除けば、ワイルドカード証明書をどのように一致させるかについての共通の合意はありません。使用されるアプリケーションプロトコルまたはソフトウェアに応じて、異なるルールが適用されます。[176]
- subjectAltName 拡張子にすべての仮想ホスト名を追加します。大きな問題は、新しい仮想サーバーが追加されるたびに証明書を再発行する必要があることです。
サーバー名を提供するために、RFC 4366 トランスポート層セキュリティ (TLS) 拡張機能により、クライアントは拡張 ClientHello メッセージにサーバー名表示拡張機能 (SNI) を含めることができます。この拡張機能により、クライアントが接続しようとしている名前がサーバーに即座に通知されるため、サーバーは適切な証明書を選択してクライアントに送信できます。
RFC 2817 には、HTTP/1.1 アップグレード ヘッダー を介して HTTP を TLS にアップグレードすることで、名前ベースの仮想ホスティングを実装する方法も記載されています。通常、これはメインの "http" URI スキーム内で HTTP over TLS を安全に実装するためのものです(URI スペースの分岐を回避し、使用されるポートの数を減らします)。ただし、現在これをサポートする実装はほとんどありません。[引用が必要]
参照
- アプリケーション層プロトコルネゴシエーション- SPDYおよびTLS False Startに使用されるTLS拡張機能
- Bullrun（暗号解読プログラム） – 米国国家安全保障局が運営する秘密の暗号解読プログラム
- 証明機関
- 証明書の透明性
- 委任された資格情報
- HTTP 厳格なトランスポート セキュリティ– HSTS
- キーリングファイル
- プライベート コミュニケーション テクノロジ(PCT) – SSL 2.0 の歴史的な Microsoft の競合製品
- QUIC (クイック UDP インターネット接続) – 「…TLS/SSL と同等のセキュリティ保護を提供するように設計されています」。QUIC の主な目的は、現在 TCP を使用している接続指向の Web アプリケーションの認識されるパフォーマンスを向上させることです。
- サーバーゲート暗号化
- tcpcrypt
- データグラム トランスポート層セキュリティ
- TLSアクセラレーション
参考文献
- ^ ie 「(D)TLS の委任された資格情報」。Ietf。2024年6 月 26 日時点のオリジナルよりアーカイブ。2024 年 6 月 26 日閲覧。
- ^ ab Lawrence, Scott; Khare, Rohit (2000 年 5 月)。HTTP/1.1 内での TLS へのアップグレード。 インターネットエンジニアリング タスク フォース。doi : 10.17487/ RFC2817。RFC 2817 。
- ^ 「SSL/TLS の詳細」。TechNet。Microsoft Docs。2009年 10 月 8 日。2022 年 8 月 13 日時点のオリジナルよりアーカイブ。2021年10 月 24 日閲覧。
- ^ ab Hooper, Howard (2012). CCNP Security VPN 642–648 公式認定ガイド (第 2 版). Cisco Press. p. 22. ISBN 9780132966382。
- ^ ab Spott, Andrew; Leek, Tom; et al. 「TLS とはどのようなレイヤーか?」Information Security Stack Exchange . 2021-02-13 のオリジナルからアーカイブ。 2017-04-13に取得。
- ^ abcdef E. Rescorla (2018 年 8 月). トランスポート層セキュリティ (TLS) プロトコル バージョン 1.3. IETF TLS ワークグループ. doi : 10.17487/RFC8446 . RFC 8446. 提案された標準。RFC 5077、5246、および 6961 を 廃止し、 RFC 5705 および 6066 を更新します。
- ^ レスコーラ、エリック;モダドゥグ、ナゲンドラ（2006 年 4 月）。データグラムトランスポート層セキュリティ。土井: 10.17487/RFC4347。RFC 4347。
- ^ レスコーラ、エリック;モダドゥグ、ナゲンドラ（2012 年 1 月）。データグラム トランスポート層セキュリティ バージョン 1.2。土井: 10.17487/RFC6347。RFC 6347。
- ^ Titz, Olaf (2001-04-23). 「TCP Over TCP がなぜ悪い考えなのか」。2023-03-10 時点のオリジナルよりアーカイブ。2015-10-17に閲覧。
- ^ 本田 修、大崎 博之、今瀬 誠、石塚 美香、村山 純一 (2005 年 10 月)。「TCP over TCP の理解: TCP トンネリングがエンドツーエンドのスループットと待ち時間に与える影響」。Atiquzzaman, Mohammed、Balandin, Sergey I (編)。次世代通信およびセンサー ネットワークのパフォーマンス、サービス品質、および制御 III 。第6011 巻。Bibcode :2005SPIE.6011..138H。CiteSeerX 10.1.1.78.5815。doi : 10.1117 /12.630496。S2CID 8945952。
- ^ RFC 4347 § 4
- ^ Rescorla, Eric; Tschofenig, Hannes; Modadugu, Nagena (2022 年 4 月 21 日). データグラム トランスポート層セキュリティ (DTLS) プロトコル バージョン 1.3. doi : 10.17487/RFC9147 . RFC 9147.
- ^ 「AnyConnect FAQ: トンネル、再接続動作、および非アクティビティ タイマー」。Cisco。2017年 2 月 26 日時点のオリジナルよりアーカイブ。2017 年2月26 日閲覧。
- ^ 「Cisco InterCloud アーキテクチャの概要」(PDF)。Cisco Systems。2022年 8 月 9 日のオリジナルからアーカイブ(PDF) 。2022 年 11 月 29 日閲覧。
- ^ “OpenConnect”. OpenConnect . 2017年2月2日時点のオリジナルよりアーカイブ。2017年2月26日閲覧。
- ^ 「ZScaler ZTNA 2.0 Tunnel」。ZScaler 。 2022年11月29日時点のオリジナルよりアーカイブ。2022年11月29日閲覧。
- ^ 「f5 Datagram Transport Layer Security (DTLS)」。f5 Networks。2022年11月29日時点のオリジナルよりアーカイブ。2022年11月29日閲覧。
- ^ 「DTLS 仮想サーバーの構成」。Citrix Systems。2016年 12 月 21 日時点のオリジナルよりアーカイブ。2022 年 11 月 29 日閲覧。
- ^ 「WebRTC Interop Notes」。2013 年 5 月 11 日時点のオリジナルよりアーカイブ。
- ^ abcde Bright, Peter (2018年10月17日). 「Apple、Google、Microsoft、MozillaがTLS 1.0の廃止に向けて協力」。2018年10月17日時点のオリジナルよりアーカイブ。 2018年10月17日閲覧。
- ^ abcd 「Firefox 74.0 Stable の新機能と変更点 – gHacks Tech News」www.ghacks.net . 2020年3月10日。2020年3月11日時点のオリジナルよりアーカイブ。 2020年3月10日閲覧。
- ^ abcd 「TLS 1.0 および TLS 1.1 – Chrome プラットフォームのステータス」。chromestatus.com。2023年 7 月 7 日時点のオリジナルよりアーカイブ。2020年 3 月 10 日閲覧。
- ^ abcde 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 を更新。
- ^ ab 「TLS を使用したデータ保護」www.ncsc.gov.uk . 2021 年 7 月 21 日時点のオリジナルよりアーカイブ。2022 年8 月 24 日閲覧。
- ^ 「TLS 1.3: 1年後」。IETF。2020年7月8日時点のオリジナルよりアーカイブ。 2022年8月24日閲覧。
- ^ 「TLS の作成: ルース・ネルソンの先駆的役割」。2020 年 6 月 24 日時点のオリジナルよりアーカイブ。2020 年 7 月 4 日閲覧。
- ^ 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 日に取得。
- ^ “1994 USENIX Summer Technical Conference Program、ボストン、1994年6月6～10日”. 2023年10月6日時点のオリジナルよりアーカイブ。2024年1月21日閲覧。
- ^ Simon S. Lam (PI/PD)、「モジュールとインターフェイスの理論をセキュリティ検証に適用する」、NSA INFOSEC 大学研究プログラム助成金番号 MDA 904-91-C-7046、1991 年 6 月 28 日から 1993 年 6 月 27 日。
- ^ 「2004 ACM Software System Award citation」ACM。2013年6月17日時点のオリジナルよりアーカイブ。2012年7月25日閲覧。
- ^ 「ACM プレスリリース、2005年3月15日」。ACM。2016年1月10日時点のオリジナルよりアーカイブ。2012年7月25日閲覧。
- ^ “インターネットの殿堂入りサイモン・S・ラム”. 2024年2月6日時点のオリジナルよりアーカイブ。2024年3月3日閲覧。
- ^ “コンピュータ科学者がインターネットの殿堂入り”. 2024年3月8日時点のオリジナルよりアーカイブ。2024年3月3日閲覧。
- ^ Messmer, Ellen. 「SSL の父、Taher Elgamal 博士、中東で急速に発展する IT プロジェクトを発見」。Network World。2014年 5 月 31 日時点のオリジナルよりアーカイブ。2014 年5 月 30 日閲覧。
- ^ Greene, Tim. 「SSL の父、攻撃にもかかわらず、セキュリティの要である SSL にはまだまだ寿命があると語る」Network World。2014 年 5 月 31 日時点のオリジナルよりアーカイブ。2014 年5 月 30 日閲覧。
- ^ ab Oppliger, Rolf (2016). 「はじめに」。SSL と TLS: 理論と実践(第 2 版)。Artech House。 p. 13。ISBN 978-1-60807-999-52018年3月1日閲覧– Google ブックス経由。
- ^ 「THE SSL PROTOCOL」。Netscape Corporation。2007年。1997年6月14日時点のオリジナルよりアーカイブ。
- ^ レスコーラ 2001
- ^ 「POODLE: SSLv3 の脆弱性 (CVE-2014-3566)」。2014 年 12 月 5 日時点のオリジナルよりアーカイブ。2014年10 月 21 日閲覧。
- ^ 「ブラウザ戦争におけるセキュリティ標準と名称変更」。2020年2月29日時点のオリジナルよりアーカイブ。2020年2月29日閲覧。
- ^ Laura K. Gray (2015-12-18). 「SSL および初期の TLS からの移行に関する日付変更」。Payment Card Industry Security Standards Councilブログ。2015-12-20 のオリジナルからアーカイブ。2018-04-05に取得。
- ^ 「PCIコンプライアンスの変更は6月30日に実施されます。あなたのeコマースビジネスは準備ができていますか？」Forbes。2018年6月21日時点のオリジナルよりアーカイブ。 2018年6月20日閲覧。
- ^ T. Dierks; E. Rescorla (2006 年 4 月). トランスポート層セキュリティ (TLS) プロトコル バージョン 1.1. IETF TLS ワークグループ. doi : 10.17487/RFC4346 . RFC 4346. 歴史的。RFC 5246 によって廃止されました。RFC 2246 を廃止します。
- ^ abc 「トランスポート層セキュリティパラメータ - 暗号スイート」。Internet Assigned Numbers Authority (IANA)。2016年12月21日時点のオリジナルよりアーカイブ。 2022年12月16日閲覧。
- ^ Mackie, Kurt. 「Microsoft、TLS 1.0 および 1.1 のサポート終了を延期」 - Microsoft Certified Professional Magazine Online。 2021 年 6 月 14 日時点のオリジナルよりアーカイブ。 2021 年 6 月 14 日閲覧。
- ^ 「TLS 1.2 FAQ – ナレッジベース」。Answers.psionline.com 。 2022年2月20日時点のオリジナルよりアーカイブ。2022年2月20日閲覧。
- ^ 「TLS 1.2 と TLS 1.3 の違い (#TLS13)」WolfSSL 2019-09-18。2019-09-19 のオリジナルからアーカイブ。2019-09-18に取得。
- ^ “アーカイブコピー”. 2024年3月17日時点のオリジナルよりアーカイブ。2024年3月17日閲覧。
{{cite web}}: CS1 maint: アーカイブされたコピーをタイトルとして (リンク) - ^ 「NSS 3.29 リリースノート」。Mozilla Developer Network。2017 年 2 月。2017 年 2 月 22 日時点のオリジナルよりアーカイブ。
- ^ 「TLS 1.3 をデフォルトで有効にする」。Bugzilla@Mozilla。2016年10月16日。2018年8月12日時点のオリジナルよりアーカイブ。2017年10月10日閲覧。
- ^ 「Firefox — Notes (60.0)」。Mozilla。2018年5月9日時点のオリジナルよりアーカイブ。2018年5月10日閲覧。
- ^ 「ProxySG、ASG、WSS は、TLS 1.3 を使用するクライアントが TLS 1.3 を使用するサイトにアクセスすると SSL 接続を中断します」。BlueTouch Online。2017年 5 月 16 日。2017 年 9 月 12 日時点のオリジナルよりアーカイブ。2017 年9 月 11 日閲覧。
- ^ Sullivan, Nick (2017-12-26). 「なぜ TLS 1.3 はまだブラウザに導入されていないのか」。Cloudflare ブログ。2017-12-26 のオリジナルからアーカイブ。2020-03-14に取得。
- ^ ab Thomson, Martin; Pauly, Tommy (2021年12月). プロトコル拡張メカニズムの長期的な実行可能性。doi : 10.17487 /RFC9170 . RFC 9170。
- ^ 「TLS 1.3 IETF 100 Hackathon」。2018年1月15日時点のオリジナルよりアーカイブ。
- ^ ab IETF – Internet Engineering Task Force (2017-11-12)、IETF Hackathon Presentations and Awards、2021-10-28にオリジナルからアーカイブ、2017-11-14に取得
- ^ 「やったー！ TLS 1.3 がリリースされました。次はこれを実装してソフトウェアに組み込む番です」。2018 年 3 月 27 日時点のオリジナルよりアーカイブ。2018年 3 月 28 日閲覧。
- ^ IETF – Internet Engineering Task Force (2018-07-15)、IETF102-HACKATHON-20180715-1400、2021-10-28にオリジナルからアーカイブ、2018-07-18に取得
- ^ 「wolfSSL TLS 1.3 BETA Release Now Available」。info@wolfssl.com。2017年5月11日。2018年7月9日時点のオリジナルよりアーカイブ。2017年5月11日閲覧。
- ^ 「TLS 1.3 プロトコルサポート」。info@wolfssl.com。2018年7月9日時点のオリジナルよりアーカイブ。2018年7月9日閲覧。
- ^ 「wolfSSL での TLS 1.3 ドラフト 28 のサポート」。info@wolfssl.com。2018 年 6 月 14 日。2018 年 7 月 9 日時点のオリジナルよりアーカイブ。2018年6 月 14 日閲覧。
- ^ “OpenSSL 1.1.1 がリリースされました”. Matt Caswell. 2018年9月11日. 2018年12月8日時点のオリジナルよりアーカイブ。2024年10月11日閲覧。
- ^ 「TLS/SSL のプロトコル (Schannel SSP)」。Microsoft Docs 2022 年 5 月 25 日。2023 年 1 月 25 日時点のオリジナルよりアーカイブ。2023年2 月 21 日閲覧。
- ^ ab Hoffman-Andrews, Jacob (2019-02-26). 「ETS は TLS ではないので使用しないでください」。Electronic Frontier Foundation。 2019-02-26 時点のオリジナルよりアーカイブ。2019-02-27に取得。
- ^ TS 103 523-3 – V1.1.1 – CYBER; ミドルボックス セキュリティ プロトコル; パート 3: エンタープライズ ネットワークおよびデータ センターのアクセス制御のプロファイル( PDF )。ETSI .org。2018年 11 月 14 日時点のオリジナルからアーカイブ(PDF) 。
- ^ Cory Doctorow (2019年2月26日). 「Monumental Recklessness」. Boing Boing . 2019年2月27日時点のオリジナルよりアーカイブ。
- ^ Rea, Scott (2013). 「安全な Web のための認証局の代替手段」(PDF)。RSA Conference Asia Pacific。2016年 10 月 7 日時点のオリジナルよりアーカイブ(PDF) 。2016 年9 月 7 日閲覧。
- ^ “SSL証明書のカウント”. 2015年5月16日時点のオリジナルよりアーカイブ。 2022年2月20日閲覧。
- ^ Raymond, Art (2017年8月3日). 「Lehi's DigiCert、10億ドルの取引でウェブセキュリティの競合企業を買収」Deseret News。2018年9月29日時点のオリジナルよりアーカイブ。 2020年5月21日閲覧。
- ^ 「SSL 認証局の市場シェア動向」W3Techs . 2020 年5 月 21 日閲覧。
- ^ Ryan Singel (2010年3月24日). 「Law Enforcement Appliance Subverts SSL」. wired .com . 2014年4月12日時点のオリジナルよりアーカイブ。
- ^ Seth Schoen (2010 年 3 月 24 日)。「新しい調査で、政府が SSL 証明書を偽造する可能性があることが示唆される」。EFF .org。2010年3 月 25 日時点のオリジナルよりアーカイブ。
- ^ P. Eronen 編 (2005 年 12 月)。Eronen、P、Tschofenig、H (編)。トランスポート層セキュリティ (TLS) 用の事前共有キー暗号スイート。インターネット技術タスクフォース。doi : 10.17487 / RFC4279。RFC 4279。2013年9月 9 日に取得。
- ^ D. Taylor編 (2007年11月)。TLS認証にセキュアリモートパスワード(SRP)プロトコルを使用する。インターネット技術特別調査委員会。doi : 10.17487 /RFC5054。RFC 5054。2014年12月21日閲覧。
- ^ Gothard, Peter (2013 年 7 月 31 日)。「Google が SSL 証明書を 2048 ビット暗号化に更新」。コンピューティング。Incisive Media。2013 年 9 月 22 日時点のオリジナルよりアーカイブ。2013 年9 月 9 日閲覧。
- ^ 「2,048 ビット暗号化の価値: 暗号化キーの長さが重要な理由」SearchSecurity。2018 年 1 月 16 日のオリジナルからアーカイブ。2017年 12 月 18 日に取得。
- ^ Sean Turner (2015年9月17日). 「コンセンサス: TLS 1.3 から DSA を削除」。2015年10月3日時点のオリジナルよりアーカイブ。
- ^ RFC 8422
- ^ abcdefg RFC 5830、6986、7091、7801、8891
- ^ RFC 5288、5289
- ^ RFC 6655、7251
- ^ RFC 6367
- ^ RFC 5932、6367
- ^ RFC 6209より
- ^ RFC 4162
- ^ 「64 ビット ブロック暗号の実際的な (不) セキュリティについて - TLS および OpenVPN 経由の HTTP に対する衝突攻撃」(PDF)。2016 年 10 月 28 日。2017年 4 月 24 日にオリジナルからアーカイブ(PDF) 。2017年 6 月 8 日に取得。
- ^ 「NIST Special Publication 800-57 鍵管理に関する推奨事項 - パート 1: 一般 (改訂版)」(PDF) 。2007 年 3 月 8 日。2014年 6 月 6 日時点のオリジナル(PDF)からアーカイブ。2014 年 7 月 3 日に閲覧。
- ^ abc Qualys SSL Labs. 「SSL/TLS 導入のベストプラクティス」。2015 年 7 月 4 日時点のオリジナルよりアーカイブ。2015年6 月 2 日閲覧。
- ^ RFC 5469
- ^ RFC 7905
- ^ “Http vs https”. 2015年2月12日時点のオリジナルよりアーカイブ。2015年2月12日閲覧。
- ^ abcd 2024年5月3日現在。「SSL Pulse: 最も人気のあるウェブサイトのSSL実装に関する調査」。Qualys。2021年3月8日時点のオリジナルよりアーカイブ。2024年5月30日閲覧。
- ^ ab ivanr (2013年3月19日). 「TLSのRC4が壊れている: 次は何をするか?」 Qualsys Security Labs. 2013年8月27日時点のオリジナルよりアーカイブ。 2013年7月30日閲覧。
- ^ abc Bodo Möller、Thai Duong、Krzysztof Kotowicz。「This POODLE Bites: Exploiting The SSL 3.0 Fallback」(PDF)。2014 年 10 月 14 日のオリジナルからアーカイブ(PDF) 。2014 年 10 月 15 日に取得。
- ^ “Internet Explorer 11 は廃止され、正式にサポート対象外になりました。知っておくべきこと”. 2022年6月15日. 2022-06-15時点のオリジナルよりアーカイブ。 2022-06-15に閲覧。
- ^ 「Windows 10 の特定のバージョンに対する Internet Explorer 11 デスクトップ アプリのサポートが終了しました」。2022 年 6 月 17 日閲覧。
- ^ 「Java Secure Socket Extension (JSSE) リファレンス ガイド」。Oracleヘルプ センター。2022 年 1 月 22 日時点のオリジナルよりアーカイブ。2021 年 12 月 24 日取得。
- ^ 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）されました。
- ^ Audet, F. (2009). セッション開始プロトコル (SIP) における SIPS URI スキームの使用。doi : 10.17487/RFC5630 . RFC 5630。
- ^ Sheffer, Y.; Holz, R.; Saint-Andre, P. (2015). トランスポート層セキュリティ (TLS) とデータグラム TLS (DTLS) に対する既知の攻撃のまとめ。doi : 10.17487 /RFC7457 . RFC 7457。
- ^ 「CVE – CVE-2009-3555」。2016年1月4日時点のオリジナルよりアーカイブ。
- ^ Rescorla, Eric (2009-11-05). 「TLS 再ネゴシエーション攻撃を理解する」。Educated Guesswork。 2012-02-11 にオリジナルからアーカイブ。2009-11-27に取得。
- ^ 「SSL_CTX_set_options SECURE_RENEGOTIATION」OpenSSL Docs 2010-02-25。2010-11-26 にオリジナルからアーカイブ。2010-11-18に取得。
- ^ 「GnuTLS 2.10.0 リリース」。GnuTLS リリースノート。2010-06-25。2015-10-17 にオリジナルからアーカイブ。2011-07-24に取得。
- ^ 「NSS 3.12.6 リリースノート」。NSSリリースノート。2010-03-03。2012年3月6日時点のオリジナルよりアーカイブ。 2011年7月24日閲覧。
- ^ A. Langley、N. Modadugu、B. Moeller (2010-06-02)。「トランスポート層セキュリティ (TLS) False Start」。インターネット技術タスクフォース。IETF。2013-09-05 のオリジナルからアーカイブ。2013-07-31に取得。
- ^ Gruener, Wolfgang. 「False Start: Google Proposes Faster Web, Chrome Supports It Already」。2010 年 10 月 7 日時点のオリジナルよりアーカイブ。2011年 3 月 9 日閲覧。
- ^ Smith, Brian. 「False Start と Snap Start における限定的なロールバック攻撃」。2011 年 5 月 4 日時点のオリジナルよりアーカイブ。2011年 3 月 9 日閲覧。
- ^ Dimcev, Adrian. 「False Start」. Random SSL/TLS 101 . 2011-05-04 にオリジナルからアーカイブ。2011-03-09に取得。
- ^ 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）されました。
- ^ 「SMACK: State Machine AttaCKs」。2015年3月12日時点のオリジナルよりアーカイブ。
- ^ Goodin, Dan (2015-05-20). 「HTTPS を壊滅させる攻撃が数万の Web サーバーとメール サーバーを脅かす」Ars Technica。2017-05-19 時点のオリジナルよりアーカイブ。
- ^ Leyden, John (2016年3月1日). 「HTTPSウェブサイトの3分の1がDROWN攻撃にさらされている」The Register。2016年3月1日時点のオリジナルよりアーカイブ。 2016年3月2日閲覧。
- ^ ab 「新たな復号化攻撃により 1,100 万以上の HTTPS ウェブサイトが危険にさらされる」Ars Technica 2016 年 3 月。2016 年 3 月 1 日時点のオリジナルよりアーカイブ。2016年 3 月 2 日閲覧。
- ^ Thai Duong & Juliano Rizzo (2011-05-13). 「Here Come The ⊕ Ninjas」。2014-06-03時点のオリジナルよりアーカイブ。
- ^ Goodin, Dan (2011-09-19). 「ハッカーが数百万のサイトで使用されている SSL 暗号化を破る」The Register。2012-02-10 のオリジナルからアーカイブ。
- ^ 「Y Combinator がこの件についてコメント」 2011 年 9 月 20 日。2012 年 3 月 31 日時点のオリジナルよりアーカイブ。
- ^ 「SSL/TLS における CBC 暗号スイートのセキュリティ: 問題と対策」 2004 年 5 月 20 日。2012 年 6 月 30 日時点のオリジナルよりアーカイブ。
- ^ Ristic, Ivan (2013年9月10日). 「BEASTはまだ脅威か?」 2014年10月12日時点のオリジナルよりアーカイブ。 2014年10月8日閲覧。
- ^ 「Chrome 安定版リリース」。Chromeリリース。2011 年 10 月 25 日。2015 年 2 月 20 日時点のオリジナルよりアーカイブ。2015年 2 月 1 日閲覧。
- ^ 「TLS で保護された通信に対する攻撃」。Mozillaセキュリティ ブログ。Mozilla。2011 年 9 月 27 日。2015 年 3 月 4 日にオリジナルからアーカイブ。2015年 2 月 1 日に取得。
- ^ Smith, Brian (2011-09-30). 「(CVE-2011-3389) Rizzo/Duong 選択プレーンテキスト攻撃 (BEAST) SSL/TLS 1.0 (websockets-76 によって促進)」。2012-02-10 にオリジナルからアーカイブ。2011-11-01に取得。
- ^ MSRC (2012-01-10). SSL/TLS の脆弱性により情報漏えいが起こる可能性がある (2643584).セキュリティ情報(技術レポート). MS12-006 . 2021-10-24に取得 – Microsoft Docs経由。
- ^ Ristic, Ivan (2013 年 10 月 31 日). 「Apple が OS X 10.9 Mavericks で BEAST 緩和策を有効に」。2014 年 10 月 12 日時点のオリジナルよりアーカイブ。2014 年10 月 8 日閲覧。
- ^ Goodin, Dan (2012-09-13). 「インターネットの信頼基盤の亀裂により、HTTPS セッションのハイジャックが可能に」Ars Technica。 2013-08-01 にオリジナルからアーカイブ。2013-07-31に取得。
- ^ Fisher, Dennis (2012 年 9 月 13 日)。「CRIME 攻撃は、TLS 要求の圧縮率をサイド チャネルとして使用して、安全なセッションをハイジャックします」。ThreatPost。2012 年 9 月 15 日時点のオリジナルよりアーカイブ。2012 年 9 月 13 日閲覧。
- ^ ab Goodin, Dan (2013年8月1日). 「30秒で消える：新たな攻撃がHTTPSで保護されたページから秘密を盗み出す」Ars Technica . Condé Nast. 2013年8月3日時点のオリジナルよりアーカイブ。 2013年8月2日閲覧。
- ^ Leyden, John (2013年8月2日). 「Step into the BREACH: New attackdeveloped to read encrypted web data」. The Register . 2013年8月5日時点のオリジナルよりアーカイブ。 2013年8月2日閲覧。
- ^ P. Gutmann (2014 年 9 月). 「トランスポート層セキュリティ (TLS) およびデータグラム トランスポート層セキュリティ (DTLS) の暗号化後 MAC」。インターネット技術タスク フォース。doi : 10.17487 / RFC7366。RFC 7366 。
- ^ Langley, Adam (2014年12月8日). “The POODLE bites again”. 2014年12月8日時点のオリジナルよりアーカイブ。 2014年12月8日閲覧。
- ^ 「ssl – BEAST で使用する最も安全な暗号は? (TLS 1.0 エクスプロイト) RC4 は影響を受けないと読んだ」Serverfault.com。2022 年 2 月 20 日時点のオリジナルよりアーカイブ。2022年2 月 20 日閲覧。
- ^ Pouyan Sepehrdad、Serge Vaudenay、Martin Vuagnoux (2011)。「RC4 における新しいバイアスの発見と活用」。Alex Biryukov、Guang Gong、Douglas R. Stinson (編)。暗号技術の特定分野: 第 17 回国際ワークショップ、SAC 2010、カナダ、オンタリオ州ウォータールー、2010 年 8 月 12 ～ 13 日、改訂版選定論文。コンピュータ サイエンスの講義ノート。第 6544 巻。pp. 74 ～ 91。doi : 10.1007 / 978-3-642-19574-7_5。ISBN 978-3-642-19573-0。
- ^ Green, Matthew (2013 年 3 月 12 日). 「今週の攻撃: RC4 は TLS ではちょっと壊れている」. Cryptography Engineering . 2013 年 3 月 14 日時点のオリジナルよりアーカイブ。2013 年3 月 12 日閲覧。
- ^ AlFardan, Nadhem; Bernstein, Dan; Paterson, Kenny; Poettering, Bertram; Schuldt, Jacob. 「TLS における RC4 のセキュリティについて」。ロイヤル・ホロウェイ大学ロンドン校。2013 年 3 月 15 日時点のオリジナルよりアーカイブ。2013年3 月 13 日閲覧。
- ^ 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 日に閲覧。
- ^ AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob CN (2013 年 8 月 15 日)。TLS における RC4 のセキュリティについて(PDF)。第 22 回USENIXセキュリティ シンポジウム。p. 51。2013年 9 月 22 日時点のオリジナルからアーカイブ(PDF) 。2013年9 月 2 日に取得。TLS
における RC4 に対するプレーンテキスト復元攻撃は、実際には実用的ではないものの、実行可能です。
- ^ Goodin, Dan (2015 年 7 月 15 日). 「かつては理論上のものだった HTTPS に対する暗号攻撃が、今では実用化に近づいている」Ars Technical . Conde Nast. 2015 年 7 月 16 日時点のオリジナルよりアーカイブ。 2015 年7 月 16 日閲覧。
- ^ 「Mozilla セキュリティ サーバー側 TLS 推奨構成」。Mozilla。2015 年 1 月 3 日時点のオリジナルよりアーカイブ。2015 年 1 月 3 日閲覧。
- ^ 「セキュリティ アドバイザリ 2868725: RC4 を無効にすることを推奨」。Microsoft。2013 年 11 月 12 日。2013 年 11 月 18 日時点のオリジナルよりアーカイブ。2013年 12 月 4 日に取得。
- ^ 「Microsoft Edge および Internet Explorer 11 での RC4 暗号のサポート終了」。Microsoft Edge チーム。2015 年 9 月 1 日。2015 年 9 月 2 日時点のオリジナルよりアーカイブ。
- ^ Langley, Adam (2015年9月1日). 「非推奨の意図: RC4」。2013年5月23日時点のオリジナルよりアーカイブ。 2015年9月2日閲覧。
- ^ Barnes, Richard (2015 年 9 月 1 日)。「出荷予定: Firefox 44 では RC4 がデフォルトで無効化」。2011 年 1 月 22 日時点のオリジナルよりアーカイブ。
- ^ ab John Leyden (2013年8月1日). 「Gmail、Outlook.com、電子投票が暗号回避ハックでステージ上で「乗っ取られる」」The Register。2013年8月1日時点のオリジナルよりアーカイブ。 2013年8月1日閲覧。
- ^ 「BlackHat USA Briefings」。Black Hat 2013。 2013年7月30日時点のオリジナルよりアーカイブ。2013年8月1日閲覧。
- ^ Smyth, Ben; Pironti, Alfredo (2013). ウェブアプリケーションにおける信念を侵害するための TLS 接続の切断。第 7 回 USENIX 攻撃技術ワークショップ(レポート)。2015 年 11 月 6 日時点のオリジナルよりアーカイブ。2016年2 月 15 日閲覧。
- ^ AlFardan, Nadhem; Paterson, Kenneth G (2012). Plaintext-recovery attacks against datagram TLS (PDF) . Network and distribution system security symposium (NDSS 2012). 2012-01-18 にオリジナルからアーカイブ。
{{cite conference}}: CS1 maint: unfit URL (link) - ^ Goodin, Dan (2016年7月26日). 「新たな攻撃がMac、Windows、LinuxのHTTPS保護をバイパス」Ars Technica . Condé Nast. 2016年7月27日時点のオリジナルよりアーカイブ。 2016年7月28日閲覧。
- ^ Goodin, Dan (2016年8月24日). 「HTTPSとOpenVPN、秘密のクッキーを解読できる新たな攻撃に直面」Ars Technica。2016年8月24日時点のオリジナルよりアーカイブ。 2016年8月24日閲覧。
- ^ 「なぜ『Heartbleed Bug』と呼ばれるのか？」ワシントンポスト。2014年4月9日。2014年10月9日時点のオリジナルよりアーカイブ。
- ^ 「Heartbleed Bugの脆弱性 [2014年4月9日]」。Comodo Group。2014年7月5日時点のオリジナルよりアーカイブ。
- ^ Bleichenbacher, Daniel (2006 年 8 月). 「Bleichenbacher の RSA 署名偽造は実装エラーに基づく」。2014 年 12 月 16 日時点のオリジナルよりアーカイブ。
- ^ 「BERserk」。Intel Security: Advanced Threat Research。2014 年 9 月。2015 年 1 月 12 日時点のオリジナルよりアーカイブ。
- ^ Goodin, Dan (2015年2月19日). 「Lenovo PCにはHTTPS接続を遮断する中間者アドウェアが搭載されている」Ars Technica。 2017年9月12日時点のオリジナルよりアーカイブ。 2017年12月10日閲覧。
- ^ Valsorda, Filippo (2015-02-20). 「Komodia/Superfish SSL 検証が壊れている」Filippo.io。2015-02-24 にオリジナルからアーカイブ。
- ^ ab Goodin, Dan (2016年5月26日). 「「禁じられた攻撃」により、数十のHTTPS Visaサイトが改ざんに対して脆弱に」Ars Technica。 2016年5月26日時点のオリジナルよりアーカイブ。 2016年5月26日閲覧。
- ^ Clark Estes、Adam (2017年2月24日)。「最新のインターネットセキュリティ災害、Cloudbleedについて知っておくべきことすべて」Gizmodo。2017年2月25日時点のオリジナルよりアーカイブ。 2017年2月24日閲覧。
- ^ 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 日に取得。
- ^ “2007年10月のTLSメーリングリストでの議論”. 2013年9月22日時点のオリジナルよりアーカイブ。2022年2月20日閲覧。
- ^ 「前方秘匿性による長期的なデータ保護」。2013 年 5 月 6 日時点のオリジナルよりアーカイブ。2012年 11 月 5 日閲覧。
- ^ Bernat, Vincent (2011 年 11 月 28 日). 「SSL/TLS と Perfect Forward Secrecy」。2012 年 8 月 27 日時点のオリジナルよりアーカイブ。2012年 11 月 5 日閲覧。
- ^ 「SSL Labs: Forward Secrecy の導入」Qualys.com、2013 年 6 月 25 日。2013 年 6 月 26 日にオリジナルからアーカイブ。2013年 7 月 10 日に取得。
- ^ Ristic, Ivan (2013-08-05). 「SSL Labs: Deploying Forward Secrecy」. Qualsys. 2013-09-20 にオリジナルからアーカイブ。2013-08-31に取得。
- ^ ab Langley, Adam (2013年6月27日). 「TLS forward secrecyを台無しにする方法」. imperialviolet.org . 2013年8月8日時点のオリジナルよりアーカイブ。
- ^ ab Daignière, Florent. 「TLS "Secrets": OpenSSL に実装されたセッション チケット (RFC 5077) の展開のセキュリティへの影響を示すホワイト ペーパー」(PDF) 。 Matta Consulting Limited。 2013 年 8 月 6 日のオリジナルからアーカイブ(PDF) 。 2013 年8 月 7 日に取得。
- ^ ab Daignière, Florent. 「TLS「Secrets」：誰もがあなたに伝え忘れたこと…」(PDF)。 Matta Consulting Limited。2013 年 8 月 5 日時点のオリジナルよりアーカイブ(PDF) 。 2013 年8 月 7 日閲覧。
- ^ LS Huang; S. Adhikarla; D. Boneh; C. Jackson (2014). 「TLS Forward Secrecy Deployments の実験的研究」. IEEE Internet Computing . 18 (6): 43–51. CiteSeerX 10.1.1.663.4653 . doi :10.1109/MIC.2014.86. S2CID 11264303. 2015年9月20日時点のオリジナルよりアーカイブ。2015年10月16日閲覧。
- ^ 「前方秘匿性による長期的なデータ保護」。2014 年 2 月 12 日時点のオリジナルよりアーカイブ。2014年 3 月 7 日閲覧。
- ^ Hoffman-Andrews, Jacob. 「Twitter における前方秘匿性」。Twitter。2014 年 2 月 16 日時点のオリジナルよりアーカイブ。2014 年 3 月 7 日閲覧。
- ^ abc 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日閲覧。
- ^ ab これらの証明書は現在X.509ですが、RFC 6091 ではOpenPGPベースの証明書 の使用も指定されています。
- ^ 「tls – 「プレマスターシークレット」、「マスターシークレット」、「秘密鍵」、および「共有シークレット」という用語の違いは何ですか？」。Cryptography Stack Exchange。 2020 年 9 月 22 日のオリジナルからアーカイブ。 2020 年 10 月 1 日に取得。
- ^ Chris (2009-02-18). 「vsftpd-2.1.0 リリース – FTPS データ接続認証に TLS セッション再開を使用」. Scarybeastsecurity. blogspot.com. 2012-07-07 にオリジナルからアーカイブ。2012-05-17に取得。
- ^ Rescorla, Eric (2018 年 8 月). 「暗号化ネゴシエーション」. トランスポート層セキュリティ (TLS) プロトコル バージョン 1.3. IETF. sec. 4.1.1. doi : 10.17487/RFC8446 . RFC 8446.
- ^ Valsorda, Filippo (2016年9月23日). 「TLS 1.3の概要とQ&A」。Cloudflareブログ。2019年5月3日時点のオリジナルよりアーカイブ。 2019年5月3日閲覧。
- ^ ワイルドカード SSL 証明書の概要、2015 年 6 月 23 日にオリジナルからアーカイブ、2015 年 7 月 2 日に取得
- ^ 名前ベースの SSL 仮想ホスト: 問題への対処方法(PDF)、2012 年 8 月 3 日にオリジナルからアーカイブ(PDF) 、2012 年 5 月 17 日に取得
さらに読む
Wikimedia Commons にはSSL と TLSに関連するメディアがあります。
- Wagner, David; Schneier, Bruce (1996 年 11 月)。「SSL 3.0 プロトコルの分析」(PDF)。第 2 回 USENIX 電子商取引ワークショップ議事録。USENIX Press。29 ～ 40 ページ。2006年 10 月 16 日にオリジナルからアーカイブ(PDF) 。2006年 10 月 12 日に取得。
- Rescorla, Eric (2001)。SSLと TLS: 安全なシステムの設計と構築。米国: Addison-Wesley Pub Co. ISBN 978-0-201-61598-2。
- Stephen A. Thomas (2000)。Webを保護する SSL と TLS の基本。ニューヨーク: Wiley。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 日に取得。
- TLS再ネゴシエーションの変更に関するRFC 。 2010年。doi :10.17487/RFC5746。RFC 5746 。
- IPsec と SSL/TLS を使用した VPN の作成 2015-04-12 にWayback MachineでアーカイブLinux Journal の記事 Rami Rosen 著
- ジョシュア・デイヴィス (2010) 。SSL /TLS の実装。Wiley。ISBN 978-0470920411。
- Polk, Tim、McKay, Kerry、Chokhani, Santosh (2014 年 4 月)。「トランスポート層セキュリティ (TLS) 実装の選択、構成、および使用に関するガイドライン」(PDF) 。米国国立標準技術研究所。2014年 5 月 8 日にオリジナル(PDF)からアーカイブ。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版。Feisty Duck。ISBN 978-1907117091。
主な基準
現在承認されている (D)TLS のバージョンはバージョン 1.3 であり、次のとおり指定されています。
- RFC 8446:「トランスポート層セキュリティ (TLS) プロトコル バージョン 1.3」。
- RFC 9147: 「データグラム トランスポート層セキュリティ (DTLS) プロトコル バージョン 1.3」
現在の標準は、現在では時代遅れとみなされている以下の以前のバージョンに代わるものです。
- RFC 5246:「トランスポート層セキュリティ (TLS) プロトコル バージョン 1.2」。
- RFC 6347:「データグラム トランスポート層セキュリティ バージョン 1.2」
- RFC 4346:「トランスポート層セキュリティ (TLS) プロトコル バージョン 1.1」。
- RFC 4347" "データグラム トランスポート層セキュリティ"
- RFC 2246:「TLS プロトコル バージョン 1.0」。
- RFC 6101:「Secure Sockets Layer (SSL) プロトコル バージョン 3.0」。
- インターネット ドラフト (1995):「SSL プロトコル」
拡張機能
その後、他のRFCによって (D)TLS が拡張されました。
(D)TLS 1.3 の拡張機能には以下が含まれます。
- RFC 9367: 「トランスポート層セキュリティ (TLS) プロトコル バージョン 1.3 の GOST 暗号スイート」。
(D)TLS 1.2 の拡張機能には以下が含まれます。
- RFC 5288: 「TLS 用の AESガロア カウンター モード(GCM) 暗号スイート」。
- RFC 5289:「SHA-256/384 および AES ガロア カウンター モード (GCM) を使用した TLS 楕円曲線暗号スイート」。
- RFC 5746: 「トランスポート層セキュリティ (TLS) 再ネゴシエーション表示拡張」。
- RFC 5878: 「トランスポート層セキュリティ (TLS) 認証拡張」。
- RFC 5932: 「TLS 用 Camellia 暗号スイート」
- RFC 6066:「トランスポート層セキュリティ (TLS) 拡張: 拡張定義」には、サーバー名表示とOCSP ステープリングが含まれます。
- RFC 6091:「トランスポート層セキュリティ (TLS) 認証にOpenPGPキーを使用する」。
- RFC 6176:「Secure Sockets Layer (SSL) バージョン 2.0 の禁止」。
- RFC 6209: 「トランスポート層セキュリティ (TLS) へのARIA暗号スイートの追加」。
- RFC 6347:「データグラム トランスポート層セキュリティ バージョン 1.2」。
- RFC 6367: 「トランスポート層セキュリティ (TLS) への Camellia 暗号スイートの追加」。
- RFC 6460: 「トランスポート層セキュリティ (TLS) の Suite B プロファイル」。
- RFC 6655: 「トランスポート層セキュリティ (TLS) 用の AES-CCM 暗号スイート」。
- RFC 7027: 「トランスポート層セキュリティ (TLS) 用の楕円曲線暗号 (ECC) ブレインプール曲線」。
- RFC 7251: 「TLS 用の AES-CCM 楕円曲線暗号化 (ECC) 暗号スイート」。
- RFC 7301:「トランスポート層セキュリティ (TLS)アプリケーション層プロトコル ネゴシエーション拡張」。
- RFC 7366: 「トランスポート層セキュリティ (TLS) およびデータグラム トランスポート層セキュリティ (DTLS) の暗号化してから MAC」。
- RFC 7465:「RC4 暗号スイートの禁止」。
- RFC 7507:「プロトコル ダウングレード攻撃を防ぐための TLS フォールバック シグナリング暗号スイート値 (SCSV)」。
- RFC 7568: 「Secure Sockets Layer バージョン 3.0 の廃止」
- RFC 7627:「トランスポート層セキュリティ (TLS) セッション ハッシュと拡張マスター シークレット拡張」。
- RFC 7685:「トランスポート層セキュリティ (TLS) ClientHello パディング拡張」。
- RFC 9189: 「トランスポート層セキュリティ (TLS) プロトコル バージョン 1.2 の GOST 暗号スイート」。
(D)TLS 1.1 の拡張機能には以下が含まれます。
- RFC 4366:「トランスポート層セキュリティ (TLS) 拡張」では、特定の拡張のセットと汎用拡張メカニズムの両方について説明します。
- RFC 4492: 「トランスポート層セキュリティ (TLS) 用の楕円曲線暗号化(ECC) 暗号スイート」。
- RFC 4680:「補足データ用の TLS ハンドシェイク メッセージ」。
- RFC 4681:「TLS ユーザー マッピング拡張」。
- RFC 4785: 「トランスポート層セキュリティ (TLS) 用の NULL 暗号化を使用した事前共有キー (PSK) 暗号スイート」。
- RFC 5054: 「 TLS 認証にセキュア リモート パスワード(SRP) プロトコルを使用する」。TLS -SRP暗号スイートを定義します。
- RFC 5077: 「サーバー側の状態なしでのトランスポート層セキュリティ (TLS) セッション再開」。
- RFC 5081: 「トランスポート層セキュリティ (TLS) 認証にOpenPGPキーを使用する」は、RFC 6091 によって廃止されました。
- RFC 5216: 「EAP -TLS 認証プロトコル」
TLS 1.0 の拡張機能には以下が含まれます。
- RFC 2595: 「IMAP、POP3、ACAP での TLS の使用」。サーバーとクライアントがトランスポート層セキュリティを使用して、インターネット経由でプライベートで認証された通信を提供できるようにする IMAP、POP3、ACAP サービスの拡張機能を指定します。
- RFC 2712: 「トランスポート層セキュリティ (TLS) へのKerberos暗号スイート の追加」。このメモで定義されている 40 ビットの暗号スイートは、それらの暗号スイート コードがすでに割り当てられているという事実を文書化する目的でのみ表示されます。
- RFC 2817: 「HTTP/1.1 内での TLS へのアップグレード」では、HTTP/1.1 のアップグレード メカニズムを使用して、既存の TCP 接続でトランスポート層セキュリティ (TLS) を開始する方法について説明しています。これにより、セキュリティ保護されていない HTTP トラフィックとセキュリティ保護された HTTP トラフィックが同じ既知のポート (この場合は、443 の https: ではなく 80 の http:)を共有できるようになります。
- RFC 2818:「HTTP Over TLS」では、異なる「サーバー ポート」を使用して、セキュリティで保護されたトラフィックとセキュリティで保護されていないトラフィックを区別します。
- RFC 3207: 「トランスポート層セキュリティを介した安全な SMTP のための SMTP サービス拡張」。SMTP サーバーとクライアントがトランスポート層セキュリティを使用して、インターネット経由でプライベートで認証された通信を提供できるようにする SMTP サービスの拡張を指定します。
- RFC 3268: 「TLS の AES 暗号スイート」。既存の対称暗号にAdvanced Encryption Standard (AES) 暗号スイートを追加します。
- RFC 3546: 「トランスポート層セキュリティ (TLS) 拡張」は、セッション初期化中にプロトコル拡張をネゴシエートするための メカニズムを追加し、いくつかの拡張を定義します。RFC 4366 によって廃止されました。
- RFC 3749:「トランスポート層セキュリティ プロトコル圧縮方法」では、圧縮方法のフレームワークとDEFLATE圧縮方法を指定します。
- RFC 3943: 「Lempel-Ziv-Stac (LZS) を使用したトランスポート層セキュリティ (TLS) プロトコル圧縮」。
- RFC 4132: 「トランスポート層セキュリティ (TLS) へのCamellia暗号スイートの追加」。
- RFC 4162: 「トランスポート層セキュリティ (TLS) へのSEED暗号スイートの追加」。
- RFC 4217: 「TLS による FTP のセキュリティ保護」
- RFC 4279:「トランスポート層セキュリティ (TLS) の事前共有キー暗号スイート」では、事前共有キーに基づく認証をサポートするために、TLS プロトコル用の新しい暗号スイートの 3 セットが追加されています。
情報RFC
- RFC 7457: 「トランスポート層セキュリティ (TLS) とデータグラム TLS (DTLS) に対する既知の攻撃の概要」
- RFC 7525: 「トランスポート層セキュリティ (TLS) とデータグラム トランスポート層セキュリティ (DTLS) の安全な使用に関する推奨事項」
外部リンク
- インターネット エンジニアリング タスク フォース – TLS ワークグループ 2014-01-11 にWayback Machineでアーカイブ