web-dev-qa-db-ja.com

DNSSECではなくhttpsを使用している場合、どのような状況でクライアントが脆弱になりますか?

したがって、DNSSECは、返されたIPアドレスが汚染されないようにすることを目的としています。そしてhttpsはリモートサーバーを確認することです。

私の質問は、httpsで保護されている場合、どのような状況でクライアントが脆弱になるかということです。

https://www.facebook.com にアクセスするとします。DNSSECで保護されていなくても、攻撃者はどのような損害を与える可能性がありますか? DigiNotarのものはないと仮定しましょう。

ありがとう

11
Eniaczz

Httpsを適切に使用すると、エンドポイントが証明書であるかどうかを検証することによってエンドポイントが予期したものであるかどうかがチェックされるため、DNSSsecを使用しないリスクを軽減できます。また、データ転送自体も保護されています。 https自体で問題が発生する可能性があるものはいくつかあります(弱い暗号、検証プロセスのエラー、同じ権限を持つ信頼されたルートCAが多すぎるなど)。ただし、これらすべてが適切に処理されていると仮定した場合(多くの場合は正しくありません)https次の保護を提供します:

  • あなたは正しいサーバーと話します。
  • ブラウザとサーバーの間のトラフィックは、傍受や変更から保護されています。

それだけです。

特に欠けているのは、ブラウザーの安全でないWebアプリケーションやバグ、または設計エラーによって引き起こされる攻撃に対する保護です。つまり、CSRF、XSS、Flash、Java、Silverlight、ActiveXを使用したエクスプロイト、アクセスしたサイト(つまり、ソーシャルネットワーク、追跡、広告...)および今日のWebにおけるその他すべての典型的な攻撃。また、コンピュータがマルウェアやセキュリティまたはヘルパーソフトウェアによって既に危険にさらされている場合も、httpsは役に立ちません 害が大きくなります 役立つよりも。

7
Steffen Ullrich

DigiNotarのものはないと仮定しましょう。

しかし、そこがDNSSECのすべての利点です。たとえば、次の2つの状況では、DNSSECを使用してもセッションが危険にさらされることはありませんが、DNSSECを使用すると発生しません。

ハイジャックされたリゾルバ

  • ウェブサイトの不正な証明書が発行されます
  • ISPのDNSサーバーが乗っ取られ、間違ったIPをポイントする

キャッシュポイズニング

  • ウェブサイトの不正な証明書が発行されます
  • リゾルバーのキャッシュが悪意のあるIPで汚染されている
0
ConnorJC