Loading article…
トランスポート層セキュリティ（TLS）は、インターネットなどのコンピュータネットワーク上で通信のセキュリティを確保するために設計された暗号化プロトコルです。このプロトコルは、電子メール、インスタントメッセージ、VoIPなどのアプリケーションで広く使用されていますが、 HTTPSのセキュリティ確保における利用が最も広く知られています。
TLSプロトコルは、主に暗号化技術（証明書の使用など）を用いて、通信する2つ以上のコンピュータアプリケーション間で、プライバシー（機密性）、完全性、および認証性を含むセキュリティを提供することを目的としている。TLSプロトコルはプレゼンテーション層で動作し、TLSレコードとTLSハンドシェイクプロトコルの2つの層から構成されている。
密接に関連するデータグラムトランスポート層セキュリティ（DTLS）は、データグラムベースのアプリケーションにセキュリティを提供する通信プロトコルです。技術文書では、両方のバージョンに適用される場合に「（D）TLS」という表記がよく見られます。[ 1 ]
TLSは、インターネット技術タスクフォース（IETF）が提案した標準規格であり、1999年に初めて定義されました。現在のバージョンはTLS 1.3で、2018年8月に定義されました。TLSは、Netscape Communicationsが自社のWebブラウザであるNetscape NavigatorにHTTPSプロトコルを追加するために開発した、現在では非推奨となっているSSL（Secure Sockets Layer）仕様（1994年、1995年、1996年）に基づいています。
クライアント/サーバーアプリケーションは、盗聴や改ざんを防ぐように設計された方法で、ネットワークを介して通信するためにTLSプロトコルを使用します。
アプリケーションはTLS（またはSSL）の有無にかかわらず通信できるため、クライアントはサーバーにTLS接続を確立するように要求する必要があります。 [ 2 ]これを実現する主な方法の1つは、TLS接続に別のポート番号を使用することです。ポート80は通常、暗号化されていないHTTPトラフィックに使用され、ポート443は暗号化されたHTTPSトラフィックによく使用されるポートです。もう1つのメカニズムは、プロトコル固有のSTARTTLSリクエストをサーバーに送信して接続をTLSに切り替えることです。たとえば、一部のメールおよびニュースプロトコルを使用する場合などです。
クライアントとサーバーがTLSの使用に合意すると、ハンドシェイク手順を使用してステートフル接続をネゴシエートします（ §TLS ハンドシェイクを参照）。[ 3 ]プロトコルは、非対称暗号を使用したハンドシェイクを使用して、暗号設定だけでなく、以降の通信を対称暗号で暗号化するセッション固有の共有鍵も確立します。このハンドシェイク中に、クライアントとサーバーは、接続のセキュリティを確立するために使用されるさまざまなパラメータについて合意します。
これでハンドシェイクが完了し、セッションキーを使用して暗号化と復号化が繰り返されるセキュアな接続が開始されます。接続が閉じられるまで、この接続はセッションキーによって暗号化と復号化が繰り返されます。上記の手順のいずれかが失敗した場合、TLSハンドシェイクは失敗し、接続は確立されません。
TLSおよびSSLの旧バージョンでは、サーバーの公開鍵と秘密鍵を使用したPreMasterSecretを介してセッションを確立することが可能でした。これらのアルゴリズムは、前方秘匿性が義務付けられたTLS1.3で廃止されました。[ 4 ]
TLSとSSLは、 OSIモデルやTCP/IPモデルのいずれの単一層にもきれいに収まりません。[ 5 ] [ 6 ] TLSは「何らかの信頼性の高いトランスポートプロトコル（例えばTCP）の上」で動作します[ 7 ] : §1 。これは、TLSがトランスポート層よりも上位にあることを意味します。TLSは上位層に暗号化を提供しますが、これは通常プレゼンテーション層の機能です。しかし、アプリケーションは一般的にTLSをトランスポート層であるかのように使用します[ 5 ] [ 6 ] 。ただし、TLSを使用するアプリケーションは、TLSハンドシェイクの開始と交換される認証証明書の処理を積極的に制御する必要があります[ 7 ] : §1。
TLSで保護されている場合、クライアント（例：Webブラウザ）とサーバー（例：wikipedia.org）間の接続は、以下のすべての特性を持ちます。[ 7 ]： §1
TLSは、鍵の交換、データの暗号化、メッセージの完全性の認証に関して、さまざまな方法をサポートしています。そのため、TLSの安全な構成には多くの設定可能なパラメータが関係し、すべての選択肢が上記のリストに記載されているプライバシー関連の特性をすべて提供するわけではありません（以下の表「 鍵交換」、「 暗号のセキュリティ」、「 データの完全性」を参照してください）。
TLSが提供しようとする通信セキュリティの側面を侵害しようとする試みがなされており、これらのセキュリティ上の脅威に対処するためにプロトコルは何度か改訂されてきました。ウェブブラウザの開発者は、潜在的なセキュリティ上の脆弱性が発見されるたびに、それらから保護するために製品を繰り返し改訂してきました（ウェブブラウザのTLS/SSLサポートの歴史を参照）。
データグラムトランスポート層セキュリティ（DTLSと略される）は、盗聴、改ざん、またはメッセージの偽造を防止するように設計された方法で通信できるようにすることで、データグラムベースのアプリケーションにセキュリティを提供する関連通信プロトコルです[ 8 ] [ 9 ]。DTLSプロトコルは、ストリーム指向のトランスポート層セキュリティ（TLS）プロトコルに基づいており、同様のセキュリティ保証を提供することを目的としています。ただし、TLSとは異なり、ユーザーデータグラムプロトコル（UDP）、データグラム輻輳制御プロトコル（DCCP）、無線アクセスポイントの制御とプロビジョニング（CAPWAP）、ストリーム制御伝送プロトコル（SCTP）カプセル化、セキュアリアルタイムトランスポートプロトコル（SRTP）など、ほとんどのデータグラム指向プロトコルで使用できます。
DTLSプロトコルのデータグラムは基盤となるトランスポートのセマンティクスを保持するため、アプリケーションはストリームプロトコルに関連する遅延の影響を受けません。ただし、アプリケーションはパケットの順序変更、データグラムの損失、およびデータグラムネットワークパケットのサイズを超えるデータに対処する必要があります。DTLSはTCPではなくUDPまたはSCTPを使用するため、 VPNトンネルを作成する際に使用されるTCPメルトダウン問題を回避します[ 10 ] [ 11 ]。
2006年に最初にリリースされたDTLSバージョン1.0は、単独の文書ではありませんでした。TLS 1.1への一連の差分として提供されました。[ 8 ] : §4同様に、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 クライアントはDTLS を使用して UDP トラフィックを保護しています。さらに、最新の Web ブラウザはすべてWebRTC用のDTLS-SRTP [ 19 ]をサポートしています。
将来の量子コンピュータによる「今すぐ収集して後で復号する」攻撃から保護するために、TLS 1.3 にはハイブリッドポスト量子鍵合意スキームが導入されています。これらは、古典的なECDHE交換と、2024 年 8 月にNISTによってFIPS 203 として標準化された格子ベースの鍵カプセル化メカニズムであるML-KEMを組み合わせたものです。 [ 20 ] IETF TLS ワーキンググループは、インターネット ドラフトでハイブリッド グループ X25519MLKEM768、SecP256r1MLKEM768、SecP384r1MLKEM1024 を定義しており、[ 21 ] TLS 1.3 のハイブリッド鍵交換の一般的なフレームワーク[ 22 ]およびスタンドアロン (非ハイブリッド) ML-KEM 鍵合意の仕様も定義しています。[ 23 ]
X25519MLKEM768（およびその前身であるX25519Kyber768）は、Google Chromeではバージョン131（2024年11月）以降[ 24 ]、Firefoxではバージョン132以降[ 25 ]でデフォルトで有効になっており、 OpenSSL 3.5 [ 26 ] 、 BoringSSL、Cloudflare [ 27 ]などのサーバーサイド実装でサポートされています。
1986年8月、国家安全保障局、国立標準局、国防通信局は、公共および民間インターネット上のアプリケーションに実装される次世代の安全なコンピュータ通信ネットワークと製品仕様を設計することを目的として、セキュアデータネットワークシステム（SDNS）と呼ばれるプロジェクトを開始しました。これは、米国政府のGOSIPプロファイルと国際的な大規模なITU-ISO JTC1インターネットの取り組みの両方で急速に出現している新しいOSIインターネット標準を補完することを意図していました。[ 37 ]
このプロジェクトの一環として、研究者たちは SP4 ( OSI システムのレイヤー 4 のセキュリティ プロトコル)と呼ばれるプロトコルを設計しました。これは後にトランスポート レイヤー セキュリティ プロトコル (TLSP) と改名され、1995 年に国際標準 ITU-T X.274|ISO/IEC 10736:1995 として公開されました。 [ 38 ]名前は似ていますが、これは今日の TLS とは異なります。
トランスポート層のセキュリティに向けたその他の取り組みとしては、セキュア ネットワーク プログラミング(SNP)アプリケーション プログラミング インターフェイス(API) があり、1993 年に、既存のネットワーク アプリケーションにセキュリティ対策を後付けしやすくするために、バークレー ソケットによく似たセキュア トランスポート層 API を持つアプローチを模索しました。SNP は、1994 年のUSENIX夏季技術会議で発表されました。[ 39 ] [ 40 ] SNP プロジェクトは、1991 年にNSAからテキサス大学オースティン校のSimon Lam教授への助成金によって資金提供されました。 [ 41 ]セキュア ネットワーク プログラミングは、 2004 年のACM ソフトウェア システム賞を受賞しました。[ 42 ] [ 43 ] Simon Lam は、「1991 年にセキュア ソケットを発明し、1993 年に SNP と呼ばれる最初のセキュア ソケット レイヤーを実装した」功績により、インターネットの殿堂入りを果たしました。 [ 44 ] [ 45 ]
Netscape はオリジナルの SSL プロトコルを開発し、1995 年から 1998 年までNetscape Communicationsの主任科学者であったTaher Elgamalは「 SSL の父」と呼ばれています。 [ 46 ] [ 47 ] [ 48 ] [ 49 ] SSL バージョン 1.0 は、プロトコルに重大なセキュリティ上の欠陥があったため、一般には公開されませんでした。1995 年 2 月にリリースされたバージョン 2.0 は、セキュリティとユーザビリティに多数の欠陥があることがすぐに判明しました。メッセージの認証と暗号化に同じ暗号鍵を使用していました。秘密のプレフィックス付き MD5 ハッシュ関数を使用する脆弱な MAC 構造であったため、長さ拡張攻撃に対して脆弱でした。また、開始ハンドシェイクと明示的なメッセージ終了のどちらにも保護が提供されていなかったため、中間者攻撃が検出されない可能性がありました。さらに、SSL 2.0 は単一のサービスと固定ドメイン証明書を前提としており、Web サーバーで広く使用されている仮想ホスティング機能と競合していたため、ほとんどの Web サイトは SSL を使用できなくなりました。
これらの欠陥により、プロトコルを完全に再設計して SSL バージョン 3.0 にする必要がありました。[ 50 ] [ 48 ] 1996 年にリリースされた SSL 3.0 は、Netscape のエンジニアである Phil Karlton と Alan Freier と協力してPaul Kocherが作成し、Certicom の Christopher Allen と Tim Dierks がリファレンス実装を作成しました。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 で使用されているため、破られる可能性があります。[ 51 ] SSL 3.0 は 2015 年 6 月にRFC 7568により非推奨となりました。
TLS 1.0 は、1999 年 1 月にRFC 2246で SSL バージョン 3.0 のアップグレードとして初めて定義され、Certicom の Christopher Allen と Tim Dierks によって書かれました。RFC に記載されているように、「このプロトコルと SSL 3.0 の違いは劇的ではありませんが、TLS 1.0 と SSL 3.0 の相互運用性を排除するのに十分なほど重要です」。Tim Dierks は後に、これらの変更と「SSL」から「TLS」への名称変更は、Microsoft の面子を保つためのジェスチャーであり、「IETF が Netscape のプロトコルをただ追認しているように見えないようにするため」だったと述べています。[ 52 ]
PCI Council は、組織が 2018 年 6 月 30 日までに TLS 1.0 から TLS 1.1 またはそれ以上に移行することを推奨しました。[ 53 ] [ 54 ] 2018 年 10 月、Apple、Google、Microsoft、およびMozilla は、2020 年 3 月に TLS 1.0 および 1.1 を非推奨にすることを共同で発表しました。[ 31 ] TLS 1.0 および 1.1 は、 2021 年 3 月にRFC 8996で正式に非推奨となりました。
TLS 1.1は、2006年4月にRFC 4346で定義されました。 [ 55 ]これはTLSバージョン1.0からのアップデートです。このバージョンの主な違いは次のとおりです。
TLS バージョン 1.0 および 1.1 のサポートは、2020 年頃に Web サイトによって広く廃止され[ 57 ] 、 Firefoxバージョン 24 より前とChromium ベースのブラウザ29 より前のバージョンへのアクセスが無効になりました[ 58 ]。ただし、サードパーティの修正により、Netscape Navigator および古いバージョンの Firefox に TLS 1.2 のサポートを追加できます[ 59 ]。
TLS 1.2は、2008年8月にRFC 5246で定義されました。 [ 34 ]これは、以前のTLS 1.1仕様に基づいています。主な違いは次のとおりです。
2011年3月にRFC 6176で全てのTLSバージョンがさらに改良され、SSLとの下位互換性が削除されたため、TLSセッションではSecure Sockets Layer（SSL）バージョン2.0の使用がネゴシエートされることはなくなりました。
2026年7月現在 TLS 1.2の廃止日は正式には定められておらず、レガシークライアントとの互換性が確保されています。ただし、MD5およびSHA1ハッシュ方式、有限体上のDiffie-Hellman（DH）およびRSA鍵交換の使用は廃止されました。（RFC 9155、10015）
TLS 1.3 は2018 年 8 月にRFC 8446で定義されました。 [ 7 ] 2026 年 7 月にRFC 9846で更新されました。これは以前の TLS 1.2 仕様に基づいています。TLS 1.2 との主な違いは次のとおりです。[ 4 ]
Mozillaが開発し、同社のウェブブラウザFirefoxで使用されている暗号化ライブラリであるNetwork Security Services （NSS）は、2017年2月にTLS 1.3をデフォルトで有効にしました。 [ 61 ]その後、TLS 1.3のサポートは、少数のユーザーとの互換性の問題により自動的には有効にされなかったものの、 2017年3月にリリースされたFirefox 52.0に追加されました。 [ 62 ] TLS 1.3は、2018年5月にFirefox 60.0がリリースされた際にデフォルトで有効になりました。[ 63 ]
Google Chromeは2017年に短期間TLS 1.3をデフォルトバージョンに設定しましたが、Blue Coatウェブプロキシなどの互換性のないミドルボックスのため、デフォルトから削除しました。[ 64 ]
TLSの新バージョンの不耐性はプロトコルの硬直化でした。ミドルボックスがプロトコルのバージョンパラメータを硬直化させていたのです。その結果、バージョン1.3はバージョン1.2のワイヤイメージを模倣しています。この変更は設計プロセスの非常に遅い段階で発生し、ブラウザの展開中に初めて発見されました。[ 65 ]この不耐性の発見により、以前のバージョンネゴシエーション戦略（最も一致するバージョンを選択する）も、硬直化のレベルが実用的でないため放棄されました。[ 66 ]拡張ポイントを「グリースアップ」する、つまり、プロトコル参加者の1人が存在しない拡張機能のサポートを主張することで、認識されていないが実際には存在する拡張機能が許容され、硬直化に抵抗するという方法は、元々はTLS用に設計されたものですが、その後他の場所でも採用されています。[ 66 ]
2017年にシンガポールで開催されたIETF 100ハッカソンでは、TLSグループがオープンソースアプリケーションをTLS 1.3に対応させる作業に取り組みました。[ 67 ] [ 68 ] TLSグループは、cyberstorm.muチームを通じて日本、英国、モーリシャスのメンバーで構成されていました。[ 68 ]この作業は、ロンドンで開催されたIETF 101ハッカソン[ 69 ]とモントリオールで開催されたIETF 102ハッカソン[ 70 ]でも継続されました。
wolfSSL は、2017 年 5 月にリリースされたバージョン 3.11.1 から TLS 1.3 の使用を可能にしました。[ 71 ]商用 TLS 1.3 実装としては初めて、wolfSSL 3.11.1 はドラフト 18 をサポートし、現在は最終バージョンであるドラフト 28 [ 72 ]と多くの古いバージョンをサポートしています。TLS 1.2 と 1.3 のパフォーマンスの違いに関する一連のブログが公開されました。[ 73 ]
で人気のOpenSSLプロジェクトは、TLS 1.3のサポートを「目玉の新機能」とするライブラリのバージョン1.1.1をリリースした。[ 74 ]
Windows 11およびWindows Server 2022のGAリリースでは、セキュアチャネル（schannel）にTLS 1.3のサポートが追加されました。[ 75 ]
電子フロンティア財団はTLS 1.3を称賛し、TLS 1.3の重要なセキュリティ対策を意図的に無効にする派生プロトコルであるエンタープライズトランスポートセキュリティ（ETS）について懸念を表明した。[ 76 ]元々はエンタープライズTLS（eTLS）と呼ばれていたETSは、「ETSI TS103523-3」、「ミドルボックスセキュリティプロトコル、パート3：エンタープライズトランスポートセキュリティ」として知られる公開標準である。銀行システムなどの独自のネットワーク内でのみ使用することを意図している。ETSは前方秘匿性をサポートしていないため、独自のネットワークに接続されたサードパーティ組織が秘密鍵を使用してネットワークトラフィックを監視し、マルウェアを検出したり、監査を容易に実行したりすることができる。[ 77 ] [ 78 ]主張されている利点にもかかわらず、EFFは前方秘匿性の喪失によりデータが漏洩しやすくなる可能性があると警告し、トラフィックを分析するより良い方法があると述べた。[ 76 ]
デジタル証明書は、証明書に記載された主体が公開鍵を所有していることを証明し、その鍵の想定される使用方法を示します。これにより、他の者（依拠当事者）は、認証された公開鍵に対応する秘密鍵による署名や表明を信頼することができます。キーストアとトラストストアは、.pem、.crt、.pfx、.jksなど、さまざまな形式で保存できます。
TLS は通常、証明書の真正性を確立するために信頼できるサードパーティの認証局のセットに依存します。信頼は通常、ユーザーエージェントソフトウェアとともに配布される証明書のリストに基づいており、[ 79 ]依拠当事者によって変更される可能性があります。
アクティブなTLS証明書を監視しているNetcraftによると、市場をリードする認証局（CA）は、調査開始以来Symantec （またはSymantecが認証サービス事業部門を買収する前のVeriSign）である。Netcraftがカウントした2015年の時点で、Symantecは全証明書の3分の1弱、最もアクセス数の多い100万のWebサイトで使用されている有効な証明書の44%を占めていた。[ 80 ] 2017年、SymantecはTLS/SSL事業をDigiCertに売却した。[ 81 ]更新されたレポートでは、 2019年5月以降、 IdenTrust、DigiCert、Sectigoが市場シェアの点で上位3つの認証局であることが示された。 [ 82 ]
X.509証明書を選択する結果、証明書とその所有者との関係を検証し、証明書の有効性を生成、署名、管理するために、認証局と公開鍵基盤が必要になります。これは信頼のウェブを介してIDを検証するよりも便利かもしれませんが、2013年の大規模監視の暴露により、認証局がセキュリティの観点から弱点であり、認証局が協力（または侵害）した場合、中間者攻撃（MITM）を許してしまうことが広く知られるようになりました。[ 83 ] [ 84 ]
2025年4月11日、CA/Browser Forumは、すべての公開TLS証明書の有効期間を2029年までに47日間に段階的に短縮することを義務付ける投票を承認した。 [ 85 ]この投票はAppleによって提案された。[ 86 ]
クライアントとサーバーが 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) [ 34 ] 、事前共有鍵(TLS_PSK) [ 87 ]、セキュア リモート パスワード(TLS_SRP) [ 88 ]などがあります。
TLS_DH_anonとTLS_ECDH_anonの鍵合意方式は、サーバーまたはユーザーの認証を行わないため、中間者攻撃に対して脆弱であり、ほとんど使用されません。前方秘匿性を提供するのはTLS_DHEとTLS_ECDHEのみです。
交換/合意中に使用される公開鍵証明書は、交換中に使用される公開/秘密暗号鍵のサイズによっても異なり、したがって提供されるセキュリティの堅牢性も異なります。2013 年 7 月、Google は、暗号化の強度が鍵のサイズに直接関係するため、ユーザーに提供する TLS 暗号化のセキュリティを強化するために、1024 ビットの公開鍵の使用をやめ、代わりに 2048 ビットの鍵に切り替えると発表しました。[ 89 ] [ 90 ]
注記
データ整合性のためにメッセージ認証コード（MAC）が使用されます。ブロック暗号のCBCモードではHMACが使用されます。GCMやCCMモードなどの認証付き暗号化（AEAD）では、AEAD統合MACが使用され、 HMACは使用されません。[ 7 ]： §8.4 TLSハンドシェイクにはHMACベースのPRFまたはHKDFが使用されます。
アプリケーション設計において、TLSは通常、トランスポート層プロトコルの上に実装され、 HTTP、FTP、SMTP、NNTP、XMPPなどのプロトコルに関連するすべてのデータを暗号化します。
歴史的に、TLSは主に伝送制御プロトコル（TCP）などの信頼性の高いトランスポートプロトコルで使用されてきました。しかし、ユーザーデータグラムプロトコル（UDP）やデータグラム輻輳制御プロトコル（DCCP）などのデータグラム指向のトランスポートプロトコルでも実装されており、これらのプロトコルの使用はデータグラムトランスポート層セキュリティ（DTLS ）という用語を用いて独自に標準化されています。
TLSの主な用途は、HTTPプロトコルでエンコードされたWebサイトとWebブラウザ間のワールドワイドウェブトラフィックを保護することです。HTTPトラフィックを保護するためのこのTLSの使用は、 HTTPSプロトコルを構成します。[ 110 ]
注記
2025年3月現在 最新バージョンの主要なウェブブラウザはすべてTLS 1.2と1.3をサポートしており、 IE 11を除いてデフォルトで有効になっています。TLS 1.0と1.1は、最新バージョンの主要なブラウザすべてでデフォルトで無効になっています。
既知の攻撃に対する対策だけでは不十分である。
SSLおよびTLSプログラミングライブラリのほとんどは、無料のオープンソースソフトウェアです。
2012年のACMコンピュータおよび通信セキュリティ会議で発表された論文[ 115 ]では、多くのアプリケーションがこれらのSSLライブラリの一部を誤って使用し、脆弱性につながっていることが示されました。著者によると、次のとおりです。
「これらの脆弱性のほとんどの根本原因は、基盤となるSSLライブラリのAPIの設計が劣悪であることにある。これらのAPIは、機密性や認証といったネットワークトンネルの高度なセキュリティ特性を表現する代わりに、SSLプロトコルの低レベルな詳細をアプリケーション開発者に公開している。その結果、開発者はSSL APIを誤って使用し、その多様なパラメータ、オプション、副作用、戻り値を誤解してしまうことが多い。」
シンプルメール転送プロトコル（SMTP）もTLSで保護できます。これらのアプリケーションは公開鍵証明書を使用してエンドポイントの身元を確認します。
TLSは、ネットワークスタック全体をトンネル化してVPNを構築するためにも使用できます。これはOpenVPNやOpenConnectの場合に当てはまります。多くのベンダーは、TLSの暗号化および認証機能を認可機能と統合しています。また、1990年代後半以降、Webブラウザ以外のクライアント技術の開発も大幅に進み、クライアント/サーバーアプリケーションのサポートが可能になりました。従来のIPsec VPN技術と比較すると、TLSはファイアウォールやNATの通過においていくつかの固有の利点があり、大規模なリモートアクセス環境でも管理が容易です。
TLSは、セッション開始プロトコル（SIP）アプリケーションのシグナリングを保護するための標準的な方法でもあります。TLSは、 VoIPやその他のSIPベースのアプリケーションに関連付けられたSIPシグナリングの認証と暗号化を提供するために使用できます。[ 116 ]
TLS/SSLに対する主な攻撃事例を以下に示します。
2015年2月、IETFはTLS/SSLに対する既知の様々な攻撃をまとめた情報RFC [ 117 ]を発行した。
2009 年 8 月に、再ネゴシエーション手順の脆弱性が発見され、SSL 3.0 および現在のすべてのバージョンの TLS に対して平文挿入攻撃が可能になりました。[ 118 ]例えば、HTTPS接続を乗っ取った攻撃者が、クライアントと Web サーバー間の会話の冒頭に自身の要求を挿入することが可能になります。攻撃者はクライアントとサーバー間の通信を実際に復号化できないため、典型的な中間者攻撃とは異なります。短期的な対策としては、Web サーバーが再ネゴシエーションを許可しないようにすることです。通常、クライアント証明書認証を使用しない限り、他の変更は必要ありません。この脆弱性を修正するために、TLS の再ネゴシエーション表示拡張機能が提案されました。[ 119 ]これにより、クライアントとサーバーは、再ネゴシエーションのハンドシェイクに以前のハンドシェイクに関する情報を含めて検証する必要があります。[ 120 ]この拡張機能は、いくつかのライブラリで実装されています。[ 121 ] [ 122 ] [ 123 ]
プロトコルのダウングレード攻撃（バージョンロールバック攻撃とも呼ばれる）は、ウェブサーバーをだまして、すでに安全性が低いとして廃止されているTLSの以前のバージョン（SSLv2など）との接続を確立させる攻撃です。
False Start [ 124 ] (Google Chrome [ 125 ]で採用され有効化されている) やSnap Startなど、元のプロトコルに対する以前の変更では、限定的な TLS プロトコルのダウングレード攻撃[ 126 ]が導入されたり、クライアントからサーバーに送信される暗号スイート リストの変更が可能になったりしたと報告されている。その際、攻撃者は、より弱い対称暗号化アルゴリズムまたはより弱い鍵交換を使用するようにネゴシエートされた暗号スイートをダウングレードしようとして、暗号スイートの選択に影響を与えることに成功する可能性がある。[ 127 ] 2012 年にACM のコンピュータおよび通信セキュリティに関する会議で発表された論文では、False Start 拡張機能にリスクがあることが実証された。特定の状況下では、攻撃者がオフラインで暗号化キーを復元し、暗号化されたデータにアクセスできるようになる可能性がある。[ 128 ]
暗号化ダウングレード攻撃は、サーバーとクライアントに暗号的に弱い鍵を使用して接続をネゴシエートさせる可能性があります。2014年に、OpenSSLスタック、デフォルトのAndroidウェブブラウザ、および一部のSafariブラウザに影響を与えるFREAKと呼ばれる中間者攻撃が発見されました。[ 129 ]この攻撃は、サーバーをだまして、暗号的に弱い512ビットの暗号化鍵を使用してTLS接続をネゴシエートさせるものでした。
Logjamは、1990年代に遡る旧式の「輸出グレード」 512ビットDiffie-Hellmanグループを使用するオプションを悪用する、2015年5月に発見されたセキュリティエクスプロイトです。 [ 130 ]この脆弱性により、脆弱なサーバーは暗号的に弱い512ビットDiffie-Hellmanグループにダウングレードせざるを得なくなります。攻撃者は、 Diffie-Hellman鍵交換を使用してクライアントとサーバーが決定する鍵を推測することができます。
DROWN攻撃は、最新のSSL/TLSプロトコルスイートをサポートするサーバーを攻撃するエクスプロイトであり、古い安全性の低いSSLv2プロトコルのサポートを悪用して、本来安全であるはずの最新プロトコルを使用する接続を攻撃します。[ 131 ] [ 132 ] DROWNは、特定の実装エラーではなく、使用されているプロトコルとサーバー構成の脆弱性を悪用します。DROWNの詳細は、エクスプロイトに対するパッチとともに2016年3月に発表されました。当時、最も人気のある上位100万のWebサイトのうち81,000以上が、TLSで保護されたWebサイトであり、DROWN攻撃に対して脆弱でした。[ 132 ]
2011年9月23日、研究者のThai DuongとJuliano Rizzoは、Javaアプレットを使用して同一オリジンポリシーの制約を破るBEAST（Browser Exploit Against SSL/TLS）[ 133 ]と呼ばれる概念実証を実証しました。これはTLS 1.0の長年知られている暗号ブロック連鎖（CBC）の脆弱性に対するものです。 [ 134 ] [ 135 ]連続する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年にフィリップ・ロガウェイ[ 136 ]によって最初に発見されたもので、これまで実用的な悪用例は示されていませんでした。この攻撃の脆弱性は2006年にTLS 1.1で修正されましたが、TLS 1.1はこの攻撃の実証以前には広く普及していませんでした。
ストリーム暗号としてのRC4はBEAST攻撃に対して耐性があります。そのため、RC4はサーバー側でBEAST攻撃を軽減する方法として広く使用されていました。しかし、2013年に研究者たちはRC4のさらなる脆弱性を発見しました。それ以降、サーバー側でRC4を有効にすることは推奨されなくなりました。[ 137 ]
ChromeとFirefox自体はBEAST攻撃に対して脆弱ではありませんが[ 138 ] [ 139 ]、MozillaはBEASTのような攻撃を軽減するためにNSSライブラリを更新しました。NSSはMozilla FirefoxとGoogle ChromeでSSLを実装するために使用されています。SSL仕様の実装に欠陥のある一部のWebサーバーは、その結果動作しなくなる可能性があります。[ 140 ]
Microsoft は2012 年 1 月 10 日にセキュリティ情報 MS12-006 を公開し、Windows セキュア チャネル ( Schannel ) コンポーネントがサーバー側から暗号化されたネットワーク パケットを送信する方法を変更することで BEAST の脆弱性を修正しました。[ 141 ]古いバージョンの 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脆弱性を軽減しました。[ 142 ]
BEAST攻撃の作者は、後にCRIME攻撃も考案しており、この攻撃では、TLSとデータ圧縮が併用されている場合に、攻撃者がWebクッキーの内容を復元することが可能になります。[ 143 ] [ 144 ]秘密認証クッキーの内容を復元するために使用すると、攻撃者は認証済みのWebセッションでセッションハイジャックを実行できます。
CRIME攻撃は、TLSを含む多数のプロトコル、およびSPDYやHTTPなどのアプリケーション層プロトコルに対して効果的に機能する一般的な攻撃として提示されましたが、TLSとSPDYに対するエクスプロイトのみが実証され、ブラウザとサーバーで大部分が軽減されました。CRIMEの作者は、この脆弱性がSPDYとTLSの圧縮を合わせたものよりもさらに広範囲に及ぶ可能性があると警告しているにもかかわらず、 HTTP圧縮に対するCRIMEエクスプロイトは全く軽減されていません。2013年に、HTTP圧縮に対するCRIME攻撃の新たな事例であるBREACHが発表されました。CRIME攻撃に基づくBREACH攻撃は、攻撃者が被害者を悪意のあるWebリンクに誘導するか、ユーザーがアクセスしている有効なページにコンテンツを挿入できる場合（例：攻撃者が制御する無線ネットワーク）、TLSで暗号化されたWebトラフィックからログイントークン、電子メールアドレス、またはその他の機密情報をわずか30秒（抽出するバイト数による）で抽出できます。[ 145 ] TLS および SSL のすべてのバージョンは、使用されている暗号化アルゴリズムや暗号に関係なく、BREACH の危険にさらされています。[ 146 ] TLS 圧縮または SPDY ヘッダー圧縮を無効にすることで効果的に防御できる以前の CRIME の事例とは異なり、BREACH は HTTP 圧縮を悪用しますが、事実上すべての Web サーバーがユーザーのデータ伝送速度を向上させるために HTTP 圧縮に依存しているため、現実的に無効にすることはできません。[ 145 ]これは、TLS が保護することを意図していたアプリケーション層データに対する選択平文攻撃に対して脆弱であるため、TLS の既知の制限です。
以前のTLSバージョンは、 2002年に発見されたパディングオラクル攻撃に対して脆弱だった。2013年には、ラッキーサーティーン攻撃と呼ばれる新たな亜種が発表された。
一部の専門家[ 106 ]は、トリプルDES CBCの使用を避けることを推奨しています。Windows XPのSSL/TLSライブラリを使用するプログラム（Windows XP上のInternet Explorerなど）をサポートするために開発された最後のサポート暗号はRC4とトリプルDESであり、RC4は現在非推奨となっているため（ RC4攻撃に関する議論を参照）、XP上でこのライブラリを使用するプログラムでSSLのどのバージョンもサポートすることが困難になっています。
2014年にTLS仕様のEncrypt-then-MAC拡張機能として修正がリリースされました。[ 147 ] Lucky Thirteen攻撃は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）と名付けた。平均して、攻撃者は暗号化されたメッセージの1バイトを明らかにするために、わずか256回のSSL 3.0リクエストを行うだけでよい。[ 113 ]
この脆弱性は SSL 3.0 にのみ存在し、ほとんどのクライアントとサーバーは TLS 1.0 以上をサポートしていますが、主要なブラウザはすべて、ユーザーまたは管理者が SSL 3.0 を無効にするオプションを提供し、ユーザーまたは管理者がそれを行わない限り、新しいバージョンの TLS とのハンドシェイクが失敗した場合に、自主的に SSL 3.0 にダウングレードします。したがって、中間者はまずバージョンロールバック攻撃を実行し、次にこの脆弱性を悪用することができます。[ 113 ]
2014年12月8日、パディングバイト要件を適切に強制しないTLS実装に影響を与えるPOODLEの亜種が発表されました。[ 148 ]
RC4のセキュリティを破る攻撃が存在するにもかかわらず、SSL および TLS で使用されている方法に基づいて、RC4 に基づく SSL および TLS の暗号スイートは 2013 年以前は依然として安全であると考えられていました。2011 年に、RC4 スイートは実際にBEAST攻撃の回避策として推奨されました。[ 149 ] 2013 年 3 月に明らかにされた新しい攻撃形式は、TLS で RC4 を破ることが可能であることを決定的に示し、BEAST の適切な回避策ではないことを示唆しました。[ 112 ] AlFardan、Bernstein、Paterson、Poettering、および Schuldt は、RC4 キー テーブルで新たに発見された統計的バイアスを使用して、多数の TLS 暗号化で平文の一部を復元する攻撃シナリオを提案しました。 [ 150 ] [ 151 ] [ 152 ] RC4 を破るために13 × 2 20 回の暗号化を必要とする TLS および SSL の RC4 に対する攻撃が2013 年 7 月 8 日に明らかにされ、その後 2013 年 8 月にUSENIXセキュリティ シンポジウムで行われた付随のプレゼンテーションで「実行可能」と説明されました。 [ 153 ] [ 154 ] 2015 年 7 月、この攻撃のその後の改良により、RC4 で暗号化された TLS のセキュリティを破ることがますます現実的になりました。[ 155 ]
多くの最新のブラウザは BEAST 攻撃に対抗するように設計されているため (Mac OS X 10.7 以前、iOS 6 以前、および Windows 用の Safari を除く。§ Web ブラウザを参照 )、RC4 は TLS 1.0 にはもはや適していません。過去に BEAST 攻撃の影響を受けていた CBC 暗号は、保護のためのより一般的な選択肢となっています。[ 106 ] Mozilla と Microsoft は、可能な限り RC4 を無効にすることを推奨しています。[ 156 ] [ 157 ] 2015 年 2 月に、すべてのバージョンの TLS で RC4 暗号スイートの使用が正式に禁止されました。[ 109 ]
2015年9月1日、Microsoft、Google、Mozillaは、2016年初頭にRC4暗号スイートをブラウザ（Microsoft Edge [Legacy]、Windows 7/8.1/10上のInternet Explorer 11 、 Firefox、Chrome ）でデフォルトで無効にすると発表した。 [ 158 ] [ 159 ] [ 160 ]
TLS (ログアウト) トランケーション攻撃は、被害者のアカウントのログアウト要求をブロックし、ユーザーが知らず知らずのうちにウェブサービスにログインしたままになるようにします。ログアウト要求が送信されると、攻撃者は暗号化されていないTCP FIN メッセージ (送信者からのデータはありません) を挿入して接続を閉じます。そのため、サーバーはログアウト要求を受信せず、異常終了に気づきません。[ 161 ]
2013 年 7 月に公開された[ 162 ] [ 163 ]この攻撃は、 GmailやHotmailなどの Web サービスで、ユーザーが正常にログアウトしたことを通知するページを表示させ、ユーザーのブラウザがサービスとの認証を維持するようにすることで、その後ブラウザにアクセスできる攻撃者がユーザーのログイン済みアカウントにアクセスして制御を奪取できるようにします。この攻撃は、被害者のコンピュータにマルウェアをインストールすることに依存していません。攻撃者は、被害者と Web サーバーの間に自身を配置するだけで済みます (たとえば、不正なワイヤレス ホットスポットを設定することによって)。[ 161 ]この脆弱性には、被害者のコンピュータへのアクセスも必要です。別の可能性としては、FTP を使用している場合、データ接続のデータ ストリームに偽の FIN が含まれる可能性があり、close_notify アラートを交換するためのプロトコル ルールが遵守されていない場合、ファイルが切り詰められる可能性があります。
2013年2月、ロンドン大学ロイヤルホロウェイ校の2人の研究者が、暗号ブロック連鎖モード暗号化が使用されている場合、OpenSSLまたはGnuTLSのDTLS実装を使用したDTLS接続から平文（の一部）を復元できるタイミング攻撃[164]を発見しました。
2016 年半ばに発見されたこの攻撃は、Web Proxy Autodiscovery Protocol (WPAD) の脆弱性を悪用して、TLS が有効になっている Web リンクを介して Web ユーザーがアクセスしようとしている URL を公開します。[ 165 ] URL の開示は、アクセスした Web サイトだけでなく、URL がユーザー認証に使用される場合もあるため、ユーザーのプライバシーを侵害する可能性があります。Google や Dropbox などが提供するドキュメント共有サービスも、URL に含まれるセキュリティ トークンをユーザーに送信することで機能します。このような URL を入手した攻撃者は、被害者のアカウントやデータに完全にアクセスできるようになる可能性があります。
この脆弱性は、ほぼすべてのブラウザとオペレーティングシステムに対して有効です。
Sweet32攻撃は、誕生日攻撃と中間者攻撃または悪意のあるJavaScriptのWebページへの挿入のいずれかを悪用することにより、TLSで使用されるCBCモードで使用されるすべての64ビットブロック暗号を破ります。中間者攻撃またはJavaScript挿入の目的は、攻撃者が誕生日攻撃を実行するのに十分なトラフィックを傍受できるようにすることです。[ 166 ]
Heartbleedバグは、広く使われているOpenSSL暗号化ソフトウェア ライブラリの SSL/TLS 実装に特有の深刻な脆弱性で、バージョン 1.0.1 から 1.0.1f に影響します。2014 年 4 月に報告されたこの脆弱性により、攻撃者は通常は保護されているはずのサーバーから秘密鍵を抽出できます。 [ 167 ] Heartbleed バグにより、インターネット上の誰でも、脆弱なバージョンの OpenSSL ソフトウェアで保護されているシステムのメモリを読み取ることができます。これにより、サービス プロバイダを識別し、トラフィックを暗号化するために使用される公開証明書に関連付けられた秘密鍵、ユーザーの名前とパスワード、および実際のコンテンツが危険にさらされます。これにより、攻撃者は通信を盗聴し、サービスやユーザーから直接データを抽出し、サービスやユーザーになりすますことができます。[ 168 ]この脆弱性は、SSL または TLS プロトコル仕様の欠陥ではなく、OpenSSL ソフトウェアのバッファ オーバー リードバグによって引き起こされます。
2014年9月、Intel Security Advanced Threat Researchは、 Daniel BleichenbacherのPKCS#1 v1.5 RSA署名偽造の脆弱性[ 169 ]の亜種を発表しました。BERserkと呼ばれるこの攻撃は、一部のSSL実装における公開鍵署名のASN.1長さデコードが不完全であることに起因し、公開鍵署名を偽造することで中間者攻撃を可能にします。[ 170 ]
2015 年 2 月、メディアが一部の Lenovo ノートブックにSuperfishアドウェアが隠されてプリインストールされていることを報じた後、 [ 171 ]ある研究者が、影響を受けた Lenovo マシンの信頼できるルート証明書が安全ではないことを発見しました。これは、パスフレーズとして会社名 Komodia を使用してキーに簡単にアクセスできたためです。[ 172 ] Komodia ライブラリは、ペアレンタル コントロールと監視のためにクライアント側の TLS/SSL トラフィックを傍受するように設計されていましたが、Superfish を含む多数のアドウェア プログラムでも使用されており、多くの場合、コンピュータ ユーザーに知られることなく密かにインストールされていました。その結果、これらの潜在的に不要なプログラムが不正なルート証明書をインストールし、攻撃者が Web トラフィックを完全に制御して偽の Web サイトを本物として確認できるようにしました。
2016年5月、 Visa Inc.が所有する数十のデンマークのHTTPS保護されたウェブサイトが、ハッカーが訪問者のブラウザに悪意のあるコードや偽造コンテンツを注入できる攻撃に対して脆弱であることが報告された。[ 173 ]この攻撃が成功したのは、影響を受けたサーバーで使用されていたTLS実装が、各TLSハンドシェイクが一意であることを保証するために一度だけ使用されることを意図した乱数（ nonce ）を誤って再利用していたためである。[ 173 ]
2017年2月、HTML解析に使用されるコード内の1文字の入力ミスによる実装エラーにより、Cloudflareサーバーでバッファオーバーフローエラーが発生しました。2014年に発見されたHeartbleedバグと同様の影響を持つこのオーバーフローエラーは、Cloudbleedとして広く知られており、権限のない第三者がサーバー上で実行されているプログラムのメモリ内のデータを読み取ることを可能にしました。このデータは、本来TLSによって保護されているはずでした。[ 174 ]
2025年6月現在 トラストワージー・インターネット・ムーブメントは、TLS攻撃に対して脆弱なウェブサイトの割合を推定した。[ 111 ]
前方秘匿性とは、公開鍵と秘密鍵のセットから派生したセッション鍵が、将来いずれかの秘密鍵が漏洩した場合でも漏洩しないことを保証する暗号システムの特性です。[ 175 ]前方秘匿性がない場合、サーバーの秘密鍵が漏洩すると、そのサーバー証明書を使用する将来のすべてのTLS暗号化セッションが漏洩するだけでなく、過去にそのサーバー証明書を使用したセッションも漏洩します（ただし、これらの過去のセッションが送信時に傍受され保存されていた場合に限ります）。[ 176 ] TLSの実装では、セッション鍵を確立するために一時的なDiffie-Hellman鍵交換の使用を要求することで前方秘匿性を提供できます。注目すべきTLS実装の中には、GmailやOpenSSLを使用するその他のGoogle HTTPSサービスのように、この方法のみを使用するものもあります。[ 177 ]しかし、TLSをサポートする多くのクライアントやサーバー（ブラウザやWebサーバーを含む）は、このような制限を実装するように構成されていません。[ 178 ] [ 179 ]実際には、ウェブサービスが前方秘匿性を実装するためにディフィー・ヘルマン鍵交換を使用しない限り、第三者がサーバーのマスター（秘密）鍵を入手すれば、そのサービスとの間の暗号化されたウェブトラフィックはすべて復号化される可能性があります。たとえば、裁判所命令によって入手できます。[ 180 ]
Diffie–Hellman 鍵交換が実装されている場合でも、サーバー側のセッション管理メカニズムが前方秘匿性に影響を与える可能性があります。TLSセッション チケット(TLS 拡張機能) を使用すると、前方秘匿性暗号スイートを含む他のネゴシエートされた TLS パラメータに関係なく、セッションは AES128-CBC-SHA256 で保護され、TLS セッション チケットのキーの有効期限が長いため、前方秘匿性を実装しようとする試みが失敗します。[ 181 ] [ 182 ] [ 183 ] 2014 年のスタンフォード大学の研究でも、調査した 473,802 台の TLS サーバーのうち、前方秘匿性をサポートするために一時的な Diffie–Hellman (DHE) 鍵交換を導入しているサーバーの 82.9% が弱い Diffie–Hellman パラメータを使用していることがわかりました。これらの弱いパラメータの選択は、サーバーが提供しようとしている前方秘匿性の有効性を損なう可能性があります。[ 184 ]
2011年後半以降、GoogleはGmailサービス、Googleドキュメント、暗号化検索などのサービスにおいて、 TLSによる前方秘匿性をデフォルトでユーザーに提供している。 [ 185 ] 2013年11月以降、Twitterは自社サービスのユーザーにTLSによる前方秘匿性を提供している。[ 186 ] 2019年8月現在 TLS対応ウェブサイトの約80%は、ほとんどのウェブブラウザに対して前方秘匿性を提供する暗号スイートを使用するように構成されています。[ 111 ]
TLS傍受（またはHTTPS傍受、特にHTTPSプロトコルに適用される場合）とは、暗号化されたデータストリームを傍受して復号化し、読み取り、場合によっては操作し、その後再び暗号化してデータを送信する行為です。これは「透過プロキシ」を介して行われます。傍受ソフトウェアは、受信したTLS接続を終了し、HTTPプレーンテキストを検査し、宛先への新しいTLS接続を作成します。[ 187 ]
TLS/HTTPS の傍受は、ネットワーク事業者がコンピュータウイルスやその他のマルウェアなどの悪意のあるコンテンツがネットワークに侵入するのをスキャンして防ぐための情報セキュリティ対策として使用されています。[ 187 ]このようなコンテンツは、暗号化によって保護されている限り、そうでなければ検出できません。HTTPS やその他の安全なプロトコルが日常的に使用されるようになった結果、暗号化されているケースが増えています。
TLS/HTTPS傍受の重大な欠点は、それ自体が新たなセキュリティリスクをもたらすことです。注目すべき制限の1つは、ネットワークトラフィックが暗号化されずに利用できるポイントを提供してしまうため、攻撃者が本来安全なコンテンツにアクセスするために、特にこのポイントを攻撃する動機を与えてしまうことです。傍受によって、ネットワークオペレーター、または傍受システムへのアクセス権を得た人物が、ネットワークユーザーに対して中間者攻撃を実行できるようになります。2017年の調査では、「HTTPS傍受は驚くほど広まっており、傍受製品全体として接続セキュリティに劇的な悪影響を及ぼしている」ことが判明しました。[ 187 ]
TLSプロトコルは、交換するデータを特定の形式（下記参照）でカプセル化したレコードを交換します。各レコードは、接続の状態に応じて、圧縮、パディング、メッセージ認証コード（MAC）の追加、または暗号化が可能です。各レコードには、カプセル化されたデータの種類を示すコンテンツタイプフィールド、長さフィールド、およびTLSバージョンフィールドがあります。カプセル化されたデータは、TLS自体の制御メッセージまたは手続きメッセージ、あるいはTLSで転送する必要のあるアプリケーションデータである場合があります。TLSでアプリケーションデータを交換するために必要な仕様（暗号スイート、鍵など）は、データを要求するクライアントと要求に応答するサーバー間の「TLSハンドシェイク」で合意されます。したがって、このプロトコルは、TLSで転送されるペイロードの構造と、転送を確立および監視する手順の両方を定義します。
接続が開始されると、レコードには「制御」プロトコル、すなわちハンドシェイクメッセージングプロトコル（コンテンツタイプ22）がカプセル化されます。このプロトコルは、TLSによる実際のアプリケーションデータの交換に必要なすべての情報を両者間で交換するために使用されます。メッセージのフォーマットと交換順序が定義されます。これらはクライアントとサーバーの要求に応じて異なる場合があり、つまり、接続を確立するための手順は複数存在します。この最初の交換の結果、TLS接続が成功する（両者ともTLSを使用してアプリケーションデータを転送する準備が整う）か、または（以下に説明するように）警告メッセージが送信されます。
典型的な接続例を以下に示します。これは、サーバー（クライアントではない）が証明書によって認証されるハンドシェイクを示しています。
以下の完全な例では、クライアントが（上記の例のようにサーバーに加えて）TLSを介して認証され、両方のピア間で証明書が交換される様子を示しています。相互認証を参照してください。
公開鍵暗号（RSAなど）は、計算能力の面で比較的コストがかかります。TLSは、これらの操作を回避するための安全なショートカットとして、ハンドシェイクメカニズムに再開セッションを提供します。再開セッションは、セッションIDまたはセッションチケットを使用して実装されます。
パフォーマンス上の利点に加えて、再開されたセッションは、元のセッションと再開されたセッションの両方が同じクライアントから発信されていることを保証するため、シングルサインオンにも使用できます。これは、 TLS/SSLプロトコル上の FTP にとって特に重要です。そうでなければ、攻撃者が二次データ接続の内容を傍受できる中間者攻撃の被害を受ける可能性があります。[ 190 ]
TLS 1.3のハンドシェイクは、以前のバージョンのTLS/SSLで必要だった2回の往復通信に比べて、わずか1回の往復通信に短縮されました。
ハンドシェイクを開始するには、クライアントはサーバーがどの鍵交換アルゴリズムを選択するかを推測し、サポートされている暗号のリスト（クライアントの優先順位順）と、推測した鍵交換アルゴリズムの一部またはすべての公開鍵を含むClientHelloメッセージをサーバーに送信します。クライアントが鍵交換アルゴリズムを正しく推測した場合、ハンドシェイクから 1 ラウンドトリップが省略されます。ClientHello を受信したサーバーは、暗号を選択し、自身の公開鍵を含むServerHello を返信し、続いてサーバー証明書とFinishedメッセージを送信します。[ 191 ]
クライアントがサーバーから完成したメッセージを受信した後、どの暗号スイートを使用するかについてサーバーと調整が行われます。[ 192 ]
通常の完全なハンドシェイクでは、サーバーはServerHelloメッセージの一部としてセッション IDを送信します。クライアントはこのセッション ID をサーバーの IP アドレスと TCP ポートに関連付け、クライアントがそのサーバーに再度接続する際に、セッション IDを使用してハンドシェイクを短縮できるようにします。サーバー側では、セッション ID は以前にネゴシエートされた暗号化パラメータ、具体的には「マスター シークレット」にマッピングされます。両者が同じ「マスター シークレット」を持っている必要があり、そうでない場合は再開されたハンドシェイクは失敗します (これにより、盗聴者がセッション IDを使用することを防ぎます)。ClientHelloメッセージとServerHelloメッセージに含まれるランダムなデータは、生成される接続キーが以前の接続とは異なることをほぼ保証します。RFC では、このタイプのハンドシェイクは短縮ハンドシェイクと呼ばれています。文献では、再開ハンドシェイクとも呼ばれています。
セッションIDの代わりに、TLSはセッションチケットを使用して拡張することもできます。[ 193 ]これは、セッション固有の状態をTLSサーバーに保存する必要なくTLSセッションを再開する方法を定義します。
セッションチケットを使用する場合、TLSサーバーはセッション固有の状態をセッションチケットに保存し、そのセッションチケットをTLSクライアントに送信して保存させます。クライアントはセッションチケットをサーバーに送信することでTLSセッションを再開し、サーバーはチケット内のセッション固有の状態に基づいてTLSセッションを再開します。セッションチケットはサーバーによって暗号化および認証され、サーバーはその内容を使用する前に有効性を検証します。
OpenSSLを使用したこの方法の特に弱い点の 1 つは、AES128-CBC-SHA256実際の TLS セッションでネゴシエートされた他の TLS パラメータに関係なく、送信される TLS セッション チケットの暗号化と認証のセキュリティが常に に制限されることです。 [ 182 ]これは、状態情報 (TLS セッション チケット) が TLS セッション自体ほど保護されていないことを意味します。特に懸念されるのは、OpenSSL がアプリケーション全体のコンテキスト ( SSL_CTX) に鍵を保存していること、つまりアプリケーションのライフサイクル全体にわたって保存され、アプリケーション全体の OpenSSL コンテキストをリセットせずに TLS セッション チケットの鍵の再生成を許可しないことですAES128-CBC-SHA256(これはまれで、エラーが発生しやすく、多くの場合、手動による管理介入が必要です)。[ 183 ] [ 181 ]
これは、すべてのTLSレコードの一般的な形式です。
すべての暗号アルゴリズムとパラメータがネゴシエートされ、ハンドシェイクが完了し、その後、同じピアから送信される以降のすべてのレコードでこれらのパラメータが有効になることを示すために CipherStateChange レコード (下記参照) を送信して確認されるまでは、TLS レコードの末尾に MAC フィールドまたはパディング フィールドが存在することはできません。
TLSセッションのセットアップ中に交換されるメッセージのほとんどは、このレコードに基づいています。ただし、エラーや警告が発生してアラートプロトコルレコードで通知する必要がある場合（下記参照）、またはセッションの暗号化モードが別のレコードによって変更される場合（下記のChangeCipherSpecプロトコル参照）は除きます。
複数のハンドシェイクメッセージが1つのレコードにまとめられる場合があることに注意してください。
このレコードは通常、通常のハンドシェイクやアプリケーション間の通信中に送信すべきではありません。ただし、このメッセージはハンドシェイク中、セッションが終了するまでの間であればいつでも送信できます。致命的なエラーを通知するためにこのレコードが使用される場合、このレコードの送信後すぐにセッションが閉じられるため、このレコードはセッション終了の理由を示すために使用されます。アラートレベルが警告としてフラグ付けされている場合、リモートは、セッションが自身のニーズを満たすほど信頼できないと判断した場合、セッションを閉じることができます（その前に、リモートは独自のシグナルを送信することもあります）。
アプリケーションプロトコルの観点から見ると、TLSは下位層に属しますが、TCP/IPモデルではそれを表現するには粗すぎるため、ここでは扱いません。つまり、TLSハンドシェイクは通常（STARTTLSの場合を除いて）、アプリケーションプロトコルが開始する前に実行されます。アプリケーション層が提供する名前ベースの仮想サーバー機能では、サーバーがClientHelloメッセージの直後に証明書を選択して送信する必要があるため、すべての共存仮想サーバーが同じ証明書を共有します。これは、すべての顧客間で同じ証明書を共有するか、顧客ごとに異なるIPアドレスを使用するかのどちらかを選択する必要があるため、ホスティング環境では大きな問題となります。
X.509には、既知の回避策が2つあります。
サーバー名を提供するために、トランスポート層セキュリティ（TLS）拡張機能により、クライアントは拡張された ClientHello メッセージにサーバー名表示拡張機能（SNI）を含めることができます。 [ 196 ]： §3この拡張機能は、クライアントが接続したい名前をサーバーに即座に示唆するため、サーバーはクライアントに送信する適切な証明書を選択できます。
HTTP/1.1 Upgrade ヘッダーを使用して HTTP を TLS にアップグレードすることで、名前ベースの仮想ホスティングを実装する方法もあります。[ 2 ]通常、これは一般的に使用されている「https」スキームではなく、メインの「http」 URI スキーム内で HTTP over TLS を安全に実装するためのものです。これにより、URI 空間のフォークが回避され、使用されるポートの数が削減されますが、現在これをサポートしている実装はほとんどありません。
現在承認されている(D)TLSのバージョンはバージョン1.3であり、これは以下で規定されています。
現在の規格は、以下の旧バージョンに取って代わるものです。
その後、他のRFCによって(D)TLSが拡張されました。
(D)TLS 1.3の拡張機能には以下が含まれます。
(D)TLS 1.2の拡張機能には以下が含まれます。
(D)TLS 1.1の拡張機能には以下が含まれます。
TLS 1.0の拡張機能には以下が含まれます。
{{cite web}}: CS1 maint: タイトルとしてアーカイブされたコピー (リンク)RC4に対する平文復元攻撃は、現実的ではないものの、実行可能である。