自己署名SSL証明書を使用したhttpとhttpsの違いは何ですか？
私の同僚は、セキュリティが侵害されている可能性があることを示す自己署名証明書を含むHTTPS Webサイトにアクセスするときに警告が表示される理由はわかりませんが、「通常の」HTTP Webサイトにアクセスする場合の警告はない、と私に言ったただし、セキュリティも侵害される可能性があります。
私はそれに反対する議論を考えることができませんでした（自己署名証明書とCA発行の 違い を理解しています）。
では、自己署名証明書または有効期限が切れた証明書を使用してHTTPS Webサイトにアクセスするときのセキュリティリスクは何ですか。HTTPWebサイトにアクセスするときはありません。
自己署名証明書のブラウザ警告メッセージの背後にある理由は何ですかを追加したいのですが、HTTPには何もありませんが、すでにいくつか考えられます。ウェブの90％のユーザー」が1つです。
注
非常によく似た質問 は知っていますが、私の特定の質問には答えません。
更新
Googleはこのパラドックスに気づき、間もなくすべてのHTTP-not-S接続を非セキュアとしてマークします： https://security.googleblog.com/2016/09/moving-towards-more-secure-web。 html
警告の目的は、HTTPSを使用することで適切なセキュリティが期待されることですが、自己署名または期限切れの証明書には、ユーザーが注意する必要がある脆弱性があります。
「リスク」とは、適切に保護されていると考えられているが、暗号化がまったく行われていないことがわかっているHTTPとは異なり、完全には保護されていないということです。
妥協するセキュリティ（つまり暗号化）がないため、HTTPに対する警告はありません。
セキュリティの違い
最初に、SSL（ちなみにTLSと呼ばれています）について話しましょう。HTTPの最後に 'S'が追加されます[〜＃〜] s [〜＃〜]で、 " 通信を保護します "。この質問に答えるための手がかりは、確かに私たちが「コミュニケーションを確保する」とはどういう意味かを完全に理解することです。
SSLは、使用されている自己署名証明書であるか、信頼できるCAによって署名された証明書であるかに関係なく、ユーザーとリモートホスト間の通信の機密を保持し、誰も交換されたデータを改ざんできないようにします。
したがって、警告はそれについてではありません。
しかし、どのようにして、このリモートホストがリクエストに応答しているのかを本当に確認できますか？公開Webサイトでは、自分で証明書を直接認証する方法がないため、不可能です。ここに外部の信頼できるCAがあります。CAを信頼することにより、そのCAによって署名されたすべての証明書は、証明書で明示的に言及されているサーバーでトラフィックを保護する正当な目的にのみ使用されると想定します。
これがこの警告のすべてです：ブラウザは警告しますが、通信自体は保護されていますが、それ自体で証明書を認証する自動化された方法がないため、証明書の受け入れまたは拒否に依存しています。
自己署名証明書がサーバーの1つに関連付けられている場合、この手動認証を続行できるはずです。証明書のフィンガープリントを確認できるか、少なくとも証明書が最近変更されたかどうかを知っている必要があります。
この手動認証が完了すると、ブラウザーはこの証明書を「記憶」する可能性を提供します。これは、ブラウザーがこの自己署名証明書をURLホストに関連付け、将来ブラウザーに警告を表示しないことを意味します証明書を認証する自動化された方法があります。
ただし、サーバーで自己署名証明書が変更されるとすぐに、ブラウザーは再び警告を表示し、この証明書の変更が正常であるかどうか、および新しい証明書が提示されているかどうかを判断するのは、エンドユーザーの責任です。サーバーによる確かに本物です。
UXの違い
私の答えは、これまであなたの質問のブラウザのユーザーインターフェースの側面をカバーしていませんでした。
ブラウザがユーザーに現在のセキュリティについて通知するデフォルトの方法では、ほとんど効果がないことがわかりました。ユーザーは 南京錠を気にしない 、そして SSLセキュリティが欠落していることに気付かない です。適切な情報にアクセスしていないユーザーでも、Webサイトが Extended Validation Certificate を表示することを妨げるものはありません。 ：デフォルトのブラウザのインターフェースはそれでも満足し、「一流のセキュリティ」の緑色のバーを表示します）。
うまくいけば、使用するブラウザによっては、この状況を改善しようとするプラグインがいくつかあるかもしれません。 Firefoxには SSLeuth があり、デフォルトで新しい通知領域が左側またはURLバー（南京錠がある場合はその横）に追加されます。
この新しい通知領域には、次のプロパティがあります。
- 背景色の範囲は、赤（セキュリティなし：HTTP）、オレンジ（不十分なセキュリティ設定）から青と緑（現在のベストプラクティスによる良好で最高のセキュリティ）までです。
- オプションにより、この色をURLバー全体に拡張できるため、HTTP Webサイトは完全に赤いURLバーを表示します。
- 最後に、スコア（0〜10）が表示され、現在のSSL/TLSセキュリティレベルの推定が示されます。証明書のタイプ（自己署名、CA署名、拡張検証証明書）、使用される暗号構成、サードパーティのコンテンツセキュリティなど、いくつかの基準が考慮されます。通知領域をクリックすると、すべてのスコアの詳細が表示されます。結果が期待したものではない場合に便利です（「銀行のWebサイトにオレンジ色のURLバーが付与されているのはなぜですか？」）。
自己署名または期限切れの証明書、不適切な暗号スイートの選択、その他の不適切なHTTPS構成などの警告がない場合、ユーザーに対するWebサイトのセキュリティ状態の表示はバイナリになります-サイトにHTTPSがあるか、ないか。これにより、「HTTPS」の「S」が実際にどの程度保護されているかに正確に影響を与える可能性がある多くのニュアンスが隠されます。
適切なHTTPS実装では、サイトの証明書は、クライアントシステムが信頼するサードパーティによって署名されています。これにより、コンテンツが期待どおりのシステムから配信されていること、およびその間に誰もいないことがクライアントに保証されます。
自己署名証明書の問題は、誰でも作成できることです。そのため、その証明書は、あなたと信頼できるシステム間でやり取りされるデータを傍受し、場合によっては操作する中間者として機能するシステムからも生成できます。高信頼性システムが通常自己署名証明書を使用していて、その証明書を帯域外で、または以前の既知の信頼できる接続中に個人的に検証していない場合は、違いがわかりません。
これは通常のHTTPとどう違うのですか？一見、それはそうではないように見えるかもしれません-どちらのシナリオでも、MitMはかなり簡単に接続を表示して改ざんでき、気づかないでしょう。ただし、自己署名証明書でHTTPSを使用すると、HTTPができないことが提供されます。その間に誰かがいる場合でも、データが転送で暗号化されているという保証。環境（例：密集したパブリックWi-Fi）によっては、実際にMitMが使用されている場合でも、データにアクセスできるオーディエンスを大幅に減らすことができます。
別の関連する質問 で私の回答をチェックして、これについての詳細を確認することもできます。 Troy Huntの記事 "SSLは暗号化についてではない" はあなたにとって興味があるかもしれませんが、おそらくここでの議論のあなたの側にはあまり役に立ちません。
これらの答えは素晴らしいです。しかし、私はしばしば、専門用語をすべて使わずに、簡単な答えを出さなければなりません。
HTTP-暗号化されておらず、回線を介して送信されたデータは簡単に読み取ることができます。
HTTPS-データは正しいソースによって処理されている信頼できる当事者によって暗号化および検証されます。
HTTPS（自己署名）-暗号化されていますが、信頼できる当事者による正しいソースによる処理の検証は行われていません。
そのため、自己署名証明書は非常に重要な通知を受け取ります。証明書が安全でないことを意味しているわけではありませんが、ブラウザは、データの使用/送信において証明書が安全であることを確認できません。この重要な通知がなければ、詐欺師/ハッカーは証明書を独自のものに置き換えることができ、あなたは賢明ではありません。
HttpsのURLにアクセスすると、セキュリティが期待されます。 http URLにアクセスしてもアクセスしません。これは、URLを手動で入力するときだけでなく、リンクをたどってフォームを送信するときにも重要です。
これに対する解決策の1つは、「暗号化されているが認証されていない」ための別のURLスキームを追加することですが、すべてのブラウザが明日それをサポートし始めたとしても、Webサイトが信頼できるほど広く普及するまでには長い時間がかかります。また、セキュリティの違いをユーザーに説明するのも難しいかもしれません。
別の解決策は、http urlスキームの下で操作的な暗号化を行うことです。繰り返しになりますが、ブラウザへのサポートを得るのは困難な作業です。