技術を肴にご飯を食べた 〜 SSL/TLS本、技術書典2、DroidKaigi、ElixirConf、IPv6 〜

先日あきみちさん、鹿野さんと一緒にご飯を食べたときの話が面白かったのでブログに残しておきます。

あきみちさん、鹿野さんには、以前ツチノコブログに寄稿をしてもらっていて、どれも人気エントリになっております。

あきみちさんが寄稿してくれた記事一覧
http://tsuchinoko.dmmlabs.com/?author=14

鹿野さんが寄稿してくれた記事
技術書、それも売れるやつを書きたい人へ、編集者からのアドバイス
http://tsuchinoko.dmmlabs.com/?p=2303

人気エントリになると書くほうも、やったぜ、と感じるんだけど、実際にはそうそうバズることはないんだよねえ。
鹿野さんに、どうすればバズるの?、とつぶらな瞳で聞いたら、「編集者がいたほうが良いですね、ちょっと手直しをするだけで読みやすくなりますよ」と一流の編集者らしい返答。
そ、そうか、なるほど。

 

で、その編集者が出版社を起業して最近出版したばかりの本を見せてもらったら、これがとても良い本なんですわ。


プロフェッショナルSSL/TLS(紙書籍+電子書籍)
https://www.lambdanote.com/collections/frontpage/products/tls

まず、序文がグっとくる。

本書の執筆には2年ほどかかりました。

私が時間をかけた分、読者のみなさんの時間は節約できます。
私がSSL/TLSとPKIの調査に膨大な時間を割くようになってから5年ほどたっていますが、そんな時間を誰もが確保できるわけではありません。
この本には、私が知っていることの中でも特に重要な内容を詰め込んでいるので、読者はわずかな時間で同じ内容で理解してもらえるでしょう。

で、中身をペラペラめくってみたら、理論、基礎、実装、問題点、運用、具体的な設定、が事細かに書かれてる。
これは買うしかないよなあ、と家に帰ってポチりましたよ。
ちょいと高いけど、短縮される時間を考えると、まあペイできるんじゃないかな、と。

ソニーデジタルペーパー DPT-S1という端末で見せてもらったんだけど、これがまた良い端末なんですよ。
薄い、軽い、デカい。
プロはやっぱり良い道具を使っている。

ソニーデジタルペーパー DPT-S1
http://www.sony.jp/digital-paper/products/DPT-S1/

とはいえ、値段が高くて、今は販売終了してるとのこと。
世の中、良いものが売れる、というわけではないね。

(ちなみにでっかい端末じゃなくて手元のKindleでもちゃんと読めました)

 

この本の紙版は4/9に開催される技術書典2でも販売される予定とのこと。
面白そうなので私も顔を出すつもりでいます。

技術書典2
https://techbookfest.org/event/tbf02

技術書典は、TechBoosterと達人出版会の共催で、TechBoosterの代表はDroidKaigiの主催もしている@mhidakaさん。

TechBooster
http://techbooster.org/

DroidKaigi 2017
https://droidkaigi.github.io/2017/

DroidKaigiでは、CONBUがWiFiネットワーク構築を担当させてもらったよー、という話をしたら、鹿野さんもTechBooster関係者だったことが判明。
世の中狭い。
(CONBUはカンファレンスのネットワークを構築する団体でDMMも活動に協力しています)

DroidKaigi & ElixirConf への協力とCONBUプロジェクトメンバ (Droid Kaigi & ElixirConf) 募集のお知らせ
http://conbu.net/info/droid2017/

 

同じメンバーで、4/1(明日!)に開催されるElixirConfでも、WiFiネットワーク構築もすることになっているんだけど、Elixirはマニアックな言語のはずなのに思ったより人が沢山来るみたいで正直ちょっとびっくりしている。

ElixirConf 2017
http://www.elixirconf.jp/

マニアックポイントは以下。

  • ErlangのVM上で動作する(Erlangがマニアック)
  • 関数型言語(関数型ってのもマニアック)
  • 並行処理が得意(並行処理ってのもマニアック)

そんな話をしたら、鹿野さんが、日本のErlang本は全部関わってるんと思う、みたいなことを言うわけですわ。
世の中狭い&すげー。
鹿野さんによると今のElixir人気は、Phoenix人気じゃないか、とのこと。
RubyがRailsでブレイクしたのと同じことが起きているらしい。
なるほどねえ。

参考になりそうなURL
[翻訳] Railsの弟、Phoenix Frameworkで遊ぼう
http://qiita.com/HirofumiTamori/items/316e746948014cfa16e4

 

その鹿野さんがあきみちさんと今度一緒に作ろうとしてるのが、IPv6の教科書。
IPv6はもう実際に使われている技術ではあるんだけど、実際に付き合ってみると、意外と難物なんだよねえ。

  • RFCが沢山ある
  • アップデートが沢山ある。
  • 古くなった情報、間違った情報も残っている
  • デュアルスタックはトラブルシュートがむずかしい
  • IPv4を完全に置換できない
  • 実装がOSによってかなり違っている。
  • DHCPv6サーバとRDNSSサーバを両方用意する必要がある

新しい正しい情報が整理整頓されている本、というだけで手に入れる価値があると思うぞ。
近日中に情報公開されると思うのでそれをお待ちくださいませ。

(4/7追記)
情報公開されました↓
https://www.makuake.com/project/ipv6/

それにしても、Androidが、かたくなにRDNSSだけを使うのはなんとかならないものかしらねえ。
DHCPv6を使いたくない気持ちも理解はできるんだけど、AndroidがDHCPv6を使うようになれば、RDNSSの仕組みを用意しなくても良くなるのに。

 

あとは、DNSがいけてない話とか、身体の動かし方の話とかもしたかな。
いろいろ技術的に面白い話を肴に楽しい時間を過ごせるのは幸せなことだなあと思いました。
花見シーズン到来ですね。
気軽にお誘いくださいませ♪

日経NETWORKの手作りネット構築の便利ツールで取りあげられなかったもの 〜手段が目的になってはいけない〜

あけましておめでとうございます。実は今年初のブログです。
本年もよろしくお願いします。

先日CONBUの一員として取材を受けた内容が、日経NETWORKの最新号の「ネット管理のお助けツール」という特集記事で取りあげられています。

日経NETWORK2017年3月号
http://ec.nikkeibp.co.jp/item/backno/NN0203.html

我々が紹介した、手作りネット構築の便利ツール、は以下になります。

  • 譜面台
  • トランシーバーアプリ
  • 静電気で貼り付くホワイトボードシート
  • カーペット用ケーブルガード
  • マグネットフック
  • ゴムシート
  • 六輪台車
  • 隙間用LANケーブル
  • はがしやすいラベルシール
  • 360度カメラ
  • 面ファスナーテープ
  • 深めの折り畳みコンテナー
  • タグ付きのケーブルバンド
  • 外付けのNIC
  • 無線LAN調査機器

ネットワーク技術情報紙とは思えないものが並んでますね。
場違い感半端ない感じです。
でもそれぞれ便利なんですってば!!
便利そうなグッズを街で見かけたら、それどこで買ったの?、その道具の名前は何?、と遠慮せずに聞いちゃうのが情報集めのコツです。
深めの折り畳みコンテナは電車の中で釣りに行くおじさんからアイリスオーヤマで買えることを教えてもらい、スーパーマーケットの中の人に六輪台車の品名を教えてもらいました。

実際にこれらの道具が使われている様子は、CONBUがお手伝いしているイベント会場で見ることができますので、良かったら足を運んでみてくださいませ。

直近だと、DroidKaigi 2017、Elixir Conf Japan 2017 でお手伝いをさせていただきます。

DroidKaigi 2017
https://droidkaigi.github.io/2017/

Elixir Conf Japan 2017
http://www.elixirconf.jp/

 

残念ながら紙面に載ってないけど使うと楽しい道具は他にもあります。
過去のツチノコブログにも登場したモノを2つほど上げておきます。


ガフガン(GAFFGUN)

長いケーブルを一気に床養生できる凄いヤツです。

ケーブル養生の秘密兵器、GAFFGUNを使ってみた
http://tsuchinoko.dmmlabs.com/?p=1708

CONBU ライブ設営 @ YAPPC:Assia Tokyo 2015
https://www.youtube.com/watch?v=C8KR9W5JPfQ

大きめの会場で長い距離を一気に養生するときにはとても便利なんですよね。

とはいえ問題点がいくつかあるので、今回の紙面からは落選しました。

  • 使うのにちょっとコツがいる。
  • ベタっと貼られちゃうので撤収がしにくい
  • 床養生禁止の会場等もあり、使える場所を選ぶ
  • 面養生が必要なケースはそれほど多くない
  • 人が通るような場所をしっかり養生する場合にはゴムシート等の別の道具で養生するほうが良い
  • 使ってると楽しくなってきちゃって、使うことが目的になってきちゃう。

ウォーキングメジャー

コロコロ転がすと距離が測定できる道具です。

ツチノコNOC JANOG39会場下見に行ってきました
http://tsuchinoko.dmmlabs.com/?p=4877

ツチノコNOC〜会場ネットワーク構築下見編〜
http://tsuchinoko.dmmlabs.com/?p=4839

これも以下の理由で今回の紙面からは落選してしまいました。

  • 会場から提供される図面に距離がきちんと入っていることが多く測定が必要ないことが多い
  • 使ってると楽しくなってきちゃって、測定に夢中になって他の大事なことを見落としちゃうことがある。

使って楽しい道具のほうがもちろん良いのですが、楽しすぎて手段が目的化しちゃうのは良くない、ってことですねえ。
我々は使って楽しい便利な道具を引き続き募集中です。

なぜスマホの位置情報は狂うのか調べてみた

くまがいです。CROSS2016 ご来場ありがとうございました。大盛況で楽しかったですね。会場無線 LAN を CONBU で提供していましたので、繋がらない報告がないか Twitter を追っていたら、こんな投稿を見つけました。

WiFi繋いだら現在地が秋葉原になってる #cross2016

CROSS2016 は横浜ですので、位置情報がおかしいですね。

Wi-Fi測位のしくみ

スマホが現在位置を取得する方法のひとつとして、Wi-Fi の BSSID(MACアドレス) を利用したシステムがあります。端末は、周囲に見えている Wi-Fi の BSSID をサーバに送りつけます。するとその BSSID に対応した位置が返ってきます。

簡単な仕組みですが、これを世界中で実現させるには途方もない労力が必要です。位置とそれに対応する BSSID のデータベースを構築するには、測位したい全ての場所へ行って無線 LAN を受信する必要があり、今後も更新していかなければなりません。

スマホが Wi-Fi AP の位置情報を収集している

Skyhook Wireless(2010年頃以前の iOS での利用で有名)は、ウォードライビング、車で移動しながら無線 LAN を受信することによってデータベースを構築したといわれていますが、現在 Google や Apple は、この情報収集をスマホユーザ自身にやらせています。

たとえば iOS では、近くの Wi-Fi アクセスポイントの情報とその位置を端末に保存しておき、定期的に Apple へ送信しています。

Apple は Wi-Fi 測位に関する API や、誤った位置情報の修正、オプトアウトの手段などの情報を公開していません。iOS 8 および iOS 9 のプライバシーと位置情報サービスについて の「Wi-Fi と基地局の位置情報のクラウドソーシングデータベース」で何をやっているのか書かれていますが、これ以外の公式情報は見つけられませんでした。

本当のところ何を送ってるんだろう

ここまでは比較的広く知られていることかもしれません。が、具体的にどのような情報がやりとりされているのかはあまり知られていません。

試しに、手元の iPhone がどんな情報を送っているのか観察してみようと思います。使ったのは (iPhone5s, iOS8.2.1), (iPhone5, iOS9.2.1), Burp Suite 1.6.32 です。ちょっと古い理由は特になく、たまたま手元にあったからです。

観察・収集編

我々の iPhone で収集された Wi-Fi と位置データが Apple のサーバへ送信されていく様子です。
pbcwloc_270_01
おっ、何か MAC アドレスっぽいものを送っているのを見つけた!?

pbcwloc_270_02
うわー! バイナリかよ、解散~ と思いましたがこれは Protocol Buffers でシリアライズされた何かのようです。JSON や XML のような人間にやさしいエンコーディングではないため一瞬諦めそうになりました。

Protocol Buffers はバイナリエンコーディングのシリアライズフォーマットで、データ構造はエンコーディングに含まれません。データ構造は別途 IDL(インタフェース定義言語) の .proto で定義して使うもので、エンコードされたデータからはデータ構造がよくわからないのです。

ちょっと .proto をでっち上げてみました。中を見ても何だか分からない項目がいっぱいあります。いくつかは iOS7 か 8 で増えたようです。

message WiFiAccessPoint {
  required string bssid = 1;
  optional int32 channel = 2;
  optional int64 signal_dbm = 3;
    message Location {
      required double latitude = 1;
      required double longitude = 2;
      optional int32 unknown3 = 3;
      optional int32 unknown4 = 4;
      optional int32 unknown5 = 5;
      optional int32 unknown6 = 6;
      optional int32 unknown7 = 7;
      optional int32 unknown8 = 8;
      optional int64 unknown9 = 9;
      optional int64 unknown10 = 10;
      optional int32 unknown11 = 11;
      optional int32 unknown12 = 12;
    }
  optional Location location = 4;
  optional string application = 5;
  optional int32 unknown7 = 7;
}
message SmartphoneToAppleRequest {
  repeated WiFiAccessPoint ap = 3;
}

実をいうと、このメッセージは2013年頃(iOS6.0)に一度解析したことがあります。それを使って、今回のブログで気楽なネタにしようと思ったら、内容が丸ごと変わっていて全然気楽じゃありませんでした!!!

この .proto でデコードしてみたところ、以下のような内容を Apple へ送信しているようです。

ap {
  bssid: "74:3:bd:28:xx:xx"
  channel: 4
  signal_dbm: -89
  location {
    latitude: 35.6897295965
    longitude: 139.770113602
    unknown10: -1
    unknown11: 7
    unknown12: 0
  }
  application: "com.google.Maps"
  unknown7: 0
}

このケースでは、収集した約300個の BSSID が Apple へ送信されたのを観察できました。無線LANについては BSSID, チャネル、電波強度らしきものが送信されていて、SSID は送信されていないようです。_nomap は考慮されていないようで、ssid_nomap という SSID を出してみたところ普通に送信されていました。Apple に関しては _nomap は効いていないようです。

lat/lng の座標以外には、位置情報をリクエストしたであろうアプリの Bundle ID らしきものが入っています。自分の場合は他に com.protogeo.Moves や com.google.ingress などが入っていました。

その他に、端末の機種名と OS のバージョンも送っていますね。端末を個別に識別するようなものはなさそうです。HTTP ヘッダにも怪しいものはありません。認証もなく、匿名で突然送りつけているようです。

位置情報が狂う原因

AP を持ってオフィスの引越しをすると、引越し前の位置が表示されてしまうことがあります。オフィスに設置していた AP の BSSID に対応する位置情報が更新・収集されていないのが原因ですが、オフィスはともかく、最近は個人宅ではあまり聞かない現象のように思います。なぜオフィスの引越しでよく起こるのでしょうか?

オフィスには複数の AP があり、複数の BSSID が受信できるとします。すると、引越し以前から近隣にある AP よりそれらを優先して使われてしまうのかもしれません。また、都心のオフィスでは空が開けていない場所が多く、GPS の電波が受信しにくいため、BSSID と位置情報が更新されにくいのかもしれません。

更新に関しても、端末の識別もなく収集しているため、ある程度のデータが溜まって確信度が高くならないと有効にならないはずです。

収集されたデータがどのように運用されているのかは調べようがなく、曖昧な記述になってしまいましたが、きっと大きく外してはいないと思います。

観察・利用編

普通に現在位置を取得するパターンです。iOS で現在位置を取得するアプリ(ここでは Google Maps)を起動してみます。

clls_01_03
BSSID らしきものを送っていますね。これらの BSSID は確かに現在、周囲に見えているものです。

clls_02_03
位置情報が含まれたレスポンスが返ってきました。結構大きいようです。送った BSSID の他にも大量に何かがくっついています。例によってバイナリですが、これも Protocol Buffers ですので解析してみます。

でっちあげた .proto です。

message WiFiAccessPointResp {
  required string bssid = 1;
    message Location {
      required int64 latitude = 1;  // * 10e-9
      required int64 longitude = 2; // * 10e-9
      optional int32 unknown3 = 3;
      optional int32 unknown4 = 4;
      optional int32 unknown5 = 5;
      optional int32 unknown6 = 6;
      optional int32 unknown7 = 7;
      optional int32 unknown8 = 8;
      optional int32 unknown9 = 9;
      optional int32 unknown10 = 10;
      optional int32 unknown11 = 11;
      optional int32 unknown12 = 12;
    }
  optional Location location = 2;
  optional int32 channel = 21;
}

message AppleToSmartphoneRequest {
  optional int32 unknown1 = 1;
  optional WiFiAccessPointResp ap = 2;
  optional int32 unknown3 = 3;
  optional int32 unknwon4 = 4;
}

message AppleToSmartphoneResponse {
  repeated WiFiAccessPointResp ap = 2;
}

収集編での構造と同じかと思いきや微妙に違う………。lat/lng は float じゃなくて固定小数点に変わっているしタグもずれています。。これも 2013 年頃解析したものとは違います。

デコード結果は以下です。

ap {
  bssid: "10:6f:3f:6:xx:xx"
  location {
    latitude: 3565078352
    longitude: 13972113022
    unknown3: 42
    unknown4: 0
    unknown5: 21
    unknown6: 14
    unknown11: 62
    unknown12: 69
  }
  channel: 3
}

位置情報を取得するのに送信した周囲の BSSID の位置情報は、このようにして返ってきました。lat/lng 以外にも何かついてきているようです。

このケースでは、リクエスト時に BSSID を複数(12個)送信しています。レスポンスには、リクエスト時に送信した BSSID 以外にも周辺の BSSID と位置情報が100個ほど含まれていました。iOS, locationd がこのレスポンスから実際の位置情報をどのように計算しているかはわかりません。

BSSID から位置情報を取得したいならもっと簡単な方法がある

Apple のこれを使えば BSSID から位置情報を取得できる!と思うかもしれませんが、そんな面倒でグレーなことをしなくても、もっと簡単で正当な方法があります。

Google Maps Geolocation API で BSSID から位置情報を取得できます。
geolocation
ブラウザからも使われています。

プライバシーの問題

Wi-FiのMACアドレスはもはや住所と考えるしかない 高木浩光@自宅の日記 2011年11月26日

個人で設置している AP の MACアドレス(BSSID) から位置情報が引けるとなると、BSSID は住所に相当するのではないかという指摘があります。これに対し、Google Maps Geolocation API は「2つ以上のBSSIDが含まれないリクエストでは位置情報を取得できない」としています。

The request body’s wifiAccessPoints array must contain two or more WiFi access point objects. macAddress is required; all other fields are optional.

特定の BSSID から位置を調べようとした場合、その近隣の BSSID なんて事前に分からないので、位置情報が取得できません。これで多少は安全になります。一つの AP が複数の BSSID を吹いているなど、推測されやすい状況はありえますが。

結論

一般的に AP が設置されてもすぐに位置情報に反映されるわけではありませんが、カンファレンスやイベントなどで一時的に設置された AP でも、その情報がたくさんの来場者のスマホから送信されてしまい、それなりに確信度の高い位置情報として扱われてしまうのかもしれません。AP は複数台設置されるため、測位の場合でも優先されてしまうのかもしれません。

今回は Wi-Fi 測位のみを扱いましたが、その他 GPS(GNSS)や携帯電話基地局での測位とハイブリッドになっていることがほとんどであり、その挙動は多様です。大きく位置が狂うことが有り得るのは Wi-Fi 測位の特徴といえます。

他の測位手法については、他の機会に触れたいと思います。
それと Android も調べたかったのですが力尽きました。

YAPC::Asia Tokyo2015 の会場ネットワークをCONBUが構築しました

まだまだ新人ツチノコのkumaです。CONBUの一員として参加してまいりました。

Perl…に限らないエンジニア達の巨大な祭り YAPC::Asia 2015 が東京ビッグサイトで開催されました。CONBUは会場ネットワーク構築を担当しました。

同時接続数 約1,200,通算接続端末数 約3,600, UTP配線長約1.6km, アクセスポイント約36台。会場の広さもさることながら、各トラックの部屋がほぼ立ち見の満員御礼で、無線LAN環境としてはハードなものでした。さらにこれらを設営する時間はわずか90分弱、非常にハードでした。事前にAPと譜面台とUTPケーブルのキットを作っておき、よーいドンで一気に配備とケーブルの養生ができるようにチームを計画しました。

LT

動画を、音声ありでごらんください!

Day2のLTでCONBUの設営&撤収デモを行いました。LTが始まってCONBUの紹介後、号令とともに大勢のCONBUスタッフが舞台袖から一斉に出現、舞台上に無線APをライブ設営するという前代未聞のLTで、会場は一気に沸き上がり、一時 Twitter のトレンド入りも果たしたようです。

APIとヒートマップ

assoc-6f-7f
各アクセスポイントごとの接続端末数やトラフィックを眺めていると、来場者の動きがつかめます。たとえば、このグラフ(zabbix)は ある時間帯の 7F, 6F の接続端末数です。縦軸が接続端末数、横軸が時間です(色は各アクセスポイントごと)。最後のメインホールでのセッションが終わると、来場者はホールを出ますので 7F ロビーの接続数がいったん増え、さらに6Fへ移動していくのがわかります。東京ビッグサイト会議棟の構造は上から 7F → 6F → 長いエスカレータ → 2Fとなっていて、いったん6Fを経由するのです。

こういった数値をAPIとして提供し、自由に可視化できたら面白そうだと、つねづね思っていました。手が空いたら片手間に作ろうと思いつつ、毎度ネットワークの構築で手いっぱいになってしまっていたので、今回は片手間ではなくAPIチームを結成してちゃんと作りました。

会場ネットワーク情報取得API「CONBU-API]について

会場毎+AP毎に接続端末数を返すシンプルなAPIです。会場のどこにアクセスポイントが設置されているかを公開していますので 、その付近にどれくらいの端末が接続されているかを見ると、その付近におおよそどれくらいの人がいるのかわかります。

heatmap_sequence
ヒートマップとして可視化したものを、試しにアニメgif化してみました。Day1 の6Fのセッションがクローズし7Fの大きな会場へ来場者が集まっていき、やがて7Fもクローズし懇親会会場へ降りてゆく様子が見えます。

トラフィックもAPIとして提供できれば、Network WeatherMap のような可視化、あるいは、より高精度なヒートマップも実現できそうです。

カンファレンスネットワークの作り方

CONBUよりカンファレンスネットワークの作り方というトークをさせていただきました。CONBUの裏側、カンファレンスネットワークを作ってみたい方、API をいじってみたい方、ご参考にしていただければ幸いです。

トークの感想

実は… 個人的には、聞きたいと思っていたセッションのリストも事前になんとなく考えていたのですが、やはり当日はCONBUで手が空かず、無線状況の測定中に聞くのが精一杯でした。動画が上がるのを心待ちにしております!!

Blogに書くまでがYAPCです。YAPCは無事終了しました。次は 9/5 LL Ring Recursive だ!!

YAPC::Asia Tokyo2015 カンファレンス無線ホットステージ

去年のYAPC::Asia Tokyo2014 に引き続きまして 、明日より三日間 YAPC::Asia Tokyo 2015 が開催されます。なんと東京ビッグサイトでの開催です!
 YAPC::Asia Tokyo 2015 の会場で無線LANを提供する CONBU さんのホットステージの模様を一部お伝えします。ブロードバンドタワーさんのご好意により、会議室をお借りできました。

DMM.com ラボ は YAPC::Asia Tokyo 2015 へ協賛しています。
DMM.com ラボはカンファレンスネットワークを構築するチーム CONBU さんを応援しています。

でも今年は都合でDMMかき氷はありません。ごめんなさい!