鍵マークの裏にある証明書が、まだ公開していないページをすでに告げていた

競合が、チームが静かにテストを終えたのとまったく同じ都市を、広告一本買う前、リンク一本貼る前に、わずか一週間後にローンチしてしまう。ある運営者は、フォーラムの見知らぬ人物から、社外の誰も存在を知らないはずのログインページを誰かが探り当てていたと知らされる。どちらのケースも、社員からの漏洩やメール侵入、まぐれ当たりには見えない。たいていの場合、原因はもっと地味なものだ。自動発行されたセキュリティ証明書が、設計された通りの働きをしているだけなのだ。

この仕組みはCertificate Transparencyと呼ばれ、ハッキングとは何の関係もない。これは2018年から存在するHTTPS証明書の公開かつ恒久的な記録であり、無料で検索でき、このサイトであれ他のどのサイトであれ、ブラウザ警告なしに動作する証明書の背後に置かれたことのあるすべてのホスト名の履歴を、すでに完全に収めている。自分のドメインの記録を確認したことがある運営者はほとんどいない。ここで本当に埋めるべき空白はそこにある。通常の意味での脆弱性ではなく、ずっと公開されていたのに一度もそう扱われてこなかった記録なのだ。

証明書は発行された瞬間、静かに何になるのか

2018年以降、公的に信頼された証明書、つまりChromeやSafariが警告ではなく普通の鍵マークを表示するあの証明書は、複数あるCertificate Transparencyのログのいずれかに記録されなければ、これらのブラウザから信頼されない。Appleも同年のうちに、Safariに同じ要件を追加した。これは成人向けサイトや分類広告ディレクトリを狙い撃ちしたものではなく、誰かが他人のドメイン宛てに偽の証明書をこっそり発行し、その通信を傍受するのを防ぐために作られた仕組みだ。副作用として、サイトが自分自身のために取得する本物の証明書もすべて同じログに記録されることになり、この記録はもともと非公開にすることを想定していなかった。

ログには、証明書が実際にカバーするホスト名が名前付きで列挙される。admin.example.comに対して発行された証明書は、まさにその名前を平文で、永久に記録する。その名前の背後にあるページが、サイトのメニューからリンクされたことがあるか、サイトマップに記載されたことがあるか、検索エンジンに登録されたことがあるかは関係ない。認証局は発行したその瞬間にそれを記録する。それがLet's Encryptであれ、Cloudflareであれ、多くのホスティングパネルに組み込まれた自動証明書管理機能であれ、すべて同じブラウザのルールに従っているからだ。

これを確認するのに費用はかからず、一分もかからない。crt.shという無料ツールを使えば、誰でもドメインを入力するだけで、そのドメインに対して過去に発行されたすべての証明書を見ることができる。アカウントも登録も不要だ。競合のドメインを入力するのも、自分のドメインを入力するのもまったく同じように機能する。これこそが、ありふれた技術的記録をビジネス上のリスクに変えてしまう部分だ。この記事を読んでいる運営者は誰でも、今すぐそのページを開き、自分のドメインがすでに世界に何を語っていたかを初めて目にすることができる。

ここには本物の例外が一つあり、この先の話すべてに関わってくる。ワイルドカード証明書、つまり*.example.comのような一つのパターン全体をカバーし、個別の正確な名前はカバーしない証明書は、ログにそのパターン自体しか記録しない。実際にそれを使う具体的なホスト名、newcity.example.comやstaging.example.comなどは、名前としてログには現れない。一方、特定の一つのサブドメインだけに発行された専用証明書は、常に名前付きで現れる。この違いこそが、運営者が実際に手にできる唯一のてこであり、この先でまた取り上げる。

これが見知らぬ相手に実際に渡してしまうもの、三つの具体的な形

一つ目は拡張計画のタイミングだ。新しい都市や国のページは、マーケティングが発表の準備を整えるよりも何日、何週間も前に、自前のサブドメイン上で構築されテストされるのがほとんどで、それをHTTPSでテストするということは、その証明書がまさにその静かな準備期間中に発行され、ローンチ当日ではないということを意味する。同じ公開ログを基盤にした無料の監視ツールが存在し、追跡しているドメインに新しい証明書が現れると、数分から数時間以内に利用者に通知する。そもそも公開情報である親ドメインをすでに知っている競合であれば、新しい都市の名前を推測する必要さえない。ただ見張っているだけで、発表が出る前にログがそれを渡してくれる。

二つ目は内部ツールの見取り図だ。これほどの規模のディレクトリサイトなら、通常はスタッフ用のログインページ、広告を審査する担当者用のキュー、場合によっては外部の決済プロバイダー用の別パネルを運用している。それぞれがadmin、moderation、billingといった説明的な名前の専用証明書を取得していたとすれば、ログはもはや建物の見取り図のように読めてしまう。その見取り図こそが、以前にここで取り上げた類の侵入の出発点にほかならない。そこでの通常の侵入経路は派手な脆弱性攻撃ではなく、見つけやすいログインページに対して使い回されたパスワードが試される、というものだ。説明的な名前のサブドメインがそれ単独でその侵入を引き起こすわけではないが、本来なら攻撃者の足を止めるはずだった最初の一歩、ログインページをそもそも見つけるという作業を省いてしまう。

三つ目は、誰にも取り消せない履歴だ。ログは忘れない。三年前のテスト用サブドメイン、もう存在しないパートナーのために作られた短命のページ、開発者が削除しようとして忘れてしまったステージング用のコピー。こうしたものはすべて、証明書が失効した後も、そこを指していたDNSレコードが削除された後も、永久にログに残り続ける。今日crt.shでドメインを検索すれば、現在のチームの誰も作成した覚えのない名前が出てくることさえある。本当に危険なのはその記録自体ではなく、その住所にかつて応答していたサーバーが、更新もされないまま今もそこに残っている可能性だ。誰もが、リンクを外すことはそれを停止することと同じだと思い込んでいたからだ。

ここまでの話はどれも、多くの人がハッキングと呼ぶようなスキルを必要としない。無料の検索ボックスが存在することを知り、そこにドメイン名を打ち込みさえすればよい。だからこそ、これは他人が気にかければよいセキュリティ問題として片付けるのではなく、真剣に受け止める価値がある。

何もこれを止めてくれない、そして何が実際に役立つのか

検索エンジンからサイトがどう見えるかを管理するのと同じ道具に頼りたくなるが、ここではそのどれも通用しない。このディレクトリがすでに行っている、どのクローラーにどのページを見せるかという選択は、robots.txtと検索エンジンのインデックスという、証明書のログがまったく関知しない別の仕組みを通る。ボットをブロックすること、ページをインデックスから外すこと、noindexを指定すること、どれもその証明書がログに現れるかどうかには何の影響も及ぼさない。ログが記録しているのは証明書そのものであって、検索エンジンに対するページの見え方ではないからだ。

また、訪問者のブラウザで警告なしに動作する証明書を取得しながら、それをログから隠す合法的な方法も存在しない。ホスティング事業者や認証局に例外を求めることは、一般向けのビジネスには存在しないものを求めることに等しい。記録を免除される証明書は、一般の訪問者のブラウザがまったく信頼しない、私的で内部向けの認証局が発行したものだけであり、顧客や広告主が実際に開く必要のあるものには役に立たない。

後からサブドメインの名前を変えたり削除したりしても、何も解決しない。ログの古い記録は、そのままの場所に残り続けるからだ。この形ですでに記録されてしまった名前を遡って消し去る方法は存在しない。運営者が実際に変えられるのは、これから先に起こることだけだ。

実際に役立つのは、先に述べたワイルドカード証明書を意図的に使うことだ。内部ツール、ステージング用のコピー、そして一般公開前にテストされるものはすべて、その都度名前付きで新しい証明書を発行するのではなく、パターン全体をカバーする一枚の証明書の背後で動かすべきだ。ほとんどのホスティングパネルやコンテンツ配信ネットワークは、新しいサブドメインが追加された瞬間に、名前付き証明書を自動発行することを初期設定としている。それは単に構築が簡単だからであって、より安全な選択だからではない。公開マーケティングページ以外のすべてについて、この設定をホスティング事業者や開発者に変更してもらうよう頼むのは、漠然とした「セキュリティを強化してほしい」という依頼ではなく、具体的で確認可能な問いかけだ。

二つ目の本当の解決策は、分かりにくい名前をまるで錠前であるかのように頼るのをやめることだ。ログインページ、モデレーションのキュー、請求パネルには、名前が何であれ、本物のパスワード認証と、可能であればオフィスやスタッフの既知のアドレス群への制限が必要だ。名前がそれらを見つける唯一の手段だったことなど一度もないからだ。証明書とはまったく無関係に、サイトのサブドメインを洗い出す別の技術的手法も存在する。推測されにくい名前を主たる防御だと扱うことこそが、ここでの本当の過ちであって、証明書の選び方そのものではない。証明書の選び方が決めているのは、誰かがそれを探す必要すら出てくる前に、その名前がただで渡されてしまうかどうかだけなのだ。

今週、実際に確認すべきこと

最初の一歩は無料で、五分もかからない。crt.shを開き、このサイト自身のドメインを入力し、返ってきた一覧をすべて読むことだ。見覚えのない記録があれば、ホスティングを管理している人に直接尋ねる価値がある。これはまだ稼働しているのか、もしそうなら、なぜ今日公開インターネット全体がその住所を知っているのか。

その一覧の中で、すでに廃止された機能や、終わったテスト、もう存在しないパートナー向けのプロジェクトだと判明したものについては、DNSレコードを削除するだけでは解決にならない。その住所の背後にあったものは、サーバーレベルで停止し、もはやいかなるリクエストにも応答しないことを確認すべきだ。それを指していた看板だけを外して、裏では静かに動かし続けるのではなく。

次に新しい都市や国をローンチする際には、テスト段階をその都市固有の名前で発行された証明書ではなく、ワイルドカード証明書か、内部で共有する証明書の下で動かすべきだ。そうすれば、マーケティングよりも先にログが拡張計画を発表してしまうことはない。これは次のローンチの前に開発者やホスティング事業者と確認すべき一つの設定であって、すでに稼働しているものを作り直すことではない。

今日すでに稼働している社内向けのログイン、モデレーション、請求のページそれぞれについて、問うべきは名前が推測しにくいかどうかではない。名前が何であれ、その前に本物のパスワードと、可能であればアドレスによる制限が置かれているかどうかだ。なぜなら、名前自体がすでに公開されてしまった後に本当に頼りになるのはそこだけであり、crt.shを確認してみれば、おそらくすでにそうなっているはずだからだ。