英語が母国語ではないので、ご不便をおかけして申し訳ございません。
DNS が汚染されているため、一部の Web サイトにアクセスしていますhosts。
私の質問は、www.google.com例を挙げてみます。
攻撃者によるソーシャルエンジニアリングに成功し、翻訳がhostsフィッシングサイトに変更された場合。
を使用するとhttp、完全におかしくなりますよね?
を使用するとhttps、PC が侵害されていない場合はブラウザから警告が表示されます。
このhttps場合、フィッシングサイトが合格それが本物であることを証明する証明書をwww.google.com私から受け取りますか?
答え1
次の文を検討してください。
全て
examplebank.comWeb ブラウザが信頼する証明機関は、ドメイン所有権の証明がなければ攻撃者への証明書の発行を拒否します。すべての機関の署名鍵は安全に保管されており、権限のない人が自分自身に証明書を発行することはできません。（最近のコモド侵入。
Web ブラウザは、サーバーの SSL 証明書が有効な CA によって発行され、取り消されておらず、サーバーでの使用に有効であり、ドメインに対して発行されているかどうかを正しく確認します
examplebank.com。このようなチェックをバイパスさせるアクティブなマルウェアやブラウザのバグは存在しません。
常に を開き
https://examplebank.com、Web サイトによるリダイレクトに頼るのではなく、明示的に SSL を要求します。あなたは実際読むIgnoreウェブサイトを開いたときに盲目的にクリックするのではなく、SSL エラー メッセージを表示します。
上記のすべてが当てはまる場合、HTTPSはあなたに警告します偽の Web サイトに接続しようとしていることを示しています。ただし、HTTPS は低レベルのリダイレクト ( examplebank.comDNS や によるスプーフィングなど/etc/hosts) を回避できないため、警告を無視すると、データは実際の銀行ではなく攻撃者に送信されます。
結論から言うと、確かに危険です。
編集された質問に対する回答:
プレーン HTTP を使用すると、失敗します。
HTTPS を使用すると、大きな赤い警告が表示されます (回答の最初の部分を参照)。
すべての「証明書」には、RSA (場合によっては DSA、ECDSA) キー ペアがあります。ペアの公開キーは証明書の一部ですが、秘密キーは Web サーバー内にロックされ、ネットワーク経由で送信されることはありません。TLS/SSL ハンドシェイクを正常に完了するには、両方のキーが必要です。
攻撃者が証明書を提示しても、それに関連付けられた秘密鍵を持っていない場合、TLSを経由するトラフィックを復号化することはできません。WikipediaにはTLSハンドシェイクの説明。
答え2
SSL (HTTPS) は、クライアントが侵害されていない限り保護されます。。
誰かが /etc/hosts を変更できた場合、接続先のサーバーの SSL 検証を実行しないようブラウザを変更したり、詐欺サーバーの偽の証明書をシステムの信頼できる証明書のデータベースに追加したりすることもできます。
ただし、クライアントが侵害されておらず、誰かがブラウザを別の IP アドレスにリダイレクトすることに成功した場合 (たとえば、何らかの DNS 関連のハッキング、または /etc/hosts のみを変更するように騙すなど)、ブラウザはサーバーの証明書に問題があることを警告します。警告を無視して続行しない限り、安全です。
2番目の質問について:
https の場合、フィッシング Web サイトが本物であることを証明するために www.google.com からの証明書を渡すだけという可能性はありますか?
いいえ、攻撃者がサーバーの秘密鍵(たとえば、サーバー自体をハッキングするなど) たとえ詐欺サーバーがサーバーの証明書を「渡した」としても、その秘密鍵を持っていなければ、クライアントにその身元を証明することはできません。それを試みた場合は失敗し、ブラウザに警告が表示されます。
答え3
Dante、あなたの編集は歓迎します。しかし、答えはまだ残っています。hosts ファイルが侵害された場合、そのファイルでソーシャル エンジニアリングされたドメインに関するセキュリティ全体が侵害される可能性があります。
HTTPS は例外であり、表示している Web サイトが見た目どおりではない可能性があることを知らせる証明書システムにより、何らかの形の保護が提供されます。