_ OpenDNS によるエンドユーザとキャッシュサーバの間を暗号化する試みだそうな。キャッシュサーバとコンテンツサーバの間を暗号化する DNSCurveをクライアント側でも利用できるように、という発想らしい。DNSSEC に対応したスタブレゾルバも現状では存在しないし、ここでの毒入れを防ぐというのはたしかに重要なことだろう。
_ DNSCurve って、どうやら ISP や企業内の共用キャッシュ DNS を使う従来のモデルと異なり、個別のクライアント PC ごとにインストールしてそれぞれが full recursive なサーバとして動作させることを意図してるようで (*1)、そうであればスタブレゾルバとキャッシュサーバの間の毒入れは気にしなくていいんだけど、しかしその一方でキャッシュ効率が極めて低くなる。そんなのが世界中に普及されてしまったらルートや TLD の DNS に対するクエリがとんでもなく増えてしまって破綻するか、破綻しないにしてもこのへんの DNS の運用コストがべらぼうに大きくなってしまう危険なものなので、従来のモデルを保ったままセキュリティを担保しようという方針は評価していいと思う。
_ 以下、どういう仕組みで動くかのドキュメントがほとんどないんで、まあ大部分は DNSCurve そのままだろうという思い込みと、それから man の記述やソースをちらっと見たところによる推測。勘違いで実際は異なるかもしれないので注意。
_ 公開鍵暗号を使うのでとーぜん相手の公開鍵を手に入れる必要があるわけだけど、DNSCurve では NS レコードそのものを公開鍵として使うという仕様になっていた。DNSCrypt では NS レコードなんてものには頼れないので、さてどうすんだろ、と思ったら、 ソースに公開鍵が埋め込まれてた。えー。起動時の引数でも指定できるようだけど、サーバの鍵変更のタイミングに合わせて同時にクライアント側も鍵を変更してプロセス再起動しないと名前解決できなくなるので、現実的には鍵のロールオーバーをしようと思ってもできないんじゃないかしら。まあ、ロールオーバーできないってのは DNSCurve でもそうなので、ベースが同じ以上しかたないんだろうな。
_ なお、鍵のロールオーバーってのは、DNSSEC ではこれが導入の妨げになってるといってもいいほどしちめんどくさい作業が必要なものなんだけど、べつに DNSSEC に特有の概念ではないので念のため。公開鍵暗号でも共通鍵暗号でも、同じ鍵を長いこと使い続けてるとその間に解析に成功しちゃったり、あるいは人為的ミスで鍵が漏曳・紛失したりする可能性があるので鍵を交換できるようにしておきましょう、というのが暗号の常識。そうはいっても、sshd のホスト鍵をわざわざ交換することなんてめったにないわけだし、それと同じようなものと思えばそれほど目くじらを立てるほどのことでもないとも言える。
_ キャッシュサーバがコンテンツサーバを探して再帰検索するのとは違って、キャッシュサーバへのアクセスは不特定多数への接続をするわけでないので、信頼の連鎖について考慮しなくていいのはありがたいね。DNSCurve はここがダメダメなので毒入れできちゃう (*2)けど、DNSCrypt にこの問題はなさそうだ。
_ しかし、不特定多数のホストにアクセスするのではなく、専用のツールを使って特定ホスト間に閉じたアクセスしかしないプロトコルなんだから、DNS の拡張にこだわる必要はなかったと思うんだが。DNS とはまったく異なる名前解決用の新しいプロトコルをゼロから開発してしまっても誰にも迷惑をかけることはないはず。新プロトコルでなく既存のものでも、nsswitch.conf で
と書いて、DNS を使わず LDAP or LDAPS でホストの名前解決をする、というのも(実用になるかどうかはともかくとして理屈の上では)可能なわけだし。hosts: ldap_ それから、暗号化ってほんとに必要なのかしら。どんなサイトにアクセスしようとしているか、というのもプライバシーの一種として秘密にしておきたいかもしれないけど、DNS を暗号化して守っても、パケットを sniff できる攻撃者であれば、その問い合わせの結果どこにアクセスしにいくかもきっと sniff できるだろうからあんまり意味ないんじゃないかと思う。応答が改竄されてないよ、というのが確認できれば十分だと思うんだけどねぇ。それに、コンテンツサーバとキャッシュサーバの間は DNSSEC も DNSCurve も使ってないところが大半で、ここで毒入れされる可能性がある以上、クライアントとキャッシュサーバの間を守ってもあんまり実効性ないんだよな。そゆ意味では、libc (libresolv) の名前解決関数を DNSSEC 対応するだけで十分じゃね、という気もする。
_ ちうことで、まとめ。方向性としては間違ってないし、ベースとなった DNSCurve よりスジはよさそうだけど、それでも実用になるかどうかというと、うーんどうかなぁ、というのが正直なところ。現状ではまともなドキュメントが存在してないので実際はそうではないかもしれないけどね。
(*1): というかそれ以前に dnscache もそうらしく、これが djb の思想なんだろうか。
(*2): example.com の NS が uz5(51バイト略).example.com であるとき、攻撃者は com の NS に対して www.example.com の情報を問い合わせたときの応答に含まれる NS に毒を入れて、uz5(略).example.com とは異なるホストに誘導してやればよい。uz5(略).example.com がいくらがんばって DNSCurve で防御したところで、そこに問い合わせが行かないように上位の DNS で毒を入れられたら防ぎようがない。これは DNSCurve が信頼の連鎖の概念を放棄していることによる欠陥。DNSSEC は上位に毒が入った時点で検知できるのでこの問題はない。念のため、信頼の連鎖は DNSSEC 特有のものではなく暗号一般に共通する考え方。
_ コネクトフリー問題。 このへんとか このへんとか。で、それに対する 釈明。
当該サービスを実施するにあたり、利用者の以下の情報を取得していました。ネットワーク接続サービスなのであればログを取得、保存するのはあたりまえのことで、ユーザ登録しないのであればそのかわりに MAC アドレスを識別情報として使うのは、まあ自然な流れだな。アクセス期間を取得していたというけど、昔ダイアルアップでインターネットにつないでいた時代に時間従量課金ができていたのは、接続/切断時間をぜんぶ記録していたから。最近は絶滅したけど、前世紀には HTTP プロクシを提供する ISP もいくつかあって、そのサービスを使うユーザはとーぜん閲覧 URL も記録されていた(squid ではデフォルトではユーザエージェントをログに残さないので、こちらはログ取得されてなかったかもしれない)。ちうことで、取得していたとされる情報の大半は大昔から ISP がやっていたことだったりする。もちろん facebook や twitter の情報なんか拾ったりはしないし、amazon のアフィリエイトを書き換えたりもしないが。
・MACアドレス
・FacebookアカウントID・Twitter ID
・端末のユーザエージェント情報
・アクセス期間
・閲覧しているＵＲＬ_ こういった情報の取得は安定運用には欠かせないもので、これがないとトラブルが発生したときに調査のしようがない。こういう情報を記録すること自体に責められる要素はなく、むしろやってないとしたらその方が正気を疑われるレベル。問題は、その取得した情報を違う目的で利用していたこと、通信に介入してコンテンツの書き換えをおこなってたいたこと。つまり正当業務行為を越えた通信の秘密の侵害をしていたということ。…なんだけど、世間の声を見ると正当業務行為の範囲内の情報取得そのものを責めてる人も多いね。そうじゃないんだけどなぁ。
_ この件に関してはたくさんの人が注目してるし、 総務省も動きはじめたようなので、以後どうなるかはこのへんの人たちの監視におまかせするとして。
_ 一方、 セブンイレブン系列ではじまった公衆無線 LAN サービス。 /. によると、
イトーヨーカドー曳舟店内で利用してみたら、楽天とAmazonはブロックされてました。てな感じでいくつかのサイトが制限されてるらしい。これ、「えー、そうなの」という程度の感想で済ませてる人が多いみたいだけど、いや、これまずいでしょ。通信内容を覗き見してコンテンツを改竄してるってことだから。 利用規約を読んでもそんなことするとは書いてない、つまりユーザの同意を取らずに勝手にやってるってことだよね。コネクトフリーほど悪質ではないにしろ、通信を監視してブロックしてるってことは立派に秘密の侵害だよね。OP25B やら児童ポルノブロックとかはいずれも通信の秘密を侵害する行為だけど、それを上回る理由をもって違法性を阻却できるかどうかさんざん議論した上でやっとスタートしてる(そのへんすっとばして winny ブロックしたぷららは総務省に怒られた)。で、7spot はちゃんと法的な裏付けがあってそういうことをやってるんだろうか。_ もっとも、これが電気通信事業でない、となればやってしまって問題ない。企業内や学校内の通信でこういう検閲をするのは、「他人」の通信ではないから電気通信役務でないとして認められている。総務省の 電気通信事業参入マニュアルを見ると、ホテルの宿泊者向けの外線電話/インターネット接続サービスは宿泊サービスに付随したもので独立した事業でないから電気通信事業ではない、みたいな解釈があるけど、でもこれに関しては同様の解釈は無理だよね。店舗の利用とは別個にユーザ登録が必要で、運営にはセブンイレブンだけでなく日本を代表する通信事業者である NTT 東まで加わってるんだから、明らかに独立した電気通信事業だよね(その点ではむしろコネクトフリーの方が言い逃れできる余地は大きいと思う)。接続先によるブロックをやめるか、規約を改正してユーザの同意を取りつけた上でやるかどちらかしないといかんと思うぞ。