SSL証明書はどのように検証されますか？

218

SSL証明書を安全に検証するために必要な一連の手順は何ですか？私の（非常に限られた）理解では、httpsサイトにアクセスすると、サーバーが証明書をクライアント（ブラウザー）に送信し、ブラウザーはその証明書から証明書の発行者情報を取得し、それを使用して発行者に連絡し、何らかの形で比較します。有効性の証明書。

  • これはどのように正確に行われますか？
  • プロセスは、中間者攻撃の影響を受けないようにしますか？
  • ランダムな人物が中間者攻撃で使用するために独自の検証サービスをセットアップして、すべてが「安全」に見えるようにするのを妨げているのは何ですか？
algorithm  security  ssl  certificate 
— rcreswick
ソース
— 匿名のカモノハシ
フロー理解する上で、このビデオは非常に有用であることが分かっyoutube.com/watch?v=T4Df5_cojAsを
— クリシュナ

回答:

308

これは非常に簡単な説明です：

  1. Webブラウザーは、Webサーバーの公開鍵を含むWebサーバーの証明書をダウンロードします。この証明書は、信頼できる認証局の秘密鍵で署名されています。

  2. Webブラウザーには、すべての主要な認証局の公開鍵がインストールされています。この公開鍵を使用して、Webサーバーの証明書が信頼できる認証局によって実際に署名されたことを確認します。

  3. 証明書には、Webサーバーのドメイン名またはIPアドレス、あるいはその両方が含まれています。Webブラウザーは、認証局に、証明書にリストされているアドレスが接続が開いているアドレスであることを確認します。

  4. Webブラウザーは、この接続のHTTPトラフィックを暗号化するために使用される共有対称鍵を生成します。これは、すべてに公開/秘密鍵暗号化を使用するよりもはるかに効率的です。ブラウザーは対称鍵をWebサーバーの公開鍵で暗号化してから送り返します。これにより、Webサーバーだけが秘密鍵を持っているため、Webサーバーだけがそれを復号化できるようになります。

認証局（CA）は、中間者攻撃を防ぐために不可欠です。ただし、署名されていない証明書でも、共有対称鍵にアクセスする方法がないため、暗号化されたトラフィックを受動的に傍受することはできません。

— エリ・コートライト
ソース
4
ステップ1.5前後で、サーバーは証明書に関連付けられた秘密鍵で何かに「署名」します。これは、名前/ IPチェックと組み合わせて、証明書の所有サイトのみが提示することを保証します。
— Darron、
68
接続しているFirefoxを使用して、このプロセスの完全な働いた例を参照するにはamazon.comを参照してくださいmoserware.com/2009/06/first-few-milliseconds-of-https.html
— ジェフ・モーザー
9
ブラウザにすべての主要な認証局の公開鍵がインストールされていることを知りませんでした。これで、SSL証明書がMITMのリスクなしにどのように検証されるかがわかります:)。ありがとう！
— OneChillDude 14
5
サーバーはCAuthorityに証明書を要求する必要があるため、サーバーに要求を送信します。CAはサーバーが有効であることをどのように確認できますか？
— voipp 2018
4
@voipp：すばらしい質問です！歴史的には、「からメールを送信するwebmaster@<domain-being-verified>か、「このファイルをドメインに置いて、あなたがそれを所有していることを証明する」などのいくつかのアプローチがありました。しかし、実際には、CAが取得していないドメインの証明書を所有者-有名な誰かが、
— 怪しげ
58

（上記のように）証明書を購入するだけでなく、証明書を無料で作成することもできます。これは「自己署名証明書」と呼ばれます。自己署名証明書と購入した証明書の違いは単純です。購入した証明書は、ブラウザがすでに知っている認証局によって署名されています。つまり、ブラウザは購入した証明書の信頼性を簡単に検証できます。

残念ながら、これにより、自己署名証明書は本質的にGoDaddyやVerisignなどの商用CAが販売するものよりも安全性が低く、使用する場合はブラウザーの警告/例外に耐えなければならないという一般的な誤解が生じました。これは誤りです。

自己署名証明書（またはbobinceが推奨するCA証明書）を安全に配布し、それをサイトを使用するブラウザーにインストールする場合、購入した証明書と同じくらい安全であり、中間者に対して脆弱ではありません。攻撃と証明書の偽造。明らかに、これは、ごく少数の人だけがサイトへの安全なアクセスを必要とする場合にのみ実行可能であることを意味します（たとえば、内部アプリ、個人のブログなど）。

— クリント・ハリス
ソース
1
実際、独自の証明書を安全に配布することは、猫の皮を剥ぐ1つの方法ですが、はるかに簡単な方法は、いわゆる「オープン」CAのいずれかに移動することです。CACert.orgは私のお気に入りです。証明書の発行を保護するために彼らが踏む手順を信頼している限り、ルート証明書のインポートは安全です。
— nsayer 2009
6
私はこのコメントが大好きです-残念ながら、これはCAの非常に重要な弱点を強調しています。Bob SmithからCA証明書をインポートするとします。BobSmithは、任意のドメイン（google.comとchase.comを含む）の証明書に署名できます。これが実際にGoDaddy / VerisignがOSに含まれるために多額のお金を払う理由です-彼らは悪意のある人のための証明書に署名しないことを確認するためのチェックがあることを確認するためにセキュリティ衣装によって吟味されます。「このCAはmysite.comの証明書にしか署名できない」と言えるはずです。
— Natalie Adams
自己署名入りの証明書の方が安全ではない。なぜなら、そこにあるCAは、本来持ってはならないものに署名するために支払われる可能性があるからだ。CA証明書をエンドポイントに安全に配布できる場合は、常に自己署名証明書を使用してください。
— javaPhobic 2015年
ほとんどの主要ブラウザで無料で検証されているCAはありますか？メールとドメイン名を所有していることを確認するための基本的な証明書を探しています。私が見つけたものは、ほとんどの主要なブラウザにはありません。
— Alex Kwitny、2015
で@NathanAdams 理論ビッグのCAは、あなたが説明するように偽の本命の発行から保つために獣医の要求になって...しかし、この物語読まれる：stripe.ian.shを
— nsayer
38

あなたが言った

ブラウザはその証明書から証明書の発行者情報を取得し、それを使用して発行者に連絡し、証明書の有効性を比較します。

次の2つの理由により、クライアントは発行者に確認する必要がありません。

  1. すべてのブラウザには、すべての主要なCA公開鍵の事前インストールされたリストがあります
  2. 証明書は署名されており、その署名自体は証明書が有効であることの十分な証拠です。これは、クライアントが自分で、発行者のサーバーに接続せずに、その証明書が本物であることを確認できるためです。これが非対称暗号化の優れた点です。

2.は1なしでは実行できないことに注意してください。

これは、前に作成したこの大きな図でよく説明されています

（下部の「署名とは何ですか？」にスキップしてください）

ブロブ

— イシャウチ
ソース
9
これは受け入れられるべき答えでした。@Eli Courtwrightの答えは、証明書がどのように機能するかを理解するためにimhoを短くする方法です。
— Felix Crazzolara、2018年
一度これを読むだけでは十分ではないかもしれませんが、SSLの細部にすでに精通している場合は、これで本当にすべてが統合されます。良くやった！
— Cameron Gagnon、
幻想的なイメージ。最後に私の質問を説明するもの。私が行くところはどこでも、「ブラウザが証明書が正しいことを確認する」と言ったところです。しかし、それはどのように行うのですか？これは答えを与えます。
— ori6151
8

クライアントには、SSL認証局の公開鍵のシード済みストアがあります。サーバーが信頼されるためには、サーバーの証明書から、中間機関からいわゆる「ルート」証明書の1つまでの信頼チェーンが必要です。

信頼できる機関のリストを調べたり、変更したりできます。多くの場合、これを行うのは、あなたが信頼していることがわかっている地方自治体の証明書を追加するためです。たとえば、勤務先の会社や通っている学校などです。

事前シード済みリストは、使用するクライアントによって異なる場合があります。大手SSL証明書ベンダーは、ルート証明書がすべての主要なブラウザー（$$$）にあることを保証しています。

攻撃者が信頼されたルート証明書の秘密鍵を持っていない限り、中間者攻撃は「不可能」です。対応する証明書が広く展開されているため、このような秘密鍵の公開は、一般にeコマースのセキュリティに深刻な影響を及ぼします。そのため、これらの秘密鍵は非常に厳密に保護されています。

— 言論者
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.