ROCA のすべての投稿

2011-07
02
01:55:07
オープン化への変貌とキャリアの隠蔽体質を考える – secure.softbank.ne.jpの問題を受けて


7月になってsecure.softbank.ne.jpという一種のSSLプロキシの廃止を受けて、高木さんと徳丸さんから続けて背景説明のエントリーが発表されている。

SoftBankガラケーの致命的な脆弱性がようやく解消
ソフトバンクのゲートウェイ型SSLの脆弱性を振り返る

簡単に言えばこのSSLプロキシの廃止は重大なセキュリティリスクを回避するために絶対的に必要だったと言うことなのだが、詳細はぜひ上記を参照して欲しい。

正直に言うと、この高木さんとソフトバンクモバイル宮川氏のやり取りの前に少しきっかけに関わったので興味を持ってみていたのだが、当初は発端となったアプリ側でのCookieの取り扱いにくさ以上の感触を得ていなかった。
それが違うなと思い直したのは両名が7月を前に盛り上がりだしてからで(笑)、それが同一生成元ポリシーに関わる問題であろうことはその後すぐ気付いた。
しかし実は水面下では、端末のJavaScriptを調整してsecure.softbank.ne.jpでの挙動のみ変更したいたことなどは今回のエントリーで始めて知った次第だ。
アクロバティックな対応だなと思うし、非常に感じるのはこれまで閉塞した世界でなら何も考えずとも良かった問題がJavaScriptやあるいは通信路の解放などといった「オープン化」によって大きく揺らいで行くであろう未来の姿だ。

先のエントリーで徳丸氏は以下のように述べている。

この事例から言えることは、(ガラパゴスと表現されることもある)日本の携帯Web独自の仕様というのものが非常にきわどく、もろいものだということです。

 

携帯Webの仕様がオープンにならないことも問題です。私は前述のJavaScript等の仕様を調べるために、公開されている仕様書だけでは十分でないために、実機での試行錯誤が必要でした。携帯Webの安全性確保のため、開発者やセキュリティ研究者に向けた十分な情報開示を希望します。

僕も全く同意見だ。
そもそもの問題はあまりに日本のケータイWEBがガラパゴスと言われるような独自進化をし、それはクローズドだったからまだよかったものの、ここへ来てスマートフォンに始まり、JavaScriptなどブラウザがリッチ化しOSはAndroidなどよりオープンなもの(逆に言えばキャリアやメーカーが手を加えにくい) となり、また通信路はWi-Fiや定められた端末しか繋げられない閉塞したものではなくPCなどと同居するよりオープンなものへと変貌しつつある。
日本のケータイシーンはただ端末がガラケーからスマートフォンへ置き換えられているだけではない。技術的な観点からすると「一般的なインターネット」へ変貌つつある。

問題はそうした急速な変化の中で果たしてキャリアはこうした旧世代の脆い仕様との乖離に伴う脆弱性に正しく対応可能なのか、ということだ。

少し古い話になるのだが、実は半年ほど前個人的に一ユーザーとして各キャリアに以下のような質問を行ってみた。

1. 具体例は示しませんが、近年携帯電話やスマートフォンに関して、セキュリティ上の脆弱性がネットなどで指摘されることが多くなってきました。
この1年間において御社にて脆弱性が発覚または発見しこれを修正などの対策をされた実績がありますか。ある場合、もし宜しければ具体例をお教え下さい。
2. 1のケースに関わらず、一般論で結構なのですが御社では脆弱性が発覚した場合修正し対応なさいますか。対応する/しないの判断基準はどの点だと認識していらっしゃいますか。
3. その場合、脆弱性があった旨ユーザーに情報を開示されますか。
4. 御社にてこうした脆弱性対応のためのポリシーを策定し運用されていらっしゃいますか。またそれは公開されユーザーへ周知されていらっしゃいますか。

各社様々経緯があり返答に時間もかかり結局一ヶ月近くかかった覚えがあるのだが、簡単にまとめると各社の回答は以下のようなものだった。

質問事項 脆弱性が発覚または発見しこれを修正などの対策をされた実績はあるか 脆弱性が発覚した場合修正し対応するか。対応する/しないの判断基準はどの点だと認識しているか 脆弱性があった旨ユーザーに情報を開示するか 脆弱性対応のためのポリシーを策定し運用しているか。またそれは公開されユーザーへ周知されているか
ドコモ 特に回答無し – ウィルス対策、パターン更新などの対策を行っている
– 対策の判断基準は脆弱性の程度や影響などを総合的に判断
– お客様にお伝えできる情報は弊社ウェブサイト等にて公開させていただきますことをご了承ください 特に回答無し
au – 脆弱性事例はあり(最近の例を例示) – システムに脆弱性があることについて事実確認されアップデートによって脆弱性が解消できることが判明した場合には必ずWEBサイトで告知を実施した上でアップデート対応を実施する – セキュリティに関わる問題については悪用される危険性があるため詳細な内容については公表しない。但し該当ユーザーについては個別に周知している 特に回答無し
ソフトバンク 弊社の機密事項に関するものとなるで社外への情報開示はWEBサイトで公開している内容のみでそれ以外は答えられない
イーモバイル 特に回答無し 特に回答無し – お客様に影響を及ぼす問題が発見された場合には、すみやかに情報を開示し対策を実施することとしています。
情報の開示方法は、弊社ホームページ上に掲載するケースや、
個別にご連絡する場合など案件によって最適な方法で実施いたします。
特に回答無し

 

多少の違いはあるが、どれも判で押したような特に具体性のない内容であることは間違いないだろう。
注目すべきはどこのキャリアも回答には数週間から一ヶ月かかっている、つまりあらかじめ想定している内容ではなく、 社内調整した結果の回答であったのだろう。それは脆弱性ポリシーの有無の質問に対していずれも明確な回答がなかったことからも察しが付く。
つまりは各社とも今回のような脆弱性への対処については明確な社内規定やルールがあり運用されている訳ではなく、発覚した場合のケースバイケースということなのではないだろうか。
これは一言で言って常に対処が後手に回り対処療法に陥りやすい危険な兆候とも言えるだろう。

「フルディスクロージャ」という言葉がある。これは「脆弱性情報を隠蔽しこれを知り得ている一部の悪意あるユーザーに悪用されるよりは、脆弱性情報を発見したらすぐに広くオープンにして全てのユーザーに完全に周知した方が安全だ」という考え方だ。
これはこれで極端な考え方で、例えば0Dayアタックと呼ばれるような一般ユーザーにこのような脆弱性から守る術を持たないうちから攻撃されるリスクが十分あるからだ。
そこまで極端なフルディスクロージャーは近年では採用されることは少ないが、しかし一方で上記のようなキャリアの態度というのは、これまた極端な「隠蔽体質」と言われても仕方ないだろう。

しかし実はこのフルディスクロージャーの考え方には、インターネット黎明期に脆弱性の隠蔽が頻繁に行われ、その結果被害が拡大した結果、反省と反発からの一種の極論から生まれたという背景がある。

キャリアが理解しているかどうかは分からない。しかし僕にはこれまでのキャリアは閉塞網と完全に制御された端末でのうのうと暮らしてきた「井の中の蛙」に見える。
スマートフォンの伸長は歴史の針を一気に進め、蛙を大海へ叩き込んだ、とも言えるだろう。
彼らが今後暮らさなければならない「本当のインターネット」の大海では、脆弱性情報は共有され適切に管理され、インターネット全体の安全性のバランスを取る仕組みと常識感が既に熟成されている。それはインターネットの巨大なプレーヤーとしてはほぼ責務と言っていい。 だがそんな「本当のインターネットでの常識」に付いていけるだけの力を身に付けられているだろうか。僕は甚だ疑問だ。

キャリア各社は今後スマートフォンへ軸足を移し、また「普通のインターネット」を提供したいと発言している。一方で各キャリア毎に課金・認証の仕組みを導入しようとしており、ドコモはiモードを、auはau one IDをすでにAndroidに組み込んでいるようだ。
けれど彼らは本当にそれらがインターネットの大海でどういう意味を持つか理解して実現できるだろうか。
僕はこうした脆弱性ポリシーや、インターネットでは当たり前の技術情報の周知1つ出来ていない現状では結局同じことを繰り返し、更に酷いセキュリティ問題を繰り広げる未来としか思えないのだ。

 

2011-06
26
02:19:38
ニコニコシェア R1.1.0をリリースしました


R1.1.0です。

Firefox4以降に対応しました。
現在最新のFirefoxは5となっており以後6週間程度の単位で頻繁なバージョンアップが繰り返される予定ですが、少なくとも当面はこれらのバージョンアップにも対応しているはずです。

何かありましたらコメント欄までお願いします。

 

2011-06
22
10:11:41
ソフトバンク回線のパケットロスがほんとーーにひどいのかTCPでも確かめてみた


前回記事に対して、「ICMP(ping)のパケットの優先度を落としているだけでは」という意見も幾つかあったようだ。
本文でも書いているとおり、僕自身はパケットロス率に注目したのではなく、それに伴うラウンドトリップタイム(RTT)の時間帯での差異から(ICMP/TCPあるいはUDP関わらず)バックボーンを守るための何らかのパケット制限がかけられているのではないか、という見解だ。
ただ70-90%という値があまりにセンセーショナルだったため数字が一人歩きしたか、エントリー全文が読まれていないということかと思うのだが、せっかくなので、ではTCPではどうなのか確かめてみた。以下、その結果。

Continue reading

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
18
00:33:12
ニコニコPodder R1.2.5をリリースしました


(追記2) AM05:00
問題を修正したバージョンを改めてR1.2.5としてアップロードしています。下記の問題が発生している方はお手数ですが再度のダウンロードをお願いします
(追記1)  AM03:30
現行のR1.2.5には、開発環境でない一般環境では起動時にデータベースエラーが発生し正常動作しない問題が発覚しました。
急遽R1.2.4へ差し戻させて頂きます。
既にR1.2.5をダウンロードしてこのような問題が発生した場合には、お手数ですが再度R1.2.4のダウンロードをお願いします。
ご迷惑をかけてして申し訳ありません。どうぞ宜しくお願いします。
R1.2.5です。
遅くなりましたが、ブラウザ認証統合でFirefox4に対応しました。
これに伴ってこれまでのFirefox2と3.0/3.5などの違いを廃止し、Firefoxとして一本化しました。但し動作はFirefox3.6以降のみサポートします。2.x系列についてはサポートを廃止しました。

 

何かありましたらコメント欄までお願いします。