緑色の南京錠の謎が解けました: SSL ハンドシェイクはどのように機能するのでしょうか?

セキュリティを念頭に置いて毎日 Web を閲覧していると、ブラウザの Web サイト URL アドレスの近くにある有名な緑色の南京錠と、データ転送プロトコルの HTTPS バージョンについて考えます。 この記事では、HTTPS が本当に安全である理由と、通信が第三者による盗聴からどのように保護されているかについて説明します。

最初に、デジタル署名と暗号化という 2 つの基本的な暗号化の概念を簡単に紹介します。SSL ハンドシェイクと呼ばれるプロセスについて詳しく説明します。これは、クライアントとサーバーが通信の交換を開始する前に実行され、安全な暗号化コンテキストを確立するために使用されます。 最後に、クライアント証明書認証と呼ばれるオプションの手順を使用して、セキュリティをさらに強化する方法について説明します。

公開鍵暗号 101: 鍵ペア

プライベート メッセージを安全に交換するために暗号化手法を使用することを決めた 2 人のアリスとボブに会いましょう。 彼らが直面しなければならない最初の選択は、2 つの異なる暗号化タイプ、つまり対称鍵暗号化と非対称鍵暗号化(公開鍵暗号とも呼ばれます) の間です。

しかし、待ってください、これらのキーは何ですか? 基本的に、キーはランダムな文字列であることを単純化できます。 このシーケンスを使用して、メッセージを変換 (特定の暗号化操作を実行) できます。これについては、すぐに掘り下げます。

対称鍵暗号

対称鍵暗号を使用する場合、送信者は鍵を生成し、それを受信者用に複製します。 送信者は元のキーを保存し、複製が受信者に配信されます。 通信の両端で暗号化操作に同じキーが使用されます。

また、対称鍵暗号化の主なメリットとデメリットは何ですか?

非対称鍵暗号

非対称鍵暗号を使用する場合、送信者と受信者の両方が鍵ペア (公開鍵と秘密鍵) を生成します。 キーは数学的に相互に結合され、さまざまな暗号操作で連携します。 送信者と受信者の両方が秘密鍵を安全に保存しますが、特別な予防措置なしで公開鍵を交換できます。 彼らは、一種の「公開鍵のイエロー ページ」 (公開鍵サーバー) を使用して公開鍵を送信し、誰でもアクセスできるようにすることさえできます。

非対称鍵暗号方式の長所と短所は何ですか?

非対称暗号のセットアップはより安全であるため、アリスとボブはそれを採用することにしました! 今、彼らはそれを活用して、通信のセキュリティと完全性を確保することについて考え始めることができます.

公開鍵暗号 101: 暗号化

Alice が Bob にメッセージを送信するとき、彼女はその内容が他の人に見られないようにしたいと考えています。 彼女はメッセージを暗号化することにしました。 これを実現するために、アリスは最初にボブの公開鍵を鍵サーバーから取得するか、通信チャネルを介してボブから直接取得する必要があります。 アリスがキーを取得すると、送信したいメッセージにボブの公開キーを使用して暗号化操作を適用できます。

一般的に言えば、このプロセスでは、メッセージは暗号化アルゴリズム (別名暗号) によってブロック (最も一般的) に取り込まれ、メッセージとキーの間のいくつかのビット操作が実行され、暗号化されたメッセージ (別名暗号文) である出力が生成されます。 . ボブが暗号化されたメッセージを受け取ったとき、彼は自分の秘密鍵でそれを復号化できる唯一の人です。

ノート：

• メッセージの暗号化– 送信者は受信者の公開鍵でメッセージを暗号化します
• メッセージの復号化– 受信者は秘密鍵を使用してメッセージを復号化します

公開鍵暗号 101: 署名

メッセージの内容が明らかにならないようにすることとは別に、送信者の身元を確認し、メッセージが変更されていないかどうかを確認できることも同様に重要です。 デジタル署名(メッセージに添付された別のオブジェクト) がまさにこれら 2 つの理由で使用されます。

Alice はまず、ハッシュ アルゴリズムを使用してメッセージ ハッシュを作成し、署名を生成します。 ハッシュとは、メッセージに対して一方向の数学関数を計算することで、短い固定値の出力 (入力が異なると異なる) を生成します。 次に、秘密鍵を使用して、生成されたハッシュを暗号化(署名) します。

次に、Bob がメッセージと署名を受け取ると、最初に Alice の公開鍵を使用して署名を復号化できます。 それが成功すると、署名が本当に Alice によって生成されたものであることがわかります (そうでなければ、彼女の公開鍵による復号化は失敗します)。

次に、ボブはメッセージを受け取り、アリスが以前持っていたのと同じアルゴリズムを使用してそれをハッシュし、メッセージのハッシュがアリスによって生成されたものと同じであることを確認できます。 ハッシュが一致すると、メッセージが改ざんされていないことがわかります。

ノート：

• 署名の生成- 送信者は自分の秘密鍵でメッセージ ハッシュを暗号化 (署名) し、署名を作成します。
• 署名の検証- 受信者は最初に署名からメッセージ ハッシュを復号化し、彼が計算したハッシュが署名からのハッシュと一致するかどうかを確認します。
• 暗号化と署名は別々に使用できますが、最高のセキュリティを確保するために、通常は組み合わせて使用​​します。 したがって、遭遇できるほとんどの暗号関数は、 encryptSignMessage() 、 decryptVerifyMessage()などと呼ばれます。

アリスとボブの物語についていくのに苦労していないことを願っています. すべてを明確にしてまとめるため、全体の流れをもう一度説明します。

1. アリスはボブにメッセージを送りたい
2. アリスは自分の秘密鍵を受け取り、署名を生成します
3. アリスはボブの公開鍵を受け取り、メッセージを暗号化します
4. アリスがボブにメッセージを送る
5. ボブはアリスの公開鍵を受け取り、署名を検証します
6. ボブは自分の秘密鍵を使用してメッセージを復号化します

よし、それで十分な理論だ。 これらすべてが HTTPS でどのように使用されるかを見てみましょう。

SSL ハンドシェイク

よろしくお願いします

クライアントがサーバーへの接続を開始するとき、最初に適切な紹介を行い、残りの通信の暗号化コンテキストを確立することが重要です。 これは、ヘッダーとリクエスト本文を解析する前に、HTTPS CONNECT ステップで実行できます。 すべては、クライアントがクライアント ハロー メッセージを送信することから始まります。

最も重要なことは、メッセージには、クライアントが理解できる暗号化アルゴリズムと、サポートされている圧縮アルゴリズム、プロトコル バージョン、セッション ID などのいくつかの追加資料が含まれていることです。サーバーの公開鍵を含むサーバー証明書が含まれています (はい、プロセスは公開鍵暗号化に基づいています。アリスとボブが選択したのと同じ方法です)。

証明する機関

今度は、この段階で次のゲストを迎える時が来ました:認証局(CA) です。 名前は真面目に聞こえますが、基本的に世界中で信頼できると考えられている、多くのストリートクレジットを持つサードパーティエンティティです. このようなエンティティは、サーバーの ID を検証し、デジタル署名をサーバー証明書と共に配置できます (ボブにメッセージを送るときのアリスと同様)。

証明書の検証

最後に、ブラウザの URL アドレスの横にあるタイトルの緑色の南京錠について考えてみましょう。

各 Web クライアントには、既知の信頼できる認証局の公開鍵のリストがバンドルされています。 この記事の冒頭で、署名は送信者の秘密鍵を使用して生成され、送信者の公開鍵を使用して検証できると述べたことを覚えているかもしれません。 まあ、これはまさにクライアントがすることです。 バンドルされている信頼できる CA のリストを調べて、サーバー証明書の署名が信頼できる CA のいずれかに属しているかどうかを確認します。 一致する場合は、証明書を受け入れます。南京錠が緑色に変わった瞬間です。

しかし、これは最初のステップに過ぎず、セキュリティとはまだ関係ありません。 誰でも公開鍵証明書をコピーしてサーバーに配置し、接続しているクライアントに提示できますよね?

クライアントは、サーバー証明書を検証した後、通信を暗号化するための対称キーを作成します。 しかし、最初に述べたように、対称鍵の問題は、転送中に傍受されやすいことです。 この段階では、クライアントとサーバーは共通の暗号化コンテキストを持っていません。 そのため、クライアントは対称キーをサーバーに送信しますが、最初にサーバーの公開キーで暗号化します。 次に、サーバーはそれを受信し、安全な接続を確立するために暗号化を解除する機能を必要とします。

したがって、誰かが盗んだ公開鍵証明書を提示したとしても、これは彼らが失敗するステップです。 サーバー証明書の公開鍵にバインドされた有効な秘密鍵は、対称鍵を復号化するために不可欠です。 もちろん、正当なサーバーには秘密鍵が安全に保存されているため、これは問題ではありません。 これを使用して、対称キーを復号化し、以降の通信を暗号化できます。

要約すると、SSL ハンドシェイクは、対称暗号方式と非対称暗号方式の両方が使用されるプロセスです。 最初に、非対称キー ペアが接続を開始し、対称キーが移動するための安全な方法を提供します。 最初に指摘したように、対称暗号の操作はより高速であるため、セットアップ後の通信全体で使用すると有益です。 また、安全な接続が確立されると、有効期限が切れるまで再利用されるため、各クライアント要求の前に非対称キーの設定が行われることはありません。

また、実際には、証明書は最も有名な信頼できる CA (ルートと呼ばれる) によって直接署名されていないことにも言及する価値があります。 それでも、ルート CA は中間証明書に署名し、最終的にサーバー証明書に署名します。これにより、証明書のチェーンが作成され、有効な署名が満たされるまで接続クライアントがチェックします。 確かにセキュリティが向上します。中間 CA の 1 つが侵害された場合、影響を受ける人は少なくなります。

クライアント証明書の検証

ここで、理解するために必要なすべての知識があるので、簡単に説明できるオプションのステップが 1 つあります。 セキュリティを強化するために、安全な接続を確立した後にクライアント証明書を要求して検証するようにサーバーを構成できます。

これも同じように機能しますが、今回はクライアントが証明書を送信し、サーバーが信頼できる認証局のリストを調べて検証します。 また、サーバーは開発者の管理下にある (クライアントとは対照的に、つまり Web ブラウザーやモバイル オペレーティング システム) ため、バックエンド開発者は信頼できる証明書のリストを簡単に変更できることにも注意してください。

企業ネットワークは、通常、このメカニズムを使用します。 ほとんどの場合、クライアント証明書は従業員のデバイスにインストールされたデバイス管理システムによって生成され、会社が生成したルート証明書で署名されます。 同じ証明書がバックエンド環境にも追加されます。 このようにして、企業のバックエンドは、クライアントが接続したときに証明書を簡単に検証できます。

バックエンド ソリューションを見てみましょう

続きを読む

まとめとして、フロー全体の図を見てみましょう。

概要

記事の最後に到達しました！ うまくいけば、 HTTPS での暗号化セットアップの実装メカニズムと、署名および暗号化プロセスの適用方法をすでに理解していることを願っています。

物事がどのように機能するかを知っているので、データ暗号化についてより自信を持っているはずです. それでも、ブラウザの緑色の南京錠はまだ安全を保証するものではないことを覚えておくことが不可欠です. セキュリティが重要なコンテキストでは、証明書も詳しく調べる必要があります。 彼らが言うように、事前警告は事前準備です！