回答:
このシステムが壊れていると感じる人はたくさんいます。
SSL証明書が無効な場合にブラウザが警告を発する理由は次のとおりです。
SSLインフラストラクチャの当初の設計目的の1つは、Webサーバーの認証を提供することでした。基本的に、www.bank.comにアクセスすると、SSLにより、応答するWebサーバーが実際に銀行に属していることを証明することができます。これにより、詐欺師がDNSを操作したり、別の方法を使用して悪意のあるサーバーに応答させたりするのを防ぎます。
SSLの「信頼」は、信頼できるサードパーティ（VeriSignやThawte Consultingなどの企業）が証明書に署名することで提供されます。直接信頼を作成する個人または別の方法。ただし、実際にはそれがかなり緩いことを示す証拠があります-署名済みSSL証明書を取得するために必要なのは、多くの場合、800の数字と少しの演技スキルです）。
したがって、SSL証明書を提供するWebサーバーに接続しているが、信頼できる第三者によって署名されていない場合、理論上は、別の組織に属するサーバーのふりをしている詐欺師と通信している可能性があります。
実際には、自己署名証明書は一般に、サーバーを実行する組織が署名証明書の代金を払わないことを選択したことを意味します（必要な機能によっては非常に高価になる場合があります）、または構成するための技術的な専門知識がありません（一部の小規模ビジネスソリューションでは、自己署名証明書のワンクリックメカニズムを提供していますが、信頼できる証明書を取得するには、より技術的な手順が必要です。
個人的には、このシステムは壊れており、暗号化を提供しないサーバーと通信することは、自己署名証明書を使用してSSLを提供するサーバーと通信するよりもはるかに危険だと考えています。ブラウザがこのように動作しない理由は3つあります。
ページからページへの資格情報の送信は、基本的にHTTP POSTを実行しています。安全性の低いページへの投稿が警告をトリガーする場合、ユーザーは無意味な警告によって攻撃されます。
セキュリティで保護されたチャネルを使用することは、転送を保護するプログラマーの意図を示します。この場合、自己署名証明書の警告を使用することは非常に正しいことです。
コメントできないので、user40350の正しい情報を補完するこの情報を投稿します。
ただし、同じブラウザでも、セキュリティで保護されていないページ間で資格情報を送信できます。
実際にはそうでもありません。ほとんどのブラウザは、最初に試してみると、セキュリティで保護されていない接続を介してデータを送信しようとしているような警告を表示しますが、それをオフにして再び表示されないようにすることができます。
ミロAの書き込み：
ページからページへの資格情報の送信は、基本的にHTTP POSTを実行しています。POSTを介した検索語などの送信と比較して、資格情報の送信に関して特別なことはありません
パスワードフィールドは、たとえば特別なhtmlタグであるため、これも間違っています。その上、「ユーザー名」や「パスワード」などのラベルも、彼らの機密性の多くを裏切っています。ブラウザがこの種の情報を考慮することは完全に実行可能です。
https：//プロトコルによって保護されている接続は、ブラウザーによって「保護されている」ことが示されます。たとえば、小さな南京錠が表示されたり、URLの一部が緑色でマークされたりします。
したがって、ユーザーは、訪問しているページが実際に自分が入力したURLからのものであり、他人からのものではないことを信頼することになっています。
彼がhttps：//を使用していない場合、ユーザーは入力されたデータが保護されておらず、ユーザーが閲覧しているサイトが偽装されている可能性があることを知っているはずです。
自己署名証明書は確認しません-繰り返しますが、閲覧されたページが偽装されていないことを期待しているため、追加のセキュリティは提供されません。
信頼できる（信頼する機関によって署名された）証明書と信頼できない証明書を区別する必要があります。そうしないと、相対的な免責を伴う自己署名証明書を使用して、誰かが（たとえば）銀行になりすます可能性があります。
潜在的なリスクが比較的高いため、この場合、微妙な警告よりも直接警告が望ましいです。人々はhttpsリンクをクリックしても、誰かが接続を監視している途中に座っているとは思わないかもしれません。証明書が信頼されていないという兆候が微妙な場合（緑のアイコンの代わりに赤など）、人々は簡単にだまされ、SSLの利点を失います。
多くの正当な理由がリストされています。ここにもう1つあります。
ある安全なWebページが別のWebページから要素を埋め込む場合を考えてください。攻撃者は、外部Webページに対する要求（たとえば、タイミングを見ると、最初に来る必要がある）と内部要素に対する要求を検出できます。彼はMITMとして自分自身を内部要素に挿入し、自己署名証明書を使用し、ページの一部を制御できます。SSLを使用し、信頼できる証明書を使用しない内部要素に対して警告が表示されない限り、外部ページのセキュリティが侵害されます。
これが現実的な例です。私がベンダーであり、「PayPalで支払う」リンクがあるとします。あなたはそれをクリックし、私は知っています。PayPalにリダイレクトし、正当で安全なPayPalページを取得します。あなたのネットワークを監視している場合、PayPalからの最初のリクエストであることを知っており、その後すぐにパスワードを送信します。そのsubmitため、PayPalの代わりに自己署名証明書を使用して、メールアドレスとパスワードを含むMITM を作成します。
内側のページの証明書が自己署名されている場合、警告しないことで外側のページのセキュリティがどのように損なわれるかわかりますか？そのため、リンクからの自己署名証明書について警告する必要があります。
そしてもちろん、https手動で入力する場合は、警告する必要があります。あなたはそれが安全であると期待しているからです。