ActiveX や ToolBar(Browser Object) のデバッグを行うさいは、IE をデバッギー(debugee)としてVisual Studio からアタッチするのですが、今日久しぶりにやってみたら設定したブレークポイントで止まってくれません。

Visual Studio の設定ミスかと、しばらく試行錯誤しているうちに iexplore.exe のプロセスが複数いることに気がつきました。そこで、ようやく IE8 からタブごとに別プロセスで実行されることを思い出しました。

「じゃあ、自分がデバッグしたいプロセスを探してアタッチすれば。。。」と思ったのですが、毎回そんなことをやるのはさすがにめんどくさいので、Google先生に聞いてみました。

で、このサイトで解決策を発見。

IE8 がタブごとに独立したプロセスを生成しないようにレジストリの値を変更します。

• キー： HKCU\Software\Microsoft\Internet Explorer\Main
• 名前： TabProcGrowth (DWORD)
• 値： 0

Windowsネタを書くのははじめてなのか。。。

「政府機関及び金融機関のSSLサーバ暗号設定に関する調査結果について」という講演で興味深い調査結果が発表されていました。

https でサービスを提供している政府系や金融系のWebサーバーに関して、「サポートしている暗号アルゴリズム」と「実際に使用される暗号アルゴリズム」を調査したとの事ですが、ちょっと驚く結果になっていました。

曰く、調査したWebサーバのうち7割以上が新しいアルゴリズムである AES256-SHA をサポートしていますが、XP 上の IE7 では9割弱のサーバに対して比較的古くて問題の見つかっている RC4-MD5 で接続してしまうそうです。Firefox では AES256-SHA が最も多く、Vista の IE7 では AES128-SHA が最も多い結果となっていました。（Vistaでの結果も謎で AES256 が有効でも AES128 を優先して使う。）

SSL(TLS)では、サーバとクライアントがそれぞれ自分がサポートしている暗号アルゴリズムのリストを相手に示して、お互いにサポートしているアルゴリズムの中から実際に使用するものを決定します。このネゴシエーションでは「互いにサポートするアルゴリズムのうち最も暗号強度の高いアルゴリズム」が選択されるものだとばかり思っていたので、実際にはアルゴリズムの優先順位は暗号の強度とは無関係に決まっているみたいです。（IE の場合。Firefox では暗号強度の高い順になっている。）

Windows XP 用の CNG を用意しなかったマイクロソフトの判断は、今となっては間違っていたって事なんでしょうね。（2010年問題はネットブックには影響しないからいいのかな。）

もう一つ驚いたのが、SSL2.0 をサポートするサーバの数で、金融系では3割程度ですが（それでも予想よりはずっと多い）、政府系では6割程度がまだサポートしている、と。

昨年仕事で関わったサーバがユーザーの強い希望で SSL 2.0 を有効にしたのをちょっと思い出してしまいましたが、半年前の調査との比較で「AESを有効にしたらSSL 2.0も有効になった」サーバがかなりあるそうなので、誰も深く考えていないだけなのかもしれません。