web-dev-qa-db-ja.com

httpsサーバーのホスト名のSSL検証

最近、私が使用しているライブラリ（特にApache HTTPClient）が、リモートサーバーのホスト名を証明書のCNに対して検証するように構成されている場合、文字列比較を行っているようです。
つまり証明書がIPに発行されており、ユーザーが代わりに名前を入力した場合。 https://secureserver/
しかしIP <-> secureserver（Windowsホストファイルで構成されたマップなど）検証は失敗し、

javax.net.ssl.SSLException: hostname in certificate didn't match: 
    <secureserver> != <10.4.5.1>

これは通常、すべてのライブラリに実装されている方法ですか？つまりsecureserverから10.4.5.1への逆ルックアップを期待していたのは間違いです。つまり、証明書のCNが発生しているはずですか？

ありがとう

appsecauthenticationtlscertificateshttp
3
Jim

httpsはprivate/public key cryptographyに基づいています。したがって、クライアントはサーバーの公開鍵を使用して、サーバーだけが復号化できる情報を暗号化します。

この単純なレベルでは、攻撃者は、攻撃者の公開鍵を使用して、実サーバーではなくクライアントをだましてクライアントに話しかける可能性があります。その後、攻撃者は自分の秘密鍵を使用して送信された情報を復号化し、それを実サーバーに転送します。これは 中間者攻撃 と呼ばれます。

この種の攻撃を防ぐために、SSLは証明書を使用します。証明書は基本的に公開鍵であり、いくつかの識別情報が添付されています。これらの証明書は、ID情報を確認するために認証局が署名できます。

クライアントは、証明書の名前が通信先のサーバーと一致することを確認する必要があります。通常のWebブラウザの場合、アドレスバーに表示されるドメイン名です。この検証がなければ、攻撃者は証明書を送信するだけで済みます。

DNSは安全ではないため、多くの状況で簡単に操作できます。ブラウザーが検証を緩和して問題のドメイン名に属するIPアドレスを受け入れる場合、安全でないDNSを信頼します。

それとは別に、SSL証明書でのIPアドレスの使用は無効です。したがって、アドレスバーにip-addressを入力しても、ブラウザは証明書を拒否する必要があります。ただし、証明書には、有効なドメイン名のリストが含まれている場合があります。

3
Hendrik Brummermann

はい、証明書名の検証プロセスで名前解決、逆解決、またはその他のマッピングが行われることを期待するのは間違っていたと思います。行われるマッチングは、アプリケーションレイヤーで実行される文字通りのものです（申し訳ありませんが、悪いラベルです。つまり、「アプリケーションレイヤー」と言うとアプリケーションによって呼び出されるSSLライブラリコードを意味します。OSIでは、これはおそらくセッションレイヤーまたはプレゼンテーションレイヤーです。 、しかしそれはすべてアプリケーション実行可能ファイルの一部です）。

Javaライブラリハンドラーが探している名前マッピングに追加されるとは思わない。SSL/ TLSプロトコルは実際にリテラル名を照合するためのものであり、暗号化と認証局の側面が整っていることを確認します）。

SubjectAltNameタグを使用して、複数の名前に有効に一致する証明書を生成できると思いますが、これは、あなたが見ているものとは逆のアプローチです。

3
gowenfawr

SSLのポイントは、外部の世界が敵対的であるということです（少なくとも潜在的に）。接続に影響を与える可能性のある攻撃者（そして、SSLを使用する理由でそのような人がいると信じている）もDNS応答を変更する可能性があるため、DNSが真の変更されていない応答を返すことは期待できません。全体の演習は、「トラストアンカー」（別名「ルートCA」）の特定のセットを信頼し、そこから構築すること、そしてそこからonlyを構築することです。

したがって、SSLクライアントは、目的のサーバーのnameが実際にサーバーの証明書に存在することを要求します。この名前が潜在的にマップされたIPアドレスのような間接的なものはありません。 DNSのような安全でないメカニズム。

注：概念的には、クライアントが期待する限り、あらゆる種類の「アイデンティティ」を使用できますは証明書にあるものと同じです。 [〜＃〜] https [〜＃〜] では、「クライアントが期待すること」がURLによって適切に記述されていると想定されています、より正確には、URLのserver nameの部分。 Webブラウザーはその名前を目立つように表示します（私は現在Chromiumを使用しています。URLバーにURLを灰色のテキストとして表示し、サーバー名を濃い色で強調表示しています）。クライアントがターゲットIPアドレス（ハードコードされているか、DNS要求からではなく信頼できるソースから知られている）を "知っている"規則を想像し、そのIPアドレスが証明書に表示されることを期待します。 X.509証明書には実際にIPアドレスを含めることができます（ Subject Alt Name 拡張子のiPAddress名前タイプを参照）。ただし、既存の実装はIPアドレスと一致せず、名前と一致します。 それが書かれた 、そしてnamesは人間が検証でき、インフラストラクチャの移行または拡張時にIPアドレスがかなり変化する可能性があるため、それは理にかなっています。

2
Thomas Pornin