最新

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


2005-10-01

[Security] (Amit Klien) Exploiting the XmlHttpRequest object in IE - Referrer spoofing, and a lot more...

だんだん個人ブロクで書くネタじゃ無くなってきたな……。

Mozilla からの XMLHTTP の脆弱性の発表 の直後に発表されたレポート。 JVN #31226748 が出たのと前後してしまったので、

 マイクロソフト  	 該当製品なし  	2005/09/29

が波紋を呼んでいる模様。当初レポート出した時点で、SPACE とかを埋められないことを確認して、 「脆弱性無し」って報告しちゃったんだよねぇ。まさか、ちゃんと SP は除去してるのに HT や CR は通るとは思わないよなぁ……。

そういうわけで、時間軸が1日前後してしまったので混乱していますが、基本的には 「『脆弱性なし』とリリースした後に、類似パターンの脆弱性が見つかった」という 状況だと思って構わないと思います。MS が脆弱性が有るのを知っていて「無し」と 報告したというような話ではありません。

で、問題の件なのですが、状況を整理すると、

  1. まず、ユーザに影響のあるセキュリティ問題が生じているのは間違いない。
  2. MSIE のバグが問題なのも間違いない。かなり危ない動作をしているので直すべき。
  3. が、結果としての脆弱性が 100% MSIE だけの責任かといわれると微妙。

なので、Klien 氏のレポートはその辺り正しい(ツッコまれないような記述になっている、ともいう)のだが、 Secunia のアドバイザリ が MSIE だけの脆弱性にしているのはちょっと微妙かなぁとも思います。 まぁ、少なくとも 95% は MSIE の責任だけどね。

まず、おさらいしておかなきゃいけないのは、規格上

  • HTTP 1.1 のリクエスト行は、「リクエストメソッド」 SP 「URL」 SP 「HTTP-Version」 CRLF。SP は空白文字 (0x20) のみ。
  • HTTP 1.1 のリクエストメソッドに許されるのは "token"。token に許されるのは、アルファベット・数字と一部の記号。

ということです。その上で、

  • MSIE は、XMLHTTP においてリクエストメソッドに SP を入れることは許さないが、 それ以外の制御文字はすべて入れられてしまう。例えば、CR とか LF とか HT (水平タブ、0x09) とか。
  • 一方で、Apache とか多くの proxy は、SP の代わりに HT を使ったリクエストも受け付けてしまう。

という風に両方がおかしな処理をしているので、結果として、リクエストメソッドの部分を使って 怪しげなデータを送り込んで、proxy が URL とか次のヘッダとかと解釈するように仕向けることが できるという話です。通信の双方が HTTP に準拠していない データを違う風に解釈しているという状況です。

今回は、そもそも処理を開始しているのが MSIE の側ですし、 攻撃に使う文字が 改行 とか HT とか、明らかに「空白っぽい」文字ですし、 そもそも「リクエスト行」と命名されているデータに改行が含まれるのは感覚的に言って明らかにオカシイので、 まぁ MSIE が悪く言われるのも仕方がない気もしますが、一方で、この攻撃で生成される データが HTTP リクエストとして正当でないことは保証されているので、 proxy サーバ側は「400 Bad Request を返して (あるいは黙って) keepalive せずに TCP 接続を切断する」 という動作をすべきなのも間違いないです。 そのような厳格な動作をしている限り、今回の Klien 氏の攻撃は深刻な状況を生まないはずです。

HTTP Request Smuggling 系の攻撃は、ほぼ全てがこの手の「不正・異常な入力に対する サーバ・クライアント間の解釈の不一致」を突いて、それがセキュリティ的にやばい 不一致になるように攻撃を仕組むというパターンだと言えるので、両方をきちんと 直さないといけないのです。今回の件の MSIE の仕様は余り弁護できませんが、 過去に指摘された Smuggling の中には、「web server にそんな異常な動作されたら proxy はたまらないよなー」というような攻撃も結構あります。

一方で、実は今回の JVN #31226748 の 件の“味噌”は、解釈の一意に定まる HTTP/1.1 準拠のリクエストを使って攻撃が成功する、 という点にあります。今回僕が見つけた攻撃パターンは3つあるのですが、 そのうちの2つは HTTP/1.1 に完全準拠した正当なリクエストを生成していますし、 もう1つは HTTP/1.1 では「エラー」とされているものの、その際の受信側の 解釈が厳格に規定されているようなリクエストを生成しています。 つまり、これはサーバ側は「俺はちゃんと規格通りに解釈したぜ、 完全にクライアント側が一方的に悪い」と言いきれるケースなのです。 その辺りが、既存の攻撃とは違うパターンかな、と思っています。

ちなみに、最後のケースについてもう1レベル上のレベルから話をすると、 そもそもこういう不一致を生みやすい HTTP/1.1 の仕様自体にも、安定性という意味では問題があるといえます。 今回は Mozilla も Opera も HTTP/1.1 をサポートしているので 言い訳できませんが、実はこの「エラー」リクエストは、 HTTP/1.0 としてならクライアント側の解釈が正しい、とも言えるケースなのですね。 ですから、今後例えば HTTP/1.2 に変な機能が追加される(そしてサーバが HTTP/1.1 に遡って機能をサポートしてしまう)と、 今の安全な実装が次の脆弱性を産み出してしまう可能性があるわけです。 こんな危険を生むような仕様の改変は、できる限りするべきではありませんし、 中でも「誤ったデータの解釈」を定義する際には特に、この手の互換性と安全性に気を配らないといけません。 この辺り、きちんと纏めないといけないかもしれませんね。


2005-10-11

[Security] OpenSSL: Potential SSL 2.0 Rollback (CAN-2005-2969)

出ました。今回はかなり対応が素早かったなぁ。 製品がそもそもセキュリティ機能そのものを扱うものだからというのも大きいとは思いますが、 極めてよいレスポンスと対応でした。ちょっと感激(大袈裟)

具体的なユーザへの影響ですが、一言で言えば、「SSL3.0 以降で通信しているつもりでも SSL2.0 の脆弱性の影響(の一部)を受ける」 というものです。多分この中で一番強烈なのは、「一連の Web のやりとりの途中でいきなり 40bit の弱暗号に切りかえる」 攻撃ではないでしょうか。9/23 に書いた通り、今となっては 40bit 暗号は通常利用する暗号として必要な強度を持っていないので、一旦40bit 暗号で送ってしまったデータは、 悪者が解読する意思さえ持っていれば容易に解読されます。これは、 本当に秘密にする必要のあるデータを通信しているときには結構な脅威かと思います *1。 あと、「通信内容の一部(SSLレコードの末尾)を削り落とす通信改竄攻撃」も、なかなか嫌らしいです。 削れる場所がレコードの末尾に限定されるので、本当に何でも改変できるわけではないですが、 通信内容が推測されていると結構いろいろできるかも。

修正以外の回避方法ですが、Web に限れば割と簡単で、 サーバかクライアントのどちらかで SSL 2.0 を無効化すれば、 この脆弱性の影響は受けません。たとえバージョンを落とそうと攻撃者が頑張っても、 ネゴシエーションに失敗するからです。
ですから、現時点でクライアント側は、可能なら SSL 2.0 を無効にすることで 問題を回避できます。弱暗号を無効化することでもかなりのリスクが低減できるでしょう。 とはいえ、そのような設定項目の存在しないクライアントもたくさんありますので、 その場合はソースに手を入れるか、サーバ側の修正を待つしかありません。
同様に、サーバ運営者側も、SSL 2.0 か弱い暗号を無効化することで、 問題を回避できます。当たり前ですがこの場合、Web の通信データを送受信する前の SSL ネゴシエーションの段階で拒否しておく必要があります。 POST メソッドの場合、ユーザのデータを受け取ってから拒否しても何の意味もありませんので。

今回の脆弱性はサーバ側の問題なので、基本的にはクライアント側で問題を修正する 手段はありません。サーバ側の OpenSSL を修正して、サービスを再起動することになります。 サーバ側では、修正のパッチ当ては当然するにしても、 この機会に SSL2.0 サポートと輸出強度暗号のサポートが本当に必要なのか、 検討するのもよいのではないでしょうか。

そもそもこの脆弱性ですが、SSL3.0 を設計した時点でこのバージョン低下攻撃の存在は認識されていて、 OpenSSL にも攻撃検知のチェック機構が実装されていたにも関わらず、 当時のブラウザのバグ対応のためにわざと無効にされていたというものでした。 今回の修正は、この「チェックを無効化する機能」自体を削除した模様です。 ドキュメントによれば「IE3.02 のバグ (1996年頃?) の対処」とされていますが、 こちらで試した限り、遅くとも IE5.0 の時点 (1998年?) ではとっくに修正されて いましたから、もはや存在価値を失った機能であって、 明示的に有効にする必要性すら存在しないという判断なのでしょう。

追記 (10/14)

セキュリティホールmemoさんからリンクが張られてすごいことになってますね……。10/13のアクセス1386件って当初の2ヶ月分くらいなんですけど……。

正直、運営側にかかってくる責任がとんでもなくでかくなるんで、緊張しています。 個人日記として、コメント欄などは50人程度の読者を想定して運用してたんで、 少しシステム・体制ともに改編をさせてもらうことになると思います。

とりあえず、目下の変更として、コメント欄を廃止し、「メッセージ欄」にさせてもらいました。 但し、日記の内容を補完し、公開することが読者にとって有益と僕が独断で判断したメッセージは これまで同様公開されることがあります。 また、煽り・放言の含まれるコメント1件を、削除させてもらいました。 コメントの前半に含まれていた技術的質問については、週末に FAQ の方に反映させてもらいます。

読者のご質問・ご指摘にはできるだけお答えしていきたいんですが、 あくまで個人で運営している日記ですので、限界があります。 とても何でも書き込めるBBSを現在の職務外の余暇で運用していくほどの 余力はありませんので、あくまで「個人日記」であることをご理解の上ご容赦ください。

あと、/.J などに関連ストーリーが ありますんで、なにか意見がある方はそちらでもどうぞ。 ウォッチしてますので、技術的に補完すべき点はFAQに取り込ませてもらいます。

追記 (10/16)

アクセス件数は少し落ち着いてきました。 金曜日は出張でろくにメンテできる状態じゃなかったんで、 数時間に渡って即席の「人大杉」を見た人がいたかと思います。 実際のところ、原因はアクセス過多そのものじゃなくて、 アクセス増大対策をしようとしてミスって却って状況悪化させて、 にっちもさっちもいかない状況で仕事時間に突入してしまった (^^; とかいうオチだったりしますが。

FAQ の方は引き続き更新してますんでよろしく。 例のコメントについても、 一応気になった部分はFAQ更新しました。 あまり変わってないように見えるかもしれませんが……。 気になる方がいるようなので、コメント本文も張っておきますんで、ご参考までにどうぞ。

もう疲れたよ……。

*1 Web ブラウザを使っている場合、40bit 暗号にされたこと自体は判るので、パスワードが盗られただけなら即時に対処すれば取り返しはつきます。


2005-10-13

[Security] SSL 2.0 version rollback の件のFAQ

以下、SSLv3 は SSL 3.0 と TLS 1.0 (と TLS 1.1 draft) を総称します。

1. 修正すると TLS や SSL 3.0 と SSL 2.0 は同時に使えなくなるの?

いいえ。今回の修正の対象である「バージョンロールバック攻撃」は、あくまでも 「クライアントが SSL 3.0 以上で繋ごうとしているにも関わらず、 通信中継者が SSL 2.0 への降格を強制する」攻撃です。 今回の修正をしても、クライアントが SSL 2.0 しか使えないケース、 サーバが SSL 2.0 しか受け付けないケースでは、どちらも正常に SSL 2.0 で接続を確立できます。

ただし、SSL 2.0 には既知の脆弱性が知られていますので、 可能ならサーバ・クライアントとも SSL 2.0 を無効に設定することを 個人的にはお勧めします。

2. SSL_OP_ALL を使っていなければ問題ないの?
3. 特殊なオプションなら実際には影響ないんじゃないの?

SSL_OP_ALL 及び SSL_OP_MSIE_SSLV2_RSA_PADDING を使っていないケースでは、(少なくとも今回の修正に関連する) 問題は生じません。

しかし、調査した限り、OpenSSL を使う大半のアプリケーションは、SSL_OP_ALL を設定しています。 これは、マニュアルで SSL_OP_ALL は

SSL_OP_ALL
    All of the above bug workarounds.

It is usually safe to use SSL_OP_ALL to enable the bug workaround options if compati-
bility with somewhat broken implementations is desired.

と、明示的に「通常安全である」と書かれているからでもあります。

具体例としては、Apache なんかは影響をもろに受けます。 Debian で16個ほどOpenSSLをサーバ側として使っているソフトウェアを選び、 ソースコードをざっと一瞥した限りでは、 標準で SSL_OP_ALL を使っていないものは3つ (stone, ssmtp, sslwrap)、 SSL 2.0 が明示的に禁止されていて問題にならないものが 2つ (webfs, proftpd) でした。残りの11のプログラムは SSLv2 を有効にしている限りにおいて脆弱性の影響を受けそうです。

4. 実際何が起こっていたの?

今回の問題は、SSL 3.0 を実装する際、併用する SSL 2.0 実装に追加で組み込んでおくべきだった チェックが、実際には有効になっていなかったという問題です。

SSL 2.0 には、通信を確立するまでの交渉段階のパケットを改竄しても、 それを検出できない問題が知られています。SSL 3.0 以降ではこの部分の改竄防止機構が 実装されていますが、クライアントとサーバの双方が SSL 2.0 を サポートしている場合、クライアントから送る最初のパケットの情報を 「SSL 2.0 しか使えない」と改竄すると、SSL 2.0 のプロトコルが実行されるため、 SSL 3.0 の通常の改竄防止機構は役に立ちません。

そこで、SSL 3.0 以降では、SSL 2.0 を同時にサポートする場合に、 この「バージョン低下攻撃」を検知するための追加機構が設計されました。 これは、

  • SSL 2.0 において暗号鍵の元になる秘密情報はクライアントからサーバへ RSA 暗号化で送信されるが、その際盗聴による推測を防ぐため、 (padding として) 乱数を一緒に暗号化して送ることになっている。 SSL 3.0 以上をサポートするクライアントが SSL 2.0 で通信する場合、 このパケットに含まれる「乱数」パディングの一部に、 8バイトのランダムでない特殊な符号を埋め込んでおく。
  • SSL 3.0 以上をサポートするサーバが SSL 2.0 で通信している場合、 RSA 復号したデータのパディング部分にこの特殊な符号があった場合、 不正な通信が行われているものとして取り扱う。

という仕組みになっています。このようなコードを v2 の実装部分に組み込んでおくことで、 実はサーバ・クライアントの4通りの組み合わせ全てでうまく接続できます。

双方が SSL 3 以上を使える場合(SSL 2 で通信していてはオカシイ場合)
攻撃によって v2 プロトコルにダウングレードさせられそうになると、 クライアントが符号を埋め込み、サーバが検知するため、接続を拒否する(ダウングレード攻撃が失敗する)。
サーバだけが SSL 3 以上を使える場合
クライアントが符号を埋め込まないため、正常に SSL 2 で通信が成立する。
クライアントだけが SSL 3 以上を使える場合
クライアントが埋め込んだ符号をサーバは単なる乱数だと思って読み飛ばすので、正常に SSL 2 で通信が成立する。
どちらも SSL 2 しか使えない場合
クライアントが符号を埋め込まないため、正常に SSL 2 で通信が成立する。サーバも検知しようとしない。

しかし、どうやら昔の Microsoft Internet Explorer 3.02 には、 「SSL3 のサポートを明示的にオフにした場合でも、符号を埋め込んでしまう」 というバグがあったようです。*1 この場合、実際には改竄が行われず SSL 2 で通信されるのが正しい場合でも、 サーバ側が符号を検知してしまい、通信が失敗します。 このバグの対処として、サーバ側で符号を検知しないオプション SSL_OP_MSIE_SSLV2_RSA_PADDING が実装され、 また当時の状況から SSL_OP_ALL にも含めることになったのではないかと思われます。 いずれにしても、9年ほど経過した現在では不要かつ有害な対処ですので、削除するのが理に適っているでしょう。

5. 実際のところ、そんなにやばいの? SSL3.0 で通信していれば問題ないんでしょ?

クライアントが SSL 3.0 と SSL 2.0 を両方有効にしている場合、 自分が SSL 3.0 で安全に通信しているつもりであっても、サーバ側に脆弱性があると、 パスワードなどを送ろうとした瞬間に突然接続を 40bit SSLv2 に切り替えられる危険性があります。

接続が SSL 2.0 に切り替えられることによって生じる脆弱性については、9月10日の『SSL 2.0 と輸出強度暗号』、9月23日の『40ビット暗号の攻撃可能性』等をご覧ください。

逆に言えば、クライアント側で SSLv2 を無効に設定していれば、サーバ側の OpenSSL に脆弱性が存在しても 問題ありません。また、クライアント証明書を使っていない場合、 SSLv2 の弱暗号を無効にしていれば、最大の危険性である 暗号解読の被害をかなり軽減できると考えることも可能でしょう。

なお、SSLv3 の輸出強度暗号(弱い暗号)は、 (解読の危険性はv2と変わらないので利用を全くお勧めできませんが、) 今回の脆弱性とは無関係です。 例え v3 の弱い暗号を有効に設定していても、v3 の強い暗号で通信できる相手同士が 今回の脆弱性によって v3 の弱い暗号で通信させられる可能性はありません。

6. どうやって調べたの?
7. どうやったら攻撃できるの?

調査する時点では、Perl で10行くらいの proxy 作って、 明示的にそこに接続させて試してます。試すだけならいわゆる ネットワーク上での中間者攻撃をする必要は無いですから。

実際にこの脆弱性を悪用するためにはネットワーク上でパケットに 悪戯をする必要がありますが、その方法についてはお答えできません :-P

8. 回避する方法はないの? 具体的な設定方法は?

OpenSSL のバージョンアップ、パッチ適応の他に、以下のような回避策が可能です。

8-1. クライアント側の対処

10/11に書いた通り、SSLv2 を無効にすることで、ダウングレード攻撃を無効化できます。副作用として、SSLv2 でしか繋がらないサイトには接続できなくなります。大多数の Web ブラウザでは、使用する SSL のバージョンを設定ダイアログから選択できます。

なお、この設定や今回の OpenSSL 側のバグ修正は、どちらも 「SSLv3 の強い暗号で繋がるべきサイトに、弱い暗号で接続してしまう」ことを防止する効果しかありません。 「弱い暗号しかサポートしていないサイト」に接続する際には、弱い暗号で接続してしまいます (そして、同様の解読の脅威があります)。 また、サーバ側が SSLv2 しかサポートしない場合には、暗号ダウングレード攻撃は今回の修正の後でも 依然として可能です(これは、プロトコル上回避できない)。

弱い暗号プロトコルで通信されることの脅威を本質的に無効化するためには、 SSLv2 と弱い暗号の両方を無効化することをお勧めします。

具体的な方法については、例えば

等をご覧ください。Opera にも(少なくとも Windows 版 8.50 には)同様の設定が可能なダイアログがあるようです。 (IE については、 9/25 で 触れていますが、副作用の危険性が高いためあまり推奨しません。 内部で何を設定変更しているのかを理解できた人以外は、 とりあえず SSLv2 を無効にするだけにしておきましょう。)

8-2. サーバ側の対処

サーバ側でも、SSLv2 を無効化することで、ダウングレードを実質的に防止できます。 内部的には OpenSSL では、「SSLv2プロトコルを無効化する」「SSLv2の暗号を全て無効化する」の 2つの設定が可能で、ごくわずかに挙動が変わりますが、どちらでも攻撃を防げます。

具体的な方法については、サーバアプリケーションによります。たとえば、Apache については gmt-24 さんが試しています。 SSLProtocol の行と、SSLCipherSuite の行が上記のそれぞれの設定に相当します。

あるいは、SSL_OP_ALL に相当する動作の有無を明示的に指定できるアプリケーションでは、 該当オプションを「使わない」方向に設定することでも回避できます。 例えば、sslwrap や openssl s_server では、 -bugs オプションを使わない限り、今回の問題は発生しません。

*1 手元で MSIE 3.02 で試せないかいろいろ探したんですが、古過ぎて環境を発掘できませんでした……。


2005-10-14

[Work] 出張

昼1時から6時まで会議で休憩5分だけってキツ杉です。

首絞め器ネクタイを1日中着けてるのは最近慣れてきてしまいました。うーむ。

[Misc] [Music] 大合奏バンドブラザーズ

これまで割と「音ゲー」には不満を持っていたので、 友人に勧められても半信半疑で買ったのだが、すっかりはまっている。

とりあえず買って1週間でアマ、2週間でプロをクリアしたのだが、 そこからでもやり込める辺りは任天堂の本領発揮か。

とりあえず現在のスコアは……

続きを読む ...

個人的に今面白いのは暴れん坊将軍あたりか。ペットとストリングの掛け合いが楽しい。

あとは、聖者の行進を譜面と関係なくアドリブで演奏するとか。結構難しいね。 苦労した割に32点とかでるけど (^^;;


2005-10-15

[Misc] Referer

ここ、システム的には tDiary なので、Referer を全部記録・公開しているわけですが、 時々「どう考えても個人の web mail っぽい」referer が紛れ込むことがあって、 やっぱり気になりますね。 ま、多分実際にはリンクをつついても認証でちゃんと弾かれるんだと思いますけど、 万が一見えちゃったら……とか考え出すと夜も眠れない(嘘)。 とりあえず手で削除していますが、結構面倒。

というわけで、実は結構マメにチェックして、URL→名前マッピングのテーブルも 随時追加してたりして。我ながら暇だねぇ。

結構、有用な情報がリンク元から得られたりするんで、リンク元表示はできるだけ 活用していきたいと思っているのですが、spam との戦いはいずれ起こるんだろうな……。

検索キーワードも結構興味深いですね。僕の日記の場合、 あまりハズレたキーワードでは検索に引っ掛からないようなので、 割と「当たり」っぽいキーワードで訪問される方が多いようですが、 それでも「あら、そのキーワードで訪問されたらガッカリしただろうなぁ」 とかいうようなキーワードとか、「あ、そういうことに関心があるのか」と 次の記事ネタの種になりそうなキーワードとか、いろいろあって面白い。

とりあえずネタの方に関しては、あまり期待しないで待っててください、という感じでしょうか。 がっかり系、例えば「試聴」とかは、どうやっても提供できませんから、 諦めてがっかりしてください :-)

[Misc] 平面グラフ

……なんて完全に数学的概念かと思いきや、結構頭使うゲームになるんだねぇ。 というわけで、誰だったかの blog 経由で拾ってきたURLですが、 Planarity。 点を並べ替えて辺の交差しないグラフに直すだけなんですが、 かなり熱い。Lv 7 辺りでかなりお手上げ感が漂います。 これもマインスイーパとかフリーセルとかと一緒で割と無限に時間を消費するので危険。

……誰のところからだったかなぁ、とちゃんと書こうとして、 思い出せずに google で引いてみたところ、山ほど紹介されている……。 というわけでわかりませんですた。ごめんなさい。


2005-10-16

[Misc] 文才

……なんてものは、自分にはない。 自分の研究紹介のプレゼンスライドだったら割と何とかなるし、 研究チームとか研究センターの紹介とか、そういった広い話をする*1のも 割と得意ではあるが、文字化された口語の文章というのは大の苦手なのである。 ……そういえば文語(論文とか申請書とか)も割と苦手だな(ぼそ)

後輩の日記とかを見てると、自分と全然違うノリになってるのもよく見掛ける。 サークル周りだと、おてうくんの日記なんかは 2ch でガイドラインスレが立つほどの有名な日記*2だし、「おまえ本気でそう思ってないだろ」とツッコミつつ 笑わされてしまう。 研究室周りだと……某S君の日記とか、「なんか最近自分を捨てて芸人化狙ってませんか?」というようなノリになりつつある*3

「笑いを取れる文章を書く」という行為は密かに憧れるところなのではあるが、 ま、どう考えても背伸びしても手の届かないことを無理にやるとスベって寒いだけなので、 引き続き今の調子でへろへろとやっていきたいと思います。あーオチない。

[Misc] おでかけ

F1中国グランプリだというのに、すっかり忘れて予定を入れてしまいましたよ!

……仕方がないので録画仕掛けて出掛けます orz

追記 (10/16)

行ってきました。 20人くらいの小さな会場でした。内容は割と一般的な説明に終始していたかなぁ。 結構開発者側からもいろいろと意見というか要求というかが出ていましたね。 発表資料の詳細は公開されるそうです。

*1 某CEATECとかね。いくら研究所が同じといっても、ロボットのことまではさすがに答えられなかった (^^;。

*2 あー、ドラクエ解くときはサイトには大変お世話になりました _o_

*3 彼、こんなキャラだったかなぁ……。いくら某T山に似てると言われたからって、芸風まで近づけなくても……。


2005-10-26

[Misc] 不調

事情があって土日全く休めなかったので、一週間が辛い……。

こういうときに限って期限の差し迫ったデスクワーク多いし……。

[Work] 後に退けない

うっ ひゃぁ ……。

研究ネタがここまで広まってしまうと、何かもう後に退けなくなってるですよ……。

頑張ります〜〜。

………そして、忙しいときに限って別の {研究|探求|調査|思考|逃避|whatever else} ネタが思い浮かぶというのも、 まぁいつものことである。


2005-10-28

[Security] IE も SSLv2 無効化へ

IE7、HTTPSプロトコル変更でセキュリティ強化』(ITmedia エンタープライズ) より。

IEblog“Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2”で、いよいよ IE7β2 で SSLv2 をデフォルト無効化する方針が明らかになったようだ。 ついでに TLSv1 もデフォルト有効だそうで。いい方向に来てますね。*1

しかしまぁ、手元にある SSLv3 ドラフトの日付が 1996. 11. 18、TLS の RFC は 1999. 1 なので、 SSLv2 の問題が指摘され、SSLv3 で解消されてから 9年ごしの解決ということになる……いくらなんでも遅すぎないか? という気もするなぁ。 TLSv1 が今までデフォルト無効だったのは何故だろう。

あと、Vista で AES256 をサポート………ってことは、 XP の IE7 では相変わらず RC4 と 3DES (と弱い暗号) しかサポートしないって事か orz。予想はしてましたけどね orz。

ついでに、8月27日 に書いた“RFC3546: Transport Layer Security (TLS) Extensions”も使う気らしい。いい方向だけど結構強気かも。 この中で今すぐ使いたいものとすれば Server Name Indication 位しか思いつかないので、 実質的には SSL Virtual Hosting のサポートを推し進めるためのサポートとみていいんだろう。 互換性は気になるところですが、まぁ有効化するって決断したからには 恐らく著名 https サーバの実装くらいはチェックしたんだろうと期待したいので、 多分大丈夫なんでしょう(笑)*2

上記の blog には、Web サーバ管理者向けの注意として、

3. If your site supports TLS, please ensure that it has a standards-compliant implementation of TLS that does not fail when extensions are present. Testing for a non-compliant TLS server is as simple as navigating to any HTTPS page on the server using IE7 on Vista Beta 2. If IE7 fails to connect, TLS extensions are the most likely culprit.

と書いてあるので、手に入ったら早速試してみようと思う。

IEblogには“TLS extensions improve performance, and add capabilities to the TLS protocol.”とか 書いてあるんだけど、RFC3546 の中で "improve performance" するものってなんかあったかなぁ……。 敢えて言うなら Certificate Status Request かなぁという感じだが、 いずれにせよ Vista β2 の IE の送出するパケット見れば何のことかは判明すると思われ。

追記 (11/2)

Mozilla に関して言えば、遥か昔 2001.12.19 に post された bugzilla の bug 116168 と、 そこから連なる 116169, 226271 辺りで議論されていた模様。
SSL 2 を併用して SSL 2 互換形式の hello を投げている限り TLS extensions が 実装できないってのは確かにその通りなので、当時はいろいろとめんどくさい回避方法を 考えていたのがわかる。尤も、議論に出てくる 「SSL 3 のリクエストを受け取るとハングアップするS SL 2 サーバ」が 本当にあるのかどうかはよくわからないのだが……。

Firefox も SSL 2 を捨てることにしたわけなので、 今が実装するいいチャンスではあるのだが、果たしてどういう方針を取るのだろうか。

そうやって考えてみると、IE7 でも SSL 2 は設定変更すれば有効にできるっぽい (「デフォルトで使えなくなる」としか書いてない)ので、その場合の挙動も調べてみないといけないなぁ。

*1 言うまでもないが、この件の説明として「デフォルトを SSLv2 → TLSv1 と変更」というのは正しくない。{SSLv3, SSLv2} → {TLSv1, SSLv3} という変更なのでね。

*2 IEblog に書いてある通り、TLS 1.0 (RFC2246) や SSL3.0 を きちんと仕様通りに実装していれば、RFC3546 を実装してなくても互換性に問題はないはずです。


大岩 寛 (おおいわ ゆたか) <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)