証明書の透明性レビュー

SSL / TLSプロトコルの動作原理は、公開鍵暗号に基づいています。 相互作用の片側または両側には、証明書と関連する秘密鍵があります。 これにより、トラフィックの認証と暗号化が可能になります。



認証に関しては、相互認証よりも一般的です。つまり、サーバーはクライアント証明書をチェックし、クライアントはサーバー証明書をチェックしますが、サーバーのみがクライアントを認証します。 必要に応じて、サーバーは、ワンタイムパスワードなどの使用可能な方法を使用して、後でクライアントを認証できます。 証明書認証が実行される原理は非常に簡単です。クライアントは自分の秘密鍵でデータセットに署名し、サーバーはこの署名を検証します。



一部の人々が考えるように、SSL / TLSを使用した暗号化は実際には非対称ではありません。 非対称暗号化は、対称暗号化キーの交換に使用されます。 対称暗号を使用して、さらにデータ交換が行われます。



キーペアのみで認証と暗号化のための暗号化操作を実行することが可能です。 しかし、公開鍵の配布とそれらへの信頼には困難が伴います。 相互作用の各サイドでは、特定の公開キーが特定のサブジェクトに対応していることを何らかの方法で確認する必要があります。 つまり、信頼できるチャネルを介してキーを取得する必要があります。そうでない場合、攻撃者ではないことを確認する方法はありますか？ ここで、証明書が役立ちます。 それらは、サブジェクトと彼の公開鍵に関する情報を含む、電子署名によって署名されたデータのセットです。 証明書が行う最も重要なことは、その所有者（サブジェクト）が公開鍵ペア（秘密鍵）を持っていることを証明することです。



Web上の信頼モデルは、ブラウザー（または他のソフトウェア）が信頼できるもののリストに証明機関の証明書を含めるか、サブジェクトの最終的な証明書を直接信頼することを意味します。 サードパーティの証明書を信頼できるものとしてインストールするには、特にこのプロセスに賢明に取り組む場合、ユーザーによる追加のアクションが必要です。 したがって、サブジェクトの信頼モデルは、その証明書を発行した証明機関の信頼を通じてより頻繁に遭遇します。 簡単に言えば、CAを信頼する場合、CAが発行する証明書を信頼します。



もちろん、認証センターの署名の確認に加えて、有効期間、失効リスト（CRL）の存在、目的など、他の多くの証明書検証も行われます。



ドメインの証明書



ドメイン所有者は、HTTPSを介してユーザーがWebサイトにアクセスできるように証明書を受け取るため、ユーザーはWebサーバーへのトラフィックが保護され、Webサーバーが不正ではないことを確認できます。 証明書を発行する証明機関として、ほとんどのブラウザーで信頼されているものが選択されます。 これにより、サイト訪問者にはセキュリティ警告が表示されなくなります。 証明書に署名する前に、証明機関はドメイン所有者が証明書にアクセスしていることを確認します。 これを行うために、CAはこのドメインの技術的な電子メールへのリンクを送信するか、たとえば、Webサーバーに特定のファイルを配置するように依頼できます。 拡張検証-拡張検証証明書を使用した証明書には、ドメイン所有者のより厳密な検証が必要です。



証明書の問題



認証局がこれらのドメインの所有者の許可なしにドメインの証明書を発行した例があります。

• フィンランドのITマネージャーが、hostmaster @ live.fi、security @ live.fi、hostmaster @ hotmail.fiというエイリアスをメールボックスに登録しました。 彼は後にlive.fiドメインの証明書を取得しました。
• CNNIC認証局は中間認証局に証明書を発行し、中間認証局はそれを使用してローカルネットワークで中間者を編成しました。 訪問したWebサイトの有効な証明書は、その場で生成されました。
• 内部テスト中に、シマンテックは google.comやwww.google.comを含むいくつかのドメインの証明書を発行しました

有効な証明書の不正な発行のこれらのケースおよびその他のケースは、ユーザーおよび技術専門家だけを心配するものではありません。 証明機関自体は、提供するサービスに対する信頼を失いたくありません。 また、Googleのようなインターネットの巨人は、彼らのサービスが知らずに侵害されることを望んでいません。



ドメインの証明書（および秘密キー）を手元に置いて、中間者攻撃を組織し、エラーメッセージで注意を引くことはできません。ドメインの証明書は違法ではありますが、ブラウザーの観点からは無効です。疑い。



証明書の透明性



そのため、ドメイン所有者は自分のドメインに対して発行された証明書を常に把握しているわけではないという事実に気付きました。 証明書の透明性 （CT）プロジェクトは、この誤解を取り除くことを目的としています。



証明書の透明性は、実験的なオープンIETF標準であり、Googleによって開始されたオープンソースプロジェクトです。



証明書の透明性は、ドメイン所有権の追加の検証を追加せず、証明書の発行を妨げませんが、誰でも認証センターによって発行されたすべての証明書について知ることができます。 すべての証明機関がこの標準をサポートすると、ドメイン所有者がそれを知ることができないように証明書を発行することができなくなります。



証明書の透明性を使用する場合、発行された各証明書に関する情報はログ（ Certificate log ）に記録されます 。これは書き込み専用で、公開監査用に開かれています。 このログでは、エントリの変更または削除は許可されませんが、追加のみが許可されます。 誰でもログにアクセスして、発行された証明書に関する情報を取得できます。 現時点では、すでにいくつかのそのようなログがあります。 これらのログを常に監視することで、ドメインのすべての証明書の発行を追跡でき、間違った証明書を見逃すことはありません。 エントリを追加することによってのみログにアクセスできるようにするには、 Merkle treeと呼ばれるツリーハッシュを使用します 。 これにより、ログの新しいバージョンに以前のバージョンが含まれていることを確認できます。 ログ自体は電子的に署名する必要があります。より正確には、ログのマークルツリールートのハッシュに署名する必要があります。



証明書をログに追加すると、署名された証明書のタイムスタンプが応答として返されます。 それはまるでログが約束を一定時間ログに含めることの約束です。 TLS接続を確立する場合、Webサーバーは、証明書とともに1つ以上のログからタイムスタンプをクライアントに提供する必要があります。 クライアントブラウザは、有効なタイムスタンプがない場合、証明書を受け入れません。



署名されたタイムスタンプについてクライアントに伝えるには、3つの異なる方法があります。

• X.509v3証明書拡張機能にタイムスタンプを追加します。 この場合、Webサーバーは変更を必要としません。 証明機関は、いわゆる事前証明書をログサーバーに送信し、それに応じて署名付きタイムスタンプを受信します。その後、証明書が発行されます。 事前証明書自体は、特別な拡張のためにクライアントで検証に合格することはできませんが、認証センターによるその発行は、実際の証明書を発行する約束を意味します。 したがって、事前証明書の誤った発行は、証明書の誤った発行と同等です。
• TLS拡張 signed_certificate_timestampでタイムスタンプを渡します。 次に、Webサーバーがそのような拡張機能のサポートを開始するために、変更が必要です。
• OCSPのホチキス止めメカニズム。 このため、認証センターは証明書を発行すると同時に、ログサーバーに転送します。 次に、WebサーバーはOCSP要求を作成し、署名されたタイムスタンプ付きの応答を証明機関から受け取ります。

ログの監視は、オブザーバー（ 証明書モニター ）によって行われます。 これらは、ログ内の新しい各エントリを追跡し、Merkleツリールートの新しいハッシュを独自の計算と比較するサーバーです。 これらは、違法に発行された証明書または異常な証明書、たとえば認証センターの証明書を見つけるように設計されています。



証明書の透明性におけるもう1つの役割は、 証明書監査員です。 ログに関する部分的な情報を取得し、この情報が他の利用可能な部分的な情報と一致することを確認します。つまり、ログとその暗号シーケンスの正しい動作を確信しています。 監査人の2番目のタスクは、特定の証明書がログに表示されるようにすることです。 監査人は、クライアントのブラウザとサードパーティサービスの両方にすることができます。 監査機能は、オブザーバーが実行することもできます。





結果として、ブラウザが証明書を受け入れない場合、その情報がログにない場合、他の誰かのドメインに気付かれずに証明書を発行することは困難です。 ただし、証明書の透明性の要件を満たす証明書の不正な問題を検出するために、ドメイン所有者はログを監視する必要があります。 つまり、オブザーバサーバーを独立して維持するか、このドメインに対して発行された証明書をドメイン所有者に通知するサードパーティサービスにサービスの料金を支払います。



2015年の初めから、ChromeブラウザーではEV証明書のCTサポートが必要です。 そのため、たとえば、同じドメインのアドレスバーがFirefoxとChromeで表示されるようになりました。





接続の詳細を見ると、この証明書のCT情報がないことがわかります。

Firefoxブラウザーは、証明書の透明性テクノロジーもサポートする予定です。 しかし、Microsoftは独自の方法で別のテクノロジーを開発しています。 IE11以降、組み込みのSmartScreenフィルターは、Webページがアクセスした証明書に関する情報を収集します。 このデータは、たとえば次のような異常な証明書を検索するために使用できます。

• ウェブサイトは、下位の認証機関向けの証明書を使用しています
• 特定の地域への訪問者に対する別の証明書の予期しない使用
• 特定の証明機関によって発行された証明書の分野における重要な変更。 たとえば、OCSPへの参照の変更または欠如。

一般に、Microsoftのアプローチはより閉鎖的であり、主にユーザーを対象としています。 トピックはそれについてではないので、私は特にコメントしません。



おわりに



標準はまだ実験的ですが、これは徐々に適用されることを妨げません。 証明機関とブラウザメーカーの両方は、すでに部分的に証明書の透明性のサポートを開始しているか、少なくとも参加を発表しています。 企業は認証機関を管理するツールを受け取り、「悪い」証明書を迅速に特定できるようになります。 認証局は、証明書の発行においてさらに責任を負います。 万能薬として証明書の透明性に頼るべきではありませんが、攻撃者の活動を複雑にすることは間違いなく可能です。