自己署名証明書のSSL証明書の警告を無視しても、暗号化は引き続き適用されますか？
警告を無視して証明書をインストールせずに続行すると、自己署名証明書を使用するデバイスとの通信に暗号化が引き続き適用されますか？暗号化を確実にするためにインストールする必要がありますか、それともユーザーが警告を無視して続行するとデフォルトで暗号化されますか？
整合性の部分またはCAによるサーバーまたはデバイスの検証が適用されないことを理解していますが、ブラウザーの警告を無視して続行した場合に暗号化の部分が適用されるかどうかを知りたいだけです。
インストールが必要な場合、httpsなどを介して内部ネットワークから内部専用アセットにのみログインする環境では、たとえば内部ポータルを使用する場合、その自己署名証明書を信頼済みリストに追加して、暗号化が適用され、MiTM攻撃では送信された資格情報を確認できません。純粋な内部専用の本番環境設定（CAがまだ設定されていない場合）では、自己署名証明書のベストプラクティスは何でしょうか。
暗号化がまだ適用されていることを警告する証明書を無視しても、認証されていない暗号化であるため、アクティブな攻撃者は接続を再暗号化できるため、アクティブな攻撃者（通過するデータを傍受して変更できるMITMの攻撃者）に対して暗号化は役に立たない。
実稼働環境で自己署名証明書を使用するためのベストプラクティスは、証明書のフィンガープリントを、信頼できるチャネルを通じて取得された期待される証明書のフィンガープリントと比較することです。証明書のフィンガープリントを確認したら、信頼できるリストに追加して証明書を固定する必要があります。さらに、多数の証明書と多数のデバイスを操作する必要がある場合は、独自の認証局を作成し、そのルートCA証明書をルート信頼リストに追加できます。
はい、通信は依然として自己署名証明書で暗号化されています。
自己署名証明書はユーザーが作成できますが、攻撃者が作成することもできます。自己署名証明書の使用を主張する場合は、証明書を信頼できるものとしてマークすることをお勧めします。これにより、アクティブな中間者攻撃が発生した場合に警告が表示されます。
独自のCA証明書を作成することは、自己署名証明書を作成することよりも難しくなく、CA証明書を信頼するだけで、現在および将来的に信頼できる証明書を作成できるという利点があります。
暗号化には、3つの主要なセキュリティ目標があります。
- 守秘義務
- 誠実さ
- 認証
TLS/SSLハンドシェイクの証明書は、認証を提供するために使用されます。つまり、クライアントが目的のサーバーと通信していることをクライアントに保証するためであり、一部の中間者攻撃者ではありません。証明書の警告を無視すると、接続のこのプロパティが強制終了されます。
接続は引き続き暗号化手段によって保護され、機密性と完全性が提供されます。つまり、最初の通信パートナー（だれでも）だけがメッセージを読み取ったり変更したりできます。
暗号化は引き続き適用されますが、自己署名証明書の問題は、接続先のサーバーが本人であることを保証できないことです。
問題は、彼らが自己署名するほどではなく、信頼できる第三者によって署名されていないことです。 https Webサイトを参照すると、コンピューターは、与えられた証明書が信頼できるサードパーティによって署名されていることを確認します。つまり、サーバーのセキュリティが侵害されていない限り、暗号化されたチャネルandあなたが接続しているのは、彼らがそうだと言う人です。自己署名があると、2番目の部分を確信できません。
MITMを描いてみます。
===| When you accept a self-signed cert |===
===| and get lucky |===
+--[Your browser]--+ +--[Server S]--+
| accepts cert A | | has cert A |
| sends +---------------------+-------------------> has key A |
| POST /secret | | | decrypts |
| encrypts for A | +------+-----+ | |
+------------------+ pahQu:eiSh6m | sees |
(seen on wire) | POST /secret |
+--------------+
===| When you dismiss browser warnings |===
===| and accept whatever |===
+--[Your browser]--+ +---[Evil Chris' server]----+ +--[Server S]--+
| accepts cert M | | | | |
| sends | | has cert M | accepts | | has cert A |
| POST /secret +--+---> has key M | cert A +---+--> has key A |
| encrypts for M | | | decrypts | reencrypts | | | decrypts |
+------------------+ | | for A | | | |
| | ! SEES ! | | | sees |
+------------+ | POST /secret | | | POST /secret |
fex5be;P[ivR +---------------------------+ | +--------------+
(seen on wire) |
+-----+------+
Qui8paeY]u0V
(seen on wire)
見る？暗号化は、認証なしでは少し役に立たない（つまり、簡単に破られる）。
「本当の」（自己署名ではない）証明書は認証を提供します。ブラウザが、Webサイト/ドメイン所有者が制御するサーバーと通信しているか、まったく異なるマシンかを確認する方法です。
それは言った; はい暗号化は引き続き適用されます。偽の証明書があっても、passive盗聴から保護されます。ただし、原則として、一部のネットワークデバイスは自己署名証明書を検出し、完全にパッシブな方法でSSL MITMを実行できます。指紋のバイトごとの正確な一致の検証を開始するまで見えません。
イントラネットで使用する場合は、CAをセットアップし、そのルートを固定または信頼します。
ちなみに、緑色のHTTPSの支払いが必要だと思われる場合は、 https://letsencrypt.org/ NOWをチェックしてください。
これらの連中、Let's Encryptの作者であるEFFは、あなたのデジタル著作権を保護するために良い戦いをします。
詳細はご自分で。
はい、暗号化が適用されます。警告は単に、暗号化されたデータを送信しているサーバーのidentityが主張しているものと異なる可能性があることを通知しているため、暗号化された接続を介して送信した情報は、許可されていない相手に送信される可能性があります。自己署名入りの証明書は、だれでも他の誰かであると主張する証明書を生成できるため、受け入れるのは危険です。
ただし、証明書の所有者であり、証明書への秘密鍵が侵害されていないことを確認した場合、または証明書を提示した人が証明書への秘密鍵を保持していることを検証できます（また、証明書が侵害された場合）、その後、接続を信頼できます。この場合、証明書を信頼されたルートとしてインストールして、この証明書を提示するサーバーへの接続を信頼することをコンピューターに通知できます。暗号化を有効にするためにこれは必要ありませんが、警告を無視するだけで暗号化が適用されます。
暗号化は引き続き行われます。 ほとんど役に立たないですが。
TLSは、エンドポイント間の接続が安全であることを保証することを目的としています。これが発生するには、エンドポイントが相互に識別できることが不可欠です。すべてのエンドポイントが他のすべてのサイトとシークレットを共有することは非現実的であるため、信頼できるサードパーティ（認証局）を使用して、各（非対称）シークレットの所有権を確認します。
アラートで[ええ、もう、気にかけてください]をクリックすると、この検証が省略され、反対側に誰がいるかはまったくわかりません。
別の言葉で言えば：
個人データの送信先となるサイトの偽装に成功した場合、その特定の警告のみが表示されます。無視しないでください。
代わりに、特定の自己署名証明書を「信頼できる証明書」としてクライアントマシンにインストールするか、さらに優れた方法として、自己署名証明書の代わりに LE証明書 を使用するようにします。