AkamaiのMike Bishop氏らから、「DNS Security with HTTP/2 ORIGIN」という提案仕様が出ている。簡単に読む
ORIGINフレームとは
ORIGINフレームとは、RFC8336で標準化されているHTTP/2の拡張フレームです。
HTTP/2では、複数のドメインへのリクエストでもコネクションを使い回すことができます。https://a.example.comに接続した後に、https://b.example.comへのリクエストする場合、IPが同じで、そのドメインでも証明書が有効な場合(ワイルドカード証明書)は、すでにあるコネクションを再利用できます。
しかし、本当はa.example.comのサーバはb.example.comのコンテンツを提供できないという場合があります。その場合、サーバはステータスコード421を返し、それを受け取ったクライアントは改めてb.example.comにコネクションを張り直してコンテンツを取得します。これでは実際にコンテンツを取得するのが遅くなってしまいます。
ORIGINフレームでは、そのサーバがコンテンツを提供できるドメインリストをサーバから通知することで、クライアントが既存のコネクション上でリクエストを送信できるドメインを知ることが出来るようにします。
こうすることで、より効率よくコネクションの再利用が出来るようになります。
フレーム構造などは以前書いた記事が詳しいです
asnokaze.hatenablog.com
DNS Security with HTTP/2 ORIGIN
このとき、クライアントはORIGINフレームにかかれているドメインであれば無条件に既存のコネクションを使って良いわけではありません。サーバが悪意を持って他のドメインをORIGINフレームに記載すれば、本来のドメインを所持するサーバへ行くリクエストを、自身に送らせることができます。
そのため、通常のコネクションを再利用する時と同様、そのドメインがコネクションを張ったときに取得した証明書でも有効であることを確認します。その他にもCTログやOCSPを確認して証明書の有効性を確認することを推奨しています。
しかし、ORIGINフレームの仕様(RFC8336)では、ORIGINフレームで提供されたドメインの名前解決をすることは義務付けられていません。それは、名前解決の遅延や、新たな名前解決はクライアントが接続しようとしているサイトをネットワーク運用者に晒すことになるため、クライアントに一任されています。
しかし、名前解決が必須でないことは問題であり、必須にしようというのが「DNS Security with HTTP/2 ORIGIN」の提案です。
想定攻撃
この提案では名前解決を用いない場合にある種の攻撃が容易になるとしています。
たとえば秘密鍵が漏れた場合などを想定しています。そのときに、攻撃者はそのドメインへのリクエストを、自身のサーバに誘導することがきでるようになります。
例えば、victim-server.example.com の秘密鍵が流出した場合。
攻撃者は、まずユーザに自身のWebサーバにアクセスさせます、そのURLなんでも良く、SNSや掲示板に貼ればアクセスさせることは容易です。その後、攻撃者のサーバはORIGINフレームでvictim-server.example.comのコンテンツが提供できるとクライアントに通知し、さらに「Secondary Certificate Authentication in HTTP/2」の仕様に乗っ取りvictim-server.example.comの証明書と、秘密鍵の所持を証明します。
そうすると、クライアントはvictim-server.example.comへのリクエストを攻撃者のサーバに送信することになります。victim-server.example.comが、twitterだったりgoogleだったりすると思うと恐ろしいですね。
名前解決を行っていれば、この攻撃を防ぐことができます。もちろん、名前解決の通信を改ざんできれば攻撃は可能ですが、ORIGINフレームを用いることで攻撃が容易になっているということです。
