Transparencyについて勉強会で発表したので、その補足や落ち穂拾いセキュリティ終了後にメモするのをサボっていたら1週間経ってしまいましたが、主催している「すみだセキュリティ勉強会」を久々に開催しました。すみだセキュリティ勉強会2015#1発表者の@inaz2さん、@furandon_pigさん、ありがとうございました。Transparencyについてでした。発表資料は以下です(パワポ資料を、ノート付きPDFにしています)。Transparency内容については資料を見てもらうとして、以下、時間内で話せなかった部分などを補足します。復習と用語整理まず、用語を思い出しておきましょう。Transparency。CTログサーバに発行した証明書を登録することで、証明書発行の「透明性」を確保する仕組み。Timestamp、署名付き証明書タイムスタンプ。CTログサーバに証明書を登録した際に、発行してもらえるタイムスタンプ。Chromeで閲覧すると、次のように「公開監査記録がありません。」というちょっと気になるメッセージが表示されます(悪の帝国Googleの、不安を煽る手口です)。Chromeで閲覧すると次のように「公開監査が可能です」と表示されます。次の図はドイツ銀行の例です。ちなみにドイツ銀行は、「db.com」という、世界中のデータベースエンジニアが羨むドメインを所有しています。extensionsの、OID=1.3.6.1.4.1.11129.2.4.2としてSCTが埋め込まれています。OpenSSLでも、現在最新の1.0.2aでx509サブコマンドの-textオプションを使えば、次のように証明書内のSCTを直接見ることができます。63:F4:9D:41:15:D3:0C....(省略)....以下、上記の勉強会資料で抜けていた部分や補足、落ち穂拾いです。Timestamp)が上記のように証明書内に埋め込まれている様子を確認しました。Staplingを利用しても構いません。Extensionを利用しているので、こういう言い方は若干語弊があるけど、とりあえず細かい部分は無視)。これらの方法に対応するにはWebサーバ自体の対応が必要です。証明書に埋め込むだけならば、ひとつフィールドが増えるだけなので既存のアプリなどもほぼ影響を受けません。そのため現実的には、2015年現在、SCTは証明書に埋め込むパターンでしか使われていません(し、たぶんこれから先もそうでしょう)。勉強会でちらりと言いましたが、実はCTログに証明書を登録する過程には「おかしい」ところがあります。証明書をCTログサーバに登録して、SCTをもらうわけですが......CTログサーバに登録する時点では、証明書には当然のことながらSCTは入っていません。皆さんが先ほどドイツ銀行の例で見たように、証明書にはちゃんとSCTが埋め込まれています。これはなぜでしょうか?答えを先に言うと、CTログサーバに登録する証明書は「事前証明書(Precertificate)」であり、実際の証明書とは違うものだからです(ここで、「違う」の解釈で実は色々と揉めることになるのですが、とりあえず置いておきます)。あるドメイン所有者が、CT付き証明書を発行するフローは、実際は次のようになります。ここで注目すべき点が、事前証明書(Precertificate)の存在です。事前証明書(Precertificate)先ほど述べたように、CTログサーバからSCTを発行してもらうためにはまず証明書が必要です。このためSCTを証明書に埋め込みたい場合には、次のような手順を踏む必要があります。(ここ、理解が若干怪しいので後で修正するかも)ドメイン保有者は、自らの秘密鍵を元に証明書署名要求(CSR)を作成して認証局(CA)に送付し、公開鍵証明書の発行を依頼する。認証局は、ユーザから受け取ったCSRからTBSCertificateを元にして、事前証明書(Precertificate)を発行する。Extensionの付加)をしておく。発行した事前証明書をCTログサーバに登録する。CTログサーバは、証明書をログに登録してタイムスタンプ(SCT)を払い出す。Number)で作成する。認証局は、SCTを入れ込んだ証明書をドメイン所有者に発行する。※CTログサーバは実は誰でも登録できるのですが、ここでは一番ありがちなケースとして、ドメイン保有者が認証局から証明書を発行してもらうケースを考えています。このうち、いかにもビミョーなのが、「毒入れをした事前証明書を発行する」「同一のシリアルIDで証明書を発行する」という2点でしょう。6962に記述がありますので、興味のある方は読んでみてください)。一般的なPKIの仕組みから見て、いきなりこんなものが出てくると、「なんだか気持ち悪いなぁ」という感想しか私は持てませんでした(個人的な感想です:小波感)。気持ち悪いのは、「事前証明書と、SCTを入れ込んだ証明書は、同一のシリアルIDで発行する」という点でしょう。社内認証局などを運用したことのある方ならお分かりでしょうが、認証局が同一のシリアルIDで違う証明書を発行するというのは、非常にイレギュラーな処理であり普通はやりたくありません。Transparencyは認証局にこれを強要しており、美しくありません。スマートじゃありません、と言っても良いです。事前証明書を失効(Revoke)させれば良いのではここまでの話を聞いて、ちょっと詳しい方なら「じゃぁ、その事前証明書を失効(Revoke)させればいい」と思ったかもしれません。Transparencyの仕組みではそれはできません。ここで、証明書失効リストの仕組みについてまず確認しておきましょう。先ほどのドイツ銀行の証明書を見てみると、下記のように「CRL配布ポイント」というフィールドがあります。List、すなわち証明書失効リストのことです。このURLにアクセスすることで、失効リストを入手することができます。証明書失効リストは、例えばWindowsならば次のように、ファイルをダブルクリックすることで簡単に中身を閲覧できます。これを見ると分かるように、一般的な証明書失効リストはシリアルIDに対して証明書を失効させます。通常、発行した証明書には、それを発行したIssuerごとに一意のシリアルIDが付いていますから、このIDを指定して失効させれば良いわけです。Transparencyの仕組みでは、事前証明書とSCTを入れ込んだ証明書の2つは、同一のシリアルIDを持ちます。このため事前証明書を失効させると、肝心のSCTを入れ込んだ証明書も失効してしまいます。このため、事前証明書をシリアルIDを指定した方式で失効させることができません。CT対応・非対応をユーザが選択できないか?勉強会で解説しましたが、証明書をCT対応させてしまうと、証明書が誰でもアクセスできるCTログサーバに登録されます。そのため、CTログサーバをクロールしてCommonNameを収集されることにより、サーバのFQDNは秘匿することができず、全世界に公開されてしまいます。(例えば、test-admin-auth.example.comとかいうテストサーバは、内部だけで使いたいので、FQDN自体を外部に出したくありませんよね)。このため、ユーザが証明書ごとに、CT対応させるかさせないかを選べるのがベターであると個人的には考えます。ちなみにCybertrustのWebを見てみると、CT対応・CT非対応の証明書を選択してダウンロードできるようになっています。https://www.cybertrust.ne.jp/sureserver/productinfo/ct.htmlこれを見て「おっ」と思ったのですが、よく見ると証明書自体は問答無用にCTログサーバに登録してしまい、ユーザがSCT有・無の証明書を単に選択してダウンロードできるだけのようです。他の大手の認証局のWebも確認しましたが、「そもそもCTログサーバに登録しない」というオプションを提供しているところは無いようです。(あったらすみません、調査不足です)なお、一部の認証局はEV証明書のみCTログサーバに登録しているので、敢えてOV証明書を使うことでサーバのFQDNを秘匿する、という手があります。これは現時点での微妙な解なので(OV証明書もそのうちCTログサーバに登録するかもしれません)、やはり根本的にCTログサーバに登録しないオプションがあるといいな、というのが私の感じたことでした。参考リンクhttp://www.certificate-transparency.org/公式サイト、まずはここを熟読しないと始まらない。TransparencyのRFChttps://jp.globalsign.com/blog/2014/certificate_transparency.htmlCTについて色々調べる際、こちらのGlobalSignさんの記事が大変参考になりました。Transparencyについて知るきっかけとなった、k_urushima様のブログ。関する罪」の情報公開請求をしましたしばらく間が開いてしまいました。Transparencyガチャを作った。関する罪」の情報公開請求をしました月別アーカイブはてなブログをはじめよう!ozumaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。