通常、双方向SSL別名相互認証には、サーバーcaキーと証明書などの生成が含まれます。次に、クライアントがcsrを生成して提供し、csrに署名してクライアント証明書を提供します。
でも、
x509 公開証明書を相互に交換して「相互認証」を実装するようにクライアントが要求するケースに遭遇しました。これは聞いたことがありますか？おそらく「双方向SSL」または「相互認証」以外のものと呼ばれます。
これに関するドキュメントや情報をopensslで見つけるのに苦労しています。
6450 次
3 に答える
4
x509 公開証明書を相互に交換して「相互認証」を実装するようにクライアントが要求するケースに遭遇しました。これは聞いたことがありますか？
私はそれがまだ相互認証と呼ばれていると信じています。
一般に、証明書ベースの相互認証は 2 つのモデルのいずれかに分類されます。1 つ目は CA 階層を持つエンタープライズ モデルで、組織の CA がクライアント証明書とサーバー証明書の両方に署名します。
2 番目のモデルは、 Origin Bound Certificatesと呼ばれるもので自己署名証明書を使用するクライアントです。証明書を必要とする各サイト (オリジン) がクライアントに証明書を提供させるため、オリジン バウンドと呼ばれます。オリジン バインド証明書は、IETF のToken Binding プロトコルの基礎です。
トークンバインディングがオリジンバインド証明書と同じセキュリティプロパティを持っているかどうかはわかりません。ご覧のとおり、オリジン バインド証明書を使用して、認証をチャネル設定の一部にすることで中間者攻撃を阻止できます。トークン バインディングはバインディングを分離し、スタック内でそれを上に移動します。これにより、MitM が仲介者として機能できるようになると思います。
エンタープライズ証明書
エンタープライズ モデルでは、OpenSSL を使用して次のことを行います。
サーバーで以下を実行します。サーバーはクライアント証明書の検証を処理します。
SSL_CTX_set_verifyとSSL_VERIFY_PEERで呼び出しSSL_VERIFY_FAIL_IF_NO_PEER_CERTます。CTX_set_client_CA_listサーバーが受け入れる発行者 CA のリストを設定するために呼び出します。これにより、証明書を要求する適切な SSL/TLS メッセージがクライアントに送信されます。これは名前のリストをクライアントに送信するだけです。それらはまだサーバーで信頼されている必要がありますSSL_CTX_load_verify_locationsサーバーが受け入れる発行者で呼び出します。これにより、サーバー側に信頼が追加されます。
クライアントで、次を実行します。
SSL_CTX_use_certificate_fileクライアント証明書をロードするための呼び出しSSL_CTX_use_certificate_chain_file必要に応じて電話するSSL_CTX_use_PrivateKey秘密鍵をロードするための呼び出し
オリジンバウンド証明書
CA 階層がないため、オリジン バウンド証明書と自己署名証明書は少し異なります。
サーバーで以下を実行します。自己署名証明書であるため、サーバーはorを呼び出しません。SSL_CTX_load_verify_locationsCTX_set_client_CA_list
SSL_CTX_set_verifyとSSL_VERIFY_PEERで呼び出しSSL_VERIFY_FAIL_IF_NO_PEER_CERTます。SSL_get_peer_certificate鍵交換後に呼び出します。サーバーに提示されたクライアント証明書を検証します。
クライアントで、以下を実行します。エンタープライズモデルと同じです。
SSL_CTX_use_certificate_fileクライアント証明書をロードするための呼び出しSSL_CTX_use_certificate_chain_file必要に応じて電話するSSL_CTX_use_PrivateKey秘密鍵をロードするための呼び出し
エンタープライズ CA がないということは、クライアントの自己署名証明書を帯域外でサーバーに伝達する必要があることを意味します。次に、サーバーは、識別名とシリアル番号に基づいてクライアント証明書を検索するために、ある種のディレクトリを保持する必要があります。ここで本当に気にするのは、クライアントの公開鍵です。この場合、X509 証明書はプレゼンテーションの詳細です。通常、機関の署名を介して ID を公開鍵にバインドするため (ただし、このモデルではそうではありません)、単なるパッケージ化です。
このモデルの攻撃 (部屋にいる 500 ポンドのゴリラ) は、登録機関 (RA)がないため、同じ識別名とシリアル番号を使用してユーザーになりすました悪者です。公開鍵の変更が予期されていることを確認するためにユーザーに電子メールを送信するなど、だまされないようにするためのいくつかの対策が必要になります。
この攻撃は、ユーザーを登録するときに、次の 3 つまたは 4 つのものが必要であることを意味します。
- 固有の {識別名、シリアル番号}のペア
- 公開鍵 (X509 証明書の一部)
- 確認/回復メールアドレス
さらに混乱させるために、ユーザーは 3 つまたは 4 つのデバイスを所有している可能性があるため、デバイスごとに新しいオリジン バインド証明書を作成します。その登録も適切に処理する必要があります。
まとめて一周すると、本当に重要なのは、電子メール アドレスと、電子メール アドレスに関連付けられたさまざまな公開鍵/ID です。ID は、固有の{識別名、シリアル番号}のペアを持つ X509 証明書に格納されます。おそらく、監査目的でそれらを一意にする必要がありますが、デバイス間でコピー/貼り付けが行われる可能性があります.
これに関するドキュメントや情報をopensslで見つけるのに苦労しています。
これは高レベルのセキュリティ アーキテクチャと設計上の問題であるため、おそらく情報を見つけるのに苦労しているでしょう。いくつかの参照を支援するために、まず、Dietz、Czeskis、Balfanz、および Wallach のOrigin-Bound Certificates: A Fresh Approach to Strong Client Authentication for the Web を読んでください。Peter Gutmann のEngineering Securityと Ross Anderson のSecurity Engineeringも参照してください。
オリジン バウンド証明書は、ほぼすべてのパスワード ベースの認証システムを置き換えるために使用できます。ユーザー名/パスワードベースの認証から Web サービスで使用される API キーまで、ほぼすべてのシステムに適用されます。パスワードは引き続きローカルの秘密鍵を保護するために使用されますが、パスワードはネットワークに送信されません。
データの機密性レベルがより強力なセキュリティ制御を必要とする場合、クライアント証明書は、パスワードの誤った取り扱いと失敗した認証および認可制御を阻止するために最初に利用するものの 1 つです。Apple、Microsoft、Google (その他) によるパスワードの使用と取り扱いに同意しないでください。何年もの間、欠陥品でした。その単純な企業は、ユーザーがビジネスを獲得できるように簡単にします。
于 2016-05-05T07:16:24.710 に答える
1
TLS (または SSL) ハンドシェイクでの相互認証では、両方のピアの証明書を交換する必要があります。
クライアントは、サーバー証明書 (発行元の証明書チェーン) を検証することにより、接続先のサーバーを認証します。
これは、たとえば、任意の http s Web サイトを参照するときに行われます。ブラウザーは、受信した証明書が信頼されていることを確認し (証明書ストアを検索して)、他のプロパティの中で、Web サイトの dns 名が証明書の共通名と一致することも確認します。
TLS 相互認証では、サーバーはクライアント証明書を検証することによって、クライアントが信頼されていることも確認します。このあまり一般的ではないタイプの認証には、次の条件が必要です。
- クライアントは、証明書認証を必要とする適切な暗号を TLS ハンドシェイクで提案します。
- サーバーは、暗号構成に基づいてクライアント暗号の 1 つを選択します。
- サーバーの証明書ストアには、少なくともクライアント ルート CA (中間クライアント CA の可能性もあります) があります。
- クライアントには、サーバーのルート CA (および場合によっては中間 CA) も必要です。
最初の条件を満たすには、クライアントの openssl 暗号リストに、たとえば のような RSA ベースの暗号を使用した認証を含める必要がありますRSA-AES128-SHA256。メッセージを見ると、wireshark を使用しているクライアントの暗号リストを確認できclient helloます。暗号の数を定義 (または制限) するには、openssl ciphersコマンドを使用して暗号文字列を操作します。
サーバー側では、暗号も構成および選択する必要があります。この選択は実装に依存します。多くの場合、サーバーは最初に見つかった適切な暗号を選択しますclient hello(RFC で、サーバーがリストから任意の暗号を選択できると記載されている場合でも)。そのため、必要な暗号をクライアント暗号リストの一番上に置くと役立つ場合があります。
証明書に関しては、サーバーとクライアントの両方のルート CA を、クライアントとサーバーの証明書ストアにそれぞれプロビジョニングする必要があります。いずれかの側に証明書チェーンがある場合、中間 CA も証明書ストアに配置する必要がある場合があります。
于 2016-05-05T10:38:08.770 に答える