Author Archives: Hirotaka Nakajima

About Hirotaka Nakajima

Software Engineer at W3C / Project Assistant Professor & Ph.d Student, Keio University / Love geeking and eating.

family-ops – 家族を支えるテクノロジー

これは、妻・夫を #愛してる ITエンジニア Advent Calendar 2017 企画の2日目です。

はじめに

はじめまして。nunnunと申します。僕は、インターネットにおけるトラストに関する研究をしている研究者で、大学を経て、現在はメルカリという会社に所属しています。
製薬会社で働く妻と結婚してちょうど1年になりました。お互い理系カップルなので、参考にならないかもしれませんが、非エンジニアの妻と、この1年間で家庭を効率的に運用するために使ってみて、役に立ったサービスを紹介したいと思います。

G Suite

Google Appsって言われていたやつです。


登録開始を待ち望んでいた .family gTLDでドメインを取ることができたので、そのドメインを使っています。

Google Calendarはお互いの予定を見えるようにしているので、family eventの調整や遊びに行く調整などもカレンダー見て、invitation送るだけでできるので、非常に便利に活用しています。

Google Photosの共有ライブラリ機能はお互いの写真を撮った後、勝手に自動で共有してくれる上に、RAWで撮影してもそのRAWをダウンロードできるので、後でファイルをもう一回貰わなくて済むというので便利です。

他にもGoogle DriveのTeam Driveで家計簿を管理したり、大切な書類をスキャンして保存したりしています。

Slack

エンジニア同士なら確実に使っていると思うのですが、夫婦でSlackを使っています。
付き合い始めた当初はLINEを使っていたのですが、そもそも僕がLINEをほとんど使っていなかったのでSlackに移行しました。便利な点としては、

  • 会社で使っているツールなので、ひと目につきにくい
  • 履歴の検索が簡単にできる
  • チャンネルをわけることで、コンテクストが混ざらずに済む
  • Integrationが便利

Integrationはなかなか活用しきれていませんが、後に述べるGithubと連携してIssuesの通知などに活用しています。
(便利なIntegration有ったら教えてください!)

10,000メッセージ行くのに1年以上かかるのではと思っていましたが、f2fでない会話はほとんどSlack上でしているので、気がついたら10,000メッセージを超えていました。
そろそろ課金するかGoogleのHangouts Chatが出たらそっちでもいいかなと思います。

GitHub

結婚式は私の母校の教会で挙げました。
ホテルや専門式場での結婚式の場合、会場がある程度準備をしてくれるのですが、教会は式を挙げてくださるだけなので、すべての準備を二人でしなければならず、膨大なタスクリストを共有、解決するためのツールとしてGitHubを使いました。

結婚式の準備と並行して新生活の準備も実施していたため、タスクやマイルストーンを整理しながら意思決定とその記録も残したかったので、GitHubのプライベートレポジトリを活用しました。今は、生活が落ち着いているのであまり活用できていませんが、きっと子育てが始まると大活躍するようになるのかなと思います。

Find My Friends

お互いiPhoneを使用しているので、Apple純正のFind My Friendsを使って位置情報の共有をしています。共働きで、夕飯の支度をしているときに後どれくらいで帰宅するのかわかるので、非常に便利です。

1password for family

航空会社の会員番号や、身分証明書の写真や、家のWiFiのパスワードなど、Secureに共有しておきたいものを共有するのに使っています。

まとめ

参考になりましたでしょうか。
エンジニア同士でなくとも、便利に活用することができるWebサービスを紹介しました。

結婚2年目に突入したばかりですが、新しいサービスや家庭内人柱に常に協力してくれる妻には感謝しています。これからもテクノロジーの力を借りて、二人で効率的で素敵な家族を築いていけたらと思います。

明日は ものものブログ さんです!

KDDI版iOS 9デバイスでIPv6を使う

以前書いたKDDI版iPhone 5/5s/5cでIPv6をつかうのプロファイルでは動作しなくなったので、アップデートしました。

技術的な詳細はIIJてくろぐに記載されていますが、とりあえずLTE NET for DATA用のプロファイルを作成したので公開します。

https://nunnun.jp/ltenetfordata-test.mobileconfig

Eduroamに非参加でも学認に参加機関に所属する人がEduroamを使う方法

Eduroamは学術機関間におけるWiFiの相互ローミング運用プロジェクトで、全世界の大学や研究機関に所属する学生・教職員が利用できるシステムで、日本国内においては国立情報学研究所(NII)が推進をしています。

日本国内における認証連携には学術認証フェデレーションである”学認“を使用しており、学認に参加している機関であればeduroamが利用できるように見受けられますが、実際にはeduroamに別途参加しなければ利用できない仕組みになっています。

例えば慶應義塾大学のように学認に参加しているが、eduroamに参加していない機関に所属する学生・教職員はeduroamの恩恵に預かれず、国内外の学術機関に訪問した際にネットワークを利用できません。

Eduroamでは所属する機関の学生・教職員が持つクレデンシャルを利用して認証を行うため、個人や所属機関が特定されてしまうと言う問題 ((例えば[email protected]というアドレスで認証すればSFCに所属しているのがわかってしまいます)) がありました。その問題を解決するため学認では一時的に仮名のクレデンシャルを発行する仮名アカウント発行システムというシステムを運用しています。

本来仮名アカウント発行システムは利用者を保護するためのシステムですが、本システムを利用することでeduroamに参加していない機関に所属する人もeduroamを利用することができます。

方法

  1. 仮名アカウント発行システムにログインする
    https://eduroamshib.nii.ac.jp/
  2. ログインに成功したら、アカウントを発行する。
    利用期間は最大1年間まで選べます
  3. 取得したクレデンシャルでeduroamを利用する

免責事項

本記事は私が所属している組織の意見を表明したものではありません。
また本記事の内容について保証するものではありません。

HWD14をMac OS X Yosemiteで使う方法

MacをYosemiteにしてからHWD14の有線Ethernetが使えなくなって、WiFi経由でしか使えなくなってしまい、非常に不便だったのだが使える方法があったのでメモ。

基本的にこの手のデバイスは最初接続するとUSB Composit Deviceとして認識されて、専用のユーティリティがATコマンドみたいなのを飛ばして有線Ethernetデバイスとして認識させるみたいな仕組みなので、初回接続時だけユーティリティのインストールが行われる仕組みになっている。

ただ、OSのアップグレードとかでそのユーティリティが動かなくなると有線Ethernetとしても使えなくなる仕組みなので、そのユーティリティさえアップグレード出来れば問題ないはずなのだけど、残念ながらHWD14はそのアップデートが提供されず購入して1年もたたないのに最新OSで使えないという残念な仕様となっていた。

勿論本国ではそのユーティリティは提供されているので、同じHuawei製のHWD14なら動くはずということで試してみたところ問題なく動きました。というオチ。

リンクはこちら。
http://consumer.huawei.com/en/support/downloads/detail/index.htm?id=31145

ところでHWD14小田急線で全くというほど使い物にならないのだけど(というか動いてると小田急線だけじゃなくダメ)、後継機に乗り換えたら使い物になるのかな?

HTTP2におけるProxyに関する議論

この記事はHTTP2 Advent Calendarの17日目の記事です。

はじめまして。nunnunと申します。HTTP2 newbieなので戦々恐々としておりますが、よろしくお願いします。

注意: HTTP/2.0はHTTP2もしくはh2と表記が変更になりました。

先日HTTP2のExplicit Proxyとそのプライバシー上の懸念について記事を書かせていただきましたが、その後のプロキシに関する議論を書きたいと思います。

IETF 91 HonoluluではProxyに関する議論がいくつか行われました。

  • draft-nottingham-web-proxy-desc-01
  • draft-loreto-wpd-usage-00
  • draft-chow-httpbis-proxy-discovery-00

背景

Explicit Proxyの議論が生まれた背景はGoogle ChromeのSPDY Mobile Proxyをキャリアが運用したいというモチベーションでした。SPDY Mobile Proxyをオペレータが運用することでTransparent Cacheなどのトラフィックエンジニアリングによるトラフィック削減が望めるため、HTTP2においてそうした仕組みを実現したいという目的で提案がなされた模様です。

draft-nottingham-web-proxy-desc-01

httpbisの議長であるMark NottinghamによるProxy Discoveryに関するドラフトです。従来HTTPにおけるProxyの設定はPAC(Proxy Auto Configuration)と言われるJavaScriptを用いてProxyを設定するという方式が用いられていました。JavaScriptを用いるため柔軟な設定が可能である反面、その設定URLを知らなければ設定できない問題が指摘されており、その問題点を解決するためWPAD (Web Proxy Auto Discovery)と呼ばれるDHCPもしくはDNSを用いてそのURLをnotifyする仕組みが提案され、Internet ExplorerやFirefoxなどで実装され、利用されてきました。

本提案ではまずHTTP/2 over TLSの利用を必須としています。従来のPACではクリアテキストでの設定も許容されていましたが、MiTM攻撃なども想定できることから証明書の検証が必須となっています。

またどのホストにどのプロキシを利用するといった設定がJSONによる形式に変更となりました。設定では、Proxyの名称、目的を記載するだけでなく、プロキシが企業などで利用されることが多いことから、プロキシを適用するネットワーク(IPアドレスがレンジにいる場合のみに適用するなど)を追加することができるようになりました。

更にはブラウザにおいてIncognitoモードに代表されるプライバシーモードが広く使われていることから、プライバシーモードの利用を強制するオプションの設定が可能となっています。

従来のWPADによるDiscoveryは禁止されたものの、well-known URIを用いたdiscoveryを行うことが規定されています。

draft-loreto-wpd-usage-00

MarkのWPDドラフトを拡張したドラフトがdraft-loreto-wpd-usage-00です。

特徴としては携帯電話ネットワークなどの高遅延、高ジッター環境で利用することを想定し、いくつかのトラフィックタイプ(Class of Serviceに近い)をlabelというタグを用いて分類し、それらトラフィックタイプ毎にプロキシを設定することを可能にしています。そのため、クライアントはコンテンツに応じてプロキシを使い分けることが可能となり、より最適化された通信が可能となるそうです。

draft-chow-httpbis-proxy-discovery-00

draft-chow-httpbis-proxy-discovery-00はWiFiのキャプティブポータルなどと組み合わせることで、明示的に同意を取ることでhttpsスキームな通信もProxyする(ただし”it MUST NOT alter the end-to-end encryption for “https” requests”と規定)ことも可能としています。
(きちんとドラフト読み込めていないので間違っていたらすみません)

ただしこれはMiTMであり、エンドツーエンドでのセキュアな通信を犯す可能性があるため、個人的にはhealthyではない提案であると感じています。

IETFでの議論

IETFではさまざまな議論が行われましたが、結局WGとしての結論は出ず何かをWG itemとして標準化するという結論には至りませんでした。

まとめ

WPADやPACといった仕組みはold-fashionな技術であるため、新しい仕組みが必要であると個人的に感じ、Internet Confidentialityに関するIABのステートメントや、現在W3C TAG(Technical Advisory Group)によるHTTPSへの移行に関する指摘事項ドラフトなどの流れを踏まえると安全にプロキシをDiscoverする仕組みの策定は重要であると感じています。

第4回IGCJ(日本インターネットガバナンス会議)に参加してきました

去年の6月から開催されているIGCJ(日本インターネットガバナンス会議)が4回目となり、インターネットウィーク期間中に開催されているので参加してきました。(参加自体は初回からしていますが)

IANA監督権限の移管に関するアップデートやITU全権委任会議での報告などがありましたが、スライドなどはアップロードされているので、個人的に気になったポイントをまとめたいと思います。

IANA監督権限まわり

粛々と進んでいるなという印象を受けました。基本的にIANA機能はICANNにお願いするという方針で、LACNICがMONC (Multistakeholder Oversight Number Council)というマルチステークホルダな組織がIANA機能の監視をするといった提案をしているのが変わってるなと感じました。

個人的にはNROが地域RIRの活動のコーディネーションとかもしており、これ以上マルチステークホルダにしなくても良いのではないかと感じましたがどうなるかはこれからです。IETF側もIANAPLAN BoFで粛々と進んでいるので、deadlineは近いですがこのまま行くのかなと思います。

ITU全権委任会議報告

4年に1度開催されるITU全権委任会議、ITUの最高意思決定機関。今回の焦点(インターネット的な文脈)はWCIT-12で問題となり改正ITR(アラブ諸国などの提案からセキュリティやスパムなどに国が積極的に関与すべき, インターネットに関するルール策定に国連がもっと介入すべきという方針になったが、日本を含む欧米各国は不署名)によって広がった対立をどう回避出来るかが焦点。
ITUではポリシーの策定は、各国が既存の決議に対して修正提案をする or 新規決議の提案をするという形で実施される。

基本的に日本を含む先進各国はインターネットに対する政府の権限を増やすという提案には反対をしたので、修正提案は取り下げという形となった。ITUの作業部会をもっとオープンにすべきという提案についてはインターネットに関する作業部会は事前にオープンなコンサルテーション会合を開くという方針に。これもマルチステークホルダモデルを踏まえた形なのかなと。

質疑で日本が決議に反対する理由としてITUのマンデート外なので反対という理由をしているが、現実的にはどういう観点で決議への賛否を決めているのかという質問があり、情報な自由の流通を確保することが大前提。それが阻害されるような項目については反対をするという方針という説明がされてた。

インターネットの透明性や非合法盗聴などについては、そもそも国連では人権を担当する委員会とかがあるのでそっちが担当して、ITUは技術について注力するという話があった。個人的にはここは重要なのかなと思っているので、そこら辺のアップデートが聞ける場があったらよいなと思いました。

IGCJを考える会レポート

いろいろな意見が出ていましたが、個人的に思ったのは「プロ」「コーカス」「オーディエンス」という分類で、インターネットガバナンスに関わる人は割と限定されてしまっているため、会社を代表していう意見とインターネットを利用する個人としての意見をうまく帽子を被り変えながら喋らないといけないというのが難しそうだなと言うのを感じました。個人の意見と会社の意見が一緒であればいいのですが、なかなか難しかったりしそうだなと・・・。

IGF2014報告

NETmundialとかはオープンといえども招待を受けないと参加できないのに対してIGFは誰でも参加できるというのが特徴。IGFについては僕の勉強が足りていないので情報収集をしないとなという印象を受けました。(ちゃんと議論を聞けなかったので、まとめきれてなくてすみません。そしてごめんなさい)

雑感

全体的に感じたのはインターネットガバナンスに関して日本ではJPNIC, JPRSさんに頼りすぎているなというのを感じました。もちろん彼らの業務範囲であるので情報集めて、僕らにわかりやすいようにまとめて、そして僕らが考えてそうなことを会議とかで発言していただいているのかなと思うのですが、インターネットはみんなのものだと思うのでもっとインターネットに関わるいろいろな人が意見を出したり、情報を発信していかないといけないなと思いました。JPNICさんとかは妖精さんではないですからね。。。

マルチステークホルダモデルについては勉強が足りてないのですが、究極のマルチステークホルダってマルチステークホルダモデルを作るにはどうしたら良いかの議論をマルチステークホルダでやろうみたいな話になって、以下無限ループみたいになってしまうのですが、ある程度の妥協とわかりやすい仕組み作りが大切かなというのは思いました。

エンジニアな観点だとポリシーの世界はいろいろややこしいと思いますが、エンジニアリングだけで解決できない問題はいっぱいあるのでそのためにももっとエンジニアがガバナンス・ポリシー策定に関わるとよいなと思いました。

インターネットガバナンスnewbieなので、いろいろ間違った認識、おまえ何言ってんだとかあると思いますので是非是非ココ間違ってるよとかご指摘いただけるとうれしいです。

カナダ国境でのlaptop searchについて

2013年11月にカナダ バンクーバーで行われたIETF 88に参加する時に起きた話なので少し古い情報です。

2013年11月3日にIETF 88に参加するためにカナダのバンクーバー空港で入国後、バゲージクレームエリアでカナダ国境サービス庁による手荷物捜索を受けました。通常手荷物捜索は税関などが非申告の禁輸品の所持を確認するためなどの行うのですが、すべての乗客の荷物を捜索することは難しいため、ランダム(もしくは彼らが疑うに足る事由がある場合)に選択して捜索を行うのですが、私が受けた手荷物捜索では児童ポルノの所持を確認するために所持していたデジタル端末すべてのパスワードを教えてなければならないというものでした。

詳細な経緯は以下の通りです。

手荷物を受け取った後、通関ゲートに向かっていたところ、カナダ国境サービス庁の職員にカナダを訪れた理由を聞かれ、IETFへの参加であることを告げたところ、手荷物の捜索を行うということで、ブースに案内されました。
そこで手荷物の捜索に協力していたところ、デジタル端末の捜索(laptop search)も行うのでこの場で(ちなみにオープンなカウンターで他にも”ランダム”に選ばれたアジア系の若い男性が同じようにデジタル端末の捜索を行われていました)パスワードを口頭で言えと告げられました。
そもそも児童ポルノは禁輸品であり、児童の人権は守られなければならないということは認識していましたが、オープンな場所であることや、通常この手の捜索は捜査令状などが必要なのではないかと思い、拒否することを告げたところ、職員より拒否する権限はないと言われました。
しかしながらオープンな場所で口頭でパスワードを告知することは避けたかったため、文字で書くので代替できないかと交渉したところ、それは認められ、職員が所持していたメモ帳(ちなみにそれには過去に同じように捜索を受けた人のパスワードがいっぱい書いてありました)に書くよう言われました。その後職員は私の所持していたデバイスをすべて持ち、バックオフィスに行きカウンターで待機するよう命じ約30分ほど待機しました。
もちろん私は法で禁じられた画像や動画などは所持していないため、30分ほどした後職員は戻り、私は空港の外に出ることが出来ました。

私はこの捜索にはいくつもの問題があると感じています。

  • 捜索の妥当性
    どのような理由で私が選ばれたのかわかりませんが、数百人の乗客から同じように捜索を受けていたのがアジア人の若い男性のみであったことはたとえランダムだとしてもとても恣意的に感じました。
  • 運用方法について
    BC Civil Liberties Associationによると、捜索では”Electronic Media Search Form”に記入をしなければならいと規定されていますが、実際には口頭申告されたパスワードをメモ帳に書き込むというずさんな方法で捜索が行われました。職員の対応にはプロフェッショナルさを感じることは出来ませんでした。
  • 何を優先すべきか
    児童の人権は優先すべきですが、一方個人のプライバシーも大切です。児童ポルノの捜索だけを行うのであれば、別室にラップトップを持っていくというオペレーションではなく、目の前で捜索することも可能だと思います。別室にラップトップを持っていったということは児童ポルノも関係なくデータはコピーされたと考えざるを得ず、またPRISM問題直後でしたのでバックドアを仕込まれた可能性も否定できませんでした。
    また例えば私が政府関連の仕事に従事していた場合、この捜索の結果機密が他国の政府にわたる可能性もあり、これには外交官特権のみでしか対抗することができません。
    更にはもし私が仮に児童ポルノを所持していたとしたらデータを物理デバイスに入れて国境を横断するなどというわかりやすい行為はしないでしょう。暗号化してどこかのサーバにアップロードするなどすると思います。つまりこのlaptop searchでどれくらい児童ポルノが国内に持ち込まれるのを防げたかについては疑問が残り、それにより侵害される個人のプライバシーの方が大きいのではないかと思います。

法治国家に生きる市民として法律に定められた正当な行為なので従いましたが、残念ながら心地よい対応ではなく、タイミングもあって強い憤りを感じました。

法律の専門家ではありませんので、細かいところは違うかもしれません。
その直後のFacebookポストも参考にリンクしておきます。

[追記]
後日IETF 88のTechnical Plenaryの議事録が公開され、そちらに私の発言が記録されていました。

児童の人権と個人のプライバシーどちらもが尊重される社会が訪れるとよいなと切に願います。

適切な暗号スイートを選択する: BetterCrypto.org

SSLの暗号スイートはApacheなどのデフォルト設定を使えば安全と信じたいところなのだが、RC4の危殆化に伴って、RC4を無効にしないといけなかったりやPRISM問題が発生してPFSを有効にしたりと暗号スイートを自分で設定しないといけないパターンが増えてきたと思う。
(もちろんディストリビューションがデフォルトの暗号スイートを変更するのを待つという手もあるのだが、)

しかし自分で暗号スイートを選択して設定するのは困難だ。
僕は暗号の専門家ではないのでどの暗号が危殆化してないかとか、どの暗号を使うのが最適かとかを適切に選択できる自信はない。
かといって、適当にGoogleで出てきたApacheのSSLCipherSuite設定をコピペするのも不安だ。

そんな心配を解決してくれるのは、BetterCrypto.orgというサイトである。
オーストリア版CERTの中の人が、最新の安全な暗号スイートを簡単に設定出来るように常にアップデートしてくれている。

ApacheのSSLCipherSuite設定にサイトに記載されている暗号スイートをコピペすれば簡単にPFSなどを設定出来る。

オーストリアのCERNの推奨する暗号がセキュアかどうか信用できないから、自分でセキュアかどうか調べたいという人は、CRYPTREC電子政府暗号推奨リストを参照するとよい。
CRYPTRECとは総務省・経済産業省・NICT・IPAで構成された暗号の安全性・実装性について客観的に評価する組織で、様々な暗号を電子政府推奨暗号(今使える暗号)・推奨候補暗号(今後使う可能性が高い暗号)・運用監視暗号(危険なので使ってはいけない暗号) (( 括弧内の表現は目安として書いただけに過ぎないので、分類の詳細はきちんとCRYPTRECのサイトを参照してください )) に分類してくれている。

セキュリティは沼なので逃げたくなるときもあるが、簡単に安全な設定をする方法(しかも安全性が検証された形で)が提示されはじめているので、そういう情報だけでもチェックしておくと良いのかもしれない。

HTTP/2における明示的プロキシ(Explicit Trusted Proxy)について

先日Jxckさんがセッションオーナーを務めた次世代Webセッション@CROSS2014に参加してきました。

セッションではSPDYやHTTP/2(その当時はまだHTTP/2.0だったかな)について主にリソース転送をどうよくするかについて話がされ、QUICなど”Post-TCP”な話も出て非常に興味深く楽しみました。
そこで「僕が考える次世代Web」というお題でブログを書けとJxck先輩から宿題をいただいて、何の話を書こうかなとずーっと思っていたのですが、最近のIETFの議論で個人的にはとても大切だと考えるトピックがあったので紹介+僕の思いを書きたいと思います。

[訂正]
私がドラフトを読み違えていたのが問題なのですが、このExplicit Proxyの仕組みはhttp schemeの場合だけ適用され、httpsでは適用されません。そのため、httpsについては引き続き安全だと言えます。
しかしこの通信が暗号化されるべきかべきでないかの情報も秘匿すべきという考えもあり、私個人の考えとしてはhttp/httpsいずれのschemeにおいてもALPN Protocol h2を用いた方がよいと考えます。

背景

NSAによるPRISMプログラムの発覚以降、インターネットを取り巻く状況は大きく変化しました。政府によりインターネットは監視され、end-to-endにおける暗号が再び注目されるようになり、Twitterがたとえ将来秘密鍵を政府に奪われたとしても過去の暗号通信を復号されないようにEphemeral Diffie-Hellman鍵交換を用いてPFS(Perfect Forward Secrecy)に対応した話などを目にしたことがあると思います。 ((PFSについての解説と、なぜPFSが重要かは、Lavabit 事件とその余波、そして Forward Secrecyに書いてあるので見てみてください))

更には先週IABとW3CによるInternet Pervasive Monitoring(大規模モニタリング)に関する共同ワークショップ STRINT Workshopが開催され、Opportunistic keying ((日和見暗号・Opportunistic Encryptionとも。httpsなどは暗号通信を行うことが明示的に同意されているが、httpなど明示的には暗号通信を行わない通信においてもエンド間が暗号を利用できる場合、暗号を利用することで安全に通信を行おうという考え)) について取り組もうという話が出るなどエンド間における暗号の重要性が高まっています。

話を戻して、HTTP/2の前身であるSPDYはTLSによる暗号化を必要としています。これは元々ファイアウォールやロードバランサーなどのmiddleboxがSPDYなどの未知のプロトコルをブロックするが、TLSはブロックされにくいことからTLSを用いたのが始まりでした。HTTP/2でもそれを受け継ぎ、TLSを利用してプロトコルのネゴシエーションを行っています。TLSを用いてmiddleboxによるブロックを防ぐということは、middleboxにより通信内容を解析されることが困難になることから、PRISM事件以降たびたびHTTP/2において暗号通信を必須とする提案(httpであったとしてもTLSを必須とする)がなされてきました。

TLS(暗号化)がなぜダメか

HTTP/2でTLSが必須となり、すべての通信が暗号化されることにより、弊害が生じるという意見があります。様々な理由により、http通信を”最適化”・”効率化”しなければならないという意見です。例えば、

  • ペアレンタルコントロール
  • ウィルススキャン
  • ISPが転送量を減らすためにCDNを展開していないWebサイトの画像や動画などをキャッシュ(Transparent Proxy)
  • モバイルネットワーク特に衛星網など遅延が著しい環境において、画像の圧縮などを行い高速化
  • モバイルにおいて加入者情報をコンテンツプロバイダに提供
  • 最適化広告
  • エンタープライズにおいて、従業員が機密情報を社外に送信していないか監視
  • ISPによる自主的・法的問わず、児童ポルノ・違法コンテンツの流通の監視
  • 政府による合法的な市民の検閲・監視(Lawful interception / 合法的傍受)

などの理由 ((詳しくはhttp2 Githubに記載されたProxy-use-caseを参照: Proxy User Stories · http2/http2-spec Wiki ))により、TLSによる暗号化をすべきでないという意見があります。

このような意見からHTTP/2ではTLSを必須とはしない決定がなされました。つまり、httpにおいては今までと同様に平文で通信が行われることになります。(もちろんhttpsではTLSを用いて暗号化されます)

Explicit Trusted Proxyの提案

httpでは平文を使うため、先に挙げた理由などでHTTP通信を”最適化”・”効率化”することは可能です。しかし、前回バンクーバーで行われたIETFでも大規模モニタリングはプロトコルに対する攻撃であり、プロトコルは大規模モニタリングに対して策を講じなければならないと決まる ((Pervasive Monitoring is an Attack: https://datatracker.ietf.org/doc/draft-farrell-perpass-attack/)) など、可能な限り暗号化もしくは安全なプロトコルを利用しようという動きは加速しており、HTTP/2においてもTLSは必須ではないですが、おそらく多くのコンテンツプロバイダーはhttpsを用いることが予想されます。

ほとんどの通信がTLSを用いて暗号化されてしまうと、先に挙げたHTTP通信を”最適化”・”効率化”することが難しくなってしまいます。そこでEricssonやAT&Tにより、TLSを用いていたとしてもユーザの明示的な同意があればプロキシによるMITM ((Man-in-the-middle: 中間者攻撃)) を可能とする提案(draft-loreto-httpbis-trusted-proxy20)がなされました。

HTTP/2ではTLSのALPN ((Application-Layer Protocol Negociation: 詳しくは@flano_yukiさんによるALPNについての解説を参照)) というメカニズムを用いてTLS上でどのプロトコルを使用するかネゴシエーションを行います。HTTP/2の場合クライアントはh2というIDを通信可能なプロトコルとしてサーバに提示することでHTTP/2で通信が行われます。提案ではクライアントはh2clrというIDを提示している場合、中間に存在するプロキシがそこで通信を終端し、ユーザの明示的な同意(SHOULD)の後、”最適化”・”効率化”を行うことを可能としています。

提案では中間に存在するプロキシはその際拡張キー利用法にproxyAuthenticationが含まれたSSL証明書を用いなければならないとされており、より高いセキュリティが必要な場合はEV証明書を使うことを推奨しています。

ユーザが同意しない場合、プロキシはTLSのClientHelloメッセージをサーバに送信することでサーバとクライアント間でTLS接続を終端するとされています。

ユーザの明示的な同意とは

公衆無線LANなどにおけるCaptive Portalの場合など、提案ではさまざまなケースについてどういうフローを取るべきか書かれています。

また提案では、ユーザが同意した場合、ユーザエージェント ((User-Agent: ブラウザのこと)) は同意したという情報を保存し、次回以降同意無しにプロキシに接続しなければならない(SHOULD)とされています。一方提案ではその同意は特定の接続に限定されなければならなず(SHOULD)、一定の時間もしくは一回のみに限定することができる(MAY)とされていますが、特定の接続についての定義については述べていません。

しかしユーザの明示的な同意とは何をさすのでしょうか?

例えば「お客さまの通信速度の向上のため、通信の最適化を行います」と表示されたら大抵のユーザは同意ボタンを押すでしょう。しかし、本当に行っているのは安全なはずの暗号通信をman-in-the-middleする以外の何者でもない話であり、ユーザがhttpsで、アドレスバーが緑色だから安全と信じて入力したパスワードやパーソナルデータは実は”通信の最適化”のため中間者によって復号されているわけです。そして一度同意してしまったら明示的に設定をオフにしない限り、安全であるはずの通信が第三者によって見られ続けることになります。

また同意がプロキシ側で行われるのは更に問題です。この提案ではコンテンツプロバイダー側がプロキシを禁じることはできないため、プロキシが攻撃された場合ユーザ・コンテンツプロバイダー双方が気付かない間に情報が盗まれる可能性があります。

僕はこれは極めてunhealthyだと思います。

httpsを使う限り安全である ((PRISMの例や、httpsでも弱い暗号を使っていて第三者に解読される場合などはありますが)) 通信が、httpsを用いていても安全ではない、安全かどうか確認することが非常に煩雑になってしまいます。これではHTTP/2はHTTP/1.1に比べて後退してしまいます。

じゃぁどうすればいいの?

通信の秘密・言論の自由は憲法・電気通信事業法で保障された国民の権利です。一方子どもの権利は優先されるべき権利であり、それらを犯す児童ポルノなどを規制しなければならないことも理解できます。どちらも僕らの社会を支えるとても大切な権利だと信じています。

僕自身答えは持ち合わせていません。

いくつかのユースケースに対しては他のアプローチにより問題を解決することは出来ます。たとえば、キャッシュの問題ではキャリアがCDN-likeなサービスを安価で提供し、コンテンツプロバイダーが利用することで暗号化されるべき情報のみコンテンツプロバイダからサーブされ、画像などはCDNから配信するようなアプローチです。

しかしHTTP/2の持ち合わせるパフォーマンス改善など華やかな部分が取りただされている間にこの提案がなされ、静かにしかし確実に僕らのインターネットを変化させようとしていることを見逃してはいけないと思っています。

この問題はHTTP/2だけではありません。たくさん議論をしても皆が納得する結論を導くのは難しいと思っています。

コメント欄でもTwitter上でもかまいません。いろいろな意見をいただけるとうれしいです。

Natashaもこの問題を英語でも書いてくれています
Pervasive Monitoring, HTTP2, TLS: Why Can’t the User Decide?

免責事項

  • この記事は私の視点であり、所属するいかなる組織の意思を示すものではありません
  • 私はネット中立性・インターネットの自由・通信の秘密・表現の自由を支持しています

JALの国内線で機内WiFiが使えるようになる話

2014年夏から国内線でも機内WiFiが使える様になるそうだ! ((国内線においても「JALの新しい空 」が始まります – https://www.jal.co.jp/inflight/dom/new_seat/))

JALの国際線では去年の夏から機内WiFiが使える様になってすごく便利なんだけど、機内WiFiは主に2つの方法で航空機と地上とを結んでいるので紹介。

  1. Kuバンド帯を使った衛星による通信
    Kuバンドという衛星通信でよく使われる周波数帯(12-18GHz)を用いて航空機と衛星、衛星と地球局(つまり地上)と結んでインターネット接続を可能にする方法。
    この方式だと衛星に接続出来る範囲(要リサーチ)がかなり広いので、ほとんどのエリアをカバーすることが出来る。 ((ただ成田-ニューヨークでも3,4個の衛星をハンドオーバーしてるらしい – https://www.ituaj.jp/wp-content/uploads/2013/04/2013_05-3_spsky.pdf))
    欠点としては衛星を経由するのでコストがかかる。(衛星の資源は限られてるからね)
    そして地球局はあまり分散されていないので、インターネットネットワーク的に不効率な場合が多い。
    例えばJALやトルコ航空などはT-mobile DEを地球局にしているので、日本の上空に居ても
    [航空機]-[衛星]-[地球局(ドイツ)]-[日本のWebサイト]
    みたいになって通信が非常に遅くなる。
  2. Air-To-Groundによる通信
    これは衛星を使わずに航空機と地上を結びインターネット接続を可能にする方法。
    簡単に言ってしまうと地上にアンテナを設置してそれと航空機が通信する感じ。
    今回JALが提携したgogoはATG-4というネットワークを米国国内に展開していて、160以上の基地局を設置している。
    航空機と基地局の間はEV-DO Rev.B(つまりCDMA-2000)で繋がっている。まさに携帯電話の電波を空に向けて出しているような方式。
    これだと衛星を使わずに済むので、安価にネットワークを作ることができる。
    しかし海上などでは基地局を設置できないのでネットワークを作ることが難しい。

今回JALがgogoと組んだので、てっきりATGでネットワーク組むのかと思ったのだが、中の人からリプライ貰ってどうもKuバンドで組むらしい。海や山が多い日本では基地局を設置するよりも衛星の方が良さそうですよね。 ((https://twitter.com/Gogo/status/394880907003580416))

どちらの方式にもメリット・デメリットがある。
アメリカのような国ではATGは良さそう。海が多い国では衛星。

飛行機に乗ってる間ぐらいしかオフラインになれないのにネット導入するとはむきー!!っていう話も非常に理解できるんですが、個人的にはネット有れば機内で暇にならないので早く導入してほしいなと思っています。

p.s.
ところで青い航空会社はいつになったら国際線に機内WiFi導入してくれるんだろう。。。
一応2013年の夏導入開始って話らしいんだけどね。。。げほげほ ((ANA国際線機内で、Wi-Fiサービスがご利用できるようになります – http://www.ana.co.jp/pr/12_0406/12-ana-onair0625.html))
あ、なんか特定の便ではロールアウトしてるって話も聞くけど中の人こっそりおしえてください。