サイバー・セキュリティ・ソリューション（CSS）部
エバンジェリスト フェロー 関原 弘樹
2019年
10
月最後のコラムです。一月前には
30
℃を超えていた最高気温も
10
度近く下がり、本格的な秋の訪れを感じます。
一方、今月も列島を襲った豪雨の被害に関するニュースに目を向けると、平常時には気にも留めない予防のためのインフラ整備の重要性と人がもつ正常性バイアスの怖さが再認識できました。
さてこの秋、セキュリティに関するニュースの一つに
Mozilla Corporation
が開発しているウェブブラウザ
Firefox
が昨年より実験的にサポートしていた
DNS over HTTPS
（
DoH/
ドー）を正式にサポートするというものがありました。
今回のコラムではその
DoH
についてみていきます。
■
DNS
－ インターネットでの名前解決
まず、前提条件となるインターネット上の名前解決について簡単におさらいです。
「
www.idnet.co.jp
」というホストにアクセスしたい場合はまず「
www.idnet.co.jp
」というホスト名をインターネット上の住所である
IP
アドレスに変換する必要があります。これを名前解決といいます。
名前解決はエンドポイント（
PC
・スマホ）上で設定された
DNS
サーバに対してクエリー（名前解決の問い合わせ）を送信することで行われます。
※外部サイト：
出典_総務省 国民のための情報セキュリティサイト
DNS
の仕組み
例とし、トラフィックのキャプチャを見てみます。下の画像内の中央左の赤枠部分を確認するとエンドポイント「
10.0.0.11
」が
DNS
サーバ（に中継する代理サーバです、実際は）「
10.0.0.2
」にクエリーを送信し「
www.idnet.co.jp
」というホスト名を「
52.193.253.207
」というインターネット上でルーティング可能な
IP
アドレスに解決しています。
また、画像右上の赤枠部分のように
1
データグラムの
Standard query
に対し
1
データグラムの
response
というように非常にシンプルに名前解決を実現しています。
#Protocolの部分がDNSとなっており使っているポートは53/UDPです。
■
DNS
による名前解決と問題
インターネットを安全に利用するために欠かせない
DNS
ですが実はセキュリティ的にはかなり脆弱で、例えば
DNSの通信中に限っても
このような弱点があります。
・インフラとしてコネクションレスで信頼性の無い
UDP/IP
を使っており、クエリーが本当に意図した
DNS
サーバに届いているか？また、レスポンスが指定した
DNS
サーバからのものか？について保障されない。
・レスポンスの内容、例えば「
www.idnet.co.jp
」に対する「
52.193.253.207
」が経路上で改ざんされていないかを検証する手段がない。
名前解決の結果が改ざんされていても現在の
Web
サイト運営では必須といわれる
HTTPs
を利用していれば下の画像のような表示ですぐ気づくことができます。
意外と重要なサイトでもいまだに
HTTPs
に対応していないこともあります。
HTTPsでサーバの身元を示すデジタル証明書が不正に発行され、悪意のあるものに成りすまされることもあります。
インシデントがあるとブラウザのエラー画面で気づくことができないので、フィッシングの成功率は格段に高まります。
■ DoH の登場
そこでそれらの
DNS
の弱点を克服すべく登場したのが
DoH
です。
その名の通り、既存の
DNS
のプロトコルをそのままにその転送インフラだけを
UDP/IP
から現在
Web
サイトのセキュリティ対策として一般的に利用されているプロトコルスタック
-
TLS
（Transport Layer Security※）/TCP/IP
に移行しています。
※外部サイト：
TLS
IETF ※ のインターネットアーキテクチャ上に図示するとこのようなイメージになります。
なお、インターネット上で相互接続性を担保するために重要な標準化は
RFC
※
で
TLS
を標準化（
TLS1.2 RFC5246,TLS1.3 RFC8446
）している
IETF
が「
DNS Queries over HTTPS RFC8484
」として行っています。
※
IETF
⇒
Internet Engineering Task Force
インターネットに関する技術の標準化を推進する団体
※
RFC
⇒
Request for Comments
その多くは「コメント求む」という体の実質的な勧告
■
DoH
がゲットした
TLS
の
3
つのセキュリティ機能
DoHではこのようなプロトコルスタックを実現したことにより
TLS
が持つ
3
つのセキュリティインフラを手に入れました。
①
DNS
通信中のデータの暗号化
⇒クエリー内容の機密性確保
②
DNS
通信中の改ざん防止
⇒クエリー結果の完全性確保
③
DNS
サーバの認証
⇒①、②の前提となる正しいサーバの認証
個人的に①については
DNS
の名前解決後、平文で
IP
アドレスや
CN
（
Common Name=
接続先のサーバ名）が含まれた証明書データが流れることから、そこまでの重要性は感じませんが②と③については悪意のある者のフィッシングを回避するために非常に重要ですので方法が
DoH
かどうかはともかく
DNS
に対してなんらかの実装は必須であると考えています。
また、通常
HTTPs
のためにプロキシサーバでの中継と
FW
での通過を許可している
443/TCP
を利用するため既存のネットワークインフラへの変更がほぼ不要なのは大きな利点といえるかもしれません。
■
Firefox
と
Cloudflare
による
DoH
の実装
ではここで、
DoH
に対応したウェブブラウザ
Firefox
と
CDN
（コンテンツデリバリーネットワーク）とセキュリティサービスを提供するCloudflareの
DNS
※
を使って
DoH
に関する実装を見てみましょう。
※外部サイト：
Cloudflare
セキュリティ
執筆時点で最新の
Firefox Ver70.0
でオプション⇒ネットワーク設定⇒接続設定を開きます。
「
DNS over HTTPS
を有効にする」にチェック。すると「プロバイダーを使用」にはデフォルトで
Cloudflare
が設定されます。（他のサーバの
URL
も設定可能）
なお、
Firefox+Cloudflare
の組み合わせによる
DoH
のクエリー先はブラウザの
Config
で
URL「https://mozilla.cloudflare-dns.com/dns-query」として与えられています
。
ということは最初に
mozilla.cloudflare-dns.com
の名前解決をする必要があり、それは通常の
DNS
で実行するものと想定されます。
ちなみに
mozilla.cloudflare-dns.com
の
IPv4
アドレスは引いてみると執筆時点では「
104.16.248.249
」と「
104.16.249.249
」です。
パケットキャプチャで確認すると上記設定後すぐに
DoH
のクエリー先「
104.16.248.249
」に
TLS1.2
でパケットが飛んでいます。
Record Layer
の
Application Data Protocol
として「
http-over-tls
」が明記されています。もちろん
Application Data
は暗号化されており見ることはできません。
#ここでServerとClientのTLSのHelloがキャプチャされていないことと53/UDPのフィルタに「mozilla.cloudflare-dns.com」の名前解決がキャプチャされていないという疑問が出てきましたが今回は時間の関係で確認はここまでです。
■
DoH
の問題点
DNS通信にセキュリティをもたらすこの
DoH
ですが、
DNS
のクエリーがエンドポイント～
DNS
サーバの中間では暗号化されているので
DNS
クエリをベースとした危険サイトや違法サイトのフィルタリングができないということを問題視する向きもあります。
※外部サイト：
インターネットをより安全にする技術「
DoH
」に対して大手
ISP
が抱える懸念とは？
これについては
だれが責任をとるのか？誰にとってのセキュリティなのか？
という問題ですので、技術的なアプローチでの解決は難しそうです。回答はそれぞれのケースによるでしょう。
また、現在
DoH
を実装している
DNS
サーバが
Cloudflare
や
Google
といった極一部なので
DNS
トラフィックの独占という面での懸念も上がっているようです。これは今後の広まり方がポイントですね。
ちょっと気になることとして、すべての通信が通常の
HTTPs
と同様に
443/TCP
に見えるのでトラブルシューティングやインシデント時の切り分けにちょっと時間がかかるかもしれません。
■まとめ
今回は
DNS
の完全性がいかに重要となっているか及びそれに対する一つの解についてご紹介しました。
昨年以来、一部の大手検索サイトが利用者とサービス提供者を結び付ける
URL
ついて、新たな方向を模索している※というニュースもありました。
Web
と
URL
、そして
DNS
に関してはこれからの数年間どのような動きがあるか興味が尽きません。
※外部サイト：
グーグルは「
URL
がない世界」をつくろうとしている
ではまた、次回のエントリーでお会いしましょう。
Hiroki Sekihara, CRISC, CISSP, CCSP, CEH, PMP, CCIE #14607 Emeritus,
AWS Certified Solutions Architect – Professional,
当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。
エバンジェリストによるコラムやセミナー情報、
IDグループからのお知らせなどをメルマガでお届けしています。
