ゆきのぶ日記

■ [写真]今日の一枚「雪の日」

雪の夜なんてのは、D90 も性能的にいっぱいいっぱいな感じだ。

■ [写真]今日の一枚「城南島海浜公園から飛行機を狙う」

羽田空港の近くにある城南島海浜公園は、飛行機の有名な撮影スポットらしい。天気も良かったので今日はそこに自転車を走らせた。

500枚くらい撮ったのだけど、わりとマシなものを一つ。飛行機は詳しくないけど、ジェットエンジンが4つあるので747だろうか。メジャーな路線のはずなので、行先は大坂か千歳か福岡か。

■ [iPhone]iPhoneの充電は電源環境を選ぶ

ここ数日、iPhoneの充電で試行錯誤していたのでメモ。どうやらiPhoneの充電は電源環境を選ぶらしい。

いわゆる USB-ACアダプタを使っての充電を試みたのだけど、電源環境とアダプタの組み合わせよって、充電できる場合とできない場合があった。ケーブルの問題やアダプタの問題を疑っていたので試行錯誤が長期化してしまったけど、まとめると上の表のようになった。

最初、何の疑問も持たずにアダプタAを出先に持って行くも、充電できず。調べてみると充電には大きな電流が必要という話を見つけた。そう考えると確かに500mAではダメだと思い、次の日はアダプタBで、自宅で充電できることを確認してから持ってったが、それでもダメ。もう呪われているんじゃないかと思い、最後に純正アダプタ（iPhone付属品）を持って行ったら、今度は充電することができた。

聞くところによると出先は、電力量がギリギリらしいので、電圧が低下しているなどの良くないことが起きているのかも知れない。そんな中でも平気で充電できる純正品はスゴい。高価なだけのことはあると思った。

■ [iPhone]PoptopでiPhoneのためのVPNサーバを作る

LinuxをiPhoneのためのVPNサーバにしたので、メモ。

動機

出先のWiFiを安心して使うことを目指す。

iPhoneを契約して気がついてみると、BBモバイルポイントやlivedoor WirelessなどのWiFiサービスを無料で使える状態になっていた。これらのサービスはスピードが速くて良いんだけど、セキュリティ的に不安が残る。

iPhoneがWiFiでどんな通信をしているのかは調べてないけど多分、契約者固有IDや、ウェブサービスのセッションIDやパスワードが飛び交っているんだろう。そう考えると、そう言う情報を誰でも見られる*1WiFiを安心して使うことはできない。少なくともTwitterのような、認証を伴うサービスを利用するのは怖すぎる。そこで、自宅までをVPNで接続し、全ての通信をVPN経由にすることで、自宅程度の安全性で通信できるようにしようと思った。

ソフトウェア

PPTPに対応したPoptopをrpmでインストールした。

サーバの設定

Poptopをインストール後、次の設定をした。

/etc/pptpd.conf

localip 192.168.10.1
remoteip 192.168.10.11-200

IPアドレスに関する設定。使っていないIPアドレスを適当に割り振る。

/etc/ppp/options.pptpd

ms-dns 192.168.0.1
ms-wins 192.168.0.1

こちらで用意したDNSサーバをに誘導。WINSは要らないかも知れないけど一応。

/etc/ppp/chap-secrets

OLn5QsekjoOp    pptpd   "mAjh5QRcCyOs8WlF"      *

ユーザを追加。わが家のポリシーでは、ユーザ名もランダム文字列。上記に例示したアカウントは、実際のものとは別。

iptables周り

iptables -A INPUT -i ppp+ -s 192.168.10.0/24 -j ACCEPT
iptables -A FORWARD -i ppp+ -s 192.168.10.0/24 -o eth0 -d 192.168.0.0/24  -j ACCEPT

LAN内へのアクセスを許可。

iptables -A FORWARD -i ppp+ -o ppp0 -s 192.168.10.0/24 -j ACCEPT
iptables -A FORWARD -i ppp0 -o ppp+ -d 192.168.10.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.10.0/24 -j SNAT --to-source 61.192.163.51

インターネットに出ていくための設定。

/var/named/chroot/etc/named.conf

acl "internal" {
        localhost; 192.168.0.0/24; 192.168.10.0/24;
};

DNSサーバのACLにも、忘れずに追加。

iPhone側の設定

今回の目的を達するには、「すべての通信を送信」をオンにするのがポイント。

■ [写真]今日の一枚「踏切」

東京スカイツリーの麓にて。

■ [写真]今日の一枚「小料理屋」

Fotografia さんに触発されて撮った。50mm F1.4D なので、使っているレンズはかなり近いのではないか。

■ [写真]今日の一枚「呑も呑も」

よく呑んでいる人たちに捧ぐ

でも、呑みすぎない方が良いのだけは確か。

■ [写真]今日の一枚「雪の日」

雪が降っていた。

■ [写真]今日の一枚「ラーメン」

ラーメンうまうま。

■ [写真]今日の一枚「麗しきハイウェイ」

屋形船の船上より。

■ [セキュリティ][iPhone]iPhoneアプリケーションを出先のWiFiで安全に使えるか調べた（App Store, メール, TwitBird）

iPhone を買ってはや数週間。その利便性たるや凄まじいもので、もはや iPhone なしでは生活が困難になりつつある。

通信回線は、自宅では WiFi を使い、出先では 3G もしくは WiFi を使っている。WiFi の方が快適なので積極的に使いたいが、出先の WiFi*1 は通信を覗かれているかも知れず、あまり安心して使えるものではない。VPN がその解決策になることを以前に書いたが、誰にでも実現できるものではないし、別の方法も探っていきたい。

個々のアプリケーションが、暗号を適切に使った通信をしていれば、VPN は考えなくてよくなるので、調べてみた*2。

App Store

決済情報ともダイレクトに繋がっている App Store。通信が安全でないと、iTunes アカウント不正利用*3の原因にもなりかねないが、どうだろう。

ax.init.itunes.apple.com へのリクエスト

最初の通信は ax.init.itunes.apple.com への HTTP GET リクエストだった。サーバからのレスポンスには Content-Encoding: gzip とあり、通信回線の細さへの配慮が見られる。

GET /bag.xml?ix=2 HTTP/1.1
Host: ax.init.itunes.apple.com
User-Agent: iTunes-iPhone/3.1.3 (3)
Accept-Language: ********
Cookie: ********
X-Apple-Store-Front: ********
X-Apple-Connection-Type: ********
X-Dsid: ********
X-Apple-Client-Application: ********
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive

HTTP/1.1 200 OK
Content-Type: text/xml; charset=UTF-8
x-apple-application-site: ********
X-Apple-Partner: ********
Vary: Accept-Encoding
x-webobjects-loadaverage: ********
x-apple-aka-ttl: ********
x-apple-application-instance: ********
x-apple-request-store-front: ********
x-apple-max-age: ********
Content-Encoding: gzip
Cache-Control: max-age=9519
Date: Wed, 24 Feb 2010 15:45:52 GMT
Content-Length: 9369
Connection: keep-alive

（略）

以降の通信は暗号化

その後 TLS セッションが、暗号方式 TLS_RSA_WITH_RC4_128_MD5 にて確立された。この暗号方式は CPU 負荷の観点から有利らしい*4が、電子政府推奨暗号リストにない要素も含まれている。現時点において、この暗号方式が危険とは言えないが、AES を使ってくれても良いんじゃないかと思えてくる。

ともあれ重要な通信は暗号化されているように見えた。証明書の検証については確認していないが、まさか大丈夫だろうと思いたい。その前提で、ひとまず安全と判断したい。

なお、TLS セッション確立後も HTTP 通信は続く。とは言え、確認した範囲では画像の取得にしか使われていなかったので、安全性に影響はなさそうだ。

標準メールアプリ

標準メールアプリについては、設定項目「SSLを使用」を ON にして使用。この設定なら当然 SSL/TLS を使用するだろうと思う。実際に確かめてみた。

imap.softbank.jp との通信（IMAPS）

まずは imap.softbank.jp との IMAPS 通信。これは @i.softbank.jp のメールアドレスで使用するものだ。通信では、まずクライアントが TLS の Client Hello を送信し、この時クライアントは TLS_RSA_WITH_AES_128_CBC_SHA を筆頭に 13 の暗号方式を提示した。次にサーバがServer Hello を返信し、TLS_RSA_WITH_AES_128_CBC_SHA の利用が決まった。以降の通信は暗号化されているので不明。暗号方式は App Store との通信に使っているものより強力に思える。

mbox.iijmio-mail.jp との通信（POP3S）

次に mbox.iijmio-mail.jp との POP3S 通信。これは IIJmio のセーフティメール で使用するものだ。iPhone との通信方式は先の imap.softbank.jp と同じで、採用された暗号方式も同様。

まとめ

全体的に標準メールアプリは、「SSLを使用」を ON にしている限りは通信が暗号化されるようだ。App Store と同様、証明書の検証については確認していないが、まさか大丈夫だろうと思いたい。その前提で、ひとまず安全と判断したい。

TwitBird Free

ax.init.itunes.apple.com へのリクエスト（更新チェック？）

起動するとまず、App Store と同様に ax.init.itunes.apple.com への HTTP GET リクエストが行われ、次に p19-buy.itunes.apple.com との暗号通信が始まる。この正体はよく判らないが、更新チェックか何かだろうか。

itwitter.nibirutech.com へのリクエスト（利用者管理？）

次に itwitter.nibirutech.com への HTTP POST リクエストがある。

POST /devices.xml HTTP/1.1
Host: itwitter.nibirutech.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_5; en-us) AppleWebKit/526.11 (KHTML, like Gecko)
Content-Type: application/x-www-form-urlencoded
Content-Length: 178
Accept: */*
Accept-Language: ja-jp
Accept-Encoding: gzip, deflate
Connection: keep-alive

app=TwitBirdFree&UDID=********&device_token=********&version=2.4&usernames=********

HTTP/1.1 200 OK
Date: Sun, 28 Feb 2010 00:44:37 GMT
Server: Mongrel 1.1.5
Status: 200
ETag: ********
X-Runtime: 79
Cache-Control: private, max-age=0, must-revalidate
Content-Type: application/xml; charset=utf-8
Content-Length: 17
Via: 1.1 iTwitter.nibirutech.com
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive

Device Registered

これも正体はよく判らないが、通信先が twitter.com のドメインではないので、Twitter との通信ではないように思える。nibirutech.com につい調べてみると、どうやら TwitBird を作っている会社のドメインらしい。リクエストボディ内のパラメータ名から推測すると、作者による利用者管理か何かのように見える。

パラメータに usernames があるが、ここには筆者の Twitter アカウント名が含まれていた。TwitBird 作者からすると、どの Twitter ユーザがいつ TwitBird を使用しているのか、管理できていることになる。同時に、WiFi の提供者からすると、WiFi 利用者の Twitter アカウントが判ることになる。

UDID や device_token パラメータには、数字が含まれていたが、数字が何を意味するのかは判らない。

twitter.com との通信は暗号化

itwitter.nibirutech.com との通信以降は twitter.com との通信が暗号方式 TLS_RSA_WITH_AES_128_CBC_SHA にて行われる。

まとめ

TwitBird は、Twitter との通信を暗号化して行うようだ。証明書の検証については確認していないが、まさか大丈夫だろうと思いたい。その前提で、ひとまず twitter.com との通信に関しては安全と判断したい。

まとめ

今回調べた 3 つのアプリケーションについては、出先の WiFi でも、とりあえず安全に使うことができると判断した。とは言え、調べていないアプリケーションの数は膨大だし、今回調べたアプリケーションも今後とも安全という保証はない。なので、今後とも、ちょくちょく調べていこうと思う。