SSLは実際にどのように機能しますか？

Question

SSLはどのように機能しますか？

クライアント（またはブラウザー？）およびサーバー（またはWebサーバー）のどこに証明書がインストールされていますか？

ブラウザにURLを入力し、サーバーからページを取得すると、信頼/暗号化/認証プロセスはどのように開始されますか？

HTTPSプロトコルはどのように証明書を認識しますか？証明書がすべての信頼/暗号化/認証機能を実行するのにHTTPが証明書で機能しないのはなぜですか？

Mark E. Haase · Answer

注：私は元の回答を非常に急いで書きましたが、それ以来、これはかなり人気のある質問/回答になりました。そのため、少し拡大してより正確にしました。

TLS機能

「SSL」はこのプロトコルを参照するために最もよく使用される名前ですが、SSLは特に90年代半ばにNetscapeによって設計された独自のプロトコルを指します。「TLS」はSSLに基づいたIETF標準なので、回答ではTLSを使用します。最近では、Web上の安全な接続のほぼすべてが、SSLではなくTLSを実際に使用している可能性があります。

TLSにはいくつかの機能があります。

アプリケーション層のデータを暗号化します。（あなたの場合、アプリケーション層のプロトコルはHTTPです。）
サーバーをクライアントに対して認証します。
サーバーに対してクライアントを認証します。

＃1と＃2は非常に一般的です。＃3はあまり一般的ではありません。あなたは＃2に焦点を合わせているようですので、その部分を説明します。

認証

サーバーは、証明書を使用してクライアントに対して自身を認証します。証明書は、Webサイトに関する情報を含むデータの塊です[1]。

ドメイン名
公開鍵
それを所有する会社
発行されたとき
有効期限が切れたとき
誰が発行したか
等。

証明書に含まれる公開鍵を使用して、そのサーバーに安全に保存する必要がある対応する秘密鍵によってのみ復号化できるメッセージを暗号化することにより、機密性（上記の＃1）を実現できます。後で混乱しないように、このキーペアをKP1と呼びましょう。また、証明書のドメイン名がアクセスしているサイトと一致することを確認できます（上記の＃2）。

しかし、攻撃者がサーバーとの間で送受信されるパケットを変更でき、その攻撃者が提示された証明書を変更し、自分の公開鍵を挿入したり、その他の重要な詳細を変更した場合はどうでしょうか？その場合、攻撃者は、安全に暗号化されていると思われるメッセージを傍受および変更できます。

この攻撃を防ぐために、証明書は他の誰かの秘密鍵によって暗号的に署名され、対応する公開鍵を持っている人が署名を検証できるようにします。このキーペアをKP2と呼び、これらがサーバーが使用しているのと同じキーではないことを明確にします。

認証局

KP2を作成したのは誰ですか？誰が証明書に署名しましたか？

少し単純化しすぎて、認証局がKP2を作成し、彼らは秘密鍵を使用して他の組織の証明書に署名するサービスを販売しています。たとえば、証明書を作成し、Verisignなどの会社に支払い、秘密鍵で署名します。[3] Verisign以外はこの秘密鍵にアクセスできないため、誰もこの署名を偽造できません。

そして、その署名を検証するために、KP2の公開鍵を個人的にどのように取得しますか？

証明書が公開キーを保持できることはすでに見てきました。コンピューター科学者は再帰を好むので、KP2公開キーを証明書に入れて、そのように配布してみませんか。これは、最初は少しおかしく聞こえますが、実際には、まさにそれが機能する方法です。 Verisignの例を続けると、Verisignは、自分が誰であるか、どの種類の署名が許可されているか（他の証明書）、および公開キーに関する情報を含む証明書を生成します。

これで、Verisign証明書のコピーがあれば、それを使用して、訪問したいWebサイトのサーバー証明書の署名を検証できます。簡単ですね？！

まあ、それほど速くありません。 Verisign証明書をsomewhereから取得する必要がありました。誰かがVerisign証明書をスプーフィングし、そこに自分の公開鍵を入れたらどうなりますか？その後、彼らはサーバーの証明書に署名を偽造することができ、私たちは始めたところに戻ってきました：中間者攻撃。

証明書チェーン

再帰的に考え続けると、もちろん3番目の証明書と3番目のキーペア（KP3）を導入し、それを使用してVerisign証明書に署名できます。これを証明書チェーンと呼びます。チェーン内の各証明書は、次の証明書を検証するために使用されます。うまくいけば、この再帰的なアプローチがずっとカメ/証明書に過ぎないことを既におわかりいただけると思います。どこで止まりますか？

無限の数の証明書を作成することはできないので、証明書チェーンは明らかにsomewhereを停止する必要があり、それは証明書をチェーンに含めることによって行われますisself-signed.

頭から爆発した脳の破片を拾い上げる間、しばらく休止します。 自己署名？！

はい、証明書チェーンの末尾（別名「ルート」）に、独自のキーペアを使用して自身に署名する証明書があります。これにより、無限再帰の問題は解消されますが、認証の問題は修正されません。私は政治、理論物理学を専攻し、尻蹴りを適用し、下部に自分の名前を署名すると言う偽のプリンストン卒業証書を作成できるのと同じように、誰もがそれについて何でも言う自己署名証明書を作成できます。

この問題に対する[ややエキサイティングな]解決策は、明示的に信頼する自己署名証明書のセットを選択することです。たとえば、「ItrustこのVerisign自己署名証明書」と言う場合があります。

明示的な信頼が確立されていれば、証明書チェーン全体を検証できます。チェーン内に証明書がいくつあっても、各署名をルートまで検証できます。ルートに到達すると、そのルート証明書が明示的に信頼する証明書であるかどうかを確認できます。もしそうなら、私はチェーン全体を信頼することができます。

授与された信頼

TLSでの認証は、conferred trustのシステムを使用します。自動車整備士を雇いたい場合、見つけたランダムな整備士を信用できないかもしれません。しかし、おそらく私の友人は特定のメカニックを保証します。私は友人を信頼しているので、そのメカニズムを信頼できます。

コンピューターを購入するか、ブラウザーをダウンロードすると、明示的に信頼する数百のルート証明書が付属します。[4]これらの証明書を所有および運用する企業は、証明書に署名することにより、他の組織にその信頼を付与できます。

これは完璧なシステムにはほど遠い。 CAが証明書を誤って発行する場合があります。これらの場合、証明書の失効が必要になる場合があります。発行された証明書は常に暗号的に正しいため、失効は注意が必要です。以前に有効な証明書が取り消されているかどうかを調べるには、帯域外プロトコルが必要です。実際には、これらのプロトコルの一部はあまり安全ではなく、多くのブラウザはとにかくそれらをチェックしません。

CA全体が危険にさらされることもあります。たとえば、Verisignに侵入してルート署名キーを盗む場合、世界中のany証明書を偽装できます。これは、Verisignの顧客だけに影響するわけではないことに注意してください。私の証明書がThawte（Verisignのライバル）によって署名されていても、それは問題ではありません。私の証明書は、Verisignからの侵害された署名キーを使用して偽造できます。

これは単なる理論的なものではありません。それは野生で起こった。 DigiNotarは有名にハッキングされたそしてその後破産しました。 Comodoもハッキングされました、しかし、それらは今日までビジネスに残っています。

CAが直接侵害されていない場合でも、このシステムには他の脅威があります。たとえば、政府は、CAに偽造証明書への署名を強制するために法的強制を使用します。雇用主は、従業員のコンピューターに独自のCA証明書をインストールできます。これらのさまざまなケースでは、「安全」であると期待されるトラフィックは、実際にその証明書を制御する組織に完全に可視/変更可能です。

収束、 [〜＃〜] tack [〜＃〜] 、および [〜＃〜] dane [〜＃〜 ] 。

文末脚注

[1] TLS証明書データは X.509標準に従ってフォーマットされています。 X.509は ASN.1 （ "Abstract Syntax Notation＃1"）に基づいています。つまり、notです。バイナリデータ形式。したがって、X.509はバイナリ形式にエンコードする必要があります。 DERおよびPEM は、私が知っている2つの最も一般的なエンコーディングです。

[2]実際には、プロトコルは実際には対称暗号に切り替わりますが、それは質問とは関係のない詳細です。

[3]おそらく、CAは、証明書に署名する前に、あなたが誰であるかを実際に検証します。彼らがそうしなかった場合、google.comの証明書を作成し、CAに署名を依頼するだけで済みます。その証明書を使用して、google.comへの「安全な」接続を仲介者にできます。したがって、検証手順はCAの運用において非常に重要な要素です。残念ながら、世界中の何百ものCAでこの検証プロセスがどれほど厳格であるかはあまり明確ではありません。

[4] Mozillaの信頼できるCAのリストをご覧ください。

sanjay_kv · Answer

HTTPSは、[〜＃〜] http [〜＃〜]とSSL（Secure Socket Layer）クライアント（ブラウザ）とWebサーバー（アプリケーションはここでホストされます）間の暗号化された通信を提供します。

なぜそれが必要なのですか？

HTTPSは、ネットワークを介してブラウザーからサーバーに送信されるデータを暗号化します。そのため、送信中にデータを盗聴することはできません。

ブラウザとWebサーバーの間でHTTPS接続がどのように確立されますか？

ブラウザは https://payment.com に接続しようとします。
payment.comサーバーは、ブラウザーに証明書を送信します。この証明書には、payment.comサーバーの公開鍵と、この公開鍵が実際にpayment.comに属していることを示すいくつかの証拠が含まれています。
ブラウザは証明書を検証し、payment.comの適切な公開キーを持っていることを確認します。
ブラウザは、payment.comサーバーへの接続に使用するランダムな新しい対称キーKを選択します。 payment.com公開鍵の下でKを暗号化します。
payment.comは、秘密鍵を使用してKを復号化します。これで、ブラウザーと支払いサーバーの両方がKを知っていますが、他の誰も知りません。
ブラウザがpayment.comに何かを送信したいときはいつでも、Kの下でそれを暗号化します。 payment.comサーバーは受信時に暗号化を解除します。 payment.comサーバーがブラウザに何かを送信したいときはいつでも、Kの下でそれを暗号化します。

このフローは、次の図で表すことができます。 enter image description here

Abhishek Jain · Answer

このプロセスを簡単に説明する小さなブログ記事を書きました。お気軽にご覧ください。

SSLハンドシェイク

同じからの小さなスニペットは次のとおりです。

「クライアントはHTTPS経由でサーバーにリクエストを送信します。サーバーはSSL証明書と公開キーのコピーを送信します。ローカルの信頼できるCAストアでサーバーの身元を確認した後、クライアントはシークレットセッションキーを生成し、サーバーのパブリックを使用して暗号化しますサーバーは秘密キーを使用して秘密セッションキーを復号化し、クライアントに確認応答を送信します。セキュリティで保護されたチャネルが確立されました。」

Kaushal Kumar Panday · Answer

Mehaaseは既に詳細に説明しています。このシリーズに2セントを追加します。 SSLハンドシェイクと証明書を中心にした多くのブログ投稿があります。このほとんどはIIS Webサーバーを中心に展開しますが、投稿はまだ一般的なSSL/TLSハンドシェイクに関連しています。参考のためにいくつか紹介します。

処理しない[〜＃〜] certificates [〜＃〜]＆[〜＃〜] ssl [〜＃〜]1つのトピックとして。それらを2つの異なるトピックとして扱い、それらが一緒に働いている人を見ようとします。これは質問に答えるのに役立ちます。

証明書ストアを介した通信パーティ間の信頼の確立

SSL/TLS通信は、信頼のみに基づいて機能します。インターネット上のすべてのコンピューター（クライアント/サーバー）には、管理するルートCAと中間CAのリストがあります。これらは定期的に更新されます。 SSLハンドシェイク中、これは信頼を確立するための参照として使用されます。たとえば、SSLハンドシェイク中に、クライアントがサーバーに証明書を提供するとき。サーバーは、証明書を発行したCAがCAのリストに存在するかどうかを確認しようとします。これを実行できない場合、証明書チェーンの検証を実行できなかったと宣言します。（これは答えの一部です。これも[〜＃〜] aia [〜＃〜]で調べます。）クライアントも同様です。 Server Helloで受信したサーバー証明書の同様の検証。 Windowsでは、PowerShellを介してクライアントとサーバーの証明書ストアを確認できます。 PowerShellコンソールから以下を実行します。

PS証明書：> ls場所：CurrentUser StoreNames：{TrustedPublisher、ClientAuthIssuer、Root、UserDS ...}

場所：LocalMachine StoreNames：{TrustedPublisher、ClientAuthIssuer、リモートデスクトップ、ルート...}

FirefoxやOperaなどのブラウザーは、証明書管理のために基盤となるOSに依存しません。独自の証明書ストアを維持します。

SSLハンドシェイクは、対称暗号と公開鍵暗号の両方を使用します。サーバー認証はデフォルトで行われます。クライアント認証はオプションであり、サーバーエンドポイントがクライアントを認証するように構成されているかどうかによって異なります。これについて詳しく説明したので、私のブログ投稿を参照してください。

最後にこの質問について

HTTPSプロトコルはどのように証明書を認識しますか？証明書がすべての信頼/暗号化/認証機能を実行しているのにHTTPが証明書で機能しないのはなぜですか

Certificatesは、形式が X.509 standardで定義されている単なるファイルです。通信相手の身元を証明する電子文書です。 HTTPS = HTTP + SSLは、2つのパーティが互いに通信する方法に関するガイドラインを定義するプロトコルです。

詳細

証明書を理解するには、証明書とは何かを理解し、証明書管理についても読む必要があります。これらは重要です。
これを理解したら、TLS/SSLハンドシェイクを続行します。これについては、RFCを参照してください。しかし、それらはガイドラインを定義するスケルトンです。これを詳細に説明する私のものを含むいくつかのブログ投稿があります。

上記のアクティビティが完了したら、証明書とSSLについて十分に理解できます。