SSLについて考えること

サイトのお問い合わせページ、会員応募ページ、イベント参加応募ページなどの個人情報を入力するページでは、URLが「https://」で始まるSSL通信がよく使われています。またレンタルサーバーの運営は、基本サービスとして共有SSL（共用SSL）を、有料オプションとして独自SSLを提供しています。本稿ではページをSSLにするかどうか考える際に「考慮すべき事項」を考えます。

本稿を記載するにあたっては、IMAMURA BIZさんの「【wordpressのお問い合わせフォームをSSLで動かすのをやめました】contact form 7 + 共用SSLはやらないことにした」に大いに影響を受けました。また本稿は、個人情報を取り扱うことについての考察であり、その他の脅威に関しては取り扱っていません。

基礎知識

何となくSSLやサーバー証明書という言葉を知っているつもりでしたが、改めて確認しました。

SSLって何？

Wikipediaのページ（特にイラスト）がわかりやすかったです。インターネットは通信経路上に様々な機器があり、保守のために通信が覗けたりログが残ったりします。通信を暗号化すれば覗かれても何が書かれているか簡単にはわかりません。

サーバー証明書って何？

サイバートラストさんの「SSLサーバ証明書の基礎知識」のページが的確でした。サーバー証明書は「サイトの運営組織の実在証明」が目的です。（実在証明がユーザーの目に見えるように、ページ上に貼る「サイトシール」も発行してくれます。）通信経路が暗号化されても、そもそも運営組織自体が怪しければ個人情報（特に決済情報）は渡せられません。認証局（以下CA）のサーバー証明書を取得して独自ドメインにてSSL通信を行うことを、以降「独自SSL」と表します。

共有SSLとは？

サーバー証明書をレンタルサーバー運営者が取得しており、その証明書を利用する形で、レンタルしている人がSSL通信可能なページを作れるようにするサービスです。従って共有SSLのURLのホスト名は、レンタルサーバー運営者の所有するドメインか、そのサブドメインになります。詳しくは、Impress Business Media, レンタルサーバー完全ガイド「第8回　独自SSLとは、どこが違う？ 共用SSLの仕組みと利用上の注意」をご参照ください。

共有SSLの利用について

共有SSLを使うに当たって考えるべき項目は以下の通りです。

信用とコスト

上記のように、共有SSLは「レンタルサーバー運営者の実在証明」はなされていますが、「サイト運営者の実在証明」はなされていません。従って信頼されるに足るサイト運営を行うのであれば、サーバー証明書を取得すべきです。

とはいえ、資金力のないコミュニティではサーバー証明書の維持コスト（年数万円）はばかになりません。そこで共有SSLを選択してしまいがちです。

CMSの技術的な問題

WordPress自体、異なるホスト名（ドメイン）をまたがって構成されるサイトを想定して作られていません。（他のCMSも同様なのではないでしょうか。）またCookieで管理される情報（ログイン情報など）も共有できません。

従って、WordPressにて無理に共有SSLを使おうとすると、「共有SSLをWordPressのサイトで使う」に書いたような、複雑な設定が必要になります。しかも完全な統合はできず、不具合が残ります。（プレビューできない、など。）

共有SSLの危険性

共有SSLの危険性についてもインターネット上に様々な記事があります。第三者にCookieを取得されるというもので、まとめると以下の様になります。

• 「https://代表ホスト名/ユーザー名/」のようなURLの共有SSLでは、Cookieの設定時にドメイン名のみを指定した場合は、同じホストに割り当てられている他のサイト管理者にCookieを取得されてしまう。
• ではCookieの設定にパス指定をすればよいかというと、攻撃者がjavascriptを利用すれば意味をなさない。※1
• BASIC認証のパスワードも他のサイト管理者に取得されうる。※2
• 他のサイトの管理者に覗かれるだけでなく、第三者の攻撃による脆弱性もある。※1

（※1高木浩光＠自宅の日記さんの「2010年05月01日」、※2どさにっき 2.0さんの「2006年3月11日(土)」）

現在おおよそのレンタルサーバーで提供されている、サブドメインを割り当てる方式の共有SSLでは、上記の危険性は当てはまりません。

ブラウザの表示

ユーザーの意識について考える前に、SSL接続に関する各ブラウザの表示を見てみます。（ちょっと前は「セキュアな通信に入ります。」とか「セキュアな通信から抜けます」とかブラウザがうるさかったような気がしますが最近みませんね。）

CAによるサーバー証明書のないSSL

まずCAによるサーバー証明書のないサイトにSSL接続した場合の、各ブラウザの表示を見てみます。（各ブラウザは2013年10月6日現在のバージョンです。）

Google Chrome

Chromeは画面が真っ赤になり、非常に危険な気がします。「先に進まないでください」とも書いてあります。

Mozilla FireFox

FireFoxは薄い黄色です。書いてあることは中立的ですね。

Internet Explorer 10

IEはやや赤。「このページを閉じて、このWebサイトの閲覧を続行しないことを推奨します。」とのこと。

Apple Safari

Safariはダイアログボックスです。他のブラウザよりも危機感がありません。

URL表示部のアイコン

SSL接続時の、URL表示部のアイコン表示をまとめると、以下の表のようになります。

	サーバー証明書なし	ページ内で非SSL参照あり※	ページ内で非SSL参照なし
Google Chrome
Mozilla FireFox
Internet Explorer 10
Apple Safari

（※「ページ内で非SSL参照あり」は、ある企業のお問い合わせページでの表示結果です。このページではCSS、JS、画像等のリンクは相対リンクになっていました。これらが非SSLの場合はより危機的なイメージの表示になるかもしれません。）

IE10とSafariでは、URL表示部の右端にアイコンが表示されます。FireFoxの場合は、SSL接続のときにページ内に非SSL参照があると自動的にブロックしてくれるようです。

ユーザー層

サイトを訪れてくださるユーザーの意識、あるいはインターネット・リテラシーについて考えます。ユーザー層として、以下の３タイプを考えました。（名前はそれほど意味を成しません。またMECEでもないかも。）

知識層

SSLやサーバー証明書に対する知識がある、ネット・リテラシーが高い層です。CAによるサーバー証明書を求められるかもしれません。あるいはサイト運営者を信頼している場合は、CAによるサーバー証明書がないSSLによってブラウザが警告を表示したとしても、先に進んで進んでくれるかもしれません。

一般層

SSLが暗号化接続ということを知っており、ブラウザのURL表示が「http://」か「https://」どうかを気にします。そしてCAによるサーバー証明書のないSSLに対するブラウザの警告にはびっくりします。カード情報などの重要な情報のみにSSLを求める層と、個人情報全般にSSLを求める層に分けられそうです。

無関心層

URL表示が「http://」か「https://」かどうかを気にしません。CAによるサーバー証明書のないSSLに対するブラウザの警告にはびっくりします。

サイト運営者の選択オプション

サイト運営者が取りうるオプションとしては、独自SSL、共有SSL、CAによるサーバー証明書なしのSSL、非SSLの4パターンが考えられます。それらについてのメリット、デメリットをまとめると以下の様になります。

	メリット	デメリット
独自SSL	通信が暗号化される。 信用が付加される。 全てのユーザー層に受け入れられる。	コストがかかる。
共有SSL	通信が暗号化される。	運営者の実在証明を求める知識層には受け入れられない。 CMSを利用する場合、手間が必要。（技術、管理）
CAによるサーバー証明書なしのSSL	通信が暗号化される。	ブラウザに警告が表示されるので、一般層や無関心層には受け入れられない。
非SSL		通信が暗号化されない。 個人情報の暗号化を求める知識層、一般層には受け入れられない。

デメリット欄に「（特定のユーザーに）受け入れられない」と書きましたが、説明を書いてユーザーに受け入れられる努力をすることは可能です。例えばサーバー証明書なしのSSLの場合でも、サーバー証明書がない理由、SSLにする理由、ブラウザに警告が出てしまう旨をリンクするページに記載しておけば、それを読んで同意したユーザーはブラウザに警告がでても先に進んでくれるかもしれません。

またCAによるサーバー証明書なしのSSLの場合、ユーザーに、独自発行したサーバー証明書をブラウザに登録する作業をしてもらう、という手があります。しかしそれぞれのブラウザ、それぞれのバージョンに対して作業を解説するのは大変ですし、ユーザーにとっても心理障壁になります。

個人情報流出リスク

WEBページをSSLにしたとしても、他に個人情報流出リスクはあります。WordPress＋Contact Form 7プラグインのように、フォームに入力された内容をメールで管理者に送信する場合は、そのほとんどが平文（暗号化されていない文）だと思います。

フォームに入力された個人情報をサーバー内で保存し、管理者がSSLで閲覧するのであれば、通信経路は暗号化されます。しかしサーバー内の個人情報流出リスクは考慮する必要があります。

また管理者が、自分のPCのExcelなどで個人情報を管理した場合、そのファイルの流出リスクも考慮する必要があります。（サーバーの情報をエクスポートする場合も同様です。）

いずれにせよ、フォームを利用したユーザーに対する回答は通常メールにて行います。もちろん平文ですので、もはやお問い合わせページだけをSSLにする必要自体ないのかもしれません。

私の考え

（2014年6月7日修正：ブログの引っ越しに伴い、大きく修正しました。）

本章では、共有SSLの利用についての私の考えを書きたいと思います。（他のサイト運営者の方々にもそれぞれの考えがあると思います。）

共有SSLの理由

まず「自分の個人情報が覗かれる状態にあるのは気持ち悪い」というユーザーを想定します。そして「自分のできうる限りはそのリスクを減らす」というのがポリシーです。従って非SSLは考えません。

CAによるサーバー証明書なしのSSLについては、ブラウザの警告にびっくりして先に進まないユーザーが想定できますので、却下です。（独自発行のサーバー証明書を登録して頂くのも心理障壁になります。）

独自SSLは、経済的に余裕があれば導入するとよいのですが、特定ページの暗号化をする目的だけであれば、費用対効果は少ないです。

WordPressで共有SSLを使う技術的課題も（私は）クリアできますので、以上を鑑みて、お問い合わせフォームのみなのであれば、共有SSLで対応するのが良いと考えます。

もしユーザーの決済情報をお預かりする場面があり、信用を考慮しなくてはならない、という段階になったらサーバー証明書の取得を検討することになると思います。

内部でのメール送信

お問い合わせフォームをSSLにしたとしても、内部で平文のメールを送信しているのであれば、個人情報の流出リスクは残ります。

サイトと送信先メールアドレスのメールボックスが同じサーバーにあるのであれば、メールヘッダをみて通信が外に出ていないことを確認し、メーラーとメールサーバーの通信は暗号化を設定します。以上で通信路における個人情報流出リスクは低減できます。

PHPにはopenssl_pkcs7_encryptという関数がありますので、S/MIME対応の暗号化メールを送信するフォーム・プラグインも作れるかもしれません。

お問い合わせ管理ツール

とりあえずメーラーとメールサーバーの通信の暗号化の設定をしたとしても、担当者が変わり同様の設定をしなければ、個人情報が平文で流れてしまうリスクがあります。

S/MIME対応のメール送信プラグインを作った場合では、担当者がS/MIMEの設定をしなければ、お問い合わせの受信ができません。

通信路の個人情報流出リスクを低減できたとしても、お問い合せや個人情報をExcel等で管理しているのであれば、そのファイルの流出リスクもあります。パスワードの設定が必要です。

以上より、お問い合わせや個人情報を含むデータはすべてサイトのデータベースに保存し、閲覧はSSLのページで行うのが適切なのではないかと考えています。

SQLインジェクションや他の攻撃リスクも考え得るので、データベースに保存する個人情報は暗号化します。そのためのライブラリの作成から始めようと思っています。

最後に

この記事を書くにあたってWEB上の様々な記事を参照させていただきました。その中で感じたことを列挙します。

メールのセキュリティ

お問い合わせページをSSLにすることを目的とするサイト運営者は多いようですが、サーバーの内部で、平文でsendmailすることに疑問を持つ方が少ないことに驚きました。世間の、メールの盗聴に対する危険意識は低そうです。無料で簡単に個人の電子証明書が発行されるインフラができれば、このあたりの意識もかわるかもしれませんが。

共有SSLは危険？

リンクさせて頂いた高木浩光＠自宅の日記さんの記事を参照して、単に「共有SSLは危険」と主張する書き込みがありました。先に書きましたように、サブドメインを割り当てる共有SSLであればその記事に記載の脆弱性は当てはまりません。

通信路の暗号化が目的であれば共有SSLで（あるいはCAによるサーバー証明書がないSSLでも）その目的は達せられます。サイトの信頼性が目的であれば達成されません。「SSLを提供しているけどfishingサイトかもしれない」という文脈においては「共有SSLは危険」もあり得ます。

そういった文脈でもなくリンク記事の解説もなく「共有SSLは危険」と主張するのは詭弁なのかなと、思いました。（あるいは、その書き込みの当時はサブドメインを割り当てる共有SSLは少なかったのかもしれません。）

ソフトウェア提供者のジレンマ

WordPressのプラグイン提供者（あるいは他のCMS提供者）に対して、共有SSLで利用したいというユーザーがその方法を質問するディスカッションを見ました。

前記のようにWordPress自体（あるいは他のCMSも）クロスドメインでの動作を前提に作られていませんし、そのプラグインはいわんやをや、です。また共有SSLの提供方法はレンタルサーバーごとに異なり、提供者がそれらを借りて検証するわけにもいきません。

OSSの提供者はそもそも善意でソフトウェアの提供やサポートをしていると思うのですが、前提としていない機能に対する質問や、サポートできない環境には対処しきれないでしょう。（質問者のスキルもありますが、それは昔からありますので。）

そのあたりを理由にサポートできない旨を伝えればよいのかな、と思うのですが論旨の異なる理由（例えば先の「共有SSLは危険」など）で回答やサポート打ち切りを検討していたりします。

まとめ

• お問い合わせ等の個人情報を入力させるページでは、通信経路の暗号化に関して、独自SSL、共有SSL、CAによるサーバー証明書なしのSSL、非SSLの4つの選択オプションが考えられます。

• どのオプションを選択するかは、個人情報に対するポリシー、利用可能な技術、ユーザー層、コストなどを鑑みて決定します。