ゆきのぶ日記

2005/02/28(Mon)

■ 発表会

会社にて発表会。以前の侵入の件について，発表を行った。時間を大幅に超過してしまった気がするが，色々と話してきた。うまくいっていれば，何か良いことがあるはずだ。自己評価としては，まずまずの内容でできたと思う。

[ツッコミを入れる]

2009/02/28(Sat)

■ 旅行計画 - 高専カンファレンスin九州

高専カンファレンスin福井に参加できなくなってしまい悔しいので、5/16に予定されているin九州について計画を立てる。遠方からの参加者歓迎らしいので、楽しみ。

自分では、このプランを使うことにする。同行する人歓迎！

ITSスカイパック九州シティプラン (\13,850)

5/16 羽田空港(08:30) → [JAL 313] → 福岡空港(10:20)
5/17 福岡空港(19:20) → [JAL 338] → 羽田空港(20:55)
コートホテル博多駅前｜Court Hotels & Resorts

他、参考になりそうな情報。

[ツッコミを入れる]

2010/02/28(Sun)

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

iPhone

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 を使ってくれても良いんじゃないかと思えてくる。

iPhone と App Store との通信における暗号方式の選定

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

なお、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 との通信に使っているものより強力に思える。

imap.softbank.jp との通信における暗号方式の選定

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 パラメータには、数字が含まれていたが、数字が何を意味するのかは判らない。