TLS失効リストの御利益を感じた、認証局eMudhraの脆弱過ぎた中間証明書問題

認証局eMudhraの中間認証局の証明書が脆弱であったことが話題になっている^*1。ミリ秒で公開鍵から秘密鍵を計算可能。この中間認証局が署名したウェブサイトの証明書は、すべて信頼がおけないことが判明した。しかし、実質的には（特に日本人には）大した問題ではない。

ここ5年間ぐらいでウェブサイトの認証とそれとの通信の暗号化はほとんど義務になった。Googleの市場支配力によるTLS義務化^*2。

このうち認証の方は、URL（もしくはIPアドレス）ごとのウェブサイトの証明書に対して、ルート認証局が電子署名してあるか否かを、ブラウザーが調べることで実現している。

ルート認証局の証明書の秘密鍵が漏洩すると、誰でもそのルート認証局として署名を行えてしまう。重大なセキュリティー上の驚異となる。しかし、情報漏洩はこの世の常。秘密鍵が漏洩した場合の備えもある。

証明書の失効リスト（CRL）というモノがあって、サイト証明書やルート証明書を入れておくと、ブラウザー（などのTLSを使うソフトウェア）は認証時にチェックを行う。また、最近のブラウザーは自動でダウンロードする仕組みが備わっており、その動作が標準だ。

eMudhraの中間認証局（とそれを承認していたルート認証局）の証明書は、その脆弱性の発覚した直後にCRLに入れられて無効になった。無効になる前に、偽造（というか複製）証明書で何か悪い事をされているのではないか心配になるかも知れないが、偽造証明書を悪用する前に（www.yahoo.co.jpなどのホスト名をIPアドレスに変換する）DNSハイジャックが必要になる。

ネットワーク管理者が信頼のおけないネットワークに接続し、かつCRLを自動更新しないソフトウェア^*3に対しては、認証局eMudhraの複製証明書を悪用して作用することはできるが、ブラウザーに関してはそうはいかない。ネットワーク機器の中にはCRLを自動更新しないソフトウェアが動いている場合もあるのでまったくの無害とは言えないが、そういうネットワーク機器を管理しているのはDNSを管理している人と概ね一致している。古い機器を除けば、そのうちファームウェアのアップデートで、信頼する認証局の一覧からeMudhraが排除されるはずだ。

認証局eMudhraの脆弱過ぎた中間証明書は重大な問題ではあるが、従来から準備されていた仕組みによって大事にはならなかった。この辺りのことが分かっていなくて、深刻な事態だと吹聴しているソフトウェアエンジニアが散見される方が心配だ。

*1認証局eMudhraの中間証明書、秘密鍵が「数ミリ秒」で復元可能な脆弱性　大手各社が緊急遮断 - ITmedia NEWS

*2同社のブラウザーChromeは、2018年7月に非TLS通信に「保護されていない通信」と警告を出すようになり、2020年7月に古い規格/バージョンのSSL/TLSを含めて表示を拒絶するようになった。

*3プログラミング言語のTLSのライブラリーの多くは、標準では証明書失効リストをチェックしない仕様になっている。