IEのCRL取得失敗時の警告

OCSPレスポンダで遊んでいるときに気づいたのだが、IE7/8はSSL通信時にCRLの取得に失敗した場合でも、証明書を正常なものとして取り扱ってしまうようだ。気になって調べたところMicrosoftからKBが出ていた。「KB946323 Internet Explorer 7 does not send you any notification if it cannot obtain the Certificate Revocation List」

警告を出す事はできるけどデフォルトでは出ないと。うーむ。デフォルトで出した方がいいと思うんだが...

iSCSIが遅かった理由

先日からiSCSI + ESXiの環境を組んでいたのだがiSCSIディスクアクセスの速度が妙に遅くて困った。1000Base-Tなのに120Mbps程度しか出ていない。明らかに異常なのでトラブルシューティングをしてみた。

環境：

• iSCSI Target : D945CGLF2 + Realtek 8111D（オンボード）, NetBSD 5 Xen DOMU上のiSCSI Target
  
• iSCSI Initiator： Intel DQ45CB , Q8400, Intel 1000/PT (PCI-Express) ESXiをインストール
  
• その他：Apple Macbook Late 2007, Marbell Yukon 2, Mac OS X 10.5をインストール
  

問題は、iSCSI Targetと Initiator間の速度が出ない事。

iSCSIでベンチマークを取るとディスクアクセスに性能が引っ張られてしまうので、今回はUNIX系ではおなじみのネットワーク帯域測定ツールのnetperfを使って速度を計測した。Macbookをサーバーとし、各マザーに色々なOSを入れて計測してみたところ以下のような結果になった。

D945CGLF2 + NetBSD 5 amd64 Xen DOMU : 　120Mbps
D945CGLF2 + NetBSD 5 amd64 Xen DOM0 : 　110Mbps
D945CGLF2 + NetBSD 5 amd64 Xen GENERIC Kernel : 440Mbps
D945CGLF2 + CentOS 5 amd64 Xen DOMU : 200Mbps
D945CGLF2 + Puppy Linux 4.2 i386: 840Mbps
DQ45CB(Intel 1000/PT) + Puppy Linux 4.2 : 680Mbps

うわぁ。120Mbpsってなんだよ....NetBSD Xenとの相性が最悪じゃん。コリャダメだ。ファイルサーバーをXenにしたのは間違いだったか。NetBSD 5 + Generic kernelでもあまり速くないし、NetBSDは全般的に遅めの傾向。iSCSI TargetはLinuxで組み直そうかな。

この中ではLinux + D945CGLF2が一番速い。CPU負荷が若干高くなるような気がするけど、これだけ速度に差があるとそれも許せてしまうかも。Realtekは悪い意味で有名だったけど少し考え直そう。枚数を用意するときはコレでもいいかも。

IIS7によるTLS Staplingを使った失効情報の配布

IIS7とIE8の環境でOCSPのサポートがどんなもんかなーっと調査していたら、失効はうまく認識するのに、一向にOCSP(via HTTP)通信をしている気配が無い。散々いじくった結果、IISがTSL Staplingを使用して失効情報を配布していると言うことがわかった。そんな裏ワザがあったとは！

環境はこんな感じ

• Windows Server 2008 EE SP1
  * ADDS
  * ADCS
  Enterprise CA
  OCSP Responder
  * IIS 7 & SSL
  SSL用の証明書は失効済み＆失効情報をOCSP Responderで配布
  SSL用の証明書にはCDPを含まない
  SSL用の証明書のAIAにOCSP拡張を含む
  
• Windows Vista SP2
  * Internet Explorer 8

この環境でIE8を使ってSSL通信をする。SSL用のサーバー証明書は失効されており、失効情報はOCSPを用いて公開されている。また、証明書にはOCSPレスポンダへのポインタしか含んでいないので、OCSP(via HTTP)で失効情報を入手するはずだ（と思い込んでいた）。実際にやってみると証明書の失効自体はうまく検出され、IEに「この証明書は失効されています」と表示される。しかし、以下の現象が私を悩ませた。

• イベントログのCAPI2の箇所を見ると、「失効の確認」のイベントでOCSPの情報を入手している。
• Microsoft Network Monitorでトラフィックを観測すると、OCSP(via HTTP)通信をしていない。
• ファイアウォールでHTTPをブロックしてもOCSP情報が取得できる。

うんうん悩んでたら、去年のPKI Dayでマイクロソフトの人が、OCSPとTLS Staplingについて話していた事を思い出したので、資料(PDF)を探してきた。TLS Staplingというのは、SSLハンドシェイク時にWebサーバーが自分自身の証明書の失効ステータスを送信する方法だそうな。

さっそく、Network Monitorで見ると....あったあった。SSLの最初のハンドシェイクの時に、「Server Hello. Certificate. Certificate Status.」を送っている。コイツだったのか...

IISは特に意識をせずにセットアップしたので、デフォルトでオンになっているということか。ちょっと探しただけでは、オフにする方法は見当たらなかった...どこだぁ。

HP Procurve Switch 1400-8G購入

100Base-TXでiSCSIを使用しているとだいたい8〜9Mbyte/Sec程度の速度しか出ない。さすがにキツいので1000Base-Tのスイッチを購入した。購入したのはHP Procurve Switch 1400-8G。通常の8ポートのノンインテリジェントスイッチでお値段は12000円。このクラスの製品では少し高い方になる。

あまり知られていないが、HPのスイッチは全製品に永久保証がついている。以前、職場の古いシャーシスイッチが故障したときは、24時間後には交換部品が到着し業務に復帰できた。特に、追加コストも保守契約の更新もなく保守が受けられるのはとてもありがたい。ちなみに、日本ではどうだか知らないが、海外ではシェアは2位なんだそうな。

さて、問題となっていたiSCSIの速度は...遅い。17MByte/Secがいいところ。まいったな。NetBSD5+ Realtek 8168B/8110Sだとジャンボフレームが使えないのか。あー、ドライバーのソースによるとこのチップのリビジョンだけMTUは1500以上は指定できないようになっとるorz...。ちなみにチップ自体は7Kbyteまでのジャンボフレームに対応しているそうなので、ドライバーの対応待ちといったところか。

DQ45CB BIOSアップデート0083

IntelよりDQ45CBのBIOSアップデートが公開された。これで今までのNew Fixes/Featuresの合計は98件になった。今回のアップデートではBIOS Update用のF7メニューと、謎の機能のF10メニューも追加になる。

New Fixes/Features:

• Added BIOS F10 menu feature.

• Fixed issue where system could not boot normally after the system

password entered with a customer logo modified BIOS generated with

Intel® Integrator Toolkit.

• Fixed issue where system does not refresh display screen when

power-button is used to bring out of S3 state.

• Fixed issue where WHQL test would fail with E5200 processor.

• Added option for F7 update BIOS menu.

• Fixed issue if USB Emulation type is set as Auto, the disk format

should depend on the media format.

• Fixed issue where splash screen disappears after the password

entry screen

• Updated processor support.

散々、キツいことを言ってきたがDQ45CBもだいぶ安定してきている。意外とコストパフォーマンスも高いし、もう一枚くらい買ってもいいかなと思っている。