by
Anonymous Coward
on 2020年05月17日 0時12分
(#3816316)
(T/O)
DNSSEC 対応とか経路ハイジャック対策とかは力を入れてくれるでしょうが、セキュリティはそれだけではないですよね。誰がいつどのドメインを問い合わせたという記録が、電気通信事業の規制に掛からない会社に送られているわけです。 User-Agent の情報や TLS Session Ticket も含まれるので、 DNS (over 53) と比べると NAT 越しでも IP アドレスに加えて Web ブラウザひいては利用者を特定できる情報が送られています。 Public DNS サービスは DNS が速いことを売りにしているようですが、 Web ページの読み込み時間のうち DNS の占める割合はとても小さいのではないでしょうか。 Firefox は独自にキャッシュもしていますよね。たとえ DNS が速かったとしても、 CDN 事業者が 問い合わせ元のクライアントに一番近いサーバーの IP アドレスを返す仕掛けを使っていると、その恩恵を受けられないことになります。 DNS が速くても、その後のページの読み込みで太平洋の向こう側へアクセスすることになっては、本末転倒です。
by
Anonymous Coward
on 2020年05月17日 6時41分
(#3816383)
DNS の囲い込みが問題あることは正しいですね。更なる問題は、 DNS over HTTPS のクライアントに直接ネットワーク管理者が DNS サーバの在り処を伝える手段が現時点では存在しないことです。 Chrome も MS と同じような方法を取るようですが、事前に「うちの ISP の DNS サーバはこれです」という情報をブラウザに登録しないといけません。 その登録作業を一体何社に 対してすれば良いのでしょう。 Firefox に至ってはそのような仕組みがありません。 Mozilla が決めた「trusted」なサーバか、自分で about:config を編集するしかありません。そもそも DNS over HTTPS 推進者の言い分が「ISP による不当なブロッキングや捻じ曲げを回避する」なので、特定の(彼らにとって信頼できる) DNS サーバに集中させる方向になるとしか思えません。
念のためもう一度書きますと、「DNS over HTTPS のクライアントに直接ネットワーク管理者が DNS サーバの在り処を伝える手段が現時点では存在しない」のが問題です。現状ではごく少数の DNS over HTTPS サーバに囲い込まれることになります。
MS の実装は、レジストリに「DNS (over 53) のIPアドレス」と「DNS over HTTPS サーバ の URL」のマップを持っています。 プライマリ/セカンダリ DNS サーバとしてマップにマッチするエントリがあれば、そのエントリを利用して DNS over HTTPS するという仕掛けです。ですので、利用者が DHCP で指定されたアド
> DHCP サーバで指定された DNS サーバは 192.168.11.1 などモデムの LAN 側 IP アドレスです これはモデムがルーターを兼ねてる場合だから、必ずしもそうじゃないはず。 単機能のモデムなんて今時ないかもしれないけど。 レンタルしてるのがモデム兼ルーターなら、モデム兼ルーター前提の対処ができることにもなる。
Google/Cloudflare/IBM に情報を握られる (スコア:1)
(T/O)
DNSSEC 対応とか経路ハイジャック対策とかは力を入れてくれるでしょうが、セキュリティはそれだけではないですよね。誰がいつどのドメインを問い合わせたという記録が、電気通信事業の規制に掛からない会社に送られているわけです。 User-Agent の情報や TLS Session Ticket も含まれるので、 DNS (over 53) と比べると NAT 越しでも IP アドレスに加えて Web ブラウザひいては利用者を特定できる情報が送られています。
Public DNS サービスは DNS が速いことを売りにしているようですが、 Web ページの読み込み時間のうち DNS の占める割合はとても小さいのではないでしょうか。 Firefox は独自にキャッシュもしていますよね。たとえ DNS が速かったとしても、 CDN 事業者が 問い合わせ元のクライアントに一番近いサーバーの IP アドレスを返す仕掛けを使っていると、その恩恵を受けられないことになります。 DNS が速くても、その後のページの読み込みで太平洋の向こう側へアクセスすることになっては、本末転倒です。
# EDNS Client Subnet のことは存じていますが、 CDN 事業者の DNS サーバが対応してくれないと効果がありません
# Cloudflare の 1.1.1.1 はプライバシーの懸念から EDNS Client Subnet に対応しないと明言しています
Re: (スコア:0)
ツッコミどころ満載ですね
User-Agent は送る必要がない
(なんでワザワザ利用者が特定できる情報を送るんですか?)
TLS Session Ticketはランダムなものをつかうから、NAT越しなら、利用者までは特定できない
(あなたはTLSの仕組みを誤解しています。
あなたの考えているSession Ticketの使い方だと TLSを使う全てのアプリで利用者が特定できてしまいます)
Public DNS サービスを使って速くなるか遅くなるかは実際に測ってみれば済むことで
タラレバを言っても意味がない(速くなることもあれば遅くなることもある。だから何?)
Re: (スコア:0)
信用し過ぎでは?
Re: (スコア:0)
User-Agent について、 Firefox でも半年前まで送っていました (https://bugzilla.mozilla.org/show_bug.cgi?id=1543201) HTTP(S) 処理を既存の Web ブラウザのコードを使い回せば楽になるという発想があるので、あえて User-Agent を送らないようにするというコードを書かないといけない。他のクライアントは知りませんが、少なくとも Firefox は不注意な実装だったのは事実ですね。
Session Ticket は Webサーバが送った ticket をブラウザが次回接続時に返してくれるので、トラッキングに使えるのでは? (https://svs.informatik.uni-hamburg.de/publicatio
Re: (スコア:0)
関連ストーリー [security.srad.jp]より
警戒するとしたら名前解決に相互運用性のない独自プロトコルを導入して囲い込みを図ろうとすることだろう
Re:Google/Cloudflare/IBM に情報を握られる (スコア:1)
DNS の囲い込みが問題あることは正しいですね。更なる問題は、 DNS over HTTPS のクライアントに直接ネットワーク管理者が DNS サーバの在り処を伝える手段が現時点では存在しないことです。 Chrome も MS と同じような方法を取るようですが、事前に「うちの ISP の DNS サーバはこれです」という情報をブラウザに登録しないといけません。 その登録作業を一体何社に 対してすれば良いのでしょう。 Firefox に至ってはそのような仕組みがありません。 Mozilla が決めた「trusted」なサーバか、自分で about:config を編集するしかありません。そもそも DNS over HTTPS 推進者の言い分が「ISP による不当なブロッキングや捻じ曲げを回避する」なので、特定の(彼らにとって信頼できる) DNS サーバに集中させる方向になるとしか思えません。
情報の補足 (スコア:1)
Mozilla が決めた「trusted」なサーバか、自分で about:config を編集するしかありません。
この情報はちょっと古いですね。
最近だと設定画面(about:preferences)で任意のURLをDoHのサーバーとして追加できるようになっています。
Firefox Nightlyでしか確認していないのでRelease版に実装されているのかは分かりませんが、それほど厳重なテストが必要な機能でもないので、仮に実装されていないとしても数か月でReleaseに降りてくると思いますよ。
Re: (スコア:0)
情報ありがとうございます。 76.0.1 ではまだですね。
about:config や about:preferences で追加できたとしても、現時点では DHCP で配るようにはいかず、 Mozilla が決めた「trusted」なサーバに囲い込まれやすいことには変わりないかと思います。
Re: (スコア:0)
> その登録作業を一体何社に 対してすれば良いのでしょう
難しくてわからないのですが、記事中のMSのブログは、設定手順でコントロールパネルか設定アプリで対応サーバーを指定するとあります。
ご家庭のパソコンなら、明示的に設定しないかぎりはレンタルされたモデムとDHCPを経由してISPのDNSサーバーになると思ったのですが、間違ってますでしょうか。
Re: (スコア:0)
念のためもう一度書きますと、「DNS over HTTPS のクライアントに直接ネットワーク管理者が DNS サーバの在り処を伝える手段が現時点では存在しない」のが問題です。現状ではごく少数の DNS over HTTPS サーバに囲い込まれることになります。
MS の実装は、レジストリに「DNS (over 53) のIPアドレス」と「DNS over HTTPS サーバ の URL」のマップを持っています。
プライマリ/セカンダリ DNS サーバとしてマップにマッチするエントリがあれば、そのエントリを利用して DNS over HTTPS するという仕掛けです。ですので、利用者が DHCP で指定されたアド
Re: (スコア:0)
> 「DNS over HTTPS サーバ の URL」のマップを持っています
ここ理解できてなかった。解説ありがとう。
証明書検証をしたいけど、マップに証明書の情報自体を入れるわけでもないみたいね。
ISPがDoHをやろうとするなら、DoHクライアントの作りを改修して、
・IPはDHCPの配布した値は特別扱い
・ホスト名はdohdns.comとかを特別扱い(現状でもルーターなどが独自のホスト名を名乗ることがある)
・パスは/dns-query決め打ち
にすれば行けることは行けると思う。
> DHCP サーバで指定された DNS サーバは 192.168.11.1 などモデムの LAN 側 IP アドレスです
これはモデムがルーターを兼ねてる場合だから、必ずしもそうじゃないはず。
単機能のモデムなんて今時ないかもしれないけど。
レンタルしてるのがモデム兼ルーターなら、モデム兼ルーター前提の対処ができることにもなる。
長々と書いたけど、ISPがやるほどの話じゃなさそうだね。