SSL/TLS プロトコルの動作メカニズムの概要_html/css_WEB-ITnose

インターネット通信のセキュリティは SSL/TLS プロトコルに基づいています。

この記事では、SSL/TLS プロトコルの動作メカニズムを簡単に紹介します。この記事の焦点は設計のアイデアと運用プロセスにあり、具体的な実装の詳細は含まれません。これについて詳しく知りたい場合は、RFC ドキュメントを参照してください。

1. 機能

SSL/TLSを使用しないHTTP通信は暗号化されない通信です。平文で拡散されるすべての情報には 3 つの大きなリスクが伴います。

(1) 盗聴（盗聴）の危険性：通信内容を第三者に知られる可能性があります。

(2) 改ざんリスク：第三者により通信内容が改ざんされる可能性があります。

(3) ふり: 第三者は他人になりすましてコミュニケーションに参加することができます。

SSL/TLS プロトコルは、次の 3 つの主要なリスクを解決するように設計されており、次のことを実現することを目指しています。

(1) すべての情報は暗号化されて送信され、第三者は盗聴できません。

(2) 改ざんされると、通信相手はすぐにそれを発見します。

(3)なりすましを防止する身分証明書を搭載。

インターネットはオープンな環境であり、通信の当事者はどちらも不明であるため、プロトコルの設計が非常に困難になります。さらに、プロトコルはあらゆる驚異的な攻撃に耐えることができる必要があるため、SSL/TLS プロトコルは非常に複雑になります。

2. 歴史

インターネット暗号化通信プロトコルの歴史は、インターネットとほぼ同じです。

1994 年に、NetScape は SSL プロトコル (Secure Sockets Layer) のバージョン 1.0 を設計しましたが、リリースされませんでした。

1995 年に NetScape は SSL バージョン 2.0 をリリースしましたが、すぐに重大な脆弱性が発見されました。

1996 年に SSL バージョン 3.0 が登場し、広く使用されました。

1999 年、インターネット標準化団体 ISOC は NetScape を継承し、SSL のアップグレード バージョンである TLS バージョン 1.0 をリリースしました。

2006 年と 2008 年に、TLS は TLS バージョン 1.1 と TLS バージョン 1.2 という 2 回アップグレードされました。最新の変更は、TLS 1.2 の 2011 リビジョンです。

現在、最も広く使用されているのは TLS 1.0、次に SSL 3.0 です。ただし、主要なブラウザはすでに TLS 1.2 のサポートを実装しています。

通常、TLS 1.0 は SSL 3.1、TLS 1.1 は SSL 3.2、TLS 1.2 は SSL 3.3 とラベル付けされます。

3. 基本的な操作プロセス

SSL/TLS プロトコルの基本的な考え方は、公開キー暗号化を使用することです。つまり、クライアントは最初にサーバーから公開キーを要求し、次にその公開キーを使用して暗号化します。情報を受信すると、サーバーは暗号文を受信し、独自の秘密キーで暗号化を解除します。

しかし、ここには2つの問題があります。

(1) 公開鍵が改ざんされていないことを確認するにはどうすればよいですか?

解決策: デジタル証明書に公開キーを入れます。証明書が信頼される限り、公開キーも信頼されます。

(2) 公開鍵暗号化は計算量が多すぎる 時間を短縮するには？

解決策: セッションごとに、クライアントとサーバーは「セッション キー」を生成し、それを使用して情報を暗号化します。 「会話キー」は対称的に暗号化されるため、処理速度が非常に速く、サーバー公開鍵は「会話キー」自体の暗号化にのみ使用されるため、暗号化処理にかかる時間が短縮されます。

したがって、SSL/TLS プロトコルの基本的なプロセスは次のとおりです:

(1) クライアントはサーバーに公開鍵を要求し、検証します。

(2) 双方が交渉して「会話キー」を生成します。

(3) 双方は「会話キー」を使用して暗号化通信を行います。

上記のプロセスの最初の 2 つのステップは、「ハンドシェイク フェーズ」とも呼ばれます。

4. ハンドシェイク フェーズの詳細なプロセス

「ハンドシェイク フェーズ」には 4 つの通信が含まれます。1 つずつ見てみましょう。 「ハンドシェイクフェーズ」中のすべての通信は平文で行われることに注意してください。

4.1 クライアントがリクエストを行う (ClientHello)

まず、クライアント (通常はブラウザ) は、ClientHello リクエストと呼ばれる暗号化された通信リクエストをサーバーに送信します。

このステップでは、クライアントは主に次の情報をサーバーに提供します。

(1) サポートされているプロトコルのバージョン (TLS バージョン 1.0 など)。

(2) 後で「会話キー」を生成するために使用される、クライアントが生成した乱数。

(3) RSA 公開キー暗号化などの暗号化方式がサポートされています。

(4) サポートされている圧縮方法。

ここで、クライアントによって送信される情報にはサーバーのドメイン名が含まれないことに注意してください。つまり、理論上、サーバーには Web サイトを 1 つだけ含めることができます。そうでないと、どの Web サイトのデジタル証明書をクライアントに提供すべきかが不明確になります。通常、サーバーがデジタル証明書を 1 つだけ持つことができるのはこのためです。

仮想ホスティングユーザーにとって、これは確かに非常に不便です。 2006 年に、サーバー名表示拡張機能が TLS プロトコルに追加され、クライアントが要求したドメイン名をサーバーに提供できるようになりました。

4.2 サーバー応答 (SeverHello)

サーバーはクライアントのリクエストを受信した後、SeverHello と呼ばれる応答をクライアントに送信します。サーバーの応答には次の内容が含まれます。

(1) TLSバージョン1.0など、使用している暗号化通信プロトコルのバージョンを確認します。ブラウザとサーバーがサポートするバージョンが一致しない場合、サーバーは暗号化通信を切断します。

(2) サーバーが生成した乱数。後で「会話キー」を生成するために使用されます。

(3) RSA公開鍵暗号など、使用されている暗号化方式を確認します。

(4) サーバー証明書。

上記の情報に加えて、サーバーがクライアントの身元を確認する必要がある場合、クライアントに「クライアント証明書」の提供を求めるリクエストも含まれます。たとえば、金融機関は多くの場合、認定された顧客のみに自社のネットワークへの接続を許可し、正規の顧客にはクライアント証明書を含む USB キーを提供します。

4.3 クライアントの応答

クライアントはサーバーの応答を受信した後、まずサーバーの証明書を検証します。証明書が信頼できる機関によって発行されていない場合、証明書内のドメイン名が実際のドメイン名と一致しない場合、または証明書の有効期限が切れている場合は、訪問者に警告が表示され、訪問者は通信を継続するかどうかを選択できます。

証明書に問題がなければ、クライアントは証明書からサーバーの公開鍵を取り出します。次に、以下の3つの情報をサーバーに送信します。

(1) 乱数。乱数はサーバーの公開キーで暗号化され、盗聴を防ぎます。

(2) エンコーディング変更通知。その後の情報は、双方が合意した暗号化方式とキーを使用して送信されることを示します。

(3) クライアント ハンドシェイク終了通知。クライアントのハンドシェイク フェーズが終了したことを示します。この項目は、以前に送信されたすべてのコンテンツのハッシュ値でもあり、サーバーの検証に使用されます。

上記の最初の項目の乱数は、ハンドシェイク フェーズ全体で表示される 3 番目の乱数であり、「プレマスター キー」とも呼ばれます。これにより、クライアントとサーバーは同時に 3 つの乱数を取得し、双方が事前に合意した暗号化方式を使用して、このセッションに使用する同じ「セッション キー」を生成します。

「セッション キー」の生成に 3 つの乱数を使用する必要がある理由については、dog250 が非常にわかりやすく説明しています:

「クライアントとサーバーの両方で、生成されたキーが毎回使用されないように乱数が必要です。」 SSL プロトコルの証明書は静的であるため、ネゴシエートされたキーのランダム性を保証するためにランダム要素を導入することが非常に必要です

RSA キー交換アルゴリズムの場合、プレマスターキー自体これは乱数に hello メッセージのランダム性を加えたもので、3 つの乱数は最終的にキー エクスポータを通じて対称キーから導出されます

プレマスターの存在は、SSL プロトコルが各ホストが認証できることを信頼していないことです。完全にランダムな乱数を生成する 乱数がランダムでない場合、プレ マスター シークレットのみをキーとして使用することは適切ではないため、新しいランダム要素を導入する必要があります。クライアントとサーバーは、プレマスターシークレットの 3 つの乱数によって生成されたキーを推測するのは簡単ではありません。1 つの疑似乱数はまったくランダムではないかもしれませんが、3 つの疑似乱数は次数が増えるごとにランダムに非常に近くなります。自由度が増すと、ランダム性が高まります。

さらに、前のステップでサーバーがクライアント証明書を必要とする場合、クライアントはこのステップで証明書と関連情報を送信します。

4.4 サーバーの最終応答

サーバーは、クライアントの 3 番目の乱数プレマスター キーを受信した後、このセッションに使用される「セッション キー」を計算して生成します。そして最後に以下の情報をクライアントに送信します。

(1) エンコーディング変更通知。その後の情報は、双方が合意した暗号化方式とキーを使用して送信されることを示します。

(2) サーバー ハンドシェイク終了通知。サーバーのハンドシェイク フェーズが終了したことを示します。この項目は、以前に送信されたすべてのコンテンツのハッシュ値でもあり、クライアントの検証に使用されます。

この時点で、ハンドシェイクフェーズ全体が終了します。次に、クライアントとサーバーは暗号化通信を開始します。完全に通常の HTTP プロトコルを使用しますが、コンテンツを暗号化するために「セッション キー」を使用します。 https接続の最初の数ミリ秒、ssl/tls、ssl/tls、ssl/tlsの参照リンク5。