kdnakt blog

hello there.

ゆるTLSアドベントカレンダー 9日目:SSL証明書とドメイン管理権限の検証

この記事は ゆるTLS Advent Calendar 2021 の9日目の記事です(34日遅れorz)。

 

7日目、8日目は認証局の話をしたので、SSL証明書の発行にまつわる話を。

 

 

[SSL証明書発行時の検証方法]

SSL証明書認証局による発行時の検証手順によって大きく以下の3つに分類される。

  • DV証明書(Domain Validation)
  • OV証明書(Organization Validation)
  • EV証明書(Extended Validation)

 

DV証明書の発行時には、ドメインの管理権限の検証が行われる。OV証明書やEV証明書の場合、これに加えて、証明書を取得する主体に関する確認が追加され、OV証明書よりもEV証明書の方が基準が高度で複雑になる*1

 

いずれの証明書の場合でも、ドメインの管理権限の検証は不可欠である。

証明書発行対象となるドメインの管理権限を申請者が持っているかどうか、以下のいずれかの方法で検証される。

  • メール認証
  • ファイル認証(ページ認証)
  • DNS認証

 

メール認証では、admin@example.comのように、adminやhostmasterなどいくつかの固定のローカルパートと証明書のコモンネーム(ドメイン)を組み合わせて連絡先メールアドレスとして指定する。そして、そのアドレスに送られてくるメールに含まれるリンクをクリックすることで検証が完了する*2

 

ファイル認証(ページ認証)では、ドメインの指定されたパス(例:/.well-known/pki-validation/XXX.txt)に指定された認証ファイルを配置すると、認証局がそれをチェックすることで検証が完了する。

 

DNS認証も同様で、TXTレコードに認証文字列を追加し、認証局がこれをチェックすることで検証が完了する。

 

[DNSの重要性]

メール認証、ファイル認証(ページ認証)、DNS認証の3つの検証方法をよく見ると、どれもがDNS(Domain Name System)と密接に結びついていることが分かる。

 

2021年のBlack Hat USAというセキュリティイベントでは、Let's Encryptが2020年に導入した多視点ドメイン検証という手法*3脆弱性があることが指摘された。

ドメイン検証のためリクエストを送信するバンテージポイントが利用するネームサーバを攻撃することで、不正な証明書を取得できる可能性がわずかながらあるらしい。DNSの問題ということは、多視点ドメイン検証を行なっていないLet's Encrypt以外の認証局も同様の攻撃に対して脆弱、ということになりそう。

portswigger.net

元の発表資料はこちら(Let‘s Attack Let‘s Encrypt)

 

事前の対策としては、バンテージポイントまたはネームサーバを増やすという認証局頼みのものがある。また、事後的な対策としてはCT(Certificate Transparency)を利用して不正な証明書を検出するのも有効なようだ。

 

[まとめ]

  • SSL証明書はDV/OV/EVの3種類あり、いずれの場合もドメイン管理権限の検証が行われる
  • 2020年にLet's Encryptはドメイン検証の手法として多視点ドメイン検証を導入した
  • 2021年のBlack Hat USAで多視点ドメイン検証の問題点が指摘された

*1:EV証明書はGlobalSignの場合、登記簿のチェックが追加される。また、CA/B Forumが定めているEV証明書のガイドラインによると、EV証明書の場合は申請組織またはその親会社の事業期間が3年以上ないと取得できない(11.6.2.1)。

*2:その手軽さゆえに、メール認証は度々不正な証明書の取得に利用されている。参考:『プロフェッショナルSSL/TLS』84ページ

*3:この手法は、ネットワーク同士を経路制御プロトコルであるBGPを悪用した攻撃手法に対する対策として導入された。

letsencrypt.org

www.usenix.org