1. SSL の概要
SSL の中国語名はSecure Sockets Layer (Secure Sockets Layer) で、現在最も広く使用されているデータ暗号化プロトコルです。このプロトコルは、SSL1.0、SSL2.0、SSL3.0 という 3 つのバージョンを経てきました。IETF が SSL を標準化し、TLS (Transport Layer Security) トランスポート層セキュリティと呼ぶまでは。TLS (Transport Layer Security) は、厳密に言えば SSL をより安全にアップグレードしたもので、現在は基本的に TLS プロトコルが使用されています。ただし、SSL という用語の方が一般的に使用されているため、当社では依然としてセキュリティ証明書を SSLまたはSSL/TLSと呼んでいます。これまで、TLS は TLS1.0、TLS1.1 (2006)、TLS1.2 (2008)、TLS1.3 (2018) という 4 つのバージョンを経てきました。
1.1 非対称暗号化アルゴリズム
いわゆる「非対称暗号化技術」とは、「暗号化」と「復号化」に異なる鍵を使用すること、つまり、各ユーザーが公開鍵と秘密鍵の 2 つの鍵を持っていることを意味します。公開鍵は外部に公開されます。誰もが自分の公開鍵を見ることができます。秘密鍵は自分で保管されます。誰もが自分の秘密鍵だけを知り、他の人は知りません。ユーザーの公開キーで暗号化された後は、ユーザーの秘密キーのみが復号化できます。この場合、公開キーを使用してメッセージを暗号化し、(公開キーを使用した) 特定の人だけがメッセージを復号化できるようにします。 2 番目のケースでは、公開キーを使用して情報を復号化し、この情報が実際に私によって公開されたものであり、完全かつ正確であることを他の人が確実に認識できるようにします。これにより、受信者は、そのメッセージが実際にデジタル署名と呼ばれる秘密鍵を持っている人物から送信されたものであり、公開鍵はデジタル証明書の形式であることがわかります。
1.2 対称暗号化アルゴリズム
いわゆる「対称暗号化技術」は比較的単純で、「暗号化」と「復号化」に同じ鍵が使用されます。7zip または WinRAR を使用して、パスワード (パスワード) を使用して暗号化されたアーカイブを作成するのと同じです。次回この圧縮ファイルを解凍するときは、同じパスワードを入力する必要があります。この例では、パスワード/パスワードは、先ほど述べた「キー」のようなものです。
1.3 特徴
• SSL は送信データを暗号化して、第三者によるデータの盗用を防止できます。
• SSL プロトコルには改ざん防止の仕組みがあり、送信データが送信中に改ざんされた場合、通信する双方がすぐにそれを知ることができます。
• SSL には、 ID のなりすましを防ぐ認証メカニズムもあります。
1.4 TCP/IP モデルにおける SSL の位置
2. 基本的な操作手順
SSL/TLS プロトコルの基本的な考え方は、非対称暗号化アルゴリズムを使用することです。クライアントはまずサーバーから公開キーを要求し、次にその公開キーを使用してデータを暗号化します。サーバーは暗号文を受信した後、それを復号化します。独自の秘密鍵を使用して。
• 1. クライアントはサーバーに公開キーを要求し、検証します。
• 2. 双方が交渉して「対話キー」を生成します。
• 3. 両者は「会話キー」を使用して暗号化通信を行います。
上記の簡単なプロセスからもわかるように、クライアントとサーバー間の各セッションで暗号化操作に公開鍵が使用される場合、公開鍵暗号化による大きくなるために、対称暗号化アルゴリズムも使用します。したがって、この暗号化計算にかかる時間を短縮するために、インタラクティブ データには対称暗号化アルゴリズムを使用します(消費時間は非対称アルゴリズムよりも大幅に短くなります)。使用する必要があるのは公開キー暗号化アルゴリズムのみです。最初にサーバーによって提供される対称暗号化アルゴリズムの会話キー、次のデータ対話は会話キーを使用して暗号化および復号化できます。
上記 1 と 2 を「ハンドシェイク フェーズ」とも呼びます。ハンドシェイク フェーズでは、クライアントとサーバーの間で 4 回の通信が行われ、通信データはすべて平文で送信されます。
2.1 クライアントのリクエスト
クライアントはサーバーに暗号化通信のリクエストを送信します。このステップは ClientHello リクエストと呼ばれます。クライアントが提供する情報は次のとおりです。
| 情報 |
|---|
| クライアントがサポートする TLS プロトコルのバージョン |
| クライアントは、その後の「セッション キー」の生成のために乱数を生成します。 |
| クライアントがサポートする暗号化方式 (DHE-RSA 非対称暗号化アルゴリズムなど) |
| サポートされている圧縮アルゴリズム |
2.2 サーバーの応答
| 情報 |
|---|
| 使用するTLSプロトコルのバージョンを確認する |
| サーバーは、その後の「会話キー」の生成のために乱数も生成します。 |
| DHE-RSA 非対称暗号化アルゴリズムなど、使用されている暗号化アルゴリズムを確認します。 |
| サーバーの証明書 |
| サーバーがクライアントの身元を確認する必要がある場合は、証明書要求が含まれ、クライアントに身元を確認するためのクライアント証明書の提供を求めます。 |
2.3 クライアントが再度応答する
クライアントは応答を受け取った後、まずサーバーの証明書を検証します。問題がある場合は、ユーザーにアクセスを継続するかどうか警告を表示します。問題がなければ、クライアントは証明書内の公開鍵を取り出し、次に、次のデータをサーバーに送信します
| 情報 |
|---|
| 公開鍵で暗号化した乱数データを送信します。この乱数はプレマスター鍵とも呼ばれます |
| エンコーディング変更通知。合意された暗号化方式とキーを使用して今後のデータが送信されることをサーバーに通知します。 |
| クライアント ハンドシェイク終了通知。このアイテムは、以前に送信されたすべてのコンテンツのハッシュ値でもあり、サーバーに改ざん防止検証を提供するために使用されます。 |
この時点で、セッション キーの生成になぜ 3 つの乱数を使用する必要があるのかという疑問が生じるかもしれませんが、その理由は次のとおりです。
クライアントでもサーバーでも、生成されるキーが毎回同じにならないように乱数が必要です。SSL プロトコルの証明書は静的であるため、ネゴシエートされたキーのランダム性を保証するためにランダム要素を導入することが非常に必要です。
RSA キー交換アルゴリズムの場合、プレマスターキー自体は乱数に hello メッセージのランダム性を加えたもので、最終的に 3 つの乱数から **キー エクスポーター** を通じて対称キーが導出されます。
プレマスターの存在は、SSL プロトコルが各ホストが完全にランダムな乱数を生成できることを信頼していないためです。乱数がランダムでない場合、プレマスターの秘密が推測される可能性があるため、単に使用するのは適切ではありません。プレマスターシークレットをキーとして使用するため、新しいランダム要素を導入する必要があり、その場合、クライアントとサーバーによって生成されたキーにプレマスターシークレットの 3 つの乱数を加えたものを推測するのは容易ではありません。擬似ランダムはランダムに非常に近く、自由度を追加するたびにランダム性が 1 つ以上増加します。」
2.4 サーバーの最終応答
サーバーはクライアントから 3 番目の乱数プレマスター キーを受信した後、このセッションに使用される「セッション キー」を計算して生成します。
| 情報 |
|---|
| エンコーディング変更通知。合意された暗号化方式とキーを使用して今後のデータが送信されることをサーバーに通知します。 |
| サーバー ハンドシェイク終了通知。このアイテムは、以前に送信されたすべてのコンテンツのハッシュ値でもあり、クライアントにデータの改ざん防止の検証を提供するために使用されます。 |
この時点で、ハンドシェイク フェーズ全体が終了します。その後、クライアントは暗号化された状態でサーバーと通信できるようになり、データは「セッション キー」を使用して対称的に暗号化されます。