高木浩光＠自宅の日記

■ なぜ一流企業はhttpsでの閲覧をさせないようにするのか

「かんたんログイン」などという似非認証方式は、たとえIPアドレス制限を実装したとしても安全でない。仕様が公開されていないからという点の他に、技術的な理由として、少なくとも次の2つがある。

1. 「IPアドレス帯域」と俗称される重要情報が安全に配布されていない。
2. SSLを必要とするケータイサイトでは、通信経路上の攻撃によってなりすましログインされてしまう。*1

2番目には解決策がない。

1番目については解決策はあるだろうが、携帯電話事業者がサボタージュしていて、実現される見通しがない。これについては、2008年7月27日の日記にも書いたが、その後どうなったかを調べてみたところ、ソフトバンクモバイル以外は、何ら改善されておらず、当時のままだった。

NTTドコモ

「iモードセンタのIPアドレス帯域」のページをhttps:// でアクセスすると、404 Not Found となる。

KDDI

「EZサーバのIPアドレス帯域」のページをhttps:// でアクセスすると、404 Not Found となる。

ソフトバンクモバイル

「Yahoo!ケータイにて利用するIPアドレス帯域」のページは、https:// でもアクセスできる。

イー・モバイル

「IPアドレス帯域」のページは、https:// でアクセスしようとしても、つながらない。ポートが遮断されている。

NTTドコモとKDDIは、ちゃんとSSLを稼働させているのに、なぜかあえて 404 Not Found にしている。せっかくSSLを正しく証明書を取得して稼働させているのに、どういうことなのか。

この違和感は、金融機関のサイトについても以前から気になっていた。

金融機関にとっては、連絡先の電話番号なども重要な情報であり、すり替えられたりしないよう、安全に閲覧できる手段を用意していてしかるべきである。それなのに、大手金融機関が、どういうわけか、それを実施していない。

以下は、「銀行」でGoogle検索して上から出てきた順に、各金融機関について現状を調べたものである。

三菱東京UFJ銀行

三菱東京UFJ銀行の「お問い合わせ先」ページ

上のページを https:// でアクセスした様子
（akamaiのサーバ証明書。ホームページをSSL対応にするつもりがないケース。）

三井住友銀行

三井住友銀行の「お問い合わせ先」ページ
（重要な用件の連絡先が書かれている。）

上のページを https:// でアクセスした様子
（EV SSLまで用意されているのに、404 Not Found になっている。）

りそな銀行

りそな銀行の「お問合せ」のページ
（重要な用件の連絡先が書かれている。）

上のページを https:// でアクセスした様子
（SSLは正常に用意されているのに、404 Not Found になっている。）

みずほ銀行

みずほ銀行の「お問い合わせ」のページ

上のページを https:// でアクセスした様子
（SSLのサーバが稼働していない。ホームページをSSL対応にするつもりがないケース。）

イーバンク銀行

「お問い合わせ」ページが見つからなかったのでスキップ。

ゆうちょ銀行

ゆうちょ銀行の「お問い合わせ」ページ

上のページを https:// でアクセスした様子
（SSL用の別サーバ wwws.jp-bank.japanpost.jp の証明書。ホームページをSSL対応にするつもりがないケース。）

別サーバ「wwws」の同じパス名に https:// でアクセスしてみた様子
（404 Not Found。別サーバで用意しているわけではないらしい。）

なんと、このように、上位5行のいずれも、問い合わせ先電話番号等を https:// ページで閲覧できるようにしてくれていない。

2008年9月にフィッシング対策協議会が公表した「フィッシング対策ガイドライン」にも、次のように書かれている。

【要件】 ◎Webサイト運営者の連絡先及びガイダンス等、顧客に間違いなく情報を伝える必要のあるページはSSL/TLSで保護すること

SSL/TLS には、機密性保護に加え、アクセスしている Web サーバの正当性(ドメイン名を含めたサーバ名と運営者との関係について認証局が確認をとっているということ)を検証する機能が備わっている。Web サイト、Web サービスに関する緊急時の連絡先及びガイダンス等、Web サイト運営者から正しく情報を伝える必要のあるページは SSL/TLS でのアクセスを可能とし、顧客が Web サイト運営者からページコンテンツが提供されていることを確認する手段を提供することが望ましい。

フィッシング対策ガイドライン, フィッシング対策協議会, 2008年9月10日

これがぜんぜん守られていない。どうしてこんなことになっているのだろうか。

ここで思い出すのが、昔からしばしば、「https:// のページは http:// でアクセスできてはいけない」などと、出鱈目なことを言う自称セキュリティ屋がいたことだ。インターネットバンキングのSSLサイトを http:// でアクセスして、アクセスできると「危ない銀行だ」などと出鱈目なことを言いふらしているのがいた。

最近でも、以下の文書がそういうことを言っている。

適切に HTTPS を使うことで通信の盗聴・改ざん・なりすましから情報を守ることができます。重要な情報を扱う場合には HTTPS で通信を行う必要があります。また特別な理由がない限りは HTTPS でアクセス可能なページは、HTTP でのアクセスを提供しないことが望ましいでしょう。

発注者のためのWebシステム/Webアプリケーションセキュリティ要件書, 株式会社トライコーダ, 2009年4月

「特別な理由がない限り」って何？ 特別な理由って何？ 理由があればいいの？ 理由がないときはなぜ提供しちゃいけないの？ *2

https:// のはずのページが攻撃者によって http:// にすり替えられることを懸念してのつもりかもしれないが、そんなのは、サーバ側で http:// を止めたところで解決にならない。攻撃者は https:// へ中継するだけだし、中継しないでそのまま偽ページを返してもいい。結局のところ、利用者自身が、見ている画面が https:// になっていることを自力で確認しないかぎり、SSLは機能しない*3のであって、サーバで http:// が稼働しているか否かは関係ない。

こういう似非セキュリティコンサルの指摘を真に受けて守ろうとするとどうなるか。

A社ホームページ http://www.example.jp/ のうち、重要な情報を掲載するページを https:// でも閲覧できるようにと、SSLを導入したとする。https://www.example.jp/important.html というページができることになるが、このSSLページは http:// でもアクセスできることになる。セキュリティコンサルが言う要件に違反してしまう。

こんな本末転倒な話があるか。似非コンサルの戯言など無視して、https:// でも閲覧できるようにするべきだ。http:// で閲覧するか https:// にするかは利用者が選ぶことだ。

このままでは、新幹線車内など公衆無線LANから銀行の電話番号を確認できないわけで、本来、こういうことは利用者がどんどん要望を出していってしかるべきことだ。私も、自分が使っている銀行については、週明けにでも電話で要望したい。