「技術ネタ」カテゴリーアーカイブ

2011-06
20
03:07:46
ソフトバンク回線のパケットロスがひどいというので、ほんとーーにそうなのか確かめてみた


追記書いてます。

#softbank 携帯によるデータ通信でのパケロスは本当に酷いのか?

という話があって、聞こえてくる話では75%のパケットロスもあるのだという。
一般的にネットワークに関わる層には一概に信じられないロス率だが、Twitterなどで流れてくる数値ではよく信用できないのと、ある程度偏ったテスト環境になってしまっている気もしたので、ドコモ回線含め時間帯も変えて比較してみることにした。
テスト環境は以下の通り。

テスト概要
JailBreakしSIMフリー化したiPhone3GS(iOS4.2.1)にてソフトバンク iPhone通常回線(smile.world)とドコモ データ定額(mopera.flat.foma.ne.jp)で複数のサーバーに対してping(ICMP echo)テストを実施し、パケットロス率およびラウンドトリップを計測する。

テスト方法
SSHでiPhoneへログインし、Cydiaのinetutilsに付属するpingコマンドを計30回試行し平均値を得る。

テストサーバー

  1. www.yahoo.co.jp(ロケーション: 東京 丸の内 ブロードバンドタワー)
  2. www.google.co.jp(ロケーション: 恐らくアメリカ西海岸)
  3. テストサーバー1(ロケーション:アメリカ FremontにあるVPSサーバー)
  4. テストサーバー2(ロケーション: さくらインターネットのVPSサーバー。設置場所は不明だが国内)

テストは都内から行っている。また時間帯も変えることとし、とある日曜日のPM9時台と翌日AM2時台の二度行った。

結果は以下の通りである。

テストケース1: PM9時台に実施

フレッツ光(Wi-Fi)
packet loss min avg max stddev
www.yahoo.co.jp 0% 11.704 16.691 23.845 3.0003ms
www.google.co.jp 0% 43.708 46.835 54.807 2.081ms
テストサーバー1 0% 139.024 187.894 239.065 30.026ms
テストサーバー2 0% 18.814 22.512 25.306 1.460ms
docomo(データ定額)
packet loss min avg max stddev
www.yahoo.co.jp 0% 108.174 118.389 154.171 8.798ms
www.google.co.jp 0% 128.898 141.954 155.505 6.944ms
テストサーバー1 0% 206.165 217.398 361.339 26.932ms
テストサーバー2 0% 106.566 132.891 613.313 89.298ms
Softbank(iPhone)
packet loss min avg max stddev
www.yahoo.co.jp 73% 88.733 179.106 370.456 92.697ms
www.google.co.jp 86% 116.306 120.867 126.555 4.248ms
テストサーバー1 76% 240.308 259.038 318.825 24.805ms
テストサーバー2 90% 121.751 131.433 146.446 10.763ms

テストケース2: AM2時台に実施

Softbank(iPhone)
packet loss min avg max stddev
www.yahoo.co.jp 3% 114.327 245.465 2133.128 403.058ms
www.google.co.jp 23% 107.446 178.063 896.914 161.420ms
テストサーバー1 0% 533.464 1064.434 1991.588 373.095ms
テストサーバー2 3% 401.674 967.69 1886.757 345.000ms

 

比較のためWi-Fi(回線はフレッツ光)も付記している。

まず第一に流れている話通り、PM9時台では確かにロス率は70%から最大90%にも達している。まさしく通常はあり得ないレベルだと言ってもいいだろう。
しかしもう一点注目すべきなのは、ラウンドトリップに関しては、実はドコモのそれと遜色ない、若しくは場合により上回っている場合もあるということだ。
次にAM2時台となるとロス率は格段に改善されている。ほぼ問題無いレベルと言ってもいいだろう。しかしその反面ラウンドトリップは極端に落ち込み、特にmax値は10倍以上遅延しているケースもあった。また平均偏差も非常に大きくなっている点にも注目したい。これはネットワーク状態が安定していないことを示している。
果たしてこれらは何を意味しているのか。

ここから憶測にすぎないが、テストケース1において、恐らくソフトバンクのバックボーンネットワークの性能自体はドコモと比較してもそれほどの遜色は元々無さそうだと言うことだ。しかしそれはパケットロス率を上げることでバックボーンへの負荷を低減しているからではないか。
これはテストケース2においてロス率が下がったと同時にラウンドトリップが極端に下がった(つまりネットワークが飽和しつつある)ことからも想像できる。
すなわち、パケットロス率はバックボーンへの負荷を減らすべく元から意図されたもので、時間帯により例えばスイッチングルーターのバッファ量を調整するなどして日夜調整されているのではないかという推測が成り立つ。

僕自身はネットワークの実務経験も乏しく専門性は持ち合わせていないのでこれ以上の論評は差し控えるが、これはこれで1つの「見切り」かも知れないという気はする。
ユーザーとしての感想を述べるなら、僕自身はパフォーマンスも少なくとも最近は1Mbpsを下回ることもなく安定して使えていると思っており、これまでもソフトバンク回線に(電波の入り以外に)大きな不満を感じたことはない。
スマートフォンに絞ればほとんどの通信はTCPベースであることは確かであり(UDPで困るのはDNSぐらいか)非常に多くのリトライパケットが発生するとしても全体としてはそれなりの「実測値」が得られると言うことなのかも知れない。

ネットワーク屋にとってはとても考えられない対応かも知れないし(僕自身もそうしたチューニングを決意する度胸はないが)、単にパケットロス率のみ取り上げて非難するのは簡単だ。しかし1つの方法論として今後「冷静に」大いに議論されても良い点ではないだろうかとも思う。
何故なら、これはもしかすると今後いずれのキャリアも通る道かも知れないからだ。

2011-06
15
11:42:45
auのEZWebがそろそろ終了しそうな件


先日auからEZWebに関わる以下のようなアナウンスがなされた。
KDDI au: EZfactory

EZブラウザは、2011年秋冬モデルにて、EZサーバを含め、「機能」及び「ネットワーク環境」の見直しを行ないます。
これによる主な変更点は以下のとおりです。

<主な変更点>
・EZサーバの言語変換機能が削除され、HDMLが非サポートとなる。
・EZブラウザ、PCサイトビューアーのIPアドレス帯域が統一される。

他にもCookie仕様の変更などがあるのだが注目すべきは、「EZブラウザとPCサイトビューアーのIPアドレス帯域が統一される」という点だ。

以前書いた記事も参照して欲しいのだが、

続:携帯で端末ID詐称は可能かもしれない話
(追記) 続:携帯で端末ID詐称は可能かもしれない話

EZWebつまり日本のケータイECを支えているケータイID(端末ID、サブスクライバーID)は単純に契約者または端末ごとに振られたIDをHTTPヘッダーに載せて通知して、WEBサイト(例えば公式サイトでの決済や課金など)ではこれを元に契約者を特定しているだけなので単にインターネット上で実現するとすぐに偽装や詐称されてしまう。
そこで再掲になるが、auに限らずドコモやソフトバンクでも以下のような脆弱な要件を満たさない限り、ケータイIDが偽装・詐称されずに正しく利用されていることはサイト側(サービスプロバイダー)では見分けが付かない

(1) そのアクセスがそのキャリアの携帯網(IPアドレス帯域)からのみであることをサービスプロバイダーが保証すること
(2) 携帯網ではケータイIDが偽装されていないことをキャリアが保証すること
(3) 端末の自由度を低くしてケータイIDの偽装などの可能性をできるだけ低く保つこと

但しauではEZ番号はゲートウェイで付加されるのではなく端末側から直接送信されているようなので、上記の三原則であれば1と3でしか担保されていない模様だ。

EZ番号を使用したケータイECに対応するのがEZブラウザであり(ドコモであればiモードブラウザ)、PCサイトビューアはEZ番号は発信しない単なるフルブラウザである。
しかし上記条件にあるようにEZブラウザ以外のブラウザやアプリからEZブラウザと同様のIPアドレス帯域に接続でき、かつEZ番号を偽装できるならこの日本独自のケータイECの仕組みは崩壊することになる。
であれば果たしてEZブラウザとPCサイトビューアのIPアドレスが統一された後、PCサイトビューアで偽装が可能になってしまわないのか。

この疑問に早速、徳丸浩氏が実験を行い結果を公表された。

EZwebの2011年秋冬モデル以降の変更内容とセキュリティ上の注意点

上記のように、現状のPCサイトビューアでは、EZ番号が追加できるほか、W52TではUser-Agentも変更できます。2011年秋冬モデルの仕様はわかりませんが、上記と同じ仕様である場合、EZ番号の偽装が可能になります。

 

2011年秋冬モデルでもEZブラウザにJavaScript機能が搭載される予定はないようですが、JavaScript機能があるPCサイトビューアのIPアドレスが統一されることで、結果として、事業者ゲートウェイを経由する端末の中に、JavaScript機能を搭載したものが含まれる状態が生まれます。このため、JavaScriptを悪用した攻撃の可能性が生じてきます。具体的には、JavaScriptによるEZ番号(サブスクライバID)の偽装、DNSリバインディング攻撃などの可能性が生じます。

IPアドレス帯域の統一は7月から、また2011年秋冬モデルからの変更と言うことなので、実際にどうなるかは7月以降の検証を待たなければならない。
しかしもしPCサイトビューアの仕様が大きく変わらないのであれば、EZWebでのあらゆる課金や決済は(たとえ暗証番号があるにせよ)偽装放題と言うことになる。
「でもそもそも他人のEZ番号なんて分からないのでは?」という疑問もあるだろう。しかしEZ番号は端末で「送信する設定」(デフォルト)にしてあれば勝手サイトにであっても常にEZ番号は送信されているのである。
つまり例えば決済や課金など関係ないケータイサイトを運用していても、実はEZ番号は大量にこれまでに入手可能であり、 ユーザー登録の必要なサイトであれば名前や住所などと紐付けられているかも知れないし、そもそも氏名など分からなくとも、ランダムにリスト化されたEZ番号を使って総当たりで詐称攻撃することも可能になるだろう。たとえ暗証番号があるにせよ、また3回間違えるとそのアカウントがロックされるにせよ、最低数百件程度のリストがあれば暗証番号を固定して次々に試せばそのうち幾つかは楽に認証を通ってしまうだろう(これはとてもよく知られた初歩的な攻撃手法に過ぎない)。
知らぬ間に公式サイトで勝手にデジタルコンテンツを大量に買っていたことになっていた・・ということも十分起き得るのである。

率直に言って、何故auがこんな仕様変更を簡単に行ってしまうのか、全く理解できない。そもそもauは、上記のような「脆弱な基盤」に支えられたケータイIDというものを理解していないのではないか。

以前僕はこのようにブログに書いたことがある。

三位一体の原則だ。これが1つでも崩れれば信頼性は崩壊する。
しかしもし上記の推測が正しければ、ことauのEZ番号については(1)と(3)によってのみしか支えられていない。SIMロック解除論議を持ち出すまでもなく、例えばauの携帯網のアクセスポイント情報が明らかになってしまったら。そこにスマートフォンなどで任意のアプリを実行できる端末が接続可能になったら・・・? 恐らくサービスプロバイダーは偽装を見破る術を持たない。
それが現実になれば、恐慌にも似たケータイECの信用崩壊が起こる可能性が非常に高い。

全ては2011年秋冬モデルの発売を待たなければ本当のところは分からないが、まさしくこの懸念が当たる際にいるのかも知れない。

2011-02
16
20:45:48
続々: 楽天銀行アプリのセキュリティについて – 結局UDID送信は中止しないし使用理由開示も行わない


前々回前回の続きをご報告したいと思う。
かなりあれから時間がかかったが、結論としてはシンプルで楽天銀行および楽天CERT・楽天グループとしてはUDIDの送信は停止しないし、また何故送信しているか、どのように利用・管理しているか は「当行不正取引防止システム運営の機密事項」のため一切開示しないとの結論であった。
以下、その詳細。

Continue reading

2011-02
11
21:32:11
[改訂版] iPhoneアプリのSSL接続をパケットキャプチャする方法


前回記事のはてブコメントで教えてもらったんですが、Burp Proxyというプロキシー型キャプチャソフトがあるそうです。
で実際使ってみると、これいい!お手軽ですね。Fiddler2と違ってiPhoneアプリでも利用可能です。
ということで改訂版をまとめてみますよ。 一応再度のまとめにしますので前回と被る部分もありますがご了承下さい。

なおやはり再度の補足になりますが、セキュリティの向上や社会的に正当な目的の下で正しく使用されることを期待してこのエントリーを記載しています。筆者は利用の結果に対して全くの無責任・無保証ですので、あくまで自己責任でご利用下さい。

Continue reading

2011-01
24
07:25:54
iPhoneアプリのSSL接続をパケットキャプチャする方法


ブラウザでアクセスするWEBサービスだと、たとえSSL/TLSでセッションが暗号化されていても所詮ピア・ツー・ピア通信なので例えばFirefoxだとFirebugなどでブラウザ側でパケットをキャプチャできます。
でもiPhone(iOS)アプリだとiPhoneにそんなツールが入れられないしキャプチャできない、と思い込んでいませんか?
実は僕もそうだったのですが、この件に関連して可能なキャプチャ方法を見つけたので覚え書きで残しておきます。

但し素人の方法なのでもっと洗練された方法もあるはず。セキュリティクラスタの皆さんにおかれてはよりよい方法をご存じであればぜひTBやコメントなど頂きたく。

なおセキュリティの向上や社会的に正当な目的の下で正しく使用されることを期待してこのエントリーを記載しています。筆者は利用の結果に対して全くの無責任・無保証ですので、あくまで自己責任でご利用下さい。

Continue reading