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では所属する機関の学生・教職員が持つクレデンシャルを利用して認証を行うため、個人や所属機関が特定されてしまうと言う問題1 がありました。その問題を解決するため学認では一時的に仮名のクレデンシャルを発行する仮名アカウント発行システムというシステムを運用しています。

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

方法

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

免責事項

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

  1. 例えばhogehoge@sfc.keio.ac.jpというアドレスで認証すればSFCに所属しているのがわかってしまいます []

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ポストも参考にリンクしておきます。

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

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

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

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

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

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

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

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

  1. 括弧内の表現は目安として書いただけに過ぎないので、分類の詳細はきちんとCRYPTRECのサイトを参照してください []