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