トランスポート層セキュリティ（TLS）は、最も重要で広く使用されているセキュリティプロトコルの1つです。オンラインで送信されるデータのかなりの部分を保護します。最も目立つ HTTPSを介してWebブラウザーとWebサイト間を移動するデータを保護するために使用されます, しかし、電子メールや他のプロトコルのホストを保護するためにも使用できます.
TLSは、接続の相手が自分の言うとおりの人物であることを保証し、データが初期の整合性を保持しているかどうかを示し、暗号化によって機密性を提供するため、貴重です.
TLSは、さまざまなアルゴリズムとスキームを使用してこれらの目的を達成します。複雑に思えるかもしれませんが、この記事では、TLSが接続を保護するためにどのように機能するかを詳しく説明するために、一度に1つの側面を説明します。.
TLSの機能?
オンラインで情報を送信する場合、3つの重大なセキュリティ問題が発生します。
- コミュニケーションをとる相手が本当に自分がそう言う人であるかどうかを知る方法?
- データが送信されてから改ざんされていないことをどのようにして知ることができますか?
- 他の人がデータを見たりアクセスしたりするのをどのように防ぐことができますか?
これらの問題は、特に機密情報や貴重な情報を送信する場合に重要です。 TLSは、さまざまな暗号技術を使用して、これら3つの問題のそれぞれに対処します。一緒に、彼らはプロトコルがすることができます 接続の相手を認証し、データの整合性をチェックし、暗号化された保護を提供します.
物事を単純化し、全国に住む友人と情報をやり取りしようとしているふりをしましょう。情報が機密である場合、上記の3つの主要な問題を非常に心配します。.
特に通信が攻撃者に狙われていると疑われる場合は、単に手紙を送って最善を期待することはできません。代わりに、受信者が正当であることを確認できるシステム、メッセージが変更されたかどうかを確認できる方法、およびcan索好きな目からそれらを保護する方法が必要です.
TLSは、さまざまなプロセスを使用してこれらの要件を満たします。それはとして知られているもので始まります TLSハンドシェイク, ここで認証が行われ、キーが確立されます.
手紙の類推に戻ると、TLSの認証部分は、識別を必要とする宅配便で手紙を送るようなものです。宅配便業者が手紙を配達すると、その人のIDと顔を比較して、受取人が正しい人であったかどうかを確認します.
キーの確立段階は、将来の通信で使用する予定のピン番号の半分が手紙に含まれている場合のように少しなります。受取人に番号の後半を見つけて、返送の手紙であなたに送るように頼むでしょう.
宅配便業者が身元を確認し、ピン番号が確立されると、情報を安全に送信するために必要なものがすべて揃います。実際には、これらの段階ははるかに複雑ですが、後で説明します.
TLSはアプリケーションプロトコルと安全に情報を交換します. 類推を続けるために、TLSを介してデータを安全に送信することは、メッセージを書き出して封筒に入れるようなものです。封印に署名を書くと、手紙が改ざんされた場合に、受取人が破れた署名でわかるようになります（これは実際には数学で行われますが、後でもう一度詳しく説明します）.
次に、コンビネーションロックのある小さな金属製の箱に手紙を入れ、受取人と共同で設定したピン番号としてコンビネーションを設定します。あなたは、パッケージが配達されるとき、識別をチェックするメッセンジャーを通して箱を送るでしょう。受信者は同じ方法で返信し、今後の通信は同じ手順に従います.
TLSは、3つの問題すべてを比較的似た方法で解決します. 宅配便業者は、受取人を認証し、箱が目的の人に配達されていることを確認します。ロックされたボックスは暗号化の一形態として機能し、パートナー以外の誰もが手紙にアクセスできないようにします。署名された封筒により、メッセージが改ざんされていないかどうかがわかります.
これは、TLSが行うことの非常に大まかな近似です。現実には, TLSはクライアントとサーバー間で行われます, お互いにメールを送信している2人ではなく。アナロジーは、何が起こっているのか、その背後にある理由を視覚化することです。以下のセクションでは、実際に何が起こるかを詳細に説明します.
TLSとSSL
TLSについて読むと、多くの場合、SSLまたはTLS / SSLの言及が表示されます。 Secure Sockets Layer（SSL）はTLSの古いバージョンですが、業界の多くは依然として古いモニカーでTLSを参照しています。この記事では全体的にTLSという用語を使用しますが、名前はしばしば同じ意味で使用されることに注意することが重要です。 SSLの詳細については、ガイドをご覧ください.
TLSの歴史
すべては、トランスポート層を保護する必要から始まりました。前述したように、TLSの前身はSSLでした。 SSLの最初のバージョンは、90年代に初期のWebブラウザの1つを構築したNetscapeによって開発されました。.
SSL 1.0には重大な脆弱性が含まれていたため、リリースされませんでした. 1995年にNetscape Navigator 1.1でバージョン2.0がリリースされました, しかし、それでも多くの重大な欠陥が含まれていました。 SSL 3.0は大幅に再設計されたバージョンであり、1996年にリリースされ、多くのセキュリティ問題が解決されました。.
1996年, IETFはRFC 6101でSSL 3.0のドラフトをリリースしました. IETFはSSLを標準化するワーキンググループを形成し、1999年に結果をTLS 1.0として公開しました。 RFC 2246に文書化されており、標準化には元のプロトコルの一部の変更と名前の変更が含まれていました。これらの変更は、Netscape、Microsoft、およびIETFワーキンググループ間の交渉の結果として生まれました。.
2006年、IETFはTLS 1.1を文書化したRFC 4346をリリースしました。このバージョンには、新しいセキュリティ条項と他の多くのアップデートが含まれていました。バージョン1.2は、わずか2年後の2008年にリリースされました。これには、認証された暗号化暗号のサポート、ハッシュ関数の使用方法に対する多くの変更、その他多くの改善が含まれています。.
次のバージョンは、TLS 1.3が定義された2023年まで届きませんでした. これには、前方転送の強制、より弱いアルゴリズムのサポートの削除など、多くの変更が含まれます.
TLS 1.0および1.1は2023年に廃止されるようになりましたが、バージョン1.2は広く使用されています。バージョン1.3の採用が増え始めています.
TLS：技術的な詳細
TLSは多くの異なる要素で構成されています。基本的な部分は、レコードプロトコルです。これは、他のすべての包括的な構造を担当する基礎となるプロトコルです。.
TLSスタックを示す図。 JeffreytedjosukmonoによるTLSプロトコルスタック。 CC0でライセンスされています.
レコードプロトコルには5つの個別のサブプロトコルが含まれており、各サブプロトコルは次のようにフォーマットされています 記録：
- ハンドシェーク –このプロトコルは、セキュリティで保護された接続のパラメーターを設定するために使用されます.
- 応用 –アプリケーションプロトコルは、ハンドシェイクプロセスの後に開始され、2者間でデータが安全に送信されます。.
- アラート –アラートプロトコルは、エラー、安定性の問題、または潜在的な侵害がある場合に、接続のいずれかの当事者が他方に通知するために使用されます。.
- 暗号仕様の変更 –このプロトコルは、クライアントまたはサーバーが暗号化パラメーターを変更するために使用します。非常に簡単なので、この記事では詳しく説明しません。.
- ハートビート –これは、ピアがまだ生きているかどうかを接続の一方に知らせるTLS拡張であり、ファイアウォールが非アクティブな接続を閉じるのを防ぎます。これはTLSのコア部分ではないため、このガイドでは省略します。.
これらの各サブプロトコルは、さまざまな情報を伝達するためにさまざまな段階で使用されます。理解する最も重要なものは、ハンドシェイクとアプリケーションプロトコルです。これらは接続を確立し、データを安全に送信する責任があるためです。.
TLSハンドシェイクプロトコル
安全な方法で接続が確立される場所です。いくつかの概念に慣れていない場合は複雑に思えるかもしれませんが、これらのそれぞれについては、それらを参照する必要がある場合は記事の後半で説明します。.
TLSハンドシェイクには3つの基本的なタイプがあります。 基本的なTLSハンドシェイク, その クライアント認証TLSハンドシェイク そしてその 短縮ハンドシェイク.
基本的なTLSハンドシェイク
TLSハンドシェイクプロセスを示す図。 FleshGrinderによる完全なTLS 1.2ハンドシェイク。 CC0でライセンスされています.
このタイプのハンドシェイクでは、サーバーではなくクライアントのみが認証されます。クライアントが送信するネゴシエーションフェーズで始まります。 クライアントこんにちは メッセージ。これには、クライアントがサポートするTLSの最高バージョン、可能な暗号スイート、圧縮をサポートするかどうかの表示、乱数、その他の情報が含まれます
Client Helloメッセージは、 サーバーこんにちは メッセージ。この応答には、サーバーがクライアントのリストから選択したセッションID、プロトコルバージョン、暗号スイート、および圧縮（使用されている場合）が含まれます。また、異なる乱数が含まれています.
選択された暗号スイートに依存しますが、サーバーは通常、 証明書 認証のためのメッセージ。これにより、IDが検証され、公開キーが含まれます.
一時的なDiffie-Hellmanまたは匿名のDiffie-Hellman鍵交換が使用されている場合、これに続いて サーバーキー交換 メッセージ。他のキー交換方法はこの部分をスキップします。サーバーは、ネゴシエーションの側で終了すると、送信します サーバーHello Done メッセージ.
今度はクライアントの番です。選択した暗号スイートに応じて、送信します クライアント鍵交換 メッセージ。これには、サーバーの公開キーで暗号化された公開キーまたはプリマスターシークレットを含めることができます.
その後、両当事者は乱数とプリマスターシークレットを使用して、マスターシークレットを作成します。キーはマスターシークレットから取得され、通信の認証と暗号化に使用されます.
その後、クライアントは 暗号仕様の変更 メッセージ。これにより、サーバーに次のメッセージが認証および暗号化されるようになります（ただし、暗号化は使用されない場合があります）.
クライアントはこれをフォローアップします 完成した メッセージ。暗号化され、認証用のメッセージ認証コード（MAC）も含まれています。サーバーはこのメッセージを解読し、MACを検証します。これらのプロセスのいずれかが失敗した場合、接続は拒否されます.
サーバーの番です 暗号仕様の変更 メッセージ、および 完成した 上記と同じ内容のメッセージ。その後、クライアントはコンテンツの復号化と検証も試みます。これがすべて正常に完了すると、ハンドシェイクは終了します。この時点で、アプリケーションプロトコルが確立されます。その後、データは以下と同じ方法で安全に交換できます。 完成した 上記のメッセージ、認証およびオプションの暗号化.
クライアント認証のTLSハンドシェイク
このハンドシェイクは基本的なTLSハンドシェイクによく似ていますが、クライアントも認証されます。主な違いは、サーバーが 証明書 メッセージ、それも送信します 証明書リクエスト クライアントの証明書を要求するメッセージ。サーバーが完了すると、クライアントはその証明書を 証明書 メッセージ.
その後、クライアントは クライアント鍵交換 基本的なTLSハンドシェイクと同様に、メッセージ。これに続いて 証明書検証 クライアントのデジタル署名を含むメッセージ。クライアントの秘密鍵から計算されるため、サーバーはクライアントのデジタル証明書の一部として送信された公開鍵を使用して署名を検証できます。残りの クライアント認証のTLSハンドシェイク 基本的なTLSハンドシェイクと同じ行に沿って続きます.
短縮TLSハンドシェイク
ハンドシェイクが既に行われている場合、TLSでは、代わりに短縮ハンドシェイクを使用してプロセスの多くをカットできます。これらのハンドシェイクはセッションIDを使用して、新しい接続を以前のパラメーターにリンクします.
短縮されたハンドシェイクにより、両当事者は以前にネゴシエートされたのと同じセットアップで安全な接続を再開できます。ハンドシェイクの開始に通常含まれる暗号化の一部は、計算リソースにかなりの負荷をかける可能性があるため、これにより時間を節約し、接続を容易にします.
プロセスは クライアントこんにちは メッセージ。以前のClient Helloメッセージによく似ていますが、 セッションID 以前の接続から。サーバーがセッションIDを認識している場合、その サーバーこんにちは メッセージ。セッションIDを認識しない場合、別の番号を返し、代わりに完全なTLSハンドシェイクを実行する必要があります.
サーバーがセッションIDを認識しない場合、 証明書 そして キー交換 手順はスキップできます。の 暗号仕様の変更 そして 完成した メッセージは、上記の基本的なTLSハンドシェイクと同じ方法で送信されます。クライアントがメッセージを復号化し、MACを検証したら、データを安全なTLS接続経由で送信できます.
また、セッションIDではなくセッションチケットを使用して接続を再開できるTLS拡張機能もあります。サーバーはセッションに関するデータを暗号化し、クライアントに送信します。クライアントがこの接続を再開したい場合、セッションチケットをサーバーに送信し、サーバーはそれを解読してパラメーターを明らかにします。.
セッションチケットは拡張機能を必要とするため、それほど頻繁には使用されません。それにもかかわらず、サーバーは何も保存する必要がないため、特定の状況で有利になります。.
TLSハンドシェイクの開梱
ハンドシェイクの3つの最も重要な手順は次のとおりです。
- パラメータが選択されています,
- 認証を実施し、
- キーが確立されます.
実際に何が起こっているのか理解できるように、それらをもう少し詳しく説明しましょう.
パラメーター
ハンドシェイクの開始時に、クライアントとサーバーは相互の合意により接続のパラメーターをネゴシエートします。これらの最初は、使用されるTLSのバージョンです。これは、両当事者がサポートする最高のバージョンであり、最も安全である傾向があります.
また、当事者は、マスターキーの確立に使用するキー交換アルゴリズムを決定します。ハッシュ関数、暗号化アルゴリズム、および圧縮方法もこの段階で合意されています。これらについては、私たちが議論するときに詳細に説明します アプリケーションプロトコル 記事の後半.
認証：デジタル証明書
認証は、通信チャネルを保護するための重要な部分です。これは、両者が、詐欺師ではなく実際に自分が考えている相手と話していることを両方の当事者に知らせるためです。 TLSおよびその他の多くのセキュリティメカニズムでは、これはデジタル証明書と呼ばれるもので実現されます.
デジタル証明書は、個人またはエンティティと公開キーの間のリンクを示す電子文書です. このリンクは認証局（CA）によって検証されます。認証局は、2つが実際に関連していることを確認し、独自の評価を使用して証明書に信頼を付与する信頼できる組織です。.
異なる証明書レベルは、さまざまな信頼度を表します。知っておくべき重要なことは、クライアントまたはサーバーが信頼できる有効な証明書を持っている場合、公開鍵が正当であり、攻撃者に対処していないと想定するのが合理的であることです。.
公開鍵に関する注意
公開キー暗号化（非対称暗号化とも呼ばれます）は暗号化の重要な部分であり、TLSのさまざまな側面で広く使用されています。これがどのように機能するかをよく知らない人のための簡単な入門書です.
短い説明は 公開鍵暗号では、単一の鍵ではなく、暗号化と復号化に鍵ペアを使用します. 送信者は、目的の受信者の公開鍵を使用してデータを暗号化します。いったん暗号化されると、受信者の一致する秘密キーによってのみ解読できます。もちろん、公開鍵は公開で共有できますが、秘密鍵は秘密にしておく必要があります.
公開鍵暗号化により、事前に鍵を交換したことがない、または鍵を交換する機会がなかったとしても、当事者は情報を安全に共有できます。これは、素数のいくつかの一意のプロパティを通じてこれを行います。詳細については、公開キー暗号化に関する記事をご覧ください。.
マスターシークレットの確立
上記で見たように、基本的なTLSハンドシェイクのプロセスを議論したとき、パーティ（または両方のパーティ）がその公開証明書で身元を証明した後, 次のステップは、共有シークレットとも呼ばれるマスターシークレットを確立することです. マスターシークレットは、2者間で送信されるデータの整合性の暗号化とチェックの両方に使用されるキーを導出するためのベースです.
TLSハンドシェイクでは、さまざまなメカニズムを使用して、この秘密を安全に共有できます。これらには、RSA、いくつかの異なるタイプのDiffie-Hellman鍵交換、PSK、Kerberosなどが含まれます。それぞれに、前方秘匿性を提供するなどの長所と短所がありますが、これらの違いはこの記事の範囲外です。.
正確なプロセスは、選択されたキー交換方法によって異なりますが、以下で説明する大まかな手順に従います。 基本的なTLSハンドシェイク セクション.
プリマスターシークレットは、以前に選択されたキー交換方法に従って導出されます。クライアントは、プリマスターシークレットをサーバーの公開キーで暗号化して、接続を介して安全に送信します.
クライアントとサーバーは両方とも、プリマスターシークレットと、通信の開始時に送信した乱数を使用して、マスターシークレットを作成します。マスターキーが計算されると、それを使用して4つまたは6つの個別のキーが作成されます。これらは次のとおりです。
- クライアント書き込みMACキー –このキーは、クライアントによって送信されたデータの整合性をチェックするためにサーバーによって使用されます.
- サーバー書き込みMACキー –サーバー書き込みMACキーは、サーバーによって送信されたデータの整合性をチェックするためにクライアントによって使用されます.
- クライアント書き込み暗号化キー –サーバーはこのキーを使用して、クライアントから送信されたデータを暗号化します.
- サーバー書き込み暗号化キー –クライアントはこのキーを使用して、サーバーから送信されたデータを暗号化します.
- クライアント書き込みIVキー –クライアント書き込みIVキーは、AEAD暗号でサーバーによって使用されますが、他のキー交換アルゴリズムが使用されている場合は使用されません。.
- サーバー書き込みIVキー –同様に、このキーはAEAD暗号でクライアントによって使用されますが、他のキー交換アルゴリズムが使用される場合は使用されません。.
マスターキーの確立は、TLSハンドシェイクの重要な部分です。これにより、接続の両側で、認証と暗号化の両方に使用できるキーを安全に取得できるためです。予防措置として、両方のプロセスに個別のキーが使用されます.
認証キーと暗号化キーが導出されると、それらは両方を保護するために使用されます 完成した メッセージ、およびアプリケーションプロトコルを介して送信されたレコード.
アプリケーションプロトコル
TLSハンドシェイクによって安全な接続が確立されると、送信されたデータを保護するためにアプリケーションプロトコルが使用されます。さまざまなシナリオに合わせて幅広いアルゴリズムを使用するように構成できます.
認証アルゴリズム
メッセージの整合性は、さまざまなアルゴリズムで確認できます。これらには以下が含まれます。
- HMAC-MD5
- HMAC-SHA1
- HMAC-SHA2
- AEAD
送信されるデータの整合性を証明するために、送信者はハッシュ関数を介して情報を実行し、一意の文字列を返します。これらは、同じ入力を受け取ると常に同じ結果を返す特殊な数式です.
送信者は、このデータに秘密鍵で署名して、デジタル署名と呼ばれるものを作成します。デジタル署名はメッセージに添付され、受信者に送信されます。データの整合性が維持され、改ざんされていないかどうかを確認するには, 受信者は送信者の公開鍵でハッシュを解読します. 次に、送信されたデータに対して同じハッシュ関数を使用します。次に、受信者は2つの値を比較します.
同じ場合は、送信者によって署名されてからデータが変更されていないことを意味します。それらが異なる場合、データが改ざんされているか、他のエラーが発生した可能性があります.
これは、ハッシュ関数を使用してデータの整合性を示す方法の短いバージョンです。より詳細な理解が必要な場合は、暗号化、ソルティング、ハッシュに関する記事をご覧ください.
暗号化アルゴリズム
TLSは、対称キー暗号化を使用して、送信するデータに機密性を提供します。公開キー暗号化とは異なり、暗号化プロセスと復号化プロセスの両方で1つのキーのみが使用されます。データがアルゴリズムで暗号化されると、暗号文の寄せ集めとして表示されます。適切なアルゴリズムが使用されている限り、攻撃者は実際のデータを傍受してもアクセスできません。.
TLSは、最も一般的なAESですが、CamelliaやARIAなど、さまざまなアルゴリズムを使用できます.
圧縮
圧縮とは、データをエンコードしてスペースを節約するプロセスです。 TLSは、接続の両側で使用することを決定した場合、圧縮をサポートします。この機能にもかかわらず、特にCRIME攻撃（特に TLSセキュリティの問題 以下のセクション）は、セッションハイジャックに圧縮データを利用できることが判明しました.
パディング
パディングは、暗号化される前にメッセージに追加のデータを追加します。これは、暗号化されたデータの構造のヒントが本当の意味を与えるのを防ぐために使用される一般的な暗号化プロセスです。 TLSは通常、暗号化される前にレコードにPKCS＃7パディングを適用します.
警告プロトコル
接続またはセキュリティが不安定になった場合、セキュリティが侵害された場合、または重大なエラーが発生した場合, アラートプロトコルにより、送信者は相手に通知できます. これらのメッセージには、警告または致命的な2つのタイプがあります。警告メッセージは、セッションが不安定であることを示し、受信者はセッションを継続するかどうかを決定できます.
致命的なメッセージは、接続が侵害されたか、重大なエラーが発生したことを受信者に伝えます。送信者は、メッセージを送信した後に接続を閉じる必要があります。アラートプロトコルには、特定の接続問題の原因に関する情報も含まれています。これには、復号化の失敗、未知の認証局、不正なパラメーターなどが含まれます。.
TLS & OSIモデル
OSIモデルは、さまざまな通信システムとプロトコルをどのように捉えるかを概念化および標準化する方法です。これは単なるモデルであり、一部のプロトコルはこれに準拠していないことに注意することが重要です.
OSIには、プロトコルが動作するレベルを示す7つの個別のレイヤーがありますが、, TLSはどの1つにも適合しません. TCPのような別のトランスポートプロトコルを介して流れます。これは、4番目の層であるトランスポート層の上にあることを意味します。トランスポート層のように最も顕著に使用されますが、ハンドシェイクを実行するため、これはプレゼンテーション層またはアプリケーション層の一部であることを意味します.
ご覧のとおり、TLSは単にOSIモデルに準拠していません。これは、TLSが壊れていたり間違っているという意味ではなく、OSIモデルに欠陥があり、すべての通信プロトコルを説明できないことを示しているだけです。.
TLSの使用
TLSは、オンライン通信の大部分を保護するために使用されます。通常、次のようなプロトコルで実装されます 伝送制御プロトコル（TCP）, ただし、データグラム輻輳制御プロトコル（DCCP）およびユーザーデータグラムプロトコル（UDP）でも使用できます。.
HTTP、SMTP、FTP、XMPP、NNTPなどのプロトコルを保護できます, 他と同様。最も一般的なアプリケーションは、ハイパーテキスト転送プロトコルセキュア（HTTPS）であり、WebブラウザーとWebサイト間の接続を保護します。ブラウザの上部にあるURLの左側に小さな緑色のロックアイコンが表示されるため、HTTPSを使用してオンライン接続を保護していることがわかります。.
TLSは、VPNの構築にも使用できます, OpenConnectやOpenVPNなど。暗号化および認証機能を使用して、ホストとネットワークを相互に接続できるトンネルを形成します。 OpenVPNのようなTLSベースのVPNテクノロジーは、IPsecのような代替手段よりも有利です。これは、OpenVPNに深刻なセキュリティ問題があることは知られていないためです。これらのVPNは構成も簡単です.
別の用途は STARTTLSを介した安全なメール. TLSを実装すると、攻撃者がメールサーバー間を移動するときにメッセージにアクセスできなくなります。.
TLSセキュリティの問題
ほとんどのプロトコルと同様に、TLSにはさまざまな実装に対する過去の脆弱性と理論的な攻撃が数多くあります。これにもかかわらず, 最新バージョンは、実用的な目的で安全であると見なされます.
SSL 2.0や3.0（およびSSL 3.0と本質的に同じTLS 1.0）などの過去のバージョンには、多くのセキュリティ上の欠陥がありますが、これらは古いプロトコルおよび非推奨のプロトコルであるため、詳細には触れません。代わりに、TLS 1.2および1.3を使用して接続を保護する必要があります.
TLSの新しいバージョンには、SSLよりも脆弱性の少ないアップグレードが多数あります。それにもかかわらず、このプロトコルにはまだ次のセキュリティ問題があります。
再交渉攻撃
TLSの機能の1つは、クライアントとサーバーのペアが既存の接続のパラメーターを再ネゴシエートできることです。 2009年に、攻撃者がこれを悪用して、トラフィックを注入してクライアントから来たように見せることができることが発見されました。サーバーはリクエストを正当なものとして受け入れます。つまり、攻撃者が発信メッセージを操作する可能性があります。.
この攻撃では、攻撃者が応答を確認することはできませんが、依然として損害を与える可能性があります。これらの攻撃を防ぐ拡張機能は現在提案されている標準です.
獣
SSL / TLSに対するブラウザエクスプロイト（BEAST）攻撃は、2011年に研究者によって初めて発見されました。メッセージの解読に使用できるTLSの暗号ブロックチェーンの脆弱性を利用します。この攻撃は、プロトコルの古くて弱いバージョンであるTLS 1.0にのみ影響します。 2023年まで非推奨ではありませんが、ユーザーはバージョン1.2と1.3を代わりに使用する必要があります.
タイミング攻撃
これらのサイドチャネル攻撃は、アルゴリズムの実行にかかる時間を分析し、その情報を使用して逆方向に動作し、キーを見つけ出します。 2013年に、メッセージ認証コード（MAC）のチェック中に、タイミング攻撃とパディングオラクル攻撃の両方を活用するLucky Thirteen攻撃が発見されました。この攻撃はTLSアルゴリズムを破るために使用できますが、大部分のTLSユーザーにとって危険とは見なされません.
犯罪 & 違反
CRIME攻撃は、さまざまなプロトコルに対して機能します。データが圧縮されると、認証Cookieからコンテンツを引き出すことができます。この情報は、セッションハイジャックに使用できます。多くのプロトコルに影響しますが、効果的な緩和戦略がないため、HTTP圧縮が使用されている場合、攻撃は特に心配です。.
2013年、ブラウザの偵察とハイパーテキストの適応圧縮（BREACH）エクスプロイトによるエクスフィルトレーションがHTTP圧縮に同様の影響を与えることが判明しました。このバージョンの攻撃では、TLSで暗号化された電子メールアドレスやその他の貴重なデータを回復できます。 BREACH攻撃は、HTTP圧縮を無効にするか、クロスサイトリクエストフォージェリ（CSRF）保護などの技術を使用することで軽減できます。.
ダウングレード攻撃
これらは、TLSの以前の安全性の低いバージョンを使用するようにサーバーをだます攻撃です。攻撃者はこれらの手法を使用して、安全性の低いキー交換と暗号の使用をネゴシエートする可能性があります。 Logjam攻撃は、脆弱なサーバーが脆弱な512ビットDiffie-Hellmanを使用する可能性があるため、良い例です。その後、攻撃者はこのキー交換メカニズムを破ってキーを抽出し、セッションへの完全なアクセスを許可できます。.
ハートブリード
Heartbleedは、2012年に誤ってOpenSSL暗号化ライブラリに導入されたセキュリティ上の欠陥でした, これは2014年まで公開されていません。これはTLSのこのような一般的に使用される実装であるため、重大な世界的な損害を引き起こしました.
TLSハートビート拡張機能の開発者の1人が、バッファーの過剰読み取りの脆弱性を追加しました。コードのレビュー時にエラーが検出されなかったため、多くの重大な攻撃が発生しました.
OpenSSLライブラリは非常に広く実装されているため、この問題を緩和するための国際的な費用は非常に高価になりました。サーバー管理者は、新しいパッチをインストールし、脆弱性が存在する2年間に侵害された可能性のある証明書とキーペアを再生成する必要がありました.
溺れる
Obsolete and Weakened eNcryption（DROWN）攻撃による復号化RSAは2016年に発表され、SSL 2.0のサーバーサポートを利用しています。 SSL 2.0を引き続きサポートするサーバー、およびSSL 2.0をサポートする別のサーバーと同じ公開鍵証明書を共有するサーバーに対して、選択された暗号文攻撃を使用します.
攻撃が発表されたとき、初期セットアップコストは約18,000ドル、攻撃ごとに約400ドルで開始できました。 DROWN攻撃が成功すると、セッションキーを取得します.
サーバー証明書を共有しないことで、攻撃を緩和できます. OpenSSLグループは、古いプロトコルと暗号のサポートを削除するパッチもリリースしましたが、これらは、サーバーの証明書がSSL 2.0をサポートする他のサーバーと共有されていない場合にのみ機能します.
不浄なPAC
この攻撃は2016年に発見されました。これはWeb Proxy Autodiscovery Protocol（WPAD）の弱点を利用しています。ユーザーがTLS暗号化接続を介してWebサイトにアクセスしようとすると、この欠陥によりURLが表示される可能性があります。 URLは認証の一形態としてユーザーに送信されることがあるため、Unholy PAC攻撃により、攻撃者がユーザーのアカウントを乗っ取ることが可能になります.
TLSは安全です?
多くのセキュリティ上の問題があるように思えるかもしれませんが、現実には、これらのほとんどはかなりマイナーであり、軽減できるか、または軽減されています。技術が進歩し、脆弱性が発見され、新しい攻撃が開発されるにつれて、TLSは引き続きより多くのセキュリティ問題を抱えることになります。それにも関わらず、現在および予見可能な将来において、TLSはオンライン世界を保護するために使用する主要かつ最も信頼できるツールの1つであり続けるようです。.
サイバーセキュリティビジネステクノロジー TheDigitalArtistによるライセンス CC0