DNS over TLS/HTTPS

2019/06/11 #doh_study

Transcript

1. サービス開発者が知っておくべき DNS over TLS/HTTPS やまぐち@iij 2019/06/11 #doh_study
2. 誰だおまえ • DNS 屋さん • どっかの ISP でユーザサポートやってます • 最前線で手を動かす仕事は(ほぼ)引退 • 例の public DoT/DoH も会社ブログ書いた以外のことはしてない • なので、定性的な話が主で定量的な話はほとんどありません • 「サービス開発者が知っておくべき DoT/DoH」とかいうお題ですけど、 わしゃサービス開発のことなんぞ何も知らんぞ • 何を知っておくべきかは皆様が汲み取ってください
3. Web 屋さんのための DNS 基礎知識 (1) • 権威サーバ • コンテンツサーバ、オーソリテイティブサーバとも • ゾーンファイルの NS レコードに書く DNS サーバ • 参照サーバ • キャッシュサーバ、フルリゾルバとも • DHCP で自動設定されたり resolv.conf に書いたりする DNS サーバ • スタブリゾルバ • getaddrinfo(3) などの名前解決 API • クライアントとほぼ同義
4. • 参照サーバは web でいえば forward proxy 相当 • ただし、web で proxy は必須ではないが、DNS で参照サーバは必須 • web で proxy は組織ごとに専用だが、DNS では野良参照サーバもある • またの名を public DNS Web 屋さんのための DNS 基礎知識 (2) スタブ リゾルバ 参照 サーバ 権威 サーバ 権威 サーバ 権威 サーバ ブラウザに 相当 オリジンに 相当 プロクシに 相当
5. DNS over UDP • 基本のキ • 複雑なネゴシエーション不要 • ステートレス • パケット1往復で完了 • サイズ制限 • 512バイト上限 → EDNS0 により緩和 • IP fragment の問題 • パケット偽造されやすい • キャッシュポイズニング (IP アドレス、ポート番号、query id の偽造) • DNS amp (IP アドレスの偽造) • fragmentation attack (フラグメントしたパケットの2番目を偽造)
6. DNS over TCP • RFC1123 • UDP のサイズ制限で収まらない場合にかぎって TCP fallback • RFC5966、RFC7766 • UDP からの fallback でなくても TCP を使ってよい • が、現在でも fallback 以外で使われることはほぼない • 3 way handshake • UDP よりやりとりが多い • UDP より偽造されにくい • query pipelining • 1回の TCP 接続で複数クエリを送る • クエリを投げた順に応答が返ってくるとはかぎらない
7. DNS とプライバシー (1) • 昔: DNS は公開情報 • 盗聴されないことよりも改竄されないことを重視 ⇒ DNSSEC • スノーデン事件(2013) • DNS に関しても広範に監視がおこなわれていたことが発覚 • MORECOWBELL / QuantumDNS • RFC7258 Pervasive Monitoring is an Attack • 公開情報とはいえ、どんな情報を欲しがっているのかは個人のプラ イバシー • 完全性だけでなく、機密性ももっと考慮しないといけないのでは?
8. DNS とプライバシー (2) • IETF dprive (DNS PRIVate Exchange) WG (2014) • DNS に機密保持機能を追加することをミッションとする WG • https://datatracker.ietf.org/wg/dprive/ • RFC7626 DNS Privacy Considerations • さまざまなプロトコル拡張・修正 • Qname minimisation (RFC7816) • EDNS(0) padding option (RFC7830、RFC8467) • DNS トランスポートの暗号化 • など
9. DNS プライバシーのスコープ スタブ リゾルバ 参照 サーバ 権威 サーバ 権威 サーバ 権威 サーバ トランスポート暗号化 EDNS padding option qname minimisation
10. • 従来 • ルートサーバや jp. の権威サーバ、途中経路上の監視者は www.example.jp の情報を欲しがっているユーザの存在を知ることが できる Qname minimisation (1) スタブ リゾルバ 参照 サーバ jp example.jp root www.example.jp/A ? www.example.jp/A ?
11. • 問い合わせ情報の最小化 • 権威 - 参照間で www.example.jp の問い合わせ情報が必要以上に 露出しない Qname minimisation (2) スタブ リゾルバ 参照 サーバ jp example.jp root www.example.jp/A ? example.jp/NS ?
12. EDNS(0) padding option • DNS message は可変長 • が、問い合わせ/応答のサイズは問い合わせ内容によりほぼ固定 • サイズが推測の手がかりになる可能性 • ダミーデータを padding することでサイズからの推測を防止 • トランスポート暗号化と併用 00000000 00 00 81 80 00 01 00 01 00 00 00 01 03 77 77 77 |.............www| 00000010 06 67 6f 6f 67 6c 65 03 63 6f 6d 00 00 01 00 01 |.google.com.....| 00000020 c0 0c 00 01 00 01 00 00 00 d5 00 04 d8 3a c5 e4 |.............:..| 00000030 00 00 29 05 ac 00 00 00 00 00 45 00 0c 00 41 00 |..).......E...A.| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| padding option code option length
13. • すなわち、DNS over (D)TLS/HTTPS トランスポート暗号化 (1) スタブ リゾルバ 参照 サーバ 権威 サーバ 権威 サーバ 権威 サーバ ここは従来のまま 変わらない ここだけ 暗号化
14. トランスポート暗号化 (2) • TLS は end-to-end の通信を保護する • DoT/DoH における E2E: スタブリゾルバ - 参照サーバ • 参照サーバ - 権威サーバ間は traditional DNS のまま • この区間で改竄される可能性 • 一般に、TLS は完全性を保証する • が、(DNSSEC なしなら)参照サーバの持つ情報が正しいという保証がない • DoT/DoH はあくまでスタブ - 参照間の完全性が保証されるだけ • 権威まで含めた DNS の系全体で考えれば完全性はない
15. DNS over (D)TLS • RFC7858 (TLS)、RFC8094 (DTLS) • 853/tcp (TLS)、853/udp (DTLS) • SMTP の STARTTLS や HTTP の Upgrade のような、平文ポートに接続してか ら TLS に移行する仕組みは存在しない • DNS の TCP/UDP wire format をそのまま TLS/DTLS セッションに載せ たもの • DTLS は大きな応答で truncation することがある • TLS or 平文 TCP に fallback
16. DNS over HTTPS (1) • RFC8484 • dprive WG ではなく、doh WG から • DNS の UDP wire format をそのまま HTTPS に載せたもの • content-type: application/dns-message • HTTP(S) ではなく、HTTPS • S はオプションではなく、必須 • HTTP/1.1 非推奨 • server push 可 • 対応してる実装があるかどうかは未確認
17. DNS over HTTPS (2) • request • GET でも POST でも可 • response • application/dns-message で wire format を応答 • それ以外の content-type による応答も想定されている • RFC8484 では application/dns-message だけ • accept ヘッダでコンテンツネゴシエーション :method: GET :path: /dns-query?dns=(base64(DNS wire format)) accept: application/dns-message :method: POST :path: /dns-query accept: application/dns-message content-type: application/dns-message (DNS wire format)
18. DNS over QUIC • IETF 提案中 • https://www.ietf.org/id/draft-huitema-quic-dnsoquic-06.txt • 標準化されるとしても当分先ではないかと • 784/udp (正式に IANA から割り当てられたわけではない) • HTTP/3 (HTTP over QUIC) になると DoH も QUIC 利用可能に • あくまで DoH であって DoQ とは別モノですが
19. もうひとつの DNS over HTTPS • google 独自形式 • https://developers.google.com/speed/public-dns/docs/dns-over-https • RFC8484 よりこっちが先なので、これが DoH だと勘違いしてる人も多そう • GET の query string に問い合わせ内容、JSON で応答 • 既存の DNS ライブラリ不要で、HTTPS アクセスと JSON の解釈ができればよ いので、用途によってはこっちのほうが便利かも • 隠しパラメータ "&encoding=raw" ⇒ 応答が application/dns-message に % curl -q 'https://dns.google.com/resolve?name=www.google.com&type=A' {"Status": 0,"TC": false,"RD": true,"RA": true,"AD": false,"CD": false, "Question":[ {"name": "www.google.com.","type": 1}], "Answer":[ {"name": "www.google.com.","type": 1,"TTL": 255,"data": "172.217.26.4"}]}
20. その他のトランスポート暗号化 • DNSCrypt • スタブ - 参照間; not TLS • https://dnscrypt.info/ • DNSCurve • 権威 - 参照間; not TLS • https://dnscurve.org/ • DNS over Tor • https://developers.cloudflare.com/1.1.1.1/fun-stuff/dns-over-tor/ • XFR over TLS (XoT) • 権威サーバ間のゾーン転送の TLS 化 • https://tools.ietf.org/html/draft-hzpa-dprive-xfr-over-tls-01
21. DNSSEC vs DoT/DoH • DNSSEC = DNS SECurity extensions • 一言でいうと、｢電子署名つき DNS」 • スコープが異なる • DNSSEC ⇒ 完全性の保証、否認防止 • DoT/DoH ⇒ 機密性の保証 • DNSSEC が守るもの ≠ DoT/DoH が守るもの • DoT/DoH があるから DNSSEC なんかいらない、とはならない(vice versa)
22. DoT vs DoH • HTTP のレイヤが必要ない分だけ DoT の方がシンプル • そのかわり HTTP/2 の再送制御などの恩恵はない • DoT は専用ポート(853/tcp)を使う • 通信の中身がわからなくても、DoT を使ってることはわかる • OP853B で DoT をブロック可能 • DoH は他の HTTPS の通信に紛れて見つけづらい • SNI は平文なのでその気になれば識別できないわけではない → ESNI • 現状ではどちらか一方しかサポートしてない実装がほとんどで、同じ 条件で比較するのが難しい
23. 対応状況: OS DoT DoH 備考 Android ◦ × 9 (Pie) 以降 Linux ◦ × systemd-resolved (rel. 239) 証明書検証しない DoT がコケると平文に fallback するので downgrade attack 可能 FreeBSD ◦ × local-unbound(8) OpenBSD ◦ × unwind(8)
24. • POSIX/Windows/Mac の標準ライブラリでは対応していない 対応状況: スタブリゾルバ DoT DoH 備考 getdns ◦ ×
25. 対応状況: アプリ ブラウザ DoT DoH 備考 Firefox × ◦ Chrome × △ 6/4 に commit されたばかり 正式リリース版は未対応 ローカルリゾルバ DoT DoH 備考 Intra × ◦ Android DNSCloak × ◦ iOS DNSCrypt にも対応 Stubby ◦ × Mac/Linux/Win DoH 対応予定あり cloudflared × ◦ Mac/Linux/Win
26. 対応状況: DNS サーバ DoT DoH 備考 Unbound up/down × DoH 実装予定らしい https://twitter.com/NLnetLabs/status/1 131857380642381824 Knot Resolver up/down down dnsdist down down フルリゾルバではなく、DNS ロードバラ ンサ/プロクシ 権威サーバ or 参照サーバ 参照 サーバ スタブ リゾルバ upstream downstream
27. 対応状況: public DNS DoT DoH 備考 google (8.8.8.8) ◦ × 独自形式 DoH あり cloudflare (1.1.1.1) ◦ ◦ google独自形式 DoH あり Android/iOS アプリあり (DoT/DoH) quad9 (9.9.9.9) ◦ ◦ DNSCrypt にも対応 Android アプリあり (DoT) iij (public.dns.iij.jp) ◦ ◦ traditional DNS 非対応
28. DoT/DoH bootstrap (1) • ネットワークにつなぐと traditional DNS が自動設定される • IP アドレスなどの自動設定プロトコルに DNS サーバを指定するオプション • DHCP/DHCPv6、IPCP、IPv6 RA • ネットワーク内部から悪意の攻撃を受けることには無力なプロトコル • DoT/DoH を自動設定する仕組みは、ない • ネットワーク管理者が多数のクライアントを一斉に DoT/DoH 対応させるよう なことができない • 標準化に向けた議論は始まっている • 安全でないプロトコルで入手した情報を「とりあえず信じる」方向になる(?)
29. DoT/DoH bootstrap (2) • Android9 の DoT は独自の自動設定をサポート • 観測された挙動 1. DHCP などから降ってきた DNS サーバに対して、53/udp ではなく 853/tcp に DoT でアクセスしてみる 2. 証明書を検証して OK なら以後それを、NG なら 53/udp を使う • ただし、root CA から chain がつながっているかどうかの検証までで、 CommonName/SubjectAltName は見ていない模様 • 標準化より先にこれが de facto standard になる???
30. DoT/DoH bootstrap (3) • traditional DNS の手動設定は IP アドレスで指定 • DoT/DoH の手動設定はホスト名が基本 • サーバ証明書の CommonName、SubjectAltName の都合 • IP アドレス証明書を発行してもらうのがクソめんどくさい • Android9 の設定 UI に IP アドレスを入力すると保存ボタンを押せない • そのホスト名はどうやって名前解決するのか? • DoT/DoH サーバの名前解決のときだけ traditional DNS を使う実装が多い • つまり、traditional DNS は今後もなくならない • IP アドレスと SNI ホスト名のペアで設定するものや、IP アドレスと証 明書の pin-sha256 のペアで設定するものも
31. DoT/DoH bootstrap (4) • 将来自動設定が標準化されて実装されると、DoT/DoH 設定が目に 触れる機会はなくなる • いちいち確認しなきゃならないなら自動設定の意義が薄れる • DoT/DoH にはアドレスバーがない • 鍵マークがなければ、EV 証明書で緑になることもない • 万が一 DoT/DoH 設定を不正なものにすりかえる攻撃がおこなわれる場合、 従来のフィッシングなどとは異なり、攻撃者は見た目の紛らわしい URL に偽 装する必要はない
32. DoH のレイテンシ (1) https://blog.nightly.mozilla.org/2018/08/28/firefox-nightly-secure-dns-experimental-results/
33. DoH のレイテンシ (1) https://blog.nightly.mozilla.org/2018/08/28/firefox-nightly-secure-dns-experimental-results/ 2割ほどのクエリは traditional DNS より 大きく改善
34. DoH のレイテンシ (1) https://blog.nightly.mozilla.org/2018/08/28/firefox-nightly-secure-dns-experimental-results/ ほとんどのクエリは traditional DNS より悪化
35. DoH のレイテンシ (2) • このグラフ、縦軸横軸とも絶対量ではないことに注意 • 横軸: パーセンタイル • 縦軸: 名前解決にかかった時間の差 • DoH で悪化している部分の差はだいたい 5-10ms • traditional DNS 1ms → DoH 10ms なのか • traditional DNS 30ms → DoH 40ms なのか • どちらなのか判別できない • 定性的な傾向はわかるが、定量的な判断は難しい • ので、以下一般論として
36. 参照 DNS のレイテンシ (1) • DNS のレイテンシはサーバの性能で決まるわけではない • 影響しないわけではないが、他の要素の影響がはるかに大きく、サーバ性 能は誤差にしかならない • いちばん大きく影響するのはキャッシュヒット率 • が、ある程度以上のユーザがいればヒット率は飽和する • 企業の社内 DNS でもハイパージャイアントの public DNS でもヒット率はたぶん同程度 • ヒット率はトランスポートプロトコルによらないので、今回の文脈では無関係
37. 参照 DNS のレイテンシ (2) • 応答速度を決定するのは通信路の往復遅延 • キャッシュヒットした場合、DNSサーバ自体の処理はミリ秒未満で完了 • 通信路の伝送遅延が1～数百ミリ秒 • 伝送距離にほぼ比例 • 光速は、遅い • じゃあ、どれだけ往復するの? • DNS over UDP: 問い合わせと応答を1発ずつ送って1往復で完了 • DNS over TCP: さらに、 3 way handshake • DNS over TLS/HTTPS: さらに、 TLS handshake
38. 参照 DNS のレイテンシ (3) • DoT/DoH はパケットの往復回数が多い = それだけ遅延が大きい • UDP 以外のトランスポートも往復を減らす工夫はしている • query pipelining • TCP Fast Open • TLS session resumption • TLS 1.3 0-RTT • これらを最大限利用できる場合でも、1往復で完了する UDP と比べ て「同じ｣になるのがせいぜいで、速くなることはない…はず • とはいえ、mozilla の調査では一部のクエリで顕著なレイテンシ改善 が見られたのも事実
39. DoH によるレイテンシ改善要因 (1) • リトライ • UDP は輻輳などでパケロスすると、タイムアウトを待って再送するしかない • HTTP/2 再送制御かっちょええ • server push • 聞かれる前に答えることができる！ • リゾルバ実装 • traditional DNS のスタブリゾルバは実装が古いものが多い • 非同期処理ができないものとか… • 特定の名前解決に時間がかかると、他の処理をブロックしてしまう • HTTP/2 は新しい規格だけあってクライアント側実装もモダン • 実装の問題であってプロトコルの問題ではないが、わりと重要な点
40. DoH によるレイテンシ改善要因 (2) • 地理的要因 • traditional DNS は ISP のものを利用するケースがまだまだ多数 • サーバが大都市にしか存在しない • 現状では DoH の提供はハイパージャイアントの CDN サーバ群に限られる • 北米大陸などでは ISP の DNS よりも密に配置されている • 単純に、DoH サーバの方が距離が近い(ことが多い) • 近い = RTT が小さい • 日本国内では ISP の DNS サーバも CDN のサーバも東京大阪なので RTT に差は出ない • 北米でも traditional DNS で public DNS を使っていれば RTT に差は出ない
41. 運用上の影響 • 暗号化以前に、まず UDP → TCP という時点で超特大のインパクト • ステートレス → ステートフル • Kaminsky attack のときでも TCP 化しなかったんだぞ • anycast との相性 • TLS 化 • DNS はデータ量が極めて小さい • ほとんどのパケットは100バイト以下 • 相対的に暗号化よりもハンドシェイク、鍵交換の負荷が大きくなる • 統計情報取得 • 従来はサーバプロセスとは独立に pcap で取得するツール(DSC)が主流 • TLS 化でまったく使えなくなる
42. DoT/DoH でプライバシーは守れるのか (1) • DoT/DoH で経路上の監視者から DNS を盗聴される危険が減る • 権力による検閲からの回避 • マルウェアにとっても活動が隠蔽されて都合がいい • DNS は目的ではなく、手段である • DNS の後に続く他プロトコルによる通信が本来の目的 • こちらを盗聴されたら意味がない ⇒ DNS 以外のプロトコルも含めた全体的 な機密性確保の重要性 • 暗号化されていても宛先アドレスはわかる = どんなサイトにアクセスしてる のか推測は可能
43. DoT/DoH でプライバシーは守れるのか (2) • 参照サーバはすべてのクエリを知ることができる • ユーザが知りたいのは権威サーバが持ってる情報 • ある意味、参照サーバも経路上の中間者といえる • DoT/DoH ならではの話ではなく、traditional DNS でも同じ • が、traditional DNS では機密性は元からスコープ外だった • 膨大なプライバシーが参照サーバ運用者の手元に • 特定の public DNS による寡占化 = プライバシー情報の集中 • 集積されたプライバシーは捨てられるのか活用されるのか? 漏洩の懸念は? • どう扱うかは参照サーバのポリシーしだい • google のプライバシーポリシーって読んだことありますか?
44. DoT/DoH でユーザトラッキング • traditional DNS • ユーザを追跡できる情報は IP アドレスだけ • IPv4: CGN (carrier grade NAT) の普及 / IPv6: temporary address • DoT/DoH • IP アドレスが変わっても TLS セッションで追跡できる可能性 • DoH • HTTP のレイヤで追跡できる可能性 • RFC8484 では cookie その他のフィンガープリント情報は使うべきではないとされている • が、禁止まではしていない • DoT/DoH では参照サーバの得られるユーザ情報が増えている
45. まとめ • トランスポート暗号化のスコープ ◦ 機密性 ◦ スタブリゾルバ - 参照サーバ間 × 完全性 × 参照サーバ - 権威サーバ間 • 守備範囲はそんなに広くない • 限界をわきまえて使いましょう • たまには DNSSEC のことも思い出してあげてください
46. 宣伝 • 今年も夏日！ • DNS Summer Day 2019 • 2019/06/28 10:00 - 18:00 • 参加申し込み不要 • その他詳細 → https://dnsops.jp/event20190628.html