日記+コメント付きブックマーク+他人にも役に立つかもしれない情報など。
(更新情報: RSS(ツッコミ付き) / RSS(ツッコミ抜き) / LIRS)
- p (01/03)
- Thiramil (10/26)
- 久々にいまむらを食べたい通りすがり (09/28)
- Fluxadir (05/16)
- Antiprestin (11/08)
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 の信頼済みルート証明機関のリストを確認した。
LGPKI Application CA G2 はリストに登録されていない。
次に、広島市の電子調達システムのページ https://ebid.keiyaku.city.hiroshima.lg.jp/CALS/Accepter/ にアクセスしてみると、
何の警告もなく表示され、証明書情報を確認すると、Application CA G2 から証明書が発行されていることが確認できる。
改めて信頼済みルート証明機関のリストを確認すると、
いつの間にか Application CA G2 がリストに追加されている。
https://ebid.keiyaku.city.hiroshima.lg.jp/CALS/Accepter/ に初回アクセスした時のアクセス状況を Proxomitron で追ってみた。
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:+++
+++GET 802+++
Accept: */*
User-Agent: Microsoft-CryptoAPI/5.131.2600.2180
Host: www.download.windowsupdate.com
Cache-Control: no-cache
Pragma: no-cache
Connection: keep-alive
+++RESP 802+++
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
+++GET 803+++
Accept: */*
User-Agent: Microsoft-CryptoAPI/5.131.2600.2180
Host: www.download.windowsupdate.com
Cache-Control: no-cache
Pragma: no-cache
Connection: keep-alive
+++RESP 803+++
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
+++GET 804+++
Accept: */*
User-Agent: Microsoft-CryptoAPI/5.131.2600.2180
Host: www.download.windowsupdate.com
Cache-Control: no-cache
Pragma: no-cache
Connection: keep-alive
+++RESP 804+++
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
以上のログから流れを追うと、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 対応になっていた」に続く。
_ [システム運用] 「安全な通信を行うための証明書」と呼ぶ悪習
それにしても、GPKI/LGPKI のルート証明書のことを「安全な通信を行うための証明書」と呼ぶ悪習はいったいいつまで続くのか。
まるで他の認証局の証明書では安全な通信は行えないみたいな呼び名ですね。よく各社が総務省に苦言を呈さないものだ。
よくわかりませんがなんか凄そうでつね。
私がIEへの標準装備とLGPKI の自己署名証明書配付ページの保護化で喧嘩のようなやり取りをしてから、4年ぐらいたつのかな。<br>やっと、ここまで来ましたか。<br>最初は「予算が･･･」とか言っていたのにね。<br>これも高木さんを始めとする国民の皆さんの抗議の声の賜物でしょうね。感謝。<br>まあ、LGPKIの都道府県や市区町村に分散しているという複雑な構造を解消するのに2年ぐらいかかったわけで、意外と早かったですね。<br>2年前（3年前だったかも）の地方への予告どおり18年中にやってしまうとは、正直言って思ってませんでした。(w<br>これで住民の皆さんに胸を張ってLGPKIを使えるようになったわけで、嬉しいと言いたいところですが、待っている間に異動しちゃいました。(w
ＭＳが信用することに決めた認証局は暗黙のうちにインスコか！<br>IEのルート証明書ストアって正体不明なのいっぱい入ってるんだが、逆になんで今まで入れてもらえてなかったのかね…<br>金か。
今までは監査をパスできなかったから… (今でもまだパスしてないようですが)<br>http://takagi-hiromitsu.jp/diary/20050115.html#p02<br>http://slashdot.jp/comments.pl?sid=334724&cid=1029479
ちなみに↑の「ぴ」さんは、本日記の所有者である漏れとは別人ですょ!漏れは異動してませn!<br>そういえば、自分も2年くらい前に<br>> IEへの標準装備とLGPKI の自己署名証明書配付ページの保護化<br>のような話はしましたが、「予算が…ごもごも」という応答だった気がします。<br>前者はともかく、後者は「年間8万程度の出費まで予算云々になるのかょ!」と心の底で思いつつ引き下がったような気がしますね…<br>たぶん予算的な話じゃなくて http://slashdot.jp/comments.pl?sid=334724&cid=1029335 に書いてあるような「政府の言わば公的な組織認証というものを民間に信頼の起点をゆだねることになってしまう」を割り切れなかったということなんでしょうが…
失礼！管理人様、pというお名前でしたか。<br>通りすがりで書き込んでしまい、紛らわしい名前をつけてしまってすみません。<br>/.Jでの詳細な解説ありがとうございます。<br>まあ、4年前にお話した時の担当者様とその上司2名は、事の重大さが全然わかってらっしゃらなかったですけどね。<br>最初は、LGPKIのフィンガープリントを掲示する市区町村のサイト（もちろん保護なし）が増えれば解決する問題だなどと本気で言ってらっしゃいましたし。<br>やはり、初期のころは総務省内でもわかってらっしゃる方は一握りだったのではないでしょうか。<br>高木様を始めとする啓蒙の成果と言うのは大きいと思っています。<br>というわけで、一地方自治体の一担当者であった私は、飛ばされて今はちまちまと税金の回収をしているわけで、この問題とは全く関係ないわけですが。
> それとも IE には実はだいぶ前からこのような仕組みを用意してあって、今回もそれを利用したに過ぎないのでしょうか。<br>こちらです。Windows XPから、ルート証明書ストアは自動的に更新されるようになっています。<br>http://memo.st.ryukoku.ac.jp/archive/200205.month/3827.html
ありがとうございます。<br>なるほど、Windows XP 提供当初からでしたか…