Certificate Transparency(証明書の透明性）
ウェブサイトの信頼性を担保するため、SSL証明書を用意に検索し、情報を閲覧できるようにする仕組み。
不正に取得された証明書を見つけやすくするべく、すべての証明書の情報を検索・閲覧できるようにしてしまおうというそのコンセプトは理解できるのだけれど、、結構困ったケースが発生するなぁという愚痴です。
https://transparencyreport.google.com/https/certificates?hl=ja
ちなみにぐぐったら、まさにドンピシャな内容を5年前に公演している方が。
https://www.jnsa.org/seminar/pki-day/2016/data/1-2_oosumi.pdf
うーわ。。。私の情報おそすぎ、、、
まぁいいか。
公開したくない公開サイト
例えばあるシステムの管理用Webシステムで、インタネット経由で接続させないと使いにくいけど、接続元はベンダの拠点のIPレンジに限られるものとか。
Webサイトとしてユーザからの接続を受け付けるために公開しているものではなく、システム同士の接続のためだけに接続を受け付けていて、暗号化のためにSSLを使っている非Webサービスとか。
インタネット上に存在する以上、どれだけ頑張って隠しても、ガッツリ要塞化しても、不特定多数からアクセスされていまうケースは現実的なレベルでありえるわけで、あくまで公開サイトと同等のレベルでのセキュリティを担保して公開するべきもの、、って大前提ではあるのですが、とはいえわざわざ晒す必要もないので、原則隠しておきたいシステムというのは少なからずあるわけです。
透明性の怖さ
で、厄介なのが、上記のような隠しておきたいサイトについても、インタネット公開時同等のセキュリテイレベルを担保するべきと考えるとどうなるかというと、、、ちゃんと証明書をとる、というか、取ってしまうんですよね。。
そうすると、透明性で、ガッツリ検索可能になってしまうわけです。
証明書のCN情報であったり、SAN情報であったり。
証明書にサイトのFQDNを書かざるを得ないので、「その名前のサイトが存在する」というのがわかってしまうわけです。
あとは、DNSでそのFQDNを検索し、検索に引っかからなければ、関係者が自組織のDNSにだけレコード登録して使っている関係者限定のサイトか、あるいは構築中で近日公開予定のサイトか、という想像がつくわけです。
あるいはIPアドレスが引けたとして、接続してみてFWで遮断されている雰囲気があるなら、、やはり関係者限定のサイトがそこにある、、というあたりがつくわけですね。。
ワイルドカード証明書使ってれば個別FQDNが隠蔽できるのですけれど、「キチンとFQDNを指定したほうが安全だろう！」みたいに考えると逆にFQDNがモロバレになるという皮肉なことになるわけです。。
実運用考えてもワイルドカードの方が確実に効率的でローコストなのですが、「信頼性（というか監査と基準への適用）」とのトレードオフになるので、如何とも。
なんで怖いの？
繰り返しですが、隠してるシステムもインタネット公開システムであるという前提で作ってるはずではあるんですが、、、、得てして、ガッツリ公開してるシステムよりはセキュリティがきちんと担保しきれてないケースが少なからずあるわけです。
いつもはFire Wallで接続を遮断してるけどうっかり開けちゃって、、、Fire Wallが遮断してくれてる前提で安心して迂闊な設定残してたり、、、
ってなことが出てくる。
攻撃する側から見れば、ローコストに監視を継続して、運用者がうっかりやらかす日を静かに待ってりゃいいわけですね。
で、どうするの？
非公開システムではいっそ自己証明書を使うほうがいいのでは、、とすら思いますが、それはそれで発行局管理や失効管理の信頼性が損なわれるし、それより何より監査と規格が通せなくなる、、という悲しい状態が出来上がるわけです。。
まぁ、できることは、自分が面倒をみているドメインの状況を正しく把握しておいて、ヤバそうだなァ。。。というシステムを把握しておくくらいですかね。。
以下のサイトがjsonで透明性の結果を引っこ抜かせてくれるので、大変ありがたい。
https://crt.sh
ここで自分が面倒を見ているドメインの証明書を検索し、証明書のCNやSANに登録されたFQDNを引っこ抜いて、DNS検索+接続性の確認をするスクリプトを組んでおけば状況把握はできるかな。
つくっとくか。。