カザフスタンの政府ルート証明書問題の構造が理解できなかった数時間前の自分へ

2016年の年始にはカザフスタン政府がルート証明書のインストールを国民に強制し、そして最近になって実際にMITMが発生したと報告され(7月18日)MozillaとGoogleがブロックした(8月21日)ことをつい先ほど知った。
ちなみにこの記事を投稿したのは2019年8月28日である。

簡単に調べた限りの記事や声明などでは「政府があらゆるHTTPS通信を傍受できるようになる」といった文言が散見された。もちろん勝手にルート証明書をインストールさせるヤバさは感覚ではわかるが、どういうメカニズムで傍受・検閲されているのかが瞬時に理解できなかった。
また、それらを具体的に解説しているところは見つからなかった(業界にとっては常識だから…?)。

そこで、小一時間ほど考察して個人的に納得のいったMITMメカニズムを書き残しておく。
ツッコミはコメントかTwitterで遠慮なくつけてください。

なお今回は全てHTTP(S)通信について議論する。

おさらい

MITM (Man-In-The-Middle)

まずはMITMについておさらいする。
これは本来クライアントとサーバ間で完結するべき通信が、通信を経由する何者かによって傍受、改竄されることを言う。

HTTP通信はもともと平文であるため、悪意のあるプロバイダ等が通信に干渉すればMITMは技術的に容易である。
(また、今回の議論の対象ではないが、サービスを提供するサーバそのものをクラックし、機密情報を第三者に横流しするような攻撃も存在する。)

SSL (Secure Socket Layer)

SSLはTCPの一段上のレイヤーになる。
鍵交換をしたあとの通信は対向マシンの公開鍵で暗号化し、自マシンの秘密鍵で復号する。
この時、サーバ側の鍵が本当にドメイン所有者のものであることを証明するために、認証局CAが存在している。

暗号通信を行う前に、クライアントはサーバ公開鍵の証明書をサーバから取り寄せ、さらにそれを署名した認証局の公開鍵を別途取り寄せる。さらにその公開鍵で証明書を復号することによってサーバの真正性を確認する。
また、認証局の認証局も存在し、これが連続することによって証明書チェーンが構成されている。
しかしこれではその最もトップレベルの認証局(ルートCA)の真正性が保証できないため、ルートCAの証明書はあらかじめクライアントやブラウザにインストールされている。

今回はこのルート証明書がクライアントに手動でもインストールできる(これは会社や組織に設置されたルートCAの証明書を組織内のクライアントだけにインストールすることなどを想定している)ことを突いた話である。

偽装ドメインによる暗号化通信のMITM(フィッシング)

フィッシングもMITMの一種として分類されることがある。
フィッシングを行えば、SSL通信でもMITM攻撃が実現できる。
具体的な手法として、以下のような構成が考えられる。

正規事業者を装ったメールに誘導され、通常と(よく似た)異なるドメインにアクセスさせるが、見た目は正規のサイトと同じであるし、問題なく今まで通りの機能が利用できる。
SSLが正常に認証されていた場合、ユーザは判別が困難だろう。

この事象を起こす実装は次のようになっている。
ユーザから暗号化されて送られたリクエストを復号し、悪意のあるサーバが内容を傍受した上でまた暗号化する。
そのあとに悪意のあるサーバが、まるで自分の発したリクエストかのように同一リクエストを正規のサーバに投げ、折り返しでも同じことをする。

そしてこの実装は悪意のあるサーバが何かしらの手段で偽ドメインのSSL証明書を取得すれば済む話であり、ルート証明書云々の問題は発生しない。

ルート証明書強制インストールは何がやばいのか

さて本題に戻る。

ここまでは瞬時に理解できた(思い出せた)が、政府がルート証明書を発行することでどのような行為ができるかすぐには想像できなかった。
そしてある程度考えて結論に至った。

端的に言えば、ルート証明書が不正にインストールされるとドメインの持ち主じゃなくてもブラウザ等が有効と認識するようなドメインSSL証明書が簡単に発行できる

やばい。

想定される傍受メカニズム

今回はカザフスタンにあるISPがMITMの実行犯だということもわかっているので、政府からISPにお告げが来たと考えていいだろう。
ISPは契約者のトラフィックを一手に握るため、DNSを不正に改竄することも(技術的には)容易である。

そうして(例えば)valid.example.comの改竄A(あるいはAAAA)レコードを配布し、同ISP内のMITM中継サーバに向かわせる。
また、中継サーバが持っているvalid.example.comのSSL証明書は政府CAがちゃんと署名しているのでブラウザで警告画面が出ることもなく、中継サーバの公開鍵で暗号化したリクエストを送付してしまうことになる…

先述のMITMフィッシングはFQDNに注意していれば対処できるが、恐ろしいことにこっちは証明書チェーンを確認しないとこのMITMに気づくことはできない、というわけだ。

カザフスタンの政府ルート証明書問題の構造が理解できなかった数時間前の自分へ」への2件のフィードバック

  1. すみません。「端的に言えば、ルート証明書が不正にインストールされるとドメインの持ち主じゃなくてもブラウザ等が有効と認識するようなドメインSSL証明書が簡単に発行できる。」という結論に至る根拠が初読時には理解できませんでした。

    私は何度も文章を読み返すことで、以下のように理解したのですが、この認識で正しいでしょうか?

    まず、カザフスタン政府は国民の https 通信の内容を傍受したいという願い(悪意)を持っています。次にカザフスタン政府は、政府の協力者が運営している “偽 valid.example.com” に対する偽のサーバ証明書を発行します。

    ここで補足しておくと、通常、ドメインの実在性を何らかの方法で認証局に対して証明しない限り、サーバ証明書を認証局から発行してもらうことはできません。例えば、最も簡単なメール認証を方式の場合は、実在性を証明したいドメイン宛のメールがちゃんと受け取れて、ドメインの所有者が適切にレスポンスを返すことを確認することにより、そのドメインが確かに存在していて、そのドメイン宛のメールを受け取って応答した人は、確かにそのドメインの正規の所有者であるとみなされるわけです。

    しかしカザフスタン政府にはそもそも悪意があるので、”偽 valid.example.com” の実在性なんか全く確認せずに、”valid.example.com” に対するインチキな(偽の)サーバ証明書を発行してしまいます。なぜそんなインチキなサーバ証明書を発行できるかというと、カザフスタン政府は自前のルート証明書を国民の PC にインストールさせているので、自前のルート証明書で署名したインチキサーバ証明書をいくらでも発行することが可能だからです。

    1. もっくん さん

      コメントありがとうございます。
      もっくんさんの認識は私の文意と一致しています。
      ドメイン所有者が所持していないサーバにも、まるでドメイン所有者が所持しているかのように証明書を発行できることが、この問題の恐ろしい点であると考えています。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です