Scribble at 2022-12-09 14:24:53 Last modified: 2022-12-12 13:26:04
Qualys 社の提供している SSL サーバ証明書の運用監査ツールである。ウェブ・サーバの技術者なら知らない人は殆どいない筈である。僕もかなり前から使わせてもらっていて、僕が在籍している会社のコーポレート・サイトをホストするサーバが変わるたびに、設定の参考として使ってきた。いちおう、現状では「A+」のスコアが付いている。僕が運用しているサーバなので当然のことだが、意外に大手の企業でも「B」とかになったまま放置されている事例がある。自社サーバ、しかも社内に配備した Windows Server 2003 R2 なんかが動いてるマシンに DMZ を設定してコーポレート・サイトを公開してたりすると、「情報システム部」とは名乗っていながら、VB のコーダだとか COBOL しか書けないみたいなウェブ・サーバ運用のアマチュアが管理してたりするからだ(実際、上場企業や大手企業にも多い)。Windows Server 2003 だと、TLS 1.0 にしか対応できない(OpenSSL の新しいバージョンが、そもそも動かない)ため、Qualys のスコアなんて「B」すら取れないだろう。
さてしかし、「A+」だと言っていても十分というわけではない。たとえば当社のサーバだと HSTS は有効なのだが、「HSTS preload」は敢えて無視しているからだ。これにより、「A+」よりも上のランクがあるとしても対応はできないという話になる。どうしてわざと無視しているのかというと、HSTS preload の仕様は対応するべきかどうかが自明ではないという事情があるからだ。
HSTS preload は、RFC 6797 が元になっている。これは、PayPal や Google の技術者が起案した文書であった。そのあと、HSTS(HTTPS の強制)をサーバで設定していて HTTPS 通信できるサーバをブラウザが登録して、次回からは HTTPS へと直にアクセスするようにしたものが "HSTS preload (list)" である。これによって、プライバシーの保護を Google や Microsoft などよりも声高に叫ぶ Mozilla ですら、HTTPS を強制出来るのだからプライバシーを適切に保護できるなどと迂闊なことを言っていたわけであった。
しかし(ちなみに HSTS について日本語版のウィキペディアには満足な解説が書かれていないので、英語版を見ること)、HSTS preload を利用すると、いわゆる "Supercookie" という手法(Cookie を越えるような手法という意味であって、違う種類の super な Cookie が使えるという意味ではない)が可能になる。これは、
1. http://0000.domain.com/image.gif
2. http://0001.domain.com/image.gif
3. http://0002.domain.com/image.gif
のように、幾つもの異なる URI (HTTP) へアクセスさせて、或る UA については 1. と 3. だけを HTTPS にリダイレクトさせて HSTS preload をブラウザに記憶させる。これにより、次にアクセスしてきた UA は、記憶している HSTS の設定によって、直に HTTPS の URI へリクエストするようになるため、そのパターンを登録しておけば、次にアクセスしてきた UA が、どのパターンで最初に 1. ~ 3. の転送・非転送の設定でアクセスさせた UA なのかを特定できるようになるというわけだ。このようなサブドメインと画像を30個ていど用意すれば、2^30 = 1,073,741,824(約10億)の UA を見分けられる。
よって、上記のようなサブドメインごとの設定で HSTS preload list を事実上のデータベースなり Supercookie として悪用されないために、HSTS preload list が正しく設定されると認められるためには、現在は全てのサブメインについても同じ設定を有効にすることが求められている。