[ぴ]

トップ最新追記

日記+コメント付きブックマーク+他人にも役に立つかもしれない情報など。
(更新情報: RSS(ツッコミ付き) / RSS(ツッコミ抜き) / LIRS)

2006/09/29 編集

_ [他] 究極の“仮眠枕”を求めて――「聞こえるごろ寝まくら」編@ITmedia

今愛用してるはまりんビーズクッションがいよいよダメになった暁には買ってみようかと

本日のツッコミ(全2件) [ツッコミを入れる]

_ りそ [いつのまにそんな骨の髄まで横浜ラヴな奴になったんだ・・]

_ p [はまりん最強だから]

2006/09/28 編集

_ [システム運用] 総務省認証局・LGPKI のルート証明書が特例措置で IE 標準装備になった件

Windows(R) Updateによる電子政府システム向けルート証明書の配信を開始@Microsoft

マイクロソフト、電子政府システムのルート証明書をWindows Updateで配布@INTERNET Watch

Windows Updateで電子政府システム向けルート証明書の配信を開始@ITmedia

マイクロソフトが電子政府システムのルート証明書をWindows Updateで配布@ITPro
(日経本紙では「『電子政府』手続き簡略化」という見出しで、一見意味不明な内容でしたが、こっちの記事はストレートですね)

政府・官公庁の証明書をMSがWindows Updateで配布@/.J

というわけで、高木浩光@自宅の日記を中心に糾弾されてきた GPKI/LGPKI のルート証明書配布問題 (LGPKI Application CAに将来はあるのか) が、ここに来てかなり改善されることになりました。

それにしても、今回のマイクロソフトの対応はちょっと驚きです。

通常の Windows Update なら、「ルート証明書の更新プログラム」は「重要な更新」カテゴリに位置づけられていないため、自動更新でインストールされることはなく、ユーザ自身が Windows Update サイトを訪れて更新プログラムを能動的に選択してインストールしないといけなかったのに (実際 Windows 2000 に関しては今回もそう)、今回に限っては、Windows XP、2003、Vista では、LGPKI アプリケーション CA (第二世代) から発行されたサーバ証明書を持つサーバにアクセスすると、サーバにアクセスした瞬間に自動的にルート証明書がインストールされるようになっています。

第二世代アプリケーション CA を使用しているサーバの一つとして、広島市の電子調達システムのページ https://ebid.keiyaku.city.hiroshima.lg.jp/CALS/Accepter/ を例に流れを追ってみました。

まず、事前に Internet Explorer の信頼済みルート証明機関のリストを確認した。
信頼済みルート証明機関(1)
LGPKI Application CA G2 はリストに登録されていない。

次に、広島市の電子調達システムのページ https://ebid.keiyaku.city.hiroshima.lg.jp/CALS/Accepter/ にアクセスしてみると、
広島市電子調達システム
何の警告もなく表示され、証明書情報を確認すると、Application CA G2 から証明書が発行されていることが確認できる。

改めて信頼済みルート証明機関のリストを確認すると、
信頼済みルート証明機関(1)
いつの間にか Application CA G2 がリストに追加されている。

https://ebid.keiyaku.city.hiroshima.lg.jp/CALS/Accepter/ に初回アクセスした時のアクセス状況を Proxomitron で追ってみた。

+++GET 801+++

CONNECT / HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727)
Host: ebid.keiyaku.city.hiroshima.lg.jp
Content-Length: 0
Proxy-Connection: Keep-Alive
Pragma: no-cache

+++SSL 801:+++

SSL Pass-Thru: CONNECT https://ebid.keiyaku.city.hiroshima.lg.jp:443/

+++GET 802+++

GET /msdownload/update/v3/static/trustedr/en/authrootseq.txt HTTP/1.1
Accept: */*
User-Agent: Microsoft-CryptoAPI/5.131.2600.2180
Host: www.download.windowsupdate.com
Cache-Control: no-cache
Pragma: no-cache
Connection: keep-alive

Browser reload detected...

+++RESP 802+++

HTTP/1.1 200 OK
Content-Length: 18
Content-Type: text/plain
Last-Modified: Thu, 07 Sep 2006 16:14:19 GMT
Accept-Ranges: bytes
ETag: "889293ac98d2c61:803a"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Thu, 28 Sep 2006 16:26:26 GMT
Connection: keep-alive

+++CLOSE 802+++

+++GET 803+++

GET /msdownload/update/v3/static/trustedr/en/authrootstl.cab HTTP/1.1
Accept: */*
User-Agent: Microsoft-CryptoAPI/5.131.2600.2180
Host: www.download.windowsupdate.com
Cache-Control: no-cache
Pragma: no-cache
Connection: keep-alive

Browser reload detected...

+++RESP 803+++

HTTP/1.1 200 OK
Content-Length: 21083
Content-Type: application/octet-stream
Last-Modified: Thu, 07 Sep 2006 22:44:50 GMT
Accept-Ranges: bytes
ETag: "3ff953acfd2c61:803a"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Thu, 28 Sep 2006 16:26:26 GMT
Connection: keep-alive

+++CLOSE 803+++

+++GET 804+++

GET /msdownload/update/v3/static/trustedr/en/968338F113E36A7BABDD08F7776391A68736582E.crt HTTP/1.1
Accept: */*
User-Agent: Microsoft-CryptoAPI/5.131.2600.2180
Host: www.download.windowsupdate.com
Cache-Control: no-cache
Pragma: no-cache
Connection: keep-alive

Browser reload detected...

+++RESP 804+++

HTTP/1.1 200 OK
Content-Length: 932
Content-Type: application/x-x509-ca-cert
Last-Modified: Thu, 29 Jun 2006 03:13:10 GMT
Accept-Ranges: bytes
ETag: "0278f3299bc61:803a"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Thu, 28 Sep 2006 16:26:26 GMT
Connection: keep-alive

+++CLOSE 804+++

以上のログから流れを追うと、IE は「アクセス対象が未知のルート認証局から発行された証明書で保護されており」「かつ何かしらの条件を満たした場合」に、

http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt をチェックし、
(authrootseq.txt の中身は何かのハッシュ値と思われる18文字の16進数。次の authrootstr.cab の更新有無確認用?)
http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab をダウンロードし、
(authrootstl.cab の中身は証明書信頼リスト authroot.stl が含まれている)
authroot.stl にあって自分のリストにはない証明書 (今回は http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/968338F113E36A7BABDD08F7776391A68736582E.crt) をダウンロードしインストールする
(968338F113E36A7BABDD08F7776391A68736582E.crt は、https://www.lgpki.jp/CAInfo/AppCAG2.cer と同一のものだった)

ということが裏でこっそり行われるようだ。

WindowsUpdateによる電子政府システム向けルート証明書の配信について@Lucky Lovely Laboratory に書かれているように、上の自動インストールフローでは、自動ダウンロードが全て HTTP で行われているのが気になりましたが、2番目の authrootstr.stl がデジタル署名されているようなので、そこで検証されているのでしょう、おそらく。

IE のどのバージョンからこんな機能が実装されていたのか、気になるところです。マイクロソフトは内閣官房の要請を受けてこんな機能を作り込んだのでしょうか。それとも IE には実はだいぶ前からこのような仕組みを用意してあって、今回もそれを利用したに過ぎないのでしょうか。謎です。

ところで、LGPKI の自己署名証明書配付ページを久しぶりに確認したところ、自己署名証明書そのものもフィンガープリント一覧も、以前は生 HTTP だったのに、いつの間にかベリサインのサーバ証明書で保護された状態に変わっていました。(サーバ証明書の発行日は2006/07/11) その辺も改善されているようです。(もっとも自己署名証明書のダウンロード案内ページは保護されていないので、ログイン画面を SSL で保護していない脆弱性?とほぼ同様の問題が残っていますが)

「LGPKI の自己署名証明書・フィンガープリント一覧のページがオレオレ証明書化している, Mac OS X がいつの間にか LGPKI 対応になっていた」に続く。