この記事は、SSL/TLS暗号化に関する私のシリーズの3つのうちのパート3です。パート1では、よく知られている暗号化の概念の基本について説明します。パート2では、OpenSSLとPKIについて簡単に紹介します。このパートでは、PKIの弱点の問題を解決し、2つの対策を紹介します。
まず、依拠当事者という用語を紹介します。 。証明書利用者は、x.509証明書を検証しようとしているWebブラウザ、電子メールクライアント、チャットアプリケーションなどです。ほとんどの場合、証明書利用者は、トラストアンカーのCAが証明書に署名したかどうかを確認することでそれを実現します。
[次のこともお勧めします：複数のSSHキーペアを管理する方法]
エクスカーション：秘密鍵を保護する
パート1からわかるように、秘密鍵は保護する必要があるものです。これは、信頼できるマシンで行われるはずの作成から始まります。
ここで、「信頼できるマシンとは何ですか？」と質問するかもしれません。
さて、あなたが知らない誰かによって運営されているオンラインサービスは確かに信頼できません。サービスプロバイダーが作成されたキーのコピーを保持しているかどうかがわからないため、ブラウザでWebサービスを使用して秘密キーを作成しないでください。これを防ぐには、代わりにオフラインマシンを使用できます。
秘密鍵は必要な場所にのみ保管し、安全に保管してください。一部の匿名FTPサーバー上のディレクトリは、確かに安全な場所ではありません。特権ユーザーのみがアクセスできるネットワーク共有、または添付ファイルの保存を許可するパスワードマネージャーは、確かにそれを置くのに適した場所です。
保護されていない秘密鍵を誤ってネットワーク共有または公開Gitリポジトリにコピーした場合は、それを削除して新しい秘密鍵を作成してください。それが危険にさらされていないことを確信することはできません。すぐに削除しても、なんらかのスナップショットメカニズムでまだ保存されていないかどうかはわかりません。
PKIの弱点
PKIとは何か、およびその仕組みについては、このシリーズのパート2で説明しました。わからない場合は、まずその部分を読んでください。
一言で言えば、この証明書の混乱に対処する理由は、証明書利用者が不正ではなく正しいサーバーと通信できるように支援したいからです。ですから、証明書利用者が信頼するCAによって署名された証明書を取得し、私たちは皆幸せですよね？
そうですね、PKIに重大な設計上の欠陥がなければ、私たちはそうなる可能性があります。
インターネット上に私たちの依拠当事者の信頼を持っている数百のCAがあります。これらのCAの中には、証明書に署名し、証明書利用者の信頼を得ることができるサブCAを備えているものもあります。また、これらのCAはすべて、有効なドメイン名の証明書を発行できます。
したがって、一般的に、どのCAもドメインの証明書を発行する可能性があり、それについてさえ知らないでしょう。この証明書は、信頼できるCAによって署名されているため、証明書利用者がこの証明書を信頼するため、ドメインに対する中間者攻撃に使用される可能性があります。
そして、これは理論上の脅威ではありません。 2015年3月、CNNICによって発行された一部の無許可の証明書は、グレートファイアウォールを通過するトラフィックを復号化するために使用されました。 2012年に、警備会社は、従業員をスパイするためにそれを使用した民間企業に少なくとも1つの証明書を発行したことを認めました。そして2011年に、認証局の会社は、署名証明書の一部が盗まれたという壊滅的なハッキングを経験しました。
考えられる対策
上記の3つの例は、PKIのコアの何が問題になっているのかを示しています。デザインに欠陥があります。それで、それを修正する方法は？以下は、問題を軽減するのに役立つ可能性のある2つの手法です。
認証局承認（CAA）
RFC 8659のDNS認証局承認（CAA）リソースレコードの要約から：「認証局承認（CAA）DNSリソースレコードを使用すると、DNSドメイン名の所有者は、その証明書の発行を許可された1つ以上の認証局（CA）を指定できます。ドメイン名。CAAリソースレコードを使用すると、パブリックCAは、意図しない証明書の誤発行のリスクを軽減するための追加の制御を実装できます。」
まあ、これ以上説明することはできませんでした。 CAAを使用すると、ドメイン名の所有者は、ドメインの証明書の発行を許可するCAを指定でき、CA自体がCAAレコードを尊重することを約束します。 RFC 8659は、次の3つのプロパティを定義しています。
- issueには、CAAレコードによって特定のドメインの証明書を発行することを許可されている、CAのドメインが値として含まれています。
- issuewildは基本的にissueと同じですが、ワイルドカード証明書用です。 issuewildが設定されていない場合は、代わりにissueの値が使用されます。
- iodefには、CAAポリシーに関して問題が発生した場合に使用される連絡先情報が含まれています。
次のレコード例を見てみましょう。
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:[email protected]" 上記の例の最初の行は、CALet'sEncryptのみがドメインexample.comの下の任意のホストに対して証明書を発行できることを意味します。他のCAは、このドメインの証明書を発行してはなりません（MUSTNOT）。 2行目は、問題が発生した場合に連絡できるメールアドレスを示しています。
DNSは階層的に編成されているため、上記のCAAレコードは、web.example.comだけでなく、host.web.example.comとhost.sub.web.example.comにも適用されます。別の例を見てみましょう：
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:[email protected]"
sub.web.example.com IN CAA 0 issue "example-pki.org" ここでは、CAexample-pki.orgのみがhost.sub.web.example.comなどの証明書を発行できます。 3行目のレコードは、example.comのポリシーを上書きします。あなたはその考えを理解したと思います。
もちろん、CAAリソースレコードは、非準拠のCAが許可されていないドメインの証明書を発行することを妨げることはありません。ただし、埋め込まれたトラストアンカーから削除されるリスクがあります。これは、ほとんどの場合、廃業することを意味します。
また、許可されたCAが、使用を許可されていない人に証明書を誤って発行する可能性があります。信頼できるCAを選択し、賢明に選択してください。
ご覧のとおり、CAAは100％のセキュリティを提供しませんが、実装が簡単で、証明書の誤発行のリスクを軽減します。
証明書の透明性（CT）
証明書の透明性とは、「...発行または監視されたトランスポート層セキュリティ（TLS）証明書の存在を公に記録するための実験的なプロトコルであり、誰でも認証局（CA）の活動を監査し、容疑者の発行に気付くことができます。証明書と証明書ログ自体を監査することを目的としています。最終的には、クライアントがログに表示されない証明書を尊重することを拒否し、発行されたすべての証明書をログに追加するようにCAに強制することを目的としています。」 （要約RFC 6962）
CTは、TLS証明書のアカウンティングの形式を提供し、ドメイン名に対してCAが発行した証明書を調べることができます。そのためには、オンプレミスバージョンとしても利用できるsslmateのCertSpotterなどのサービスを使用できます。以前は仮想プライベートサーバーでオンプレミスバージョンを実行していましたが、過去2年間のログの増加により、ログを最初から最後までクロールすることは不可能のようです。仕事は何週間も実行され、終了しませんでした。更新を完了するためにホストを再起動する必要があるときに中止されました。
現在、発行された証明書をCTログに追加することを強制されるCAはありませんが、ログの増加は、それらの多くがすでに証明書を追加していることを示しています。私の意見では、主要なブラウザがCTログエントリを含む証明書のみを信頼し始め、それらを必須にするのは時間の問題です。
[この無料の電子書籍を入手する：ダミーのKubernetesクラスターを管理する。 ]
まとめ
PKIの元の設計には欠陥があり、もはやあまり信頼できません。 RFC8659とRFC6962では、信頼を取り戻し、ドメイン名の所有者がドメインの証明書を発行した人を追跡できるようにするための2つの方法が提供されています。
したがって、今後は、秘密鍵を保護し、ドメインのCAAリソースレコードを設定し、CTログの監視を開始することを忘れないでください。