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

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

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

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

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

方法

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

免責事項

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

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小田急線で全くというほど使い物にならないのだけど(というか動いてると小田急線だけじゃなくダメ)、後継機に乗り換えたら使い物になるのかな？

先日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?

免責事項

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