<前の日記(2005-08-09) 次の日記(2005-08-13)> 最新

おおいわのこめんと (2005-08-10)


2005-08-10

[Security] Scope

一部で祭になってますねぇ。まぁ話題になっている内容(PW漏洩、個人情報漏洩後の隠蔽工作)が事実だとすると、 祭られても仕方がないのだが。 漏洩してないなら「漏洩してません」と反論すればいいことなので、それができないってことは 漏洩しているんだろうなぁ、と推論されるのは仕方がない所。 こういう予期せぬ事態に対して、組織としてマトモな危機管理体制ができてないってことですね。

僕個人は、脆弱性情報は過去に何らかの危険にユーザを晒した「可能性がある」ならば、 危険に晒されなかったことをログ等で確実に確認できない限り、すべからく公開すべきだと考えています。 IPAの脆弱性情報取扱基準 (Webアプリケーション向け)でも、

「個人情報漏洩等が発生、または発生した可能性がある場合は被害拡大防止のため、事実関係を公表」

となっていますね。まして今回の場合、POP パスワードが漏洩している可能性があるということは、 関係する可能性のあるユーザは緊急にパスワードを変える必要があり、 かつそれにより今後の被害を確実に防ぐことができるわけですから、 一刻も速く「問題があったのかなかったのか、実際漏洩があったのかなかったのか判らないのか」 公開する責務があると考えるのが当然だと思います。 万が一自分で判断できないとしても、悩む前に 「現段階では判らないけど念のためパスワード変えて下さい」とアナウンスするのが妥当かな。

しかし、仮に当初は黙殺・圧殺して握りつぶす方針でいたとしても、 一般ユーザだけでなくネット系マスコミまで動いている段になって、 いつまでもダンマりを決め込んでるのはマイナスにしかならないと思うんだけどなぁ。

追記 (8/10)

まぁ 2ch の煽りもえげつないのは事実なんだけど。今回のバグに関係なさそうな 取引先業者にかたっぱしから質問状ってのはちょっとやりすぎっぽいなぁと個人的には思ったりして。

バグ入りバージョンの公開時間は(たったの)17時間かぁ。 どうせバグ入りのダウンロード数は把握しているんだから、 それなりのリリースを出して最初に正しい対処を取っておけば、 ほとんど何の問題もなく解決して信頼もほとんど落さないで済んだはずなんだけどねぇ。

で、ここまでは前置きだったりする :-)。祭りの野次馬として開発元のサイトにいって、 FAQ見ると、謎の記述が。

> SSL には対応していますか?
対応しております. ただし,携帯電話と弊社サーバ間での通信は暗号化されませんのでご注意ください.後日,携帯電話と弊社サーバ間に関しても SSL 通信に対応いたします.

(;゜д゜)

………。最近過激な言葉づかいは謹むようにと一部に言われてますが、「あふぉですか?」と思わず口からでてしまう。 SSL の意味まったくないやんけーーー。

………とはいえ、上の文章だと一見問題なさげに見えてしまうので、判りやすい日本語に翻訳してみましょう。

> 暗号化通信には対応していますか?
対応しております.ただし,暗号化していません.*1

………今度は判りやすいかな? :-)

Web ブラウザみたいな一般向けの製品、特に暗号を使ったような製品を作るときに、 きちんと所定のセキュリティ機能を実現できないのであれば、 潔く機能を提供しない*2、 というのは、サービス提供者としての最低限の責務だと思います。 ここからSSLの通信内容が情報漏洩したら、この会社は責任取ってくれるんでしょうかね? 携帯会社とセキュアな専用線で通信してれば問題ないけど、 それだったらFAQのこの項にはっきりと「対策してるんで問題ありません」と 書けるもんねぇ。

別にSSL通信機能なんて、後日直す気があるなら、 きちんと実装完成してから公開してもいい物だと思うんですけど、 なんでこんなタコ実装で公開しちゃったんだろうねぇ。

追記 (8/10 23:00)

仕様にSSL通信対応 謳ってるしー。 そういう状態で 『プログラマーズファクトリ、リンクシェアと提携。「scope」でショッピング』(Venture Now) とか言ってるしー。 ひょっとして確信的に不完全な状態で前倒し提供してる? なんかやばげ。

[Security] 携帯フルブラウザと暗号通信

上の記事への追記 (8/11 04:00)。

jig も同じ (Q22) だそうで orz (情報元: 2ch*3)。 どうしてこの業界はこう暗号化の意義とかに無頓着ですか?

どうせ

「SSL なECサイトが使えないと困る」
→「でも SSL は簡単にはサポートできない」
→「平文でいいからとにかく通信できるようにしちゃえ」

とかいう短絡的な発想なんだろうけど、インターネット上を 平文で通信するリスクを許容できるコンテンツなら、 コンテンツ提供者側が最初から http で提供すればいいわけで、 そもそも何故 SSL を使っているのか、 という肝心な点が欠落してるんじゃどうしようもない。 暗号化できないから暗号化している振りだけして平文でいい、なんて論理が成り立つわけがない

解は恐らく3つあって、

  1. SSLはサポートしない (ある意味王道)
  2. 真面目に暗号化通信を実装する
    1. ブラウザ側にSSLを実装し、コンテンツ提供者との SSL 通信のパケットを HTTP 上でトンネルするような独自プロトコルを作る (メモリきつそ〜)
    2. 専用 proxy サーバを信用するという前提の元で、 携帯本体提供の HTTPS 通信機構の上で独自プロトコルで proxy と通信、 proxy で一旦復号してから改めて HTTPS でコンテンツ提供者へ送る。 (1.より安全性に劣るがメモリ&実装節減可能) *4
  3. docomo に金積んで公式コンテンツ化&専用線直結閉域ネットワーク化することで、 平文通信区間の安全性を確保する (富豪的解決)

のどれかでしょうかね。 2-1 は、よく似た機構を携帯向 SSH クライアント が既に実装していたりする。*5

最後の解は、無線区間を追加暗号化なしで流れるリスクが SSL と比較して どの程度のものなのかをちゃんと評価しないといけないけれど、 それが十分にセキュアなら、現状の実装のまま解決できる。

*1 もちろん proxy←→サイト間は暗号化されるんだけど、 proxy 自体がインターネット上にあるのに、それだけじゃ意味がないのは当たり前。

*2 ソフトウェアによっては、利用時に「安全性に問題があります」と 警告をしつこく出しつつ動作させる、ってのは許される可能性がありますが、 Web ブラウザで SSL が正しく動作していない、ってのはそれも許されないレベルだろうなぁ。

*3 「jig もダメ」なんであって、「jig も同じだから OK」なんてことはないからねー。>某スレ480な人

*4 最初は「SSLよりシンプルな独自暗号プロトコルでも 実装しなきゃいけないかなぁ、暗号プロトコルの素人がこれを実装すると、ろくな事にならないのは 容易に想像つくなぁ」と思っていたのだが、この手のブラウザが動く程度に 最近の携帯なら proxy との間は携帯側実装の HTTPS が 使えることが確認できたので、それでいいよね、ということに。 ひょっとすると iアプリの仕様だと全部 SSL にしなきゃいけない 可能性 (←識者に聞いてみるかな) もあるが、まぁそれでも許容範囲だよね。 負荷が問題ならそれこそSSLアクセラレータでも使えばいいし。

*5 なんかQ15に微妙な記述があるけど (^^;

[TrackBack URL: http://www.oiwa.jp/~yutaka/tdiary/trackback.rb/20050810 (note: TrackBacks are moderated: spams will not be shown.) ]

大岩 寛 (おおいわ ゆたか) <yutaka@oiwa.jp.nospam ... remove .nospam> .

Copyright © 2005-2014 Yutaka OIWA. All rights reserved.
Posted comments and trackbacks are copyrighted by their respective posters.

記事の内容について (Disclaimer / Terms and Conditions)