うぇびん 
CM3Sのお問い合わせフォームを、共有SSLに対応させました。
a-blog cmsのフォームは、共有SSLでの利用に公式対応しています。
小規模の商用サイトでは、フォームを暗号化する際には、共有SSLを利用するのが当たり前となっています。独自ドメインのSSL証明書を取得すると、フォームを通して得られる収益よりも、維持費の方がはるかに高くなってしまうからです。
実装についての解説記事を書く前に、「CMSで共有SSLを利用すること」について、考えてみたいと思います。
共有SSL自体が安全とは言えない
ほとんどのレンタルサーバーでは、サーバー内で共同利用できる「共有SSL」を無償で提供しています。
ですが、共有SSLは共同で利用するという性質上、外部から傍受される危険性が高くなります。
この件については、セキュリティ論で知られる高木浩光氏が、2010年に詳しく指摘されています。
高木浩光＠自宅の日記 – 共用SSLサーバの危険性が理解されていない
とても難しい話なので、私に理解できる範囲でざっくり補足しますが、以下のように「URLが各アカウントで同じドメインになっている」タイプが、特にセキュリティ面に問題があると指摘しています。
https://(サーバー会社共通のドメイン)/(ドメイン名やアカウント名)/
ドメインが同じだと、インラインフレームを動的に埋め込むなどの手法で、同じサーバーを利用している別サイトのCookieを簡単に取得できてしまうためです。
この記事の影響なのか、現在ではほとんどの主要レンタルサーバーは、以下のように、各アカウントで違うドメインとなるよう改良が行われています。なので、この形式であれば致命的な脆弱性とはならないようです。
https://(ドメイン名やアカウント名+サーバー会社共通のドメイン)/
…が、高木氏など、セキュリティに詳しい人たちにとっては、未だに共有SSLは穴だらけのようです。
CMSで共有SSLに対応するリスク
CMSというのは、サイト内のすべてのファイルが同じドメインであることを前提に設計されています。
共有SSLを導入する場合、サイト内でフォームを送信するコンテンツだけ異なるドメインで動作するよう、かつ、HTTPSでの通信にも対応するよう、システムを改変しなければなりません。
つまり、どのCMSでもフォームプラグインでも、大なり小なり、共有SSLに対応する＝本来の仕様をねじ曲げるということになります。
WordPressの最も有名なメールフォームプラグイン「Contact Form 7」の作者、三好さんは、2011年頃のフォーラムで「Contact Form 7」を共有SSLへ対応させるハックを公に否定しています。
Contact Form 7 プラグインは「共有SSL」環境下では動作しません。おそらく他の問い合わせフォームプラグインでも同様と思います。「共有SSL」ではなく本来の真っ当な SSL の使用を推奨します。
#
「共有SSL」で Contact Form 7 を使用する「ハック」だの「修正」だのといったいい加減なブログ記事をよく見かけますので、この機会に(読んでいる皆さんにも)忠告させてもらいますが、どれも内容は単にプラグインの動作処理を毀損しているだけのことで、その結果重大なセキュリティ上の欠陥を招く恐れもあります。通信を保護するために SSL を導入しているはずが結果的には脆弱にしてしまっています。そこまでして「共有SSL」を使う意味があるのか考えてみてください。
ウェブサイトを見た限りでは、現在も共有SSLへのサポートは行っていないようです。
三好さんの発言には、要件を達成するために、本来重要視されるべきところがおざなりになっている「自己満足系カスタマイズ」への憤りが見えます。
では、共有SSLは使わないのか
と、ここまでいろいろと恐ろしいことを書きましたが、私自身は、CM3Sを共有SSLに対応させています。
以下のように考えたからです。
利用しているCMSの仕様
共有SSLを通してCookieの情報を傍受するには、システムのセキュリティホールをついたうえでの、サイトの改ざんが最も一般的です。
ですが、私がCM3Sに利用しているa-blog cmsは、現時点でほぼ日本国内でしか利用されておらず、ioncubeによってPHPソースの暗号化が行われているため、外部からの解析・改ざんがひじょうに困難になっています。
（共有SSLに対応する際に差し替えるlicence.phpも、通常状態では暗号化されており読めません）
こう言ってはなんですが、攻撃者にしてみれば、a-blog cmsを攻略するくらいならMovable TypeやWordPressを攻めた方が楽というものです。
共有SSLの改善
先述の通り、最近のレンタルサーバーの共有SSLは、アカウントごとに異なるドメインが発行されるようになりました。
少なくとも、かつて高木氏が指摘したような、とんでもないザルではなくなっているということです。
0か、0.1か
共有SSLを使わない場合、暗号化されていないコンテンツにフォームを置くことになります。
暗号化されていないよりは、少しでも暗号化されている方が良いと考えるのが普通です。
訪問者に対するマーケティング的な問題
一般のウェブサイトの訪問者は
「フォームに送信するときは、アドレスバーに鍵マークが付いているか確認する。アドレスバーが緑だとなお良い」
という常識を持っています。
残念ながら「共有SSLも実はけっこう危ないかもしれないよ！」という説明は効果がありませんし、常識になるにはあと10年以上かかるでしょう。
まったく同じフォームをふたつ用意して、非SSLと共有SSLにしたら、おそらく共有SSLの方がコンバージョンは上がることになるのでしょうか。興味深いテーマです…実験してみたいです。
まとめ：独自SSL証明書がいちばんだけど
というわけで今回も長話になりましたが、CMSに共有SSLを導入するというのは、プラグインやハックでなんとかなるような、単純な話ではないということです。
理想は、きちんと独自SSLの証明書を取ることです。
先日、さくらインターネットが「ラピッドSSLの証明書が年間1500円」というサービスをスタートし、業界に衝撃を与えました。
…が、私が利用しているエックスサーバーは、SSL証明書の外部からの持ち込みはできません。エックスサーバーの安定性が気に入って長年利用しているのに、手間をかけてさくらに引っ越すというのも、なんだか違う気がします。
ジオトラスト、グローバルサイン、ラピッドSSL、共有SSL…
予算、CMSとの相性、方針によって、自己の責任で導入を考えたいものです。