<前の日記(2004年10月16日) 次の日記(2004年10月22日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 258   昨日: 1737

2004年10月17日

電子政府つくるは素人ばかり

つくば市の電子申請・届出システムがリニューアルした。行ってみると、いきなりこんなことが書かれていた。

ご利用のブラウザ等の設定により,下の図のようなセキュリティ情報が表示される場合がありますが,問題ありません。「はい」をクリックしてください。

市役所に電話して尋ねたところ、こういう感じの応答になった。

私: 問題ないのでしょうか?

市: 問題ないですね。

私: 問題ないのにどうして出るのでしょうか?

市: そうですね……。ブラウザの設定に起因する。

私: ブラウザの設定が悪いということですか?

市: そうではない。マイクロソフトがこういうふうにしているので。

これは、https://... のページのサブフレームの中に http://... のページを埋め込んでいるために発生している。フレームの中に入れなければよいのだし、他にも解決方法は何通りもある。

それはまあ些細なこととして、もっと凄いものを目の当たりにした。申請届出システムにログインすると、こういう確認ダイアログが現れる。

これは、署名されたJavaアプレット(Sun MicrosystemsのJava VMでの起動)が使用されているために現れる、署名確認のダイアログウィンドウだが、「信頼できない団体によって発行されています」と警告印が出ている。

しかも、アプレットへの署名者の名前が「TSUAPP0002」と意味不明な記号になっている。(ここは「つくば市役所」(の英語表記)と書かれるべき部分。)

この点についても電話で市役所の担当者に尋ねたところ、こんな感じの返事だった。

NTT BizLinkという第三者機関に認証してもらった。

料金を払って証明してもらっている。

信頼できる団体と考えている。

矛盾した表示になっているが、これはマイクロソフトが……。

「TSUAPP0002」はこちらで決めた名前で、この名前でNTT BizLinkに認証してもらった。

開発ベンダーはNTT東日本。

これは、証明書の発行機関が、Java VMのルート認証局として登録されていない未信頼のところだからこういうことになる。いくら市役所の人たちが「信頼できる団体と考えている」と主張しようとも、PKIとしては全く機能していない。

PKIの基礎をまるで理解していない人達によって、電子政府は作られている。

こういうとき、ルート認証局の証明書をユーザに入れさせる自治体や中央省庁が多いが(それもデタラメなのだが)、この件もそうやって解決すればよいというものではない。その場合、最低でも、そのルート認証局の(「NTT BizLink, Inc.」の)認証局運用規定等を利用者に開示しなくてはならない。

しかし、「NTT BizLink」という会社は初耳だ。コード署名用の証明書発行認証局業務をやっているとは聞いたことがない。

「NTT Bizlink 認証」で検索してみたところ、こういうページが見つかった。

どうやら、電子入札システム用の自治体向け認証公証局サービスをやっているらしい。だが、コード署名用の証明書発行や、SSLサーバ証明書の発行などの業務については書かれていない。

可能性として次などが考えられる。

  1. 電子入札システム用として取得した証明書を、つくば市が(意味もわからず)誤って、アプレットのコード署名用として流用した。
  2. NTT BizLinkが、つくば市の依頼に基づいて、(意味もわからず)指示されるがままに適当に証明書を発行した。
  3. つくば市と開発ベンダーとNTT BizLinkが協議のうえ、「これでよい」という合議のもとでこの証明書を発行した。

電子入札システム用の証明書が勝手に流用されたにしては、その証明書発行者の認証局(電子入札公証局)証明書の名前が、「BizLink CA」というずいぶん素っ気無い名前になっていて、それは不自然だ。

コード署名用の証明書の名前欄が「TSUAPP0002」というのは、どう考えても異常な事態である。これは、スキルとか知識の問題ではない。

"TSUAPP0002"から渡された書名つきアプレットを信頼しますか?
とか、
"TSUAPP0002”はこの内容が安全であることを表明します。
とか、
"TSUAPP0002"を信頼する場合にのみ
という文章を読んで、おかしいと思わないのだろうか? 国語力が欠如しているのか? そんなことはないだろうから、ようするに単に読みもせず適当にやっているのだろう。

つくば市が「TSUAPP0002」という名前に決めたという、そのPKIに対する無理解ぶりも酷いものだが、そんなデタラメな名前の証明書を発行してしまう認証局があるということは信じ難い。

もう、日本のPKIはめちゃくちゃだ。

おそらくもう取り返しがつかないだろう。あと5年はこのままデタラメぶりが続くと予想する。

信頼済みサイトゾーンのセキュリティレベルは「中」でなくてはならない

総務省総合通信基盤局が「総務省 電波利用 電子申請・届出システム」の稼働を開始していた。その「電子申請のための準備のページを見ると、「信頼済みサイトの設定方法について」として、次のように設定するようユーザに指示している。

[セキュリティ]タブの[信頼済みサイト]を選択し、[サイト]ボタンをクリックします。 ブラウザの初期状態ではこのゾーンのセキュリティのレベルは「低」に設定されています。セキュリティのレベルは「低」「中低」または「中」に設定してください。

総務省 電波利用 電子申請・届出システム, 信頼済みサイトの設定方法について

ここは、「中」に設定しなければならないところだ。なぜなら、

[このゾーンのサイトにはすべてサーバーの確認(https:)を必要とする]のチェックをはずします。

総務省 電波利用 電子申請・届出システム, 信頼済みサイトの設定方法について

という設定をさせるからだ。

この「このゾーンのサイトにはすべてサーバーの確認(https:)を必要とする」の設定が、その意味が理解されないまま、オフにするように指示されている。

この項目がデフォルトでオンになっている理由は、[memo:4952]に書かれているように、ドメイン名だけでセキュリティゾーンを切り替えるのは、DNSスプーフィング攻撃などに弱く(SSLでサーバ証明書検証が必要とされている理由の一つ)、たとえその可能性がそれなりに小さいのだとしても、それによってセキュリティレベルが「低」となってしまうのは、リスクが可能性に比べて大きすぎるということだろう*1

実際、マイクロソフトの「ブラウジングと電子メールの安全性を強化する(ハッカーや攻撃者から身を守ることができる3 つのステップ)」という解説の中でも、「ステップ 2: 安全であると考えられる Web サイトを [信頼済みサイト] に追加する」という指示があるが、きちんとその後に、

[このゾーンのセキュリティのレベル] にあるスライダのつまみを [中] に移動します。 これにより、信頼するすべての Web サイトのセキュリティのレベルが [中] に設定されます。
と、正しい手順が書かれている。

総務省総合通信基盤局と同じ過ちは、他にも随所に見られる。

たとえば、7月24日の日記「パソコンユーザを国際電話ダイヤルアップ被害に陥れるNEC」で、「「署名済みActiveXコントロールのダウンロード」の「有効」チェックボックスをチェックします」というとんでもない危険な設定を指示していたことを書いたが、その後このページは改定されて、代わりに、信頼済サイトゾーンを使う設定方法が追記されたが、

「次の Web サイトをゾーンに追加する」に次のURLを入力し、「このゾーンのサイトにはすべてサーバーの確認(https:)を必要とする」のチェックを外して「追加」ボタンをクリックします。

NECパーソナル商品総合情報サイト 121ware.com サポート情報番号 004532

と指示しているにもかかわらず、信頼済みサイトゾーンのセキュリティレベルを「中」にするようには指示していない(デフォルトでは「低」)。

素人にセキュリティ設定の説明を書かせるのは、いいかげんやめて頂きたいものだ。

これはスキルとか知識の問題ではない。セキュリティ設定というシビアなものについて、デフォルト設定でチェックされているもののチェックを外させるということは、それが何を意味するかを当然考えてみてしかるべきだ。考えても意味がわからないのなら、セキュリティを業務にしている人に相談してからにするべきだろう。

使ってもいない機能を意味もわからず有効にさせる人たち

総務省 電波利用 電子申請・届出システムの解説には、こんなものもある。

本システムでは、通信を行うためにクッキー(Cookie)を利用します。下記の手順でブラウザのクッキーの設定を確認してください。

ブラウザの初期状態ではプライバシーの設定は「中」に設定されています。 (略) 3.[自動Cookie処理を上書きする]をチェックし、[受け入れる]又は[ダイアログを表示する]を選択してください。

総務省 電波利用 電子申請・届出システム, 電子申請のための準備 3.ブラウザの確認 - クッキー(Cookie)の設定を確認

図のように、サードパーティのCookieも「受け入れる」にしろと指示している。

本当にサードパーティのCookieを使っているのか? 普通は使う必要がないはずだ。初期設定の「中」で、正常に動作するのではないのか?

仮に初期設定の「中」では動かないシステム構成になっているのなら、P3Pのコンパクトポリシーを提示するよう、Webサーバを設定して解決するべきだ。

ようするに、意味もわからずプライバシー設定を変えさせ、人々のプライバシーを犠牲にしている。

同じことをやっているところは非常に多い。たとえば、山梨県の電子申請システムの解説も同じようになっている。

こういうのは、見よう見まねでどんどん感染拡大していくのだろう。もう、止めようがない。

Internet Weekよ、あんたもか

Internet Week 2004の参加申し込みサイトの「よくあるお問い合わせ(FAQ)」にも、次のような指示がある。

【JavaScriptの設定】
  1. メニューバーの[ツール]-[インターネットオプション]を選択します。
  2. [セキュリティタブ]を選択します。
  3. [レベルのカスタマイズ]を選択し、[Java]の項目で[安全性‐高]にチェック。また、[スクリプト]の項目で[Javaアプレットのスクリプト][アクティブスクリプト][スクリプトによる貼り付け処理の許可]のそれぞれ[有効にする]にチェックし、[OK]を押してください。
Internet Week 2004, よくあ るお問い合わせ, Q2.登録・ログオンができません

本当におまえはJavaを使っているのか? と問い詰めたい。JavaScriptとJavaの区別も付かないだけではないのか? 本当に「スクリプトによる貼り付け処理」をこのサイトで使っているのか? 「スクリプト」と書かれているから意味もわからず、とりあえず「有効にさせときゃいい」と安易に考えているんじゃないのか?

「スクリプトによる貼り付け処理の許可」は「無効にする」にしておかなくてはならない。その理由は以下に説明されている。

*1 Windows XP SP2 で導入されたポップアップウィンドウのブロック機能で、ブロックしないサイトの登録機能に https 云々の機能がないのは、DNSスプーフィングの攻撃の可能性に比べて、それによる結果のリスク(ポップアップウィンドウが出る)が十分に小さいためだろう。

本日のTrackBacks(全3件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20041017]

某市の電子申請・届出システムも心配です

フィッシング関係のセキュリティホール(1)&nbsp; の続き ■ IE 6 に欠陥 URLにワイルドカード 2004.06.11  国内記事は IE6のセキュ

Outlook Expressのプレビューについて  を書いていて 「ActiveX をオフ→ http://www.ipa.go.jp/security/c

検索

<前の日記(2004年10月16日) 次の日記(2004年10月22日)> 最新 編集

最近のタイトル

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|
<前の日記(2004年10月16日) 次の日記(2004年10月22日)> 最新 編集