SSL を使用して、2 つのピア間の信頼できる接続を形成しています。各ピアは、特定の時間に接続する (または接続を受け入れる) 相手を認識しています。有効な証明書のみを受け入れる必要があり、さらに、特定の属性を持つ証明書のみを受け入れる必要があります (おそらく正規名を確認することによって)。
これまでのところ、この質問の例とその回答に基づいて、双方に話をさせることができます。各側は、他のピアによって提示された証明書を印刷できます。
ただし、これらの証明書を確認する正しい方法が何であるかはわかりません。明らかな方法は、接続が確立された後に証明書を確認し、期待に沿わない場合は接続を切断することです。
これを行うより正しい方法はありますか？ピアの提示された証明書が与えられ、それを高く評価または低く評価できるコールバックはありますか? それとも、SSL の作業が完了した後にそれを処理するのは正しいことですか?
この場合、私が CA であるため、CA を信頼することは問題ではありません。ユーザーに代わってこれらの証明書に署名しています。正規名はドメイン名でさえありません。ユーザーはピアツーピアで接続します。私が配布するクライアント ソフトウェアで、接続しているユーザーが私が署名した証明書を持っており、正しいユーザーであることを確認する必要があります。
プライベート PKI を実行しているようです。SSL_CTX_load_verify_locationsまたはを使用して、信頼チェーンのルートを OpenSSL にロードするだけSSL_load_verify_locationsです。
SSL_PEER_VERIFYOpenSSL が検証を確実に実行するために必ず使用してください。呼び出しはおそらく のようになりますSSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL);。ピア検証が失敗すると、connectは失敗します。
connect成功することを確認し、後でエラーをキャッチする方法があります。秘訣は、検証コールバックを設定し、検証コールバックが常に を返すようにし、接続がセットアップされた後に1呼び出すことです。例については、 SSL/TLS クライアントSSL_get_verify_resultを参照してください。
注: いずれの場合も、手動で名前チェックを実行する必要があります。OpenSSL は現在それを行いません (OpenSSL 1.1.0 の HEAD にあります)。libcurlリッピングできるコードについては、 または PostgreSQL を参照してください。
SSL/TLS クライアントの例は、OpenSSL の wiki で提供されています。SSL/TLS クライアントを参照してください。現時点では、サーバー コードやサンプルはありません。
ただし、これらの証明書を確認する正しい方法が何であるかはわかりません。明らかな方法は、接続が確立された後に証明書を確認し、期待に沿わない場合は接続を切断することです。
これには多くのことがあり、そのうちのいくつかは明らかではありません。回答をいくつかの部分に分けて説明しますが、すべての部分があなたの質問に答えようとしています。
まず、証明書が正しい形式であることを確認できます。Web のコンテキストで責任を負うグループは、CA/Browser フォーラムです。証明書を作成するための基本要件と拡張要件があります。
ベースライン ドキュメントでは、たとえば、コモン ネーム (CN) としてリストされている IP は、サブジェクト代替名 (SAN) にもリストされている必要があります。拡張ドキュメントでは、プライベート IP (RFC 1918 に従って予約済み) は拡張検証 (EV) 証明書に存在できないことがわかります。EV 証明書にワイルドカードを含めることはできません。
次に、RFC 5280、 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile ( http://www.ietf.org/rfc/rfc5280.txt )に従って、通常の検証を実行できます。
慣習的なチェックは、ホスト名の一致、期間の有効性チェック、エンドエンティティまたはリーフ証明書 (クライアントまたはサーバー証明書) チェーンのルートへの検証などです。CA を使用するブラウザーでは、信頼されたルートまたは中間の何百もの数になります。
失効チェックを実行することを選択した場合、おそらくアプリケーションを DoS することになります (それは明らかです!)。3G ネットワーク上のモバイル クライアントは、30MB の CRL をダウンロードして処理できません。アプリケーションが確実にハングします。また、URL が間違っている場合、アプリケーションは OCSP クエリを実行できません。これは確実に失敗します。
また、ワイルドカードを含むホスト名の照合を実行している場合は、ccTLD を適切に処理するように注意する必要があります。ccTLD は、*.eu、*.us、または இலங்கை (nic.lk) のようなものです。それらは約 5000 あり、Mozilla はhttp://publicsuffix.org/でリストを提供しています(あるいは、https://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw= 1）。
第 3 に、CA は何も保証しないため、CA から得られる回答は無意味です。信じられない場合は、Certification Practice Statement (CPS) を確認してください。たとえば、Apple のCertification Authority Certification Practice Statement (2013 年 9 月 18 日、6 ページ)からの抜粋を次に示します。
2.4.1. Warranties to Subscribers
The AAI Sub-CA does not warrant the use of any Certificate to any Subscriber.
2.4.2. CA disclaimers of warranties
To the extent permitted by applicable law, Subscriber agreements, if applicable,
disclaim warranties from Apple, including any warranty of merchantability or
fitness for a particular purpose
つまり、発行者の署名によって公開鍵を組織にバインドすることは保証されません。そして、それが X509! の目的です。
第 4 に、DNS は信頼できる回答を提供しません。そのため、DNS から不適切な回答を得て、敵が制御するサーバーに喜んで行進する可能性があります。または、米国の管理下にある 13 のルート DNS サーバーのうち 10 が共謀して、米国の国家安全保障の名の下に間違った回答を提供する可能性があります。
米国以外のサーバーから本物の応答を得ようとすることは、ほぼ不可能です。「安全な DNS」部分 (DNSSEC なし) はまだ進化中であり、私は主流の実装を認識していません。
米国のサーバーを共謀する場合、米国が圧倒的多数を占めているため、定足数は機能しません。
ここでの問題は、外部サービス (CA および DNS) からの入力に基づいてセキュリティの決定を下していることです。基本的に、信頼できないアクターを信頼する必要があります。
PKI と PKIX に関する問題をうまく扱っているのは、Dr. Peter Gutmann のEngineering Security (www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf) です。必ず第 1 章と第 6 章を読んでください。ガットマン博士は機知に富んだユーモアのセンスを持っているので、無味乾燥ではありません。もう 1 つのすばらしい本は、http://www.cl.cam.ac.uk/~rja14/book.htmlにある Ross Anderson のSecurity Engineeringです。
PKI、PKIX、および CA によって引き起こされるすべての問題に対して、いくつかの防御策があります。まず、独自の認証局であるプライベート PKI を実行できます。この場合、部外者を信頼していません。サーバーの証明書は有効なチェーンを形成しないため、不適切な DNS 応答と不正なサーバーを検出する必要があります。
次に、セキュリティの多様化戦略を採用できます。Gutmann は彼のEngineering Securityの本でそれについて書いています。292 ページから始まる「多様性によるセキュリティ」と 296 ページの「インターネット アプリケーションのリスク分散」セクションを参照してください。
3 番目に、Trust-On-First-Use (TOFU) または Key Continuity 戦略を採用できます。これは Wendlandt、Anderson、および Perrig のPerspectives: Improving SSH-style Host Authentication with Multi-Path Probingまたは SSH のStrictHostKeyCheckingオプションに似ています。この戦略では、通常のチェックを行ってから、証明書または公開鍵を固定します。また、証明書または公開鍵の他のビューを要求することもできます。予期しない証明書またはキーの変更は、警鐘を鳴らす必要があります。
OWASP では、https: //www.owasp.org/index.php/Certificate_and_Public_Key_Pinning で証明書と公開鍵のピニングを処理しています。注: 一部の場所では証明書が 30 日程度ごとにローテーションされるため、可能であれば公開鍵をピン留めする必要があります。頻繁なローテーターのリストには Google が含まれており、Certificate Patrol などのツールが非常に騒がしい理由の 1 つは Google です。