SSL警告メッセージをクリックしても安全ですか。

Question

ユーザーは、SSL証明書に関する恐ろしいブラウザー警告をクリックしても安全かどうかをどのようにして知るのでしょうか。

理想的には、ユーザーがこれらの警告メッセージをクリックする必要は決してないはずですが、正直なWebサイトが時々正直に実行されますが、巧妙ではありませんが、人々は壊れた証明書を持っています。

tdammers · Accepted Answer

SSLには3つの目的があります（説明のためにカタツムリメールの例を使用します）。

通信を秘密に保つ：郵便配達員があなたの手紙を読まないようにします。
通信が変更されていないことを確認します。郵便配達員があなたの手紙を変更するのを防ぎます。
送信者の身元を確認します。他の人があなたに偽の名前で手紙を送るのを防ぎます。

ポイント1と2は、3が損なわれていない限り意味がないことに注意してください。他の誰かがメッセージの発信者になりすますことができる場合、それを暗号化しても、他の攻撃者がすでに危険にさらされている通信をハッキングすることはできません。検証されていない、または信頼されていない証明書をクリックすると、これがリスクになります。通信は引き続き暗号化されますが、通信先のサーバーは正当ではない可能性があります。

つまり、警告をクリックしても比較的安全な状況がいくつかあります。

パスワードやクレジットカードの詳細などの機密データを送受信していない場合。セッションIDなどを含むCookieも機密情報であることに注意してください。ログインが必要なものを使用する場合は、これを行わないでください。また、不正な証明書は悪意のあるアクティビティの兆候である可能性があるため、追加する必要があります。これが発生した場合は注意してください。
他の方法でサーバーのIDを確認できる場合：
- サーバーが同じローカルエリアネットワーク上（同じルーター/ファイアウォールの背後）にあり、サーバーIPが信頼できるDNSまたはローカルホストファイルを介して取得されている場合。
- 証明書の（SHA-1またはその他の）フィンガープリントを別のチャネル（サーバーにログインしてそこで確認するなど）で確認できる場合：クライアントから見ると、サーバーにインストールされている既知の証明書と一致している必要があります。接続は依然としてハイジャックされる可能性がありますが、ネットワークの外部からこれを行うことができるのは、ファイアウォール/ルーターが危険にさらされている場合のみです（その場合、他に注意すべき点があります）。

TL; DR：何が起こっているのか正確にわかっていない限り、私のアドバイスはクリックスルーではなく、問題を適切に解決することです。

Thomas Pornin · Answer

理論的には、証明書に関する警告が表示されるHTTPSサイトは、プレーンなHTTPサイトよりも優れていますが、劣っていません。 browse、データの読み取りは行うが何も送信しないこと、および特にtrustingの読み取りを行わない限り、無視できます。警告。ただし、読み取り専用サイトでSSLと証明書の設定に問題が発生することはほとんどありません。

実用的な観点で、証明書に関する警告のあるHTTPSサイトは、より悪いプレーンHTTPサイト。ほとんどのプレーンHTTP接続は、接続が多すぎるため、攻撃を受けることなく通過し、その多くは攻撃者にとって価値がありません。一方、攻撃者が偽の証明書でHTTPSサーバーを偽装する問題に遭遇した場合、これは接続が積極的に脅かされている兆候です。

したがって、HTTPS証明書に関するブラウザの警告は、次の2つのいずれかを意味します。

サーバー管理者は彼の仕事を適切に行いませんでした。
あなたは今積極的に攻撃されています。

したがって、警告をバイパスしたい場合は、命題1が正しいことを確認する必要があります。

比較的安全な状況は、ブラウザにウィジーを与えるonlyがサーバー証明書の有効期限が少し前（数時間、場合によっては数日）である場合です：これはちょうどこれは、一部のシステム管理者が過労または休日に働いており、彼の証明書の更新日を逃したことを意味します。他のほとんどのケースは安全ではありません：実際、最もモロニックなシステム管理者でさえ、少なくとも一度は自分のサイトを閲覧しようとしたため、「永続的な」無効の理由がある場合（たとえば、証明書の名前がホスト名と一致しない場合）、システム管理者はそれを確認している必要があります。

したがって、一般的なアドバイスは次のとおりです。警告がある場合は、そこに行かないでください。

ただ楽しむために、「[Mark Bondurant]」という名前の男からのすばらしい引用はalt.computer.security Usenetグループ（Peter Gutmannが彼の X.509スタイルガイド）で報告した引用 -文体的な文学的理由だけの場合は、やや古くても読む必要があるドキュメント）：

自分のデジタルID階層を設定し、自分の証明書を発行し、自分のコントロールに署名し、サーバー上でSSLを実行することなどができる人を知っていました。期限切れ。 friggenブラウザーの警告メッセージをオフにする必要があるだけです。

bethlakshmi · Answer

SSLが提供する点が気に入っています。

ポイントツーポイントの機密性-サーバー側のsslプロバイダーとブラウザーが暗号化されたセッションを共有しているため、中間者が簡単に破ることはできません。これにより、プライバシーとポイント間の整合性の両方が得られます。
サーバーのIDの保証-サーバー側の証明書が適切な認証を提供する場合。

ユーザーが「SSL証明書に関する恐ろしいブラウザー警告」を受け取る理由は数多くあり、それらはブラウザーのタイプ、バージョン、およびブラウザー内の設定の両方によって異なります。以前はすべての主要なブラウザーでそれらをリストすることができましたが、現時点では、それを可能にすることを考えるのは傲慢であり、非常に多くのバリエーションがあると思います。

悲しいことに、恐ろしいブラウザの警告に対処するときに、リスクを受け入れるかどうかについて完全に初心者のユーザーに与えることができる簡単な答えはありません。いくつかのケースと考慮すべき点を次に示します。

あなたが送信しているもののリスクを知っています。これは個人的な決定です。可能性はeverybodyは、クレジットカード情報、社会保障番号、または信頼できない当事者への他の個人データに注意する必要があります。しかし、ソーシャルネットワークのパスワードを送信するかどうかは、アカウントがハッキングされることによるリスクに大きく依存します。巨大なネットワークの場合、ネットワークはビジネスの公の顔です。他の人にとって-大したことではありません、それは彼らが家族の再会について知るための新しい方法が必要であることを意味します。
サーバー/サービスプロバイダーの状態を把握し、それに応じて対応します。たとえば、google、yahoo、またはAmazon.comが失敗した証明書を提供してくれた場合、私は2度考えます。有効期限の切れた証明書を持つバックウォーターレストランの予約システム？ええ、私は危険を冒します、彼らは私のクレジットカードを必要としません、そして、ママとポップのレストランが彼らが証明書を毎年更新する必要があることに気づいたチャンスは何ですか？平均的なユーザーのものではありませんが、内部LAN上の適切なサーバーと通信していることを確認しているテスト環境では、常にこれらの警告をクリックしています。
エラーの特定のジャンルとその意味は次のとおりです。
- 証明書の有効性の失敗/期限切れ-証明書は現在有効ではないが、一度は有効であったことを意味します。一般的に、ハッキングされていないことを意味し、古すぎるだけです。 canは、コンピューターの時刻設定が間違っていることを意味しますが、小規模なサイトの場合は、サーバーが正しく更新されていない可能性があります。危険にさらされて使用されているが、それが小規模なサイトである場合、おそらく攻撃を受けている
- 信頼できる機関によって署名されていない証明書-ブラウザーには信頼できるCA証明書のキャッシュがあり、サーバープロバイダーが本人であることを証明するために使用されます。主要なブラウザのほとんどの信頼できるCAは、署名した人の身元を確認する適切なプロセスを持っています。したがって、これが失敗の場合、それはリクエスタがローエンドのCAプロバイダー（認証手順が悪い）にいつアクセスするか、証明書に自己署名したことを意味します。これは、テストサイトで作業している、サーバーがクラッシュした（サーバーがデフォルトにリセットされた）場合、または目的のサイトになりすましている可能性があります。私が何かを購入している場合、このエラーは通常パスを取得させます。他の目的のために、私はリスクを取るかもしれません。
  - 証明書名がURLと一致しない-これは証明書の不良が原因である可能性がありますが、構成の変更によってURLの性質が変更されたことを意味する場合もあります。優れたサイトであればこの問題を解決できるはずなので、実際にこのサイトのテクニカルサポートに連絡することもあります。しかし、たまに、ミスマッチがあったとしても、サイトを信頼できるようにするインサイダースクープを知ることができました。

ここから、IT部門はマイレージを大きく変えることができます。証明書のステータスチェックに関するあらゆる種類のエラーが発生する可能性があります。これは、サイトの問題である可能性がありますが、ネットワークまたはブラウザの一部でのアクセスの問題でもあります。

Hendrik Brummermann · Answer

表示または提供するコンテンツを知っている場合は安全です

他の人に見られる
途中で操作される可能性があります

サイトが信頼できる当事者によって運営されているかどうかは問題ではありません。 SSLは、信頼できないネットワークを経由するデータパケットの送信を保護するために使用されます。

証明書は、サーバーの身元を確認するために使用されます。これは中間者攻撃を防ぐために必要です。さもなければ、攻撃者は彼が実サーバーであると主張し、ブラウザは攻撃者の秘密鍵のために暗号化されたメッセージを喜んで送信するでしょう。

PS：SSLには、VeriSign、Commodo、DigiNotarなどの一部の認証局が過去に間違った人々に証明書を発行したという問題があります。最後の1つだけが一般的なブラウザに信頼されていませんでした。しかし、これは別のトピックです。

Gilles &#39;SO- stop being evil&#39; · Answer

HTTPSを構成するもの

SSL/TLS （ [〜＃〜] https [〜＃〜] のSは、3つのセキュリティ機能を提供します。

SSLは、クライアントとサーバー間に安全な通信チャネルを作成します。ここで安全とは、チャネルの確立に協力したサーバーとクライアントだけが、転送されたデータを認識したり、そのデータを変更したりできることを意味します。チャンネルのセキュリティは暗号化によって確保されていますが、ここでは説明しません²。
この部分は、実際にはかなりうまく機能します。プロトコルの初期のバージョンにはバグがあり、実装に時々問題が発生しますが、SSLセッションが確立されていれば、接続先のサーバーと安全に通信していると考えることができます。実際には、このレベルのほとんどの攻撃は、一部のデータが実際にはHTTPを介して転送され、盗聴、偽造、または改ざんされたときにHTTPSで転送されたとユーザーに信じ込ませることを目的としています。これは、このレベルでの攻撃が不可能だと言っているのではありません。上の段落を書いてから数日後、 SSLのこの部分への攻撃は開示でした。
SSLはサーバー認証を有効にします。これは、クライアントがサーバーのIDを検証できることを意味します。これが機能する方法は、サーバーにキーペアがあり、クライアントに公開キーと秘密キーを知っていることの証明をクライアントに送信することです。サーバーが本人であるかどうかを確認するには、クライアントは、要求された公開鍵がクライアントが接続しようとしているサーバーに属していることを確認する必要があります。これは物事が複雑になる場所です。
SSLは、サーバーがその公開鍵をクライアントに送信するだけでなく、署名された証明書も送信することで機能します。証明書には、「私はチャーリーです。acme.comの公開キーは0xDEADBEEFであることを保証します」と書かれています（暗号化²を使用しているため、チャーリーが本当にこれを言っていたことがわかります）。そのため、クライアントがhttps://acme.comにアクセスしようとした場合、適切なサーバーに到達したことがわかります。
ちょっと待ってください、なぜクライアントはチャーリーを信頼するのですか？通常、チャーリーは認証局（CA）であり、クライアントは信頼する認証局のリストを持っています。すべてのブラウザにそのようなリストが付属しています⁴。サーバーがacme.comであるとチャーリーが保証する証明書をサーバーが送信し、チャーリーがクライアントが信頼する認証局の1つである場合、クライアントはサーバーがacme.comであると確信できます。
対称的に、プロトコルはクライアント認証を許可します。これはあまり使用されません。

ポイント＃1だけでは、クライアントが通信したいサーバーと通信していることを保証できず、両者が互いに通信しているように見えても、パーティは機密性を保証できません。当事者がお互いを認証しない限り、 man-in-the-middle がクライアントであると偽って、サーバーであると偽って、クライアントであると偽ってサーバーを中継することが可能です。データを送受信し、トラフィックを盗聴し、必要に応じてオンザフライで変更します。

ポイント＃2は、問題が発生する可能性がある場所であり、問題が発生すると、SSL警告メッセージが表示されます。ここにいくつかの一般的な理由があります（これは決して完全なリストではありません）。

証明書はacme.com用ですが、クライアントはyoyodyne.comに連絡しました。
証明書は、クライアントの信頼できるCAのリストにないDominiqueによって発行されます。
証明書は本質的に何らかの理由で無効です。たとえば、有効期限が切れています⁵。

なぜ物事が頻繁にうまくいかないのですか？この問題についてはエッセイ全体が書かれていますが、一言で言えば、これは少なくとも4人の参加者が関与する複雑なプロトコルであり、誰も他の参加者をあまり制御できないためです。

サーバー（以前にCAから証明書を取得し、現在クライアントと通信しようとしている）;
クライアント（ブラウザをどこかから入手し、現在サーバーに接続しようとしている）;
認証局（サーバーに証明書を発行し、ブラウザーメーカーに信頼されたリストに含めるように依頼した人）;
ブラウザーメーカー（信頼できるCAのリストを決定し、ブラウザーをクライアントに提供したユーザー）。

有効な証明書を取得することは、単純なWebサイトを設定する場合と比較して、比較的重くてコストのかかるプロセスです。そのため、多くの小規模なサイトはCAを経由せず、独自の証明書を生成しません。 自己署名証明書（つまり、チャーリーはサーバーです）は、サーバーが誰であるかについての情報を提供しません。

有効な証明書を取得することは、複雑または高トラフィックのWebサイトを設定することと比較して大したことではありませんが、複雑なWebサイトには独自の課題があるため、問題が発生する可能性が高くなります。たとえば、大規模な組織の下位区分は内部官僚の問題のために適切な証明書を取得できないか、サーバーの名前が変更され、システム管理者が新しい名前の証明書を取得するのを忘れています。

一般的な状況でのSSL警告

SSL警告が表示されたら、警告の性質、証明書の内容、およびサーバーとの関係を評価する必要があります。すべてのケースをカバーすることは不可能ですが、ここにいくつかの一般的なケースがあります。

サイトとの関係はありません

サイトが以前に聞いたことのないランダムなサイトである場合、有効な証明書があるかどうかは問題ではありません。有効期限が切れているか、自己署名されているか、誤って構成されている証明書は、心配する必要はありません。たとえば、証明書がwww.acme.com用であり、www1.acme.comに接続している場合、サーバーが正しく設定されていない可能性があります。サーバーまたはDNSへの攻撃である可能性もありますが、これは比較的まれであり、最終的にこれが単なるランダムサーバーである場合、有効な証明書があっても信頼できるかどうかわかりません。認証局が「この公開鍵がアリスに属していることを確認しました」と言っていることを思い出してください。「アリスは信頼できる」とは言わない。

有効な証明書からわかることの1つは、Webサイトの背後にある実際のIDです。たとえば、Webマーチャントのサイトで何かを注文している場合、証明書はサイトを訴訟を起こすことができる法人と結び付けます。少なくとも、それは理論です。実際には、ほとんどのCAは顧客の本当の身元を確認するために多くのことをしません（それは最初は危険な関係です：CAはそれを支払うエンティティを保証することになっています）。そして、CAのセキュリティ can go wrong 。

以前にサイトにアクセスしたことがあり、以前は有効な証明書を持っていた

サイトが以前は有効な証明書を持っていたが、もう持っていない場合、それは通常、何かが深刻な問題を抱えていることを示しています。誰かが接続を攻撃しているか、誰かがサーバーを攻撃しているか、サーバーの設定に誤りがあります。証明書が単に期限切れになっている場合は、おそらく構成の誤りです。一方、未知のエンティティによって署名された、または未知のエンティティの名前が付いた別の証明書がサイトに表示されている場合は、Webサイトに信頼を置くべきではありません。それはあなたがそれをまったく閲覧すべきではないという意味ではなく、機密情報を含むそのサイトを信頼しない方がよいということだけです。このアドバイスは、銀行など、頻繁に狙われるサイトにとって特に重要です。

HTTPSは2つのことのみを保証することに注意してください：安全なエンドツーエンド通信、および（適切に使用された場合）サーバーの認証。 HTTPSはサーバー自体のセキュリティのために何もしません。 HTTPSサーバーがクラックされた場合、それはあなたのクレジットカード情報をクラッカーに送信し、ウイルスが含まれたページを提供する可能性があります—すべて同じ古い完全に有効な証明書を使用します。

あなたはそのサイトについての事前の知識を持っていますが、これまでにアクセスしたことがありません

これは主に前のケースと同様です—期限切れの証明書は心配のほとんど原因ではなく、そうでなければ無効な証明書です。ただし、考慮すべき追加のケースがあります。自己署名証明書、またはブラウザによって信頼されていないCAによって署名された証明書のケースです。

その場合、サーバーとの信頼関係を確立するかどうかを決定する必要があります。証明書を受け入れることにした場合、誰と話しているのかわかりません。しかし、次に同じサーバーと通信すると、今は既知のサーバーに戻っていることがわかります。

この時点で、別のチャネルで証明書を確認できる場合があります。たとえば、ラップトップで雇用主のWebサイトに接続している場合、信頼できるネットワーク上で職場内から最初の接続を確立できる可能性があるため、署名がなくても証明書が正しいことがわかります。それ。そのため、ブラウザに信頼できる証明書のリストに証明書を入力させてください⁶。次にサイトにアクセスすると、証明書の署名の有効性に関係なく、適切なサイトにアクセスしたことがわかります。

¹ _{パケットの長さやタイミングなど、明らかになる可能性のあるサイドチャネルを除外します。それがあなたにとって心配であるなら、おそらくあなたは私がこの答えで私が言ったことすべてを私よりはるかによく知っています。}
² _{ここでは、暗号を魔法と区別が付かないほど高度な科学として扱います。それが機能する魔法です。}
³ _{私は「送信」という言葉を大まかに使用しています。これにはいくつかのメッセージの交換が必要ですが、ここでは重要ではありません。}
⁴ _{たとえば、Firefoxでは、[証明書の表示]ボタンをクリックして[認証局]タブを選択すると、設定ダイアログの[詳細]タブに信頼できる認証局のリストが表示されます。}
⁵ _{SSL証明書には有効期限があり、サーバーの秘密鍵が盗まれた場合の影響をわずかに減らします。}
⁶ _{たとえば、Firefoxでは、[証明書の表示]ボタンをクリックして[サーバー]タブを選択すると、設定ダイアログの[詳細]タブに信頼できる証明書のリストが表示されます。}

MToecker · Answer

SSL警告メッセージをクリックするのは安全ではありません。目の前の状況についてのリスクを評価し、悪い証明書を受け入れるかどうか。

少なくともそれはあなたに選択肢を提供しています、Diginotarハックはあなたからその選択肢を取り除きました、そしてあなたの選択肢も取り除く4つの他のCAがあります。

マイク

*編集-自己署名証明書を使用している場合は、自分をCAとして証明書ストアに追加する必要があります。この方法では、認識した場合にクリックする必要はありません。システムによって自動的に検証されます。自己証明書の使用に問題はありません。正しく実行してください。

*編集-指紋を自分で確認できる場合は、検査により、証明書が実際に良好であることを確認しているため、クリックスルーで問題ありません。