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 1.3では、前方秘匿性を提供する鍵交換アルゴリズムのみが使用可能であることに注意してください。したがって、サーバーの公開鍵と秘密鍵を使用してPreMasterSecretを確立できるのは、TLS 1.2以前のバージョンのみです。
TLSとSSLは、 OSIモデルやTCP/IPモデルのいずれの単一層にもきれいに収まりません。[ 4 ] [ 5 ] TLSは「何らかの信頼性の高いトランスポートプロトコル（ TCPなど）の上」で動作します[ 6 ] : §1 。これは、TLSがトランスポート層よりも上位にあることを意味します。TLSは上位層に暗号化を提供しますが、これは通常プレゼンテーション層の機能です。しかし、アプリケーションは一般的にTLSをトランスポート層であるかのように使用します[ 4 ] [ 5 ] 。ただし、TLSを使用するアプリケーションは、TLSハンドシェイクの開始と交換される認証証明書の処理を積極的に制御する必要があります[ 6 ] : §1。
TLSで保護されている場合、クライアント（例：Webブラウザ）とサーバー（例：wikipedia.org）間の接続は、以下のすべての特性を持ちます。[ 6 ]： §1
TLSは、鍵の交換、データの暗号化、メッセージの完全性の認証に関して、さまざまな方法をサポートしています。そのため、TLSの安全な構成には多くの設定可能なパラメータが関係し、すべての選択肢が上記のリストに記載されているプライバシー関連の特性をすべて提供するわけではありません（以下の表「 鍵交換」、「 暗号のセキュリティ」、「 データの完全性」を参照してください）。
TLSが提供しようとする通信セキュリティの側面を侵害しようとする試みがなされており、これらのセキュリティ上の脅威に対処するためにプロトコルは何度か改訂されてきました。ウェブブラウザの開発者は、潜在的なセキュリティ上の脆弱性が発見されるたびに、それらから保護するために製品を繰り返し改訂してきました（ウェブブラウザのTLS/SSLサポートの歴史を参照）。
データグラムトランスポート層セキュリティ（DTLSと略される）は、盗聴、改ざん、またはメッセージの偽造を防止するように設計された方法で通信できるようにすることで、データグラムベースのアプリケーションにセキュリティを提供する関連通信プロトコルです[ 7 ] [ 8 ]。DTLSプロトコルは、ストリーム指向のトランスポート層セキュリティ（TLS）プロトコルに基づいており、同様のセキュリティ保証を提供することを目的としています。ただし、TLSとは異なり、ユーザーデータグラムプロトコル（UDP）、データグラム輻輳制御プロトコル（DCCP）、無線アクセスポイントの制御とプロビジョニング（CAPWAP）、ストリーム制御伝送プロトコル（SCTP）カプセル化、セキュアリアルタイムトランスポートプロトコル（SRTP）など、ほとんどのデータグラム指向プロトコルで使用できます。
DTLSプロトコルのデータグラムは基盤となるトランスポートのセマンティクスを保持するため、アプリケーションはストリームプロトコルに関連する遅延の影響を受けません。ただし、アプリケーションはパケットの順序変更、データグラムの損失、およびデータグラムネットワークパケットのサイズを超えるデータに対処する必要があります。DTLSはTCPではなくUDPまたはSCTPを使用するため、 VPNトンネルを作成する際に使用されるTCPメルトダウン問題を回避します[ 9 ] [ 10 ]。
2006年に最初にリリースされたDTLSバージョン1.0は、単独の文書ではありませんでした。TLS 1.1への一連の差分として提供されました。[ 7 ] : §4同様に、2012年にリリースされたDTLSはTLS 1.2への差分です。TLSバージョンに合わせて、DTLS 1.2というバージョン番号が付けられました。最後に、2022年のDTLS 1.3はTLS 1.3への差分です。以前の2つのバージョンと同様に、DTLS 1.3は「順序保護/非リプレイ性を除いて[TLS 1.3と同等のセキュリティ保証」を提供することを目的としています。[ 11 ]
Cisco AnyConnect [ 12 ]や InterCloud Fabric [ 13 ] 、 OpenConnect [ 14 ]、ZScalerトンネル[ 15 ] 、 F5 Networks Edge VPN Client [ 16 ]、Citrix Systems NetScaler [ 17 ]など、多くのVPN クライアントはDTLS を使用して UDP トラフィックを保護しています。さらに、最新の Web ブラウザはすべてWebRTC用のDTLS-SRTP [ 18 ]をサポートしています。
将来の量子コンピュータによる「今すぐ収集して後で復号する」攻撃から保護するために、TLS 1.3 にはハイブリッドポスト量子鍵合意スキームが導入されています。これらは、古典的なECDHE交換と、2024 年 8 月にNISTによってFIPS 203 として標準化された格子ベースの鍵カプセル化メカニズムであるML-KEMを組み合わせたものです。 [ 19 ] IETF TLS ワーキンググループは、インターネット ドラフトでハイブリッド グループ X25519MLKEM768、SecP256r1MLKEM768、SecP384r1MLKEM1024 を定義しており、[ 20 ] TLS 1.3 のハイブリッド鍵交換の一般的なフレームワーク[ 21 ]とスタンドアロン (非ハイブリッド) ML-KEM 鍵合意の仕様も定義しています。[ 22 ]
X25519MLKEM768（およびその前身であるX25519Kyber768）は、Google Chromeではバージョン131（2024年11月）以降[ 23 ]、Firefoxではバージョン132以降[ 24 ]でデフォルトで有効になっており、 OpenSSL 3.5 [ 25 ] 、 BoringSSL、Cloudflare [ 26 ]などのサーバーサイド実装でサポートされています。
1986年8月、国家安全保障局、国立標準局、国防通信局は、公共および民間インターネット上のアプリケーションに実装される次世代のセキュアコンピュータ通信ネットワークと製品仕様を設計することを目的として、セキュアデータネットワークシステム（SDNS）と呼ばれるプロジェクトを開始しました。これは、米国政府のGOSIPプロファイルと国際的な大規模なITU-ISO JTC1インターネット活動の両方で急速に出現している新しいOSIインターネット標準を補完することを意図していました。[ 36 ]
このプロジェクトの一環として、研究者たちは SP4 ( OSI システムのレイヤー 4 のセキュリティ プロトコル)と呼ばれるプロトコルを設計しました。これは後にトランスポート レイヤー セキュリティ プロトコル (TLSP) と改名され、1995 年に国際標準 ITU-T X.274|ISO/IEC 10736:1995 として公開されました。 [ 37 ]名前は似ていますが、これは今日の TLS とは異なります。
トランスポート層のセキュリティに向けたその他の取り組みとしては、セキュア ネットワーク プログラミング(SNP)アプリケーション プログラミング インターフェイス(API) があり、1993 年に、既存のネットワーク アプリケーションにセキュリティ対策を後付けしやすくするために、バークレー ソケットによく似たセキュア トランスポート層 API を持つアプローチを模索しました。SNP は、1994 年のUSENIX夏季技術会議で発表されました。[ 38 ] [ 39 ] SNP プロジェクトは、1991 年にNSAからテキサス大学オースティン校のSimon Lam教授への助成金によって資金提供されました。 [ 40 ]セキュア ネットワーク プログラミングは、 2004 年のACM ソフトウェア システム賞を受賞しました。[ 41 ] [ 42 ] Simon Lam は、「1991 年にセキュア ソケットを発明し、1993 年に SNP と呼ばれる最初のセキュア ソケット レイヤーを実装した」功績により、インターネットの殿堂入りを果たしました。 [ 43 ] [ 44 ]
Netscape はオリジナルの SSL プロトコルを開発し、1995 年から 1998 年までNetscape Communicationsの主任科学者であったTaher Elgamalは「 SSL の父」と呼ばれています。 [ 45 ] [ 46 ] [ 47 ] [ 48 ] SSL バージョン 1.0 は、プロトコルに重大なセキュリティ上の欠陥があったため、一般には公開されませんでした。1995 年 2 月にリリースされたバージョン 2.0 は、セキュリティとユーザビリティに多数の欠陥があることがすぐに判明しました。メッセージの認証と暗号化に同じ暗号鍵を使用していました。秘密のプレフィックス付き MD5 ハッシュ関数を使用する脆弱な MAC 構造であったため、長さ拡張攻撃に対して脆弱でした。また、開始ハンドシェイクと明示的なメッセージ終了のどちらにも保護が提供されていなかったため、中間者攻撃が検出されない可能性がありました。さらに、SSL 2.0 は単一のサービスと固定ドメイン証明書を前提としており、Web サーバーで広く使用されている仮想ホスティング機能と競合していたため、ほとんどの Web サイトは SSL を使用できなくなりました。
これらの欠陥により、プロトコルを完全に再設計して SSL バージョン 3.0 にする必要がありました。[ 49 ] [ 47 ] 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 で使用されているため、破られる可能性があります。[ 50 ] 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 のプロトコルをただ追認しているように見えないようにするため」だったと述べています。[ 51 ]
PCI Council は、組織が 2018 年 6 月 30 日までに TLS 1.0 から TLS 1.1 またはそれ以上に移行することを推奨しました。[ 52 ] [ 53 ] 2018 年 10 月、Apple、Google、Microsoft、およびMozilla は、2020 年 3 月に TLS 1.0 および 1.1 を非推奨にすることを共同で発表しました。[ 30 ] TLS 1.0 および 1.1 は、 2021 年 3 月にRFC 8996で正式に非推奨となりました。
TLS 1.1は、2006年4月にRFC 4346で定義されました。 [ 54 ]これはTLSバージョン1.0からのアップデートです。このバージョンの主な違いは次のとおりです。
TLS バージョン 1.0 および 1.1 のサポートは、2020 年頃に Web サイトによって広く廃止され[ 56 ] 、 Firefoxバージョン 24 より前とChromium ベースのブラウザ29 より前のバージョンへのアクセスが無効になりました[ 57 ]。ただし、サードパーティの修正により、Netscape Navigator および古いバージョンの Firefox に TLS 1.2 のサポートを追加できます[ 58 ]。
TLS 1.2は、2008年8月にRFC 5246で定義されました。 [ 33 ]これは、以前のTLS 1.1仕様に基づいています。主な違いは次のとおりです。
TLS のすべてのバージョンは、2011 年 3 月にRFC 6176でさらに改良され、SSL との下位互換性が削除されたため、TLS セッションでは Secure Sockets Layer (SSL) バージョン 2.0 の使用がネゴシエートされなくなりました。2025 年 4 月現在、TLS 1.2 の廃止予定日は正式には定められていません。TLS 1.2 の仕様も、可能な限り安全性を維持するために、標準化トラック文書RFC 8446で再定義されました。現在では、TLS 1.3 を使用できないクライアントとのみネゴシエートされるフェイルオーバー プロトコルと見なされています (TLS 1.2 の元のRFC 5246の定義は、その後廃止されました)。
TLS 1.3 は2018 年 8 月にRFC 8446で定義されました。 [ 6 ]これは以前の TLS 1.2 仕様に基づいています。TLS 1.2 との主な違いは次のとおりです。[ 59 ]
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) [ 33 ] 、事前共有鍵(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は使用されません。[ 6 ]： §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は、最新バージョンの主要なブラウザすべてでデフォルトで無効になっています。
既知の攻撃に対する対策だけでは不十分である。
Most SSL and TLS programming libraries are free and open-source software.
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 ]
On September 23, 2011, researchers Thai Duong and Juliano Rizzo demonstrated a proof of concept called BEAST (Browser Exploit Against SSL/TLS)[133] using a Java applet to violate same origin policy constraints, for a long-known cipher block chaining (CBC) vulnerability in TLS 1.0:[134][135] an attacker observing 2 consecutive ciphertext blocks C0, C1 can test if the plaintext block P1 is equal to x by choosing the next plaintext block P2 = x ⊕ C0 ⊕ C1; as per CBC operation, C2 = E(C1 ⊕ P2) = E(C1 ⊕ x ⊕ C0 ⊕ C1) = E(C0 ⊕ x), which will be equal to C1 if x = P1. Practical exploits had not been previously demonstrated for this vulnerability, which was originally discovered by Phillip Rogaway[136] in 2002. The vulnerability of the attack had been fixed with TLS 1.1 in 2006, but TLS 1.1 had not seen wide adoption prior to this attack demonstration.
RC4 as a stream cipher is immune to BEAST attack. Therefore, RC4 was widely used as a way to mitigate BEAST attack on the server side. However, in 2013, researchers found more weaknesses in RC4. Thereafter enabling RC4 on server side was no longer recommended.[137]
Chrome and Firefox themselves are not vulnerable to BEAST attack,[138][139] however, Mozilla updated their NSS libraries to mitigate BEAST-like attacks. NSS is used by Mozilla Firefox and Google Chrome to implement SSL. Some web servers that have a broken implementation of the SSL specification may stop working as a result.[140]
Microsoft released Security Bulletin MS12-006 on January 10, 2012, which fixed the BEAST vulnerability by changing the way that the Windows Secure Channel (Schannel) component transmits encrypted network packets from the server end.[141] Users of Internet Explorer (prior to version 11) that run on older versions of Windows (Windows 7, Windows 8 and Windows Server 2008 R2) can restrict use of TLS to 1.1 or higher.
Apple mitigated the BEAST vulnerability by implementing a 1/n-1 split and turning it on by default in OS X Mavericks, released on October 22, 2013.[142]
The authors of the BEAST attack are also the creators of the later CRIME attack, which can allow an attacker to recover the content of web cookies when data compression is used along with TLS.[143][144] When used to recover the content of secret authentication cookies, it allows an attacker to perform session hijacking on an authenticated web session.
While the CRIME attack was presented as a general attack that could work effectively against a large number of protocols, including but not limited to TLS, and application-layer protocols such as SPDY or HTTP, only exploits against TLS and SPDY were demonstrated and largely mitigated in browsers and servers. The CRIME exploit against HTTP compression has not been mitigated at all, even though the authors of CRIME have warned that this vulnerability might be even more widespread than SPDY and TLS compression combined. In 2013 a new instance of the CRIME attack against HTTP compression, dubbed BREACH, was announced. Based on the CRIME attack a BREACH attack can extract login tokens, email addresses or other sensitive information from TLS encrypted web traffic in as little as 30 seconds (depending on the number of bytes to be extracted), provided the attacker tricks the victim into visiting a malicious web link or is able to inject content into valid pages the user is visiting (ex: a wireless network under the control of the attacker).[145] All versions of TLS and SSL are at risk from BREACH regardless of the encryption algorithm or cipher used.[146] Unlike previous instances of CRIME, which can be successfully defended against by turning off TLS compression or SPDY header compression, BREACH exploits HTTP compression which cannot realistically be turned off, as virtually all web servers rely upon it to improve data transmission speeds for users.[145] This is a known limitation of TLS as it is susceptible to chosen-plaintext attack against the application-layer data it was meant to protect.
Earlier TLS versions were vulnerable against the padding oracle attack discovered in 2002. A novel variant, called the Lucky Thirteen attack, was published in 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 ]
A TLS (logout) truncation attack blocks a victim's account logout requests so that the user unknowingly remains logged into a web service. When the request to sign out is sent, the attacker injects an unencrypted TCP FIN message (no more data from sender) to close the connection. The server therefore does not receive the logout request and is unaware of the abnormal termination.[161]
Published in July 2013,[162][163] the attack causes web services such as Gmail and Hotmail to display a page that informs the user that they have successfully signed-out, while ensuring that the user's browser maintains authorization with the service, allowing an attacker with subsequent access to the browser to access and take over control of the user's logged-in account. The attack does not rely on installing malware on the victim's computer; attackers need only place themselves between the victim and the web server (e.g., by setting up a rogue wireless hotspot).[161] This vulnerability also requires access to the victim's computer. Another possibility is when using FTP the data connection can have a false FIN in the data stream, and if the protocol rules for exchanging close_notify alerts is not adhered to a file can be truncated.
In February 2013 two researchers from Royal Holloway, University of London discovered a timing attack[164] which allowed them to recover (parts of the) plaintext from a DTLS connection using the OpenSSL or GnuTLS implementation of DTLS when Cipher Block Chaining mode encryption was used.
This attack, discovered in mid-2016, exploits weaknesses in the Web Proxy Autodiscovery Protocol (WPAD) to expose the URL that a web user is attempting to reach via a TLS-enabled web link.[165] Disclosure of a URL can violate a user's privacy, not only because of the website accessed, but also because URLs are sometimes used to authenticate users. Document sharing services, such as those offered by Google and Dropbox, also work by sending a user a security token that is included in the URL. An attacker who obtains such URLs may be able to gain full access to a victim's account or data.
The exploit works against almost all browsers and operating systems.
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 やその他の安全なプロトコルが日常的に使用されるようになった結果、暗号化されているケースが増えています。
A significant drawback of TLS/HTTPS interception is that it introduces new security risks of its own. One notable limitation is that it provides a point where network traffic is available unencrypted thus giving attackers an incentive to attack this point in particular in order to gain access to otherwise secure content. The interception also allows the network operator, or persons who gain access to its interception system, to perform man-in-the-middle attacks against network users. A 2017 study found that "HTTPS interception has become startlingly widespread, and that interception products as a class have a dramatically negative impact on connection security".[187]
The TLS protocol exchanges records, which encapsulate the data to be exchanged in a specific format (see below). Each record can be compressed, padded, appended with a message authentication code (MAC), or encrypted, all depending on the state of the connection. Each record has a content type field that designates the type of data encapsulated, a length field and a TLS version field. The data encapsulated may be control or procedural messages of the TLS itself, or simply the application data needed to be transferred by TLS. The specifications (cipher suite, keys etc.) required to exchange application data by TLS, are agreed upon in the "TLS handshake" between the client requesting the data and the server responding to requests. The protocol therefore defines both the structure of payloads transferred in TLS and the procedure to establish and monitor the transfer.
When the connection starts, the record encapsulates a "control" protocol – the handshake messaging protocol (content type 22). This protocol is used to exchange all the information required by both sides for the exchange of the actual application data by TLS. It defines the format of messages and the order of their exchange. These may vary according to the demands of the client and server – i.e., there are several possible procedures to set up the connection. This initial exchange results in a successful TLS connection (both parties ready to transfer application data with TLS) or an alert message (as specified below).
A typical connection example follows, illustrating a handshake where the server (but not the client) is authenticated by its certificate:
以下の完全な例では、クライアントが（上記の例のようにサーバーに加えて）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に対する平文復元攻撃は、現実的ではないものの、実行可能である。