不正なDNSサーバーが原因でHTTPS接続が侵害される可能性はありますか
有効なHTTPS証明書/接続のあるサイト（デスクトップPC、クライアント側のみ）にアクセスしている場合、悪意のあるDNSサーバーを使用している場合、それが危険にさらされる可能性があります（意図的にではなく、攻撃を心配しています） DNSサービス上）？
例えば、私は考えています：CAのサイト（HTTPS接続をチェックするため）は、私のネームサーバー（侵害されたもの）によって解決されますか？
Httpsを介するかどうかを問わず、任意のWebサイトに接続するには、サイトのIPアドレスが必要であり、サイトのドメイン名を使用してDNSサーバーに要求します。 DNSサーバーが回答をキャッシュしていない場合は、一連のDNSサーバー全体（ルートDNSサーバー、トップレベルドメインハンドラー...ドメインに対して権限のあるDNSサーバーまで）を要求することにより、要求を解決しようとします。 。
これらのサーバーのいずれかを制御する攻撃者は、そのWebサイトの偽のIPアドレスで応答する可能性があり、これがブラウザーがアクセスしようとするものです。一般的な場合のこのIPアドレスには、ホストされているWebサイトのレプリカがあり、元のWebサイトと同じに見えるようにするか、必要なものをキャプチャした後、正しいサイトへの接続のサイレントフォワーダーとして機能します。
詳細については、次のとおりです。WebサイトがHTTPSで保護されている場合、多くの落とし穴があります。通常のWebサイトには、ドメイン名の詳細をWebサイトにバインドする証明書が発行されますが、これは非対称暗号化を使用して行われます。
つまり、SSLハンドシェイクのプロセスを通じて、Webサイトは、証明書の公開鍵に関連付けられている秘密鍵を知っていることを証明する必要があります。これで、悪意のあるパーティは、正しいホスト名で間違ったIPにアクセスしようとすると、Webサイトの元の証明書を非常にうまく提供できますが、SSLハンドシェイクが完了しないため、秘密キーを知ることはできません。
しかし、インターセプターが全体を機能させる方法はいくつかあります。4つ考えられます。
1）最も簡単な解決策は、通常の証明書ではなく自己署名証明書を提供することです。これは攻撃者自身によって発行されます。通常、ブラウザはそのことを警告します。最近のブラウザバージョンを実行すると、警告はいたるところに表示されますが、ユーザーはそのようなものをクリックスルーする傾向があります。
2）Stuxnet攻撃で使用される別のアプローチは、偽装したい組織からの有効な証明書に使用される秘密鍵を盗むことです。
3）いくつかのケースで発生した別の解決策（ここでは平均的な攻撃者については触れていません）は、認証局（または登録局）が使用する登録手順の障害を悪用し、証明書を発行することです彼に属していないウェブサイトのために。 RAが単に十分なチェックを行わず、google.comの証明書を発行したというケースがありました。
4）上記と同様：有能な攻撃者は、証明書または登録機関を「ハッキング」し、自分の好きな名前で証明書を発行します。それは2011年5月（有名なコモドハック）と2011年7月（DigiNotarハック）で起こりました。詳細は CAがハッキングされるのはどの程度現実的ですか？デフォルトの信頼されたルート証明書を削除する必要がありますか？-ITセキュリティ 。
5）最後に、最も恐ろしい技術は、3つの文字機関と同様の関係者が使用できる技術です。政府が認証局を管理している場合、理論的には、どのサイトでも自由に証明書を発行することができます。現在、認証局は世界中に広がっていると考えてください。その一部は、これが非常に可能と思われる国にあります。ここで注目する例は、アラブ首長国連邦（UAE）政府が60％所有するEmirates Telecommunications Corporation（Etisalat）が運営するCAです。 Etisalatは、RIMデバイスにスパイウェアを挿入する無害に見えるBlackBerryパッチを展開し、電子メールの監視を可能にしました。
さらに、クライアントが引き続き古いSSL 2.0プロトコルをサポートしている場合、MITMはSSL接続をダウングレードし、より弱い対称暗号化アルゴリズムまたはより弱い鍵交換のいずれかを使用できます。
つまり、攻撃者がDNSサーバーを制御している場合、彼は非常に悪意のあることを行うことができますが、SSL暗号化トラフィックを傍受するには、それ以上のものが必要です。
そして最後の質問に答えます。CAのサイトは、サイトにアクセスするたびに解決する必要はありません。通常、Webサイトはそれ自体が使用する公開証明書を提供しますが、CAから取得することもできます。ただし、これによって上記のことは変更されません。
それは可能ではありません。攻撃者がDNSを制御できる場合、攻撃者は侵入先のサーバーにリダイレクトする可能性があります。ただし、ブラウザーは（正しく構成されている場合）証明書の破損について警告します。
しかし、確かにそれは可能です！サーバーに有効な証明書がない場合、実サーバーに接続するとおよび攻撃者のマシンに接続すると、ブラウザーが警告します。この警告が重要であるかどうかを決定することはできません。
別のシナリオでは、攻撃者はサーバーの有効な証明書を取得することができました（例 here を参照）。したがって、彼は侵害されたサーバーにあなたをリダイレクトすることができ、あなたのブラウザは何も言わないでしょう。
@Johnの優れた回答に加えて、悪意のあるDNSサーバーは、現在のHTTPS接続への影響に加えて、他の損傷を引き起こす可能性があります（これは厳密に質問の範囲外ですが、依然として関連性があると思います）。現在の接続を盗聴しようとする以外にも、それがもたらすダメージにはいくつかの種類があります。
悪意のあるDNSサーバーにアドレスの解決を依頼している場合は、要求していない回答が返される可能性があるため、作成した他の接続に影響を与える可能性があります-不正なDNSの使用を停止した後でも。
例えば。 DNSポイズニングテクニック を使用します。 （ この質問 に対する私の回答も参照してください。）
また、悪意のあるDNSが故意に別のサーバー（たとえば、いまや偽のリクエストが殺到する犠牲サーバー。
それ以外に、SSL接続を実際に作成することを誰が保証しますか？ほとんどのユーザーは"aich tee tee pee ESS(!) colon whack whack... "を入力する手間を省きます...ドメイン名（例： "mybank"）を入力してctrl + enterを押すか、検索エンジンにポップアップさせるか、 ..そしてこれらすべての場合において、ユーザーの最初のリクエストはHTTPSでさえない可能性が高いです。 （もちろん、doと具体的に入力した場合、それは異なりますので、その点でYMMVです）。
一部の企業プロキシ（DNSリダイレクトまたはその他のさまざまな手段を介して動作する）は、SSL接続の内容を検査する場合があります。さらに、MITM証明書がローカルストアにインストールされている場合、管理対象デスクトップのユーザーはブラウザの警告を受けません。
誰がプロキシを管理しているか、およびそのログがどのように使用されているかによって、これは許容できるか、またはあなたの観点から悪いことです。
SSLインターセプトがどのように行われるかについての詳細は、これを参照してください link ：
SSLプロキシは、SSL接続をインターセプトするときに、エミュレートされたサーバー証明書をクライアントブラウザに提示します。ブラウザはProxySGが使用する発行者を信頼しないため、クライアントブラウザはセキュリティポップアップをエンドユーザーに発行します。 SSLプロキシが使用する発行者の証明書が信頼できるルートとしてクライアントブラウザの証明書ストアにインポートされている場合、このポップアップは発生しません。
ProxySGは、構成されたすべての証明書を管理コンソールからダウンロードできるようにします。 Internet ExplorerまたはFirefoxを介して発行者の証明書をダウンロードし、選択したブラウザーに信頼できるCAとしてインストールするようにエンドユーザーに依頼できます。これにより、エミュレートされた証明書の証明書ポップアップがなくなります...
フィッシングサイトを区別するのは難しいためです。これがEFFのSSL観測所です。
https://www.eff.org/observatory
一般的な考え方は健全で、なりすましは証明書の不適切な発行によるものです。他のすべての人が証明書に直面したときに、まったく同じ証明書を持っていると確信できれば、それがフィッシングサイトである可能性はゼロに近いでしょう。研究の驚異的な部分は、ブラウザによって信頼されているリーフノードとそこにあるCAの数です。
もう1つのポイント-DNSリゾルバーを所有する攻撃者は、OCSPまたはCRL要求をブラックホールに誤って転送する可能性があり、事実上すべてのブラウザーは、証明書が取り消されていない証拠として扱います。したがって、悪意のある人物が有効な証明書を盗んでも悪意のある人物がそれを取り消す場合、悪意のある人物はOCSP/CRLリクエストをブラックホール化することで、クライアントがその取り消しを見るのを防ぐことができます。
ほとんどの人をだます混合攻撃があります http://www.h-online.com/security/news/item/Black-Hat-new-ways-to-attack-SSL-740173.html
攻撃者は真ん中の男のように振る舞い、ブラウザにhttp：// ...を表示する勝利への暗号化されていないリンクを設定しますが、南京錠が設定され、緑色なので、人々はhttps：// ...の欠如を見逃します。
疑わしい証明書をクリックして許可しない限り、その可能性はほとんどありません。設定が不十分なブラウザや古いブラウザを弱いsslでハッキングする以外に、これはかなり難しい注文です。彼らは、Java、フォント、またはその他の潜在的に危険なファイルを使用して安全でないアドレスに解決し、悪意のあるコンテンツですべてをミットする一般的な主要Webサイトで使用される混合コンテンツIPアドレスの大規模なデータベースを持つことができます。したがって、混合コンテンツを無効にすることが今のところ特に優れたアイデアである理由です。
あなたの場合、質問はNOです。HTTPS接続は危険にさらされません。
それでは、その理由を調べましょう。
ブラウザにCAの公開鍵があります。信頼できる公開鍵。
攻撃者がDNSを制御できるだけでなく、サーバー自体、この場合はCAと対象のHTTPサーバーの両方を制御できると想定します。
攻撃者はブラウザとして一致する秘密鍵を持っていないため、CAを偽ることはできません。
攻撃者の証明書には信頼できるCAのスタンプが押されていないため、攻撃者はHTTPサーバーを偽造することもできません。
攻撃者が自分が制御または所有していないドメインの証明書を取得できるという極端な場合、以前のポイントは無効です。そして、攻撃者は彼の想像力が思い起こさせることができるものは何でもすることができます。問題は、これはCAが信頼できるという私たちの前提に違反しています。そのような証明書を攻撃者に許可するのはCAの責任です。そして、CAが信頼できなくなったとき、SSLは紙の虎にすぎません。