どさにっき AI

by やまや
5月下旬

2018年5月23日(水)

1.1.1.1 いろいろ

_ ここのところブロッキングの話を追いかけてたもんだから、そのちょっと前にホットだった cloudflare の public DNS のネタを消化しきれてない。ということで、もうだいぶ遅れ気味だけどまとめて放出。

_ あ、JANOG41.5 でやったブロッキングの話の資料は ここにあります。周回遅れすぎて今さら見る必要ないかと思いますが。

DNS over TLS

_ お使いの unbound.conf に以下の設定を追加するだけで、cloudflare に対して DNS over TLS でクエリをやりとりするようになります。ただし最新の 1.7.x 以降のみ。

server:
    tls-cert-bundle: "/etc/ssl/cert.pem"	# ルート証明書束
forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853
    forward-addr: 1.0.0.1@853
    forward-addr: 2606:4700:4700::1111@853
    forward-addr: 2606:4700:4700::1001@853

_ 1.6.x 以下でも TLS が使えないわけではないんだけど、以下のような問題があるのでやめておいたほうがよい。

なお、1.7 でも SSL プロトコルバージョンや ciphersuite などは指定できない。

DNS over HTTPS

_ コマンドラインから JSON 形式ではなく DNS wireformat 形式で叩く。実用性は皆無です、はい。

> drill -q /dev/stdout www.google.com | sed 's/;.*//; y/abcdef/ABCDEF/' | tr -dc 0-9A-F | sed 's/^./A/' | dc -e'16i?P' | curl -o - -H 'Content-Type: application/dns-udpwireformat' --data-binary @- https://1.1.1.1/dns-query | drill -i /dev/stdin
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   160  100   128  100    32   3368    842 --:--:-- --:--:-- --:--:--  4210
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 42641
;; flags: qr rd ra ; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; www.google.com.      IN      A

;; ANSWER SECTION:
www.google.com. 284     IN      A       74.125.124.99
www.google.com. 284     IN      A       74.125.124.103
www.google.com. 284     IN      A       74.125.124.104
www.google.com. 284     IN      A       74.125.124.105
www.google.com. 284     IN      A       74.125.124.106
www.google.com. 284     IN      A       74.125.124.147

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; WHEN: Thu Jan  1 09:00:00 1970
;; MSG SIZE  rcvd: 128
drill にはパケットを投げたり受けとったりするかわりにファイルに読み書きする機能があるのでそれを使ってる。ただし、ファイルの読み書きはできるけど標準入出力の読み書きはできないので、/dev/std{in,out} を使ってムリヤリやらせてる。また、ファイルに書くときは実際のパケットフォーマットではなくテキスト形式でダンプするという大きなお世話をしてくれやがるので、それをバイナリに戻すという手間をかけてやる必要があって、sed やら dc やらはそれをやってる(読むときはバイナリのままでいい)。

_ DoH って期待してる人がすごく多そうに見えるんだけど、どうなのかねぇ。stub resolver として使えない以上ほとんど意味ないと思うんだけど。cloudflare は 専用のクライアントを用意してるけど、わざわざそれをインストールするぐらいなら unbound をインストールして TLS でもいいわけで(windows 版 unbound もあるよ)。

_ cloudflare は 1.1.1.1 という覚えやすい IP アドレスでそのまま HTTPS アクセスできるけど、一般的な HTTPS ではホスト名でアクセスする必要があって、DoH で使うためにはまずそのホスト名を名前解決しなけりゃならんという鶏と卵の問題があるんでめんどくさいんだよね(たとえば google の DoH は 8.8.8.8 ではなく dns.google.com でアクセスする必要がある)。ホスト名ではなく IP アドレスの証明書を発行してもらうという cloudflare のやりかたもあるし、その部分は /etc/hosts で名前解決するというやりかたもあるけど、いずれにしてもめんどくさい。

_ ホスト名の正引き逆引き以外の問い合わせを投げるツールを書くとき、いまどきのスクリプト言語であれば HTTP と JSON の処理ぐらいは標準装備してるからわざわざ DNS 用のライブラリを追加インストールしなくていい、というのは非常にメリットが大きいとは思うんだけど、それを生かせるのはかなり例外的なケースだよね。これをありがたいと思うのであれば、cloudflare なんかに頼らず、ローカルの環境に HTTPS -> DNS の proxy を自前で整備するべき。

1.1.1.1 の証明書

_ 証明書についてはすでに うるしまさんが書かれてますけれど、それとはまったく別方向で。

_ CT ログで証明書発行の記録を探してみると、cloudflare に対して 1.1.1.1 の証明書が最初に発行されたのは 3/22であることがわかる(現在の証明書とは異なる)。一方、 APNIC whowasで調べてみると、whois 情報に "APNIC and Cloudflare DNS Resolver project" という文言が入ったのは 3/30 だということがわかる。つまり、whois の情報を見ても cloudflare のものだとはわからん時期に cloudflare に対して証明書が発行されちゃったってことなんだよね。

_ じゃあ CA(digicert) はどうやって cloudflare 所有のアドレスだと確認したのか調べてたら、cloudflare(AS13335) が 1.1.1.0/24 の経路を流しはじめたのが 3/20 ごろだったということが判明。 このへんをポチポチいじるとわかる(直リンできない)。証明書が発行された 3/22 は whois の情報は変更されてなかったけど、すでに cloudflare に経路が向いてたので発行は問題なしと判断されたってことなんでしょう、たぶん。不正な手続きによる発行じゃなかったんだね、よかったよかった。

_ …で終わればいいんだけど。

_ 実は、これ以前にも 1.1.1.1 に対する証明書が発行されてるんだよ。 ここを見ると APNIC でも cloudflare でもないところに対して過去に3枚ほど 1.1.1.1 の証明書を発行されてるのがわかる(いずれも期限切れ)。どうやっても 1.1.1.1 を所有できていたと証明できるはずがないと思うんだけれど、なんでこんな証明書を CA は発行しちゃったんですかねぇ…。

_ ホスト名ではなく IP アドレスに対する証明書はチェックがザルな CA が多いという話をどこかでちらっと聞いたことがある。もしろくに確認もされずに 1.1.1.1 の証明書を誰でも取れるのが事実なのだとすれば、cloudflare が正当な手続きで取得していたのだとしても、証明書を見たたけじゃ正当に取得されたのか不当に取得されたのか客観的に区別できない以上、ぜんぶまとめて信頼できないとして扱うしかないんじゃないかなー、と思うんですがどうなんでしょう。


2018年4月27日(金)

IP over SFSS (RFC4824) における通信の秘密の検討

_ IP over SFSS についてはこちらを参照

At the physical layer, SFSS uses optical transmission, normally through the atmosphere using solar illumination and line-of-sight photonics.
との記述があるように、物理層として可視光を用いた通信方式である。

_ まず、IP over SFSS がどの法律に準拠するのかを検討する必要がある。現在のところ、IP over SFSS をサービス提供している電気通信事業者が存在しないため、電気通信事業法は適用されない。IP over SFSS は有線電気通信法2条で定義される「線条その他導体を利用した通信」にも該当しない。可視光すなわち電磁波を用いるが、その周波数帯は 400-800THz 程度であり、電波法2条1項で定義される「三百万メガヘルツ以下の電磁波」に該当しない。これらの法律ではいずれも通信の秘密を保護する条項があるが、いずれも適用されない。

_ 通信の秘密とは異なるが、信書の秘密で保護できないかも検討してみる。しかし、IP over SFSS により伝達される情報は物理的な「文書」の形態を取っておらず、郵便法4条2項で定義される信書とはいえず、郵便法、信書便法は適用されない。

_ さきほど電気通信事業法を除外した理由として、単に IP over SFSS を提供する事業者が存在しないからとした。それでは今後提供されるだろうか。

_ IP over SFSS は可視光(電磁波)を用いているため、電磁的方式による通信といえなくもない。しかしながら、その送受信には電気通信事業法2条における電気通信設備(機械、器具、線路、その他の電気的設備)は必要とされず、したがって IP over SFSS は電気通信役務とはいえない。よって、IP over SFSS をサービス化したとしてもそれは電気通信事業ではなく、電気通信事業法の制限を受けることはない。もちろん電気通信事業法4条による通信の秘密の保護もされない。

_ したがって、通信の秘密および信書の秘密を規定した各法のいずれも適用されないため、IP over SFSS の通信の秘密は保護されない。

_ 先般の海賊版サイト問題において、ブロッキングの是非の論点になっているのが通信の秘密の問題であるが、IP over SFSS であればそもそも通信の秘密は保護されないのであるから、ブロッキングを実施する障害にはならない。海賊版の被害を受けている出版業界は IP over SFSS すなわち手旗信号インターネットの商用サービス化を強く推進するべきであろう。

_ もうひとつ、 IP over Avian Carriers (RFC1149)についても検討する。

_ Avian Carriers (AC) は電磁的方式ではなく、線条その他導体を利用せず、電磁波も利用しないことから電気通信事業法、有線電気通信法、電波法のいずれも適用されず、通信の秘密の保護はない。

_ AC の運ぶ文書は「特定の受取人に対し、差出人の意思を表示し、又は事実を通知する文書(郵便法4条2項)」に該当すると考えられるから、信書といえるだろう。しかしながら、郵便法8条および信書便法5条における信書の秘密は、日本郵便あるいは信書便事業者の取り扱い中の信書のみが保護対象であり、日本郵便や信書便事業者が IP over AC を扱っていない現状では秘密は保護されない(将来的に取り扱いを始めた場合は保護の対象になりうる)。

_ したがって、現状では IP over AC による通信においてブロッキングをおこなうことは、通信の秘密の観点で違法になることはない。

_ ただしそのブロッキング手法には注意が必要である。なぜなら、IP over AC で一般的に使われる鳥類キャリア(鳩)は鳥獣保護法施行規則における狩猟鳥獣として指定されていないからである。これを狩猟によりブロッキングすることは違法である。


2018年4月26日(木)

通信の秘密

_ ちうことで、ついに 裁判に

_ 今回の件で痛感したのが、通信の秘密ってぜんぜん理解されてないんだなー、ということ。憲法で定められている基本的人権のひとつなのに。

_ ブロッキングを問題視してない人ってのは、たぶん「ブロックすること」が通秘の侵害だと考えてるんじゃないかなぁ。名指しされたサイトにアクセスしなければブロックされることもなく、ブロックされないのであれば自分自身の通信の秘密は侵害されない。そう考えてるんじゃないかと推測する。

_ この考え方は間違ってるからね。いや、ブロックすることも侵害なんだけど、それ以前に「ブロック対象かどうかチェックすること」が通信の秘密の侵害。名指しされたサイトにアクセスするのではなく、たとえば youtube で動画を見るだけでもブロック対象かどうかチェックされ、そうでなかったからブロックされずに youtube にアクセスできるわけで、名指しされたサイトだろうがそうでなかろうが、どんなサイトにアクセスするときでも常時監視されチェックされるという通信の秘密の侵害、プライバシーの侵害が起きることになる。

_ ブロック対象サイトにアクセスするときだけ侵害があるのであれば、著作権との衡量においてもブロッキングは受け入れられやすいんじゃないかと思うんだけど、というかそう考えて賛成してる人が多いと思うんだけど、実際はそうじゃない。そういったサイトに一切アクセスすることのない人までも常に監視されて権利が侵害されることになるんだから、どうしても慎重にならざるをえない。今回訴訟を起こした弁護士さんはじめブロッキングに反対している人たちは、名指しされたサイトにアクセスする一部の人の権利を守るためではなく、インターネットを使うすべての人の権利を守るために抗議の声を上げてるってことを理解してほしい。

_ それから、DNS によるブロッキングはそもそも通秘を侵害しないとか言ってる人がけっこう多いことにも驚いた。その前提がまず共有できてないのか…。政府が緊急避難としてならやれると法的整理したのは、ブロッキング推進派の政府ですら通信の秘密を侵害するという前提は動かしようがないと認識してるからなんだけどなぁ。侵害しないという理屈がすんなり通るなら、無理筋と言われてる緊急避難という理屈に頼る必要なんかどこにもない。

_ ある人がどこにアクセスしたがってるかを聞いて適切な場所に誘導するのが DNS サーバの仕事。しかし、どこにアクセスしたがってるかという情報は通信の秘密にほかならないんだから、それをユーザから聞く DNS サーバってのは、ブロックしようがしまいが通信の秘密を侵害している。つまり、DNS はその本質として通信の秘密を侵害する。しかしながら、まさにこれこそが DNS に求められた役割であり、それをしないことには通信が成立しないんだから、これは正当行為(刑法35条)であり違法ではない。通信を成立させるのではなくブロックするのは DNS に求められた仕事ではないから正当行為にもならず、でも緊急避難(刑法37条)に該当するよ(政府)、いやそれは無理筋(法律家)というのが今回の論点。

_ 「通信の秘密を侵害するが違法ではない」というのは DNS だけでなく ルータもまったく同じだし、ハガキの宛名を読んで郵便配達するのも(こちらは通信じゃなくて信書の秘密だけど)同じ。ちゃんと宛先に届けるなら正当行為だけど、勝手に捨てたら違法。

_ 特定のサイトにアクセスするときだけパケット無料にする MVNO はどうなんだ、あれも通秘の侵害だろ、という意見もあるみたい。はい、あれは無断でやると違法な侵害。なので、契約前にそういうことをやるとちゃんと説明されてるはず。それに同意しないと契約できない。ユーザが事前に同意してるので侵害ではないという理屈。そんなん知らされなかったぞ、という場合はド忘れしてるだけか、そうでなければマジ違反なので総務省に通報しましょう。

_ ISP の中の人ってのは、こんな感じで皆様の通信の秘密を毎日毎日侵害しなけりゃならず、でもやってはいけない一線を踏み越えないように注意しながらお仕事してるんです。よその業界の損害を埋めるためにそういう微妙な線引きを変えるようなめんどくさいことを押しつけるのはやめていただきたいですね。


5月下旬
やまや