Internet Explorer の TLS プロトコル。 TLS と SSL: 最低限の知識が必要です TLS プロトコルがインストールされていません

説明

TLS を使用すると、クライアント/サーバーアプリケーションが盗聴や不正アクセスを防ぐ方法でネットワーク上で通信できるようになります。

ほとんどの通信プロトコルは TLS (または SSL) の有無にかかわらず使用できるため、接続を確立するときに、クライアントが TLS をインストールするかどうかをサーバーに明示的に伝える必要があります。これは、TLS を使用して接続が常に確立される統一ポート番号 (HTTPS のポート 443 など) を使用するか、任意のポートとクライアント側からサーバーへの特別なコマンドを使用して接続を切り替えることによって実現できます。特別なメカニズムのプロトコル (電子メールプロトコルの STARTTLS など) を使用して TLS に変換します。クライアントとサーバーが TLS の使用に同意したら、安全な接続を確立する必要があります。これはハンドシェイク手順を使用して行われます。 セキュアソケットレイヤー）。このプロセス中に、クライアントとサーバーは安全な接続を確立するために必要なさまざまなパラメータについて合意します。

アルゴリズムではなく、プロトコルのソフトウェア実装に直接基づいた攻撃の亜種もあります。

TLSハンドシェイク手順の詳細

TLS プロトコルに従って、アプリケーションは、送信する必要がある情報をカプセル化 (アプリケーション内に格納) するレコードを交換します。各エントリは、現在の接続状態 (プロトコル状態) に応じて、圧縮、埋め込み、暗号化、または MAC (メッセージ認証コード) によって識別できます。各 TLS エントリには、コンテンツタイプ (エントリのコンテンツタイプを定義)、パケット長を示すフィールド、および TLS プロトコルバージョンを示すフィールドのフィールドが含まれています。

最初に接続が確立されると、TLS ハンドシェイクプロトコルを使用して対話が行われます。 コンテンツタイプそれは22です。

TLS でのシンプルなハンドシェイク

交渉フェーズ:
- クライアントがメッセージを送信する クライアントこんにちは
- サーバーはメッセージで応答します ServerHello
- サーバーがメッセージを送信する 証明書
- サーバーがメッセージを送信する サーバーこんにちは完了
- クライアントはメッセージで応答します ClientKeyExchangeこれには、PreMasterSecret の公開キーが含まれるか (この PreMasterSecret はサーバーの証明書の公開キーを使用して暗号化されます。)、または何も含まれません (これも暗号化アルゴリズムに依存します)。
- プレマスターシークレット
クライアントがメッセージを送信する 暗号仕様の変更
- クライアントがメッセージを送信する 終了した
サーバーが送信します 暗号仕様の変更

クライアント認証によるハンドシェイク

この例では、サーバーとクライアントの間で証明書を交換することによる完全なクライアント認証 (前の例のようなサーバー認証に加えて) を示します。

交渉フェーズ:
- クライアントがメッセージを送信する クライアントこんにちはサポートされている TLS プロトコルの最新バージョン、乱数、TLS での作業に適したサポートされている暗号化および圧縮方法のリストを示します。
- サーバーはメッセージで応答します ServerHelloサーバーによって選択されたプロトコルバージョン、クライアントによって送信された乱数、クライアントによって提供されたリストからの適切な暗号化および圧縮アルゴリズムが含まれます。
- サーバーがメッセージを送信する 証明書、サーバーのデジタル証明書が含まれています (暗号化アルゴリズムによっては、この手順がスキップされる場合があります)。
- サーバーがメッセージを送信する 証明書リクエスト、これには相互認証のためのクライアント証明書リクエストが含まれます。
- 【クライアント証明書の取得と検証のポイントが抜けています】 ;
- サーバーがメッセージを送信する サーバーこんにちは完了、ハンドシェイクの終了を識別します。
- クライアントはメッセージで応答します ClientKeyExchange、これには PreMasterSecret 公開キーが含まれるか、何も含まれません (これも暗号化アルゴリズムに応じて異なります)。
- キーを使用するクライアントとサーバー プレマスターシークレットランダムに生成された数値と共有秘密鍵が計算されます。他のすべての鍵情報は、共有秘密鍵 (およびクライアントとサーバーが生成したランダム値) から導出されます。
クライアントがメッセージを送信する 暗号仕様の変更これは、後続のすべての情報が、ハンドシェイクプロセス中に確立されたアルゴリズムを使用し、共有秘密キーを使用して暗号化されることを示します。これらはレコードレベルのメッセージであるため、タイプ 22 ではなく 20 になります。
- クライアントがメッセージを送信する 終了した、以前のハンドシェイクメッセージから生成されたハッシュと MAC が含まれます。
- サーバーはクライアントの Finished メッセージを復号化し、ハッシュと MAC を確認しようとします。復号化または検証プロセスが失敗した場合、ハンドシェイクは失敗したとみなされ、接続を終了する必要があります。
サーバーが送信します 暗号仕様の変更暗号化されたメッセージが完了すると、クライアントも復号化と検証を実行します。

この時点から通信確認が完了したとみなされ、プロトコルが確立されます。後続のパケットの内容はすべてタイプ 23 であり、すべてのデータが暗号化されます。

TLS接続の再開

セッションキーの生成に使用される非対称暗号化アルゴリズムは、通常、コンピューティング能力の点で高価です。接続が再開されるときにこれらの繰り返しを避けるために、TLS はハンドシェイク中に接続を再開するために使用される特別なショートカットを作成します。この場合、通常の通信確認中に、クライアントはメッセージに追加します。 クライアントこんにちは以前のセッションID セッションID。クライアントバインドID セッションIDサーバーの IP アドレスと TCP ポートを使用して、サーバーに接続するときに以前の接続のすべてのパラメーターを使用できるようにします。サーバーは以前のセッション ID と一致します セッションID使用される暗号化アルゴリズムやマスターシークレットなどの接続パラメータを使用します。両方の側が同じマスターシークレットを持っている必要があります。そうでない場合、接続は確立されません。これにより使用が妨げられます セッションID暗号解読者が不正アクセスを取得する。メッセージ内の乱数シーケンス クライアントこんにちはそして ServerHello生成されたセッションキーが前回の接続時のセッションキーと異なることを保証できます。 RFC では、このタイプのハンドシェイクを「ハンドシェイク」と呼んでいます。 省略された.

交渉フェーズ:
- クライアントがメッセージを送信する クライアントこんにちはサポートされている TLS プロトコルの最新バージョン、乱数、TLS での作業に適したサポートされている暗号化および圧縮方法のリストを示します。以前の接続識別子もメッセージに追加されます。 セッションID.
- サーバーはメッセージで応答します ServerHelloサーバーによって選択されたプロトコルバージョン、クライアントによって送信された乱数、クライアントによって提供されたリストからの適切な暗号化および圧縮アルゴリズムが含まれます。サーバーがセッションIDを認識している場合 セッションID ServerHello同じ識別子 セッションID。これは、前のセッションを再開して使用できることをクライアントに伝える信号です。サーバーがセッションIDを認識しない場合 セッションID、そして、彼はメッセージに追加します ServerHello代わりに別の意味 セッションID。クライアントにとって、これは、更新された接続が使用できないことを意味します。したがって、サーバーとクライアントは、セッションキーを生成するために同じマスターシークレットと乱数を持っている必要があります。
クライアントがメッセージを送信する 暗号仕様の変更これは、後続のすべての情報がハンドシェイクプロセス中に確立された共有秘密キーで暗号化されることを示します。これらはレコードレベルのメッセージであるため、タイプ 22 ではなく 20 になります。
クライアントがメッセージを送信する 暗号仕様の変更これは、後続のすべての情報が、ハンドシェイクプロセス中に確立されたアルゴリズムを使用し、共有秘密キーを使用して暗号化されることを示します。これらはレコードレベルのメッセージであるため、タイプ 22 ではなく 20 になります。
- クライアントがメッセージを送信する 終了した、以前のハンドシェイクメッセージから生成されたハッシュと MAC が含まれます。
- サーバーはクライアントの Finished メッセージを復号化し、ハッシュと MAC を確認しようとします。復号化または検証プロセスが失敗した場合、ハンドシェイクは失敗したとみなされ、接続を終了する必要があります。
サーバーが送信します 暗号仕様の変更暗号化されたメッセージが完了すると、クライアントも復号化と検証を実行します。

パフォーマンス上の利点に加えて、元のセッションと再開されたセッションが同じクライアントによって開始されることが保証されるため、接続更新アルゴリズムを使用してシングルサインオンを実装できます (RFC 5077)。これは、TLS/SSL 経由の FTP を実装する場合に特に重要です。そうしないと、再接続が確立されたときに攻撃者がデータコンテンツを傍受する可能性がある中間者攻撃に対して脆弱になります。

TLSで使用されるアルゴリズム

この現在のバージョンのプロトコルでは、次のアルゴリズムが使用できます。

鍵を交換してその信頼性を検証するには、RSA (非対称暗号)、Diffie-Hellman (安全な鍵交換)、DSA (デジタル署名アルゴリズム)、および Fortezza テクノロジーアルゴリズムのアルゴリズムの組み合わせが使用されます。
対称暗号化の場合: RC2、RC4、IDEA、DES、Triple DES または AES。

プロトコルのバージョンに応じてアルゴリズムを追加できます。

類似品との比較

TLS 接続のアプリケーションの 1 つは、仮想プライベートネットワーク内のホストの接続です。 TLS に加えて、IPSec プロトコルのセットと SSH 接続も使用できます。仮想プライベートネットワークを実装するこれらのアプローチにはそれぞれ、独自の長所と短所があります。。

TLS/SSL
- 利点:
  - 上位レベルのプロトコルには見えません。
  - インターネット接続や電子商取引アプリケーションでよく使用されます。
  - サーバーとクライアント間の永続的な接続の欠如。
  - 電子メール、プログラミングツールなどの TCP/IP
- 欠点:
  - UDP と ICMP。
  - 接続ステータスを監視する必要性。
  - TLS サポートには追加のソフトウェア要件があります。
IPsec
- 利点:
  - このプロトコルのデータ保護のセキュリティと信頼性は、このプロトコルがインターネット標準として採用されて以来、テストされ証明されています。
  - ネットワークプロトコルの上位層で動作し、ネットワークプロトコル層の上でデータを暗号化します。
- 欠点:
  - 実装の複雑さ。
  - ネットワーク機器 (ルーターなど) の追加要件。
  - 相互に常に正しく相互作用するとは限らないさまざまな実装が多数あります。
SSH
- 利点:
  - 電子メール、プログラミングツールなど、TCP/IP を使用するアプリケーション用のトンネルを作成できます。
  - セキュリティ層はユーザーには見えません。
- 欠点:
  - ルーターやファイアウォールなどのゲートウェイが多数あるネットワークでは使用が困難。
  - UDP および ICMP プロトコルでは使用できません。

こちらも参照

リンク

T. ディアクス、E. レスコルラ Transport Layer Security (TLS) プロトコル、バージョン 1.2 (2008 年 8 月)。 2012 年 2 月 9 日のオリジナルからアーカイブ。
SSL プロトコル: バージョン 3.0 Netscape の最終 SSL 3.0 ドラフト (1996 年 11 月 18 日)
「SSL/TLS の詳細」。 マイクロソフト TechNet。 2003 年 7 月 31 日に更新されました。
ダン・グッディン . 登録簿(2011 年 9 月 19 日)。アーカイブ済み
エリック・レスコルラ TLS 再ネゴシエーション攻撃について理解する。 知識に基づいた推測(2009 年 11 月 5 日)。 2012 年 2 月 9 日のオリジナルからアーカイブ。2011 年 12 月 7 日に閲覧。
ロバート・マクミラン。セキュリティ専門家は、新たなSSL攻撃が多くのサイトを攻撃する可能性があると述べ、 パソコンワールド(2009 年 11 月 20 日)。 2011 年 12 月 7 日に取得。
SSL_CTX_set_options SECURE_RENEGOTIATION 。 OpenSSL ドキュメント(2010 年 2 月 25 日)。 2012 年 2 月 9 日のオリジナルからアーカイブ。2010 年 12 月 7 日に閲覧。
GnuTLS 2.10.0 がリリースされました。 GnuTLS リリースノート(2010 年 6 月 25 日)。 2012 年 2 月 9 日のオリジナルからアーカイブ。2011 年 12 月 7 日に閲覧。
NSS 3.12.6 リリースノート。 NSS リリースノート(2010 年 3 月 3 日)。 2011 年 7 月 24 日に取得。
様々な IE SSL の脆弱性。 知識に基づいた推測(2002 年 8 月 10 日)。

ネットワークプロトコル SSL および TLS は、認証と、不正なアクセスや送信データの整合性の侵害に対する保護を提供する暗号化プロトコルです。 SSL/TLS プロトコルは、クライアントまたはサーバー側での識別子のなりすまし、データの開示や破損を防ぐように設計されています。これらの目的のために、信頼性の高い認証方法が使用され、通信チャネルの暗号化とメッセージ完全性コードが使用されます。 SSL/TLS の標準のデフォルトポートは、HTTPS の場合は 443、SMTPS (電子メール) の場合は 465、LDAPS の場合は 636、NNTPS の場合は 563、IRCS (チャット) の場合は 994、POP3S の場合は 995 です。

SSLプロトコル

SSL プロトコルは、サービスプロトコルとトランスポートプロトコル間のデータを保護するために Netscape によって開発されました。最初の公開バージョンは 1995 年にリリースされました。 VoIP アプリケーションやインスタントメッセージングサービスに広く使用されています。 SSL は、次の特性を持つ安全なチャネルです。

プライベートチャンネル。暗号化キーを決定するために必要なダイアログの後、すべてのメッセージが暗号化されるようにします。
チャネルは認証されています。認証はクライアント側ではオプションですが、サーバー側では必須です。
チャネルの信頼性。メッセージが転送されるとき、MAC を使用して整合性チェックが実行されます。

SSL プロトコルは対称キーと非対称キーの両方を使用します。

SSLプロトコルの特徴と目的

SSL プロトコルは、送信される情報の暗号化と、必要な場所への正確な情報の転送 (認証) という 2 つの問題に対する解決策を提供します。このプロトコルの主な目的は、アプリケーション間でデータを交換するための信頼できる方法を提供することです。 SSL の実装は多層環境の形式で行われ、安全でない通信チャネルを通じて情報を安全に送信するために使用されます。

多層構造は、接続確認プロトコル層と記録プロトコル層で表される。最初の層はトランスポートプロトコル (TCP など) です。これらの層は SSL レコードプロトコルとともに SSL のコアを形成し、その後、複雑なインフラストラクチャの形成に関与します。

SSL プロトコルの主な機能の中で、ソフトウェアプラットフォームの独立性に注目する必要があります。現在、SSL プロトコルは十分なセキュリティを提供していません。TLS プロトコルに置き換えられています。

TLSプロトコル

TLS プロトコルは、インターネット上の異なるノード間の安全なデータ転送に使用される暗号化プロトコルです。このプロトコルは、VoIP アプリケーション、Web ブラウザ、インスタントメッセージングアプリケーションで使用されます。 TLS は SSL 3.0 仕様に基づいて実装されます。このプロトコルは IETF によって開発および開発されています。

TLS プロトコルによって提供される主なセキュリティ対策には次のものがあります。

キーを使用してメッセージ認証コードを検証します。
TLS バージョンをダウングレードしたり、安全性の低いネットワークプロトコルに置き換えたりする可能性が排除されます。
ハンドシェイクメッセージには、当事者間で交換されたすべてのメッセージのハッシュが含まれています。
MAC を使用したアプリケーションレコード番号付けの使用。
入力メッセージを 2 つの部分に分割する擬似ランダム関数の使用。それぞれが異なるハッシュ関数によって処理されます。

TLS プロトコルの機能と目的

TLS プロトコルは次のアルゴリズムを使用します。

対称暗号化のための RC4、Triple DES、SEED、IDEA など。
キー認証用の RSA、DSA、Diffie-Hellman、および ECDSA。
ハッシュ関数には MD5、SHA、SHA-256/384。

アプリケーションは、データを保存するレコードを交換します。レコードは、圧縮、拡張、暗号化、または識別することができます。この場合、各エントリはパケットの長さと使用される TLS バージョンを示します。

一般に、SSL/TLS プロトコルで暗号化を使用すると、アプリケーションのパフォーマンスが大幅に低下しますが、信頼性の高いデータ送信セキュリティが提供されます。このプロトコルはクライアント側での設定を実質的に必要とせず、インターネット上で最も一般的なセキュリティプロトコルと考えられています。

特定のサイトへのアクセスが失敗し、ブラウザにメッセージが表示されるという問題が発生した場合、これには合理的な説明があります。この問題の原因と解決策は、この記事に記載されています。

SSL TLSプロトコル

予算組織のユーザーは、予算組織に限らず、その活動が財務省や財務省などの金融機関とのやり取りにおいて財務に直接関係している場合、すべての業務を安全な SSL プロトコルのみを使用して実行します。基本的に、彼らは仕事で Internet Explorer ブラウザを使用します。場合によっては - Mozilla Firefox。

SSLエラー

これらの操作、および作業一般を実行する際の主な注意は、セキュリティシステム、つまり証明書や電子署名に払われます。 CryptoPro ソフトウェアの現在のバージョンが操作に使用されます。について SSL および TLS プロトコルの問題、もし SSLエラーと表示された場合、おそらくこのプロトコルはサポートされていません。

TLSエラー

TLSエラー多くの場合、プロトコルがサポートされていないことを示すこともあります。しかし...この場合何ができるかを見てみましょう。

SSLおよびTLSプロトコルのサポート

そのため、Microsoft Internet Explorer を使用して SSL で保護された Web サイトにアクセスすると、タイトルバーに ssl および tls プロトコルが有効になっていることを確認してください。まず、Internet Explorer で TLS 1.0 プロトコルのサポートを有効にする必要があります。

インターネットインフォメーションサービス 4.0 以降を実行している Web サイトにアクセスしている場合、TLS 1.0 をサポートするように Internet Explorer を構成すると、接続のセキュリティが確保されます。もちろん、使用しようとしているリモート Web サーバーがこのプロトコルをサポートしている場合に限ります。

メニューでこれを行うには サービスチームを選ぶ インターネット設定.

タブ上 さらに章内 安全性、次のチェックボックスが選択されていることを確認してください。

SSL 2.0を使用する
SSL 3.0を使用する
SSL 1.0を使用する

ボタンをクリックしてください 適用する 、その後 わかりました . ブラウザを再起動します .

TLS 1.0 を有効にした後、Web サイトに再度アクセスしてみてください。

システムセキュリティポリシー

それでも発生する場合 SSL と TLS でのエラーそれでも SSL を使用できない場合は、リモート Web サーバーが TLS 1.0 をサポートしていない可能性があります。この場合、FIPS 準拠のアルゴリズムを必要とするシステムポリシーを無効にする必要があります。

これを行うには、 コントロールパネル選択する管理をダブルクリックします。 ローカルセキュリティポリシー.

[ローカルセキュリティ設定] で、展開します。 ローカルポリシーそしてボタンをクリックします セキュリティ設定.

ウィンドウ右側のポリシーに従い、ダブルクリックします。 システム暗号化: 暗号化、ハッシュ、署名に FIPS 準拠のアルゴリズムを使用します。そしてボタンをクリックします無効.

注意！

ローカルセキュリティポリシーが再適用されると、変更が有効になります。オンにしてブラウザを再起動します。

クリプトプロ TLS SSL

クリプトプロをアップデートする

この問題を解決するオプションの 1 つは、リソースを構成するだけでなく、CryptoPro を更新することです。この場合、これは電子決済で機能します。認証局に移動します。リソースとして電子マーケットプレイスを選択します。

ワークプレイスの自動セットアップを開始したら、あとは 手順が完了するまで待ちます、それから ブラウザをリロードする。リソースアドレスを入力または選択する必要がある場合は、必要なアドレスを選択します。セットアップが完了したら、コンピュータを再起動する必要がある場合もあります。

ロシアの法律の要件によれば、ロシアの暗号化アルゴリズム GOST 28147-89、GOST R 34.10-94、GOST R 34.11-94、および GOST R 34.10-2001 に従って確立された TLS 接続の使用のみが認められます。したがって、GOST アルゴリズムに従った暗号化を使用するサイトを使用する必要がある場合は、CryptoPro CSP プログラムをインストールする必要があります。

Windows オペレーティングシステムは、電子署名を生成し、証明書を操作するための暗号化ユーティリティのセットである CryptoPro CSP プログラムを使用します。

CryptoPro CSP をインストールするには、公式 Web サイトの資料を使用します。

CryptoPro CSP をインストールすると、ブラウザはこのプログラムの存在と機能を確認します。

GOST TLS 暗号化を要求するサイト

サイトが GOST TLS 暗号化を要求すると、ブラウザーは CryptoPro CSP プログラムがインストールされているかどうかを確認します。プログラムがインストールされている場合は、制御がそれに移ります。

暗号化を要求するサイトの例: www.gosuslugi.ru、ドメイン .gov.ru、.kamgov.ru、.nalog.ru 上のサイト。

サイトがリストにない場合は、追加の確認が必要です。サイトを信頼し、GOST TLS 暗号化を使用して接続を確立する必要がある場合は、「続行」ボタンをクリックします。

TLS プロトコルはあらゆるタイプのインターネットトラフィックを暗号化するため、オンラインでの通信と販売が安全になります。このプロトコルがどのように機能するのか、そして将来何が待っているのかについてお話します。

この記事から次のことがわかります。

SSLとは

SSL または Secure Sockets Layer は、Netscape が 90 年代半ばに開発したプロトコルの元の名前です。 SSL 1.0 は一般公開されておらず、バージョン 2.0 には重大な欠陥がありました。 1996 年にリリースされた SSL 3.0 は完全な見直しであり、開発の次の段階への方向性を定めました。

TLSとは何ですか

1999 年にこのプロトコルの次のバージョンがリリースされたとき、インターネット技術特別委員会はそれを標準化し、トランスポート層セキュリティ (TLS) という新しい名前を付けました。 TLS のドキュメントには、「このプロトコルと SSL 3.0 の違いは重要ではありません。」と記載されています。 TLS と SSL は継続的な一連のプロトコルを形成しており、SSL/TLS という名前で結合されることがよくあります。

TLS プロトコルは、あらゆる種類のインターネットトラフィックを暗号化します。最も一般的なタイプは Web トラフィックです。ブラウザが TLS 接続を確立するときは、アドレスバーのリンクが「https」で始まるかどうかでわかります。

TLS は、メールや電話会議システムなどの他のアプリケーションでも使用されます。

TLS の仕組み

オンラインで安全に通信するには暗号化が必要です。データが暗号化されていない場合、誰でもデータを分析して機密情報を読み取ることができます。

最も安全な暗号化方式は次のとおりです。 非対称暗号化。これには、公開キーと秘密キーの 2 つのキーが必要です。これらは情報を含むファイルであり、多くの場合、非常に大きな数が含まれます。メカニズムは複雑ですが、簡単に言うと、公開キーを使用してデータを暗号化できますが、復号化するには秘密キーが必要です。 2 つのキーは、ハッキングが困難な複雑な数式を使用してリンクされています。

公開キーは穴の開いたロックされたメールボックスの位置に関する情報、秘密キーはメールボックスを開ける鍵と考えることができます。箱の場所を知っている人なら誰でもそこに手紙を入れることができます。しかし、それを読むためには、箱を開けるための鍵が必要です。

非対称暗号化では複雑な数学的計算が使用されるため、大量のコンピューティングリソースが必要になります。 TLS は、セッションの開始時にのみ非対称暗号化を使用してサーバーとクライアント間の通信を暗号化することで、この問題を解決します。サーバーとクライアントは、データパケットの暗号化に使用する単一のセッションキーに同意する必要があります。

クライアントとサーバーがセッションキーに同意するプロセスは、と呼ばれます。 ハンドシェーク。これは、通信する 2 台のコンピューターがお互いに自己紹介をする瞬間です。

TLSハンドシェイクプロセス

TLS ハンドシェイクプロセスは非常に複雑です。以下の手順はプロセスの概要を示しており、プロセスが一般的にどのように機能するかを理解できます。

クライアントはサーバーに接続し、安全な接続を要求します。サーバーは、使用方法を知っている暗号のリスト (暗号化された接続を作成するためのアルゴリズムのセット) で応答します。クライアントはそのリストをサポートされている暗号のリストと比較し、適切なものを選択し、サーバーにどちらを使用するかを知らせます。
サーバーは、サーバーの信頼性を確認する第三者によって署名された電子文書であるデジタル証明書を提供します。証明書内の最も重要な情報は、暗号の公開キーです。クライアントは証明書の信頼性を確認します。
サーバーの公開キーを使用して、クライアントとサーバーは通信を暗号化するためにセッション全体で両方が使用するセッションキーを確立します。これにはいくつかの方法があります。クライアントは公開キーを使用して任意の番号を暗号化でき、その番号はサーバーに送信されて復号化され、双方がその番号を使用してセッションキーを確立します。

セッションキーは、1 つの連続セッションに対してのみ有効です。何らかの理由でクライアントとサーバー間の通信が中断された場合、新しいセッションキーを確立するために新しいハンドシェイクが必要になります。

TLS 1.2 および TLS 1.2 プロトコルの脆弱性

TLS 1.2 は、プロトコルの最も一般的なバージョンです。このバージョンでは、セッション暗号化オプションの元のプラットフォームがインストールされました。ただし、以前のバージョンのプロトコルと同様に、このプロトコルでは、古いコンピューターをサポートするために古い暗号化技術の使用が許可されていました。残念ながら、これらの古い暗号化メカニズムはより脆弱になったため、これによりバージョン 1.2 に脆弱性が発生しました。

たとえば、TLS 1.2 は、攻撃者がセッション中にデータパケットを傍受し、読み取りまたは変更した後に送信する改ざん攻撃に対して特に脆弱になっています。これらの問題の多くは過去 2 年間に表面化しており、プロトコルの更新バージョンを作成することが急務となっています。

TLS1.3

間もなく完成する予定の TLS プロトコルのバージョン 1.3 では、従来の暗号化システムのサポートを廃止することで、脆弱性に関する問題の多くが解決されています。
新しいバージョンには以前のバージョンとの互換性があります。たとえば、一方の当事者がバージョン 1.3 の許可されたプロトコルアルゴリズムのリストにある新しい暗号化システムを使用できない場合、接続は TLS 1.2 にフォールバックします。ただし、接続改ざん攻撃では、ハッカーがセッションの途中でプロトコルのバージョンを強制的に 1.2 にダウングレードしようとすると、その行為が検知され、接続が切断されてしまいます。

Google Chrome および Firefox ブラウザで TLS 1.3 サポートを有効にする方法

Firefox と Chrome は TLS 1.3 をサポートしていますが、このバージョンはデフォルトでは有効になっていません。その理由は、現時点ではドラフト形式でしか存在しないためです。

モジラ Firefox

ブラウザのアドレスバーに「about:config」と入力します。リスクを理解していることを確認してください。

Firefox 設定エディターが開きます。
検索に security.tls.version.max と入力します
現在の値をダブルクリックして、値を 4 に変更します。

グーグルクローム

ブラウザのアドレスバーに「chrome://flags/」と入力して、実験パネルを開きます。
オプション #tls13-variant を検索します
メニューをクリックして「有効 (ドラフト)」に設定します。
ブラウザを再起動します。

ブラウザがバージョン 1.2 を使用していることを確認する方法

バージョン 1.3 はまだ一般には使用されていないことをお知らせします。望まない場合は
ドラフトを使用する場合は、バージョン 1.2 をそのまま使用できます。

ブラウザがバージョン 1.2 を使用していることを確認するには、上記の手順と同じ手順に従い、次のことを確認します。

Firefox の場合、security.tls.version.max 値は 3 です。それより低い場合は、現在の値をダブルクリックして 3 に変更します。
Google Chrome の場合: ブラウザのメニューをクリックして選択します。設定- 選択する 詳細設定を表示する- セクションに移動します システムそしてクリックしてください プロキシ設定を開きます…: