Certificate Transparencyについて勉強会で発表したので、その補足や落ち穂拾い

セキュリティ

終了後にメモするのをサボっていたら1週間経ってしまいましたが、主催している「すみだセキュリティ勉強会」を久々に開催しました。

発表者の@inaz2さん、@furandon_pigさん、ありがとうございました。

今回の発表内容

私の発表は、最近ちょっと気になっているCertificate Transparencyについてでした。発表資料は以下です（パワポ資料を、ノート付きPDFにしています）。

内容については資料を見てもらうとして、以下、時間内で話せなかった部分などを補足します。

復習と用語整理

まず、用語を思い出しておきましょう。

  • CT: Certificate Transparency。CTログサーバに発行した証明書を登録することで、証明書発行の「透明性」を確保する仕組み。
  • SCT: Signed Certificate Timestamp、署名付き証明書タイムスタンプ。CTログサーバに証明書を登録した際に、発行してもらえるタイムスタンプ。

はじめに復習です。Certificate Transparencyに対応していない証明書は、Google Chromeで閲覧すると、次のように「公開監査記録がありません。」というちょっと気になるメッセージが表示されます（悪の帝国Googleの、不安を煽る手口です）。

一方、Certificate Transparencyに対応している証明書は、Google Chromeで閲覧すると次のように「公開監査が可能です」と表示されます。次の図はドイツ銀行の例です。

ちなみにドイツ銀行は、「db.com」という、世界中のデータベースエンジニアが羨むドメインを所有しています。

証明書の中身を見ると、次のようにX509v3 extensionsの、OID=1.3.6.1.4.1.11129.2.4.2としてSCTが埋め込まれています。

OpenSSLでも、現在最新の1.0.2aでx509サブコマンドの-textオプションを使えば、次のように証明書内のSCTを直接見ることができます。

$ echo Q | openssl s_client -connect www.db.com:443 | openssl x509 -text -noout
....（省略）....
X509v3 extensions:
    X509v3 Subject Alternative Name:
        DNS:db.com, DNS:staging.ext.intranet.db.com, DNS:staging.www.db.com, DNS:www.db.com
....（省略）....
  CT Precertificate SCTs:
      Signed Certificate Timestamp:
          Version   : v1(0)
          Log ID    : A4:B9:09:90:B4:18:58:14:87:BB:13:A2:CC:67:70:0A:
                      3C:35:98:04:F9:1B:DF:B8:E3:77:CD:0E:C8:0D:DC:10
          Timestamp : May  6 08:29:23.108 2015 GMT
          Extensions: none
          Signature : ecdsa-with-SHA256
                      30:46:02:21:00:9C:59:F7:55:82:3D:88:13:62:D2:7A:
                      0B:3E:A7:E5:60:41:D2:B1:17:75:2F:0D:FD:BF:CF:F4:
                      AA:1A:50:D9:E1:02:21:00:89:20:3A:68:74:53:5B:D8:
                      74:9D:6D:86:A7:69:9F:54:C1:F3:20:C3:F8:E9:79:0E:
                      4E:F1:DE:A9:77:75:5D:2F
      Signed Certificate Timestamp:
          Version   : v1(0)
          Log ID    : 56:14:06:9A:2F:D7:C2:EC:D3:F5:E1:BD:44:B2:3E:C7:
                      46:76:B9:BC:99:11:5C:C0:EF:94:98:55:D6:89:D0:DD
          Timestamp : May  6 08:29:23.337 2015 GMT
          Extensions: none
          Signature : ecdsa-with-SHA256
                      30:45:02:21:00:C4:34:D5:81:95:B4:22:2D:D6:1F:4B:
                      86:04:82:A7:0C:C8:5B:DA:C7:40:CA:03:BA:B8:F1:73:
                      65:8B:3F:48:72:02:20:6C:FD:4C:FE:04:0F:F0:13:25:
                      B7:9E:0F:ED:56:71:10:DF:E5:7E:5B:F2:1D:E7:CB:21:
                      63:F4:9D:41:15:D3:0C
....（省略）....

以下、上記の勉強会資料で抜けていた部分や補足、落ち穂拾いです。

SCTは証明書に埋め込まないといけない?

発表では、SCT(Signed Certificate Timestamp)が上記のように証明書内に埋め込まれている様子を確認しました。しかしSCTは、仕様上は証明書に埋め込む必要は無く、TLS extensionもしくはOCSP Staplingを利用しても構いません。(OCSP StaplingだってTLS Extensionを利用しているので、こういう言い方は若干語弊があるけど、とりあえず細かい部分は無視）。

が、これらの方法に対応するにはWebサーバ自体の対応が必要です。一方、証明書に埋め込むだけならば、ひとつフィールドが増えるだけなので既存のアプリなどもほぼ影響を受けません。

そのため現実的には、2015年現在、SCTは証明書に埋め込むパターンでしか使われていません（し、たぶんこれから先もそうでしょう）。

SCTを証明書に入れ込む流れの奇妙な点

勉強会でちらりと言いましたが、実はCTログに証明書を登録する過程には「おかしい」ところがあります。

証明書をCTログサーバに登録して、SCTをもらうわけですが……CTログサーバに登録する時点では、証明書には当然のことながらSCTは入っていません。しかし皆さんが先ほどドイツ銀行の例で見たように、証明書にはちゃんとSCTが埋め込まれています。これはなぜでしょうか?

答えを先に言うと、CTログサーバに登録する証明書は「事前証明書(Precertificate)」であり、実際の証明書とは違うものだからです（ここで、「違う」の解釈で実は色々と揉めることになるのですが、とりあえず置いておきます）。

あるドメイン所有者が、CT付き証明書を発行するフローは、実際は次のようになります。

ここで注目すべき点が、事前証明書(Precertificate)の存在です。

事前証明書(Precertificate)

先ほど述べたように、CTログサーバからSCTを発行してもらうためにはまず証明書が必要です。このためSCTを証明書に埋め込みたい場合には、次のような手順を踏む必要があります。（ここ、理解が若干怪しいので後で修正するかも）

  1. ドメイン保有者は、自らの秘密鍵を元に証明書署名要求(CSR)を作成して認証局(CA)に送付し、公開鍵証明書の発行を依頼する。
  2. 認証局は、ユーザから受け取ったCSRからTBSCertificateを元にして、事前証明書(Precertificate)を発行する。この事前証明書は、実際に利用されないように、毒入れ(Poison Extensionの付加)をしておく。発行した事前証明書をCTログサーバに登録する。
  3. CTログサーバは、証明書をログに登録してタイムスタンプ(SCT)を払い出す。
  4. 認証局は、SCTを入れ込んだ証明書を、事前証明書と同一のシリアルID(Serial Number)で作成する。
  5. 認証局は、SCTを入れ込んだ証明書をドメイン所有者に発行する。

※CTログサーバは実は誰でも登録できるのですが、ここでは一番ありがちなケースとして、ドメイン保有者が認証局から証明書を発行してもらうケースを考えています。

このうち、いかにもビミョーなのが、「毒入れをした事前証明書を発行する」「同一のシリアルIDで証明書を発行する」という2点でしょう。事前証明書には、OID 1.3.6.1.4.1.11129.2.4.3で定義されるpoison extensionを入れる必要があります(これもCertificate TransparencyのRFC 6962に記述がありますので、興味のある方は読んでみてください)。しかし、一般的なPKIの仕組みから見て、いきなりこんなものが出てくると、「なんだか気持ち悪いなぁ」という感想しか私は持てませんでした(個人的な感想です：小波感)。

さらに気持ち悪いのは、「事前証明書と、SCTを入れ込んだ証明書は、同一のシリアルIDで発行する」という点でしょう。社内認証局などを運用したことのある方ならお分かりでしょうが、認証局が同一のシリアルIDで違う証明書を発行するというのは、非常にイレギュラーな処理であり普通はやりたくありません。Certificate Transparencyは認証局にこれを強要しており、美しくありません。あるいは、スマートじゃありません、と言っても良いです。

事前証明書を失効(Revoke)させれば良いのでは

ここまでの話を聞いて、ちょっと詳しい方なら「じゃぁ、その事前証明書を失効(Revoke)させればいい」と思ったかもしれません。残念ながら、Certificate Transparencyの仕組みではそれはできません。

ここで、証明書失効リストの仕組みについてまず確認しておきましょう。先ほどのドイツ銀行の証明書を見てみると、下記のように「CRL配布ポイント」というフィールドがあります。

CRLとはCertificate Revocation List、すなわち証明書失効リストのことです。このURLにアクセスすることで、失効リストを入手することができます。

証明書失効リストは、例えばWindowsならば次のように、ファイルをダブルクリックすることで簡単に中身を閲覧できます。

これを見ると分かるように、一般的な証明書失効リストはシリアルIDに対して証明書を失効させます。通常、発行した証明書には、それを発行したIssuerごとに一意のシリアルIDが付いていますから、このIDを指定して失効させれば良いわけです。

が、先ほど見たようにCertificate Transparencyの仕組みでは、事前証明書とSCTを入れ込んだ証明書の2つは、同一のシリアルIDを持ちます。このため事前証明書を失効させると、肝心のSCTを入れ込んだ証明書も失効してしまいます。このため、事前証明書をシリアルIDを指定した方式で失効させることができません。

CT対応・非対応をユーザが選択できないか?

勉強会で解説しましたが、証明書をCT対応させてしまうと、証明書が誰でもアクセスできるCTログサーバに登録されます。そのため、CTログサーバをクロールしてCommonNameを収集されることにより、サーバのFQDNは秘匿することができず、全世界に公開されてしまいます。（例えば、test-admin-auth.example.comとかいうテストサーバは、内部だけで使いたいので、FQDN自体を外部に出したくありませんよね）。

このため、ユーザが証明書ごとに、CT対応させるかさせないかを選べるのがベターであると個人的には考えます。

ちなみにCybertrustのWebを見てみると、CT対応・CT非対応の証明書を選択してダウンロードできるようになっています。

これを見て「おっ」と思ったのですが、よく見ると証明書自体は問答無用にCTログサーバに登録してしまい、ユーザがSCT有・無の証明書を単に選択してダウンロードできるだけのようです。他の大手の認証局のWebも確認しましたが、「そもそもCTログサーバに登録しない」というオプションを提供しているところは無いようです。（あったらすみません、調査不足です）

なお、一部の認証局はEV証明書のみCTログサーバに登録しているので、敢えてOV証明書を使うことでサーバのFQDNを秘匿する、という手があります。しかしこれは現時点での微妙な解なので(OV証明書もそのうちCTログサーバに登録するかもしれません)、やはり根本的にCTログサーバに登録しないオプションがあるといいな、というのが私の感じたことでした。

参考リンク