2014年9月末、CDNサービスを提供しているCloudFlareが「Universal SSL」を発表しました。同社の無料プランを含む全てのユーザーに、無償でSSL(https)接続サービスを提供するという驚くべき内容です。同社によれば、現在、セキュアな接続をサポートしているサイトは全世界で200万サイトほどだったそうです。ですが、Universal SSLの登場によって倍の400万サイトまで増えることになります。
ワンクリックでHTTPS(SSL)が利用可
このブログのドメイン(srytk.com)もCloudFlareを使っているので、cloudflare.comの設定ページを見ると確かにありました。
当初、全てのユーザーがuniversal sslを利用できるようになるまで最大24時間かかる、と説明されていましたが、のちに数日伸びることなりました。私のアカウントでもSSL issuingと出て、まだ使えないようです。
For new customers who sign up for CloudFlare’s free plan, after we get through provisioning existing customers, it will take up to 24 hours to activate Universal SSL.
↑ アナウンス時 ちょっと伸びた ↓
While we’d hoped to have the deployment complete within 24 hours of the announcement, it now looks like it’s going to take a bit longer. We now expect that the full deployment will be complete about 48 hours from now (0700 UTC).
UNIVERSAL SSLのメリット・デメリット
全ての物事がそうであるように、Universal SSLにもメリットとデメリットがあります。まずはメリットから。
SSLがタダ！
Some rights reserved by 401(K) 2013
従来SSL証明書の発行は安くありませんでした。無料のSSLはStart SSLなど前からありましたが、symantecやglobal signなどの有名どころから買うと年数万円かかります。スノーデンの暴露以降、セキュリティの関心がインターネットユーザの間で高まりましたが、個人の管理者が気軽にSSLを導入できるものでなかったようです。
また、サーバーのほうも色々めんどくさそうです。やっすいレンタルサーバーとかだと独自SSLを導入するのに追加料金が必要だったり、上位プランが必要だったりします。月数百円でブログやっているような人には縁遠い話ですね。追加で設定も必要ですし。
SEOにチョットだけ有利
Some rights reserved by The Logo Smith
Googleが検索結果に用いるランキング要素の1つにHTTPSがあることは公然たる事実です。
このランキングの変更は、グローバルでクエリの 1% 未満にしか影響しませんが、これから長い期間をかけて強化していきます。全体的に見ると、このシグナルは良質なコンテンツであるといった、その他のシグナルほどウェイトは大きくありません。HTTPS は、優れたユーザー エクスペリエンスを生み出す多くの要素のうちの 1 つです。
今後、より多くのウェブサイトで HTTPS が使用されることを期待しています。ウェブの安全性をさらに強化しましょう。
ですが、今のところ、ほとんど重みは無いと思われます。常識的に考えて、セキュアであるかは、多くの場合、ドキュメントのクオリティと直接は関係ないですからね。
イメージするなら、「英検3級」といったところでしょうか。持ってるに越した事はないですが、声高にアピールする程でもないですよね。（英検3級持っている人ごめんなさい）
ただ、気になるのは「長い期間をかけて強化」です。将来的には、より「重く」なって行くのかもしれません。どちらにせよ、今のところは、SEOの観点からは、メリットは薄いことに変わりないですけどね。
SPDYが有効
Some rights reserved by Rami ™
Universal SSLを有効にすると、自動的にSPDY(スピーディー)が有効になります。SPDYはHTTPでの問題点をプロトコルレベル改善するもので、サイトによってはロードスピードがかなり改善されます。大手サイトも導入していてtwitterやgoogle, facebookなどの実績があります。
spdyでは1つのコネクションを使いまわして、上手いことリクエストするので、cssにbase64で画像を埋め込んだり、css spriteしたり、JavaScriptやCSSを結合するといかいう、みみっちい最適化しなくて済みそうです。
デメリット
Universal SSLのデメリットは以下のようなことがあります。
WIndows XPのIEはサポートされない
Some rights reserved by MLazarevski
Universal SSLは数多くのサイトを限られたリソースで提供しなければならない都合上、一般的な（昔からある伝統的な）SSLとは異なる2つの手法を使っています。
楕円曲線DSA(ECDSA)
httpと違ってhttpsでは暗号化という処理が必要なので、余計に計算リソースが必要になります。この計算リソースの消費を抑えるため、Universal SSLではRSAベース手法ではなく、ECDSAを利用するそうです。技術的な話なのでさっぱり分かりませんが。
Server Name Indication(SNI)
一般的なSSLではSSL証明書ごとにグローバルIPが必要になるそうです。何百万もユーザのいるUniversal SSLでは、グローバルIPを全て用意するのは難しく、Server Name Indicationという方法でこの問題を解決しています。
以上の様に、Universal SSLでは一般的なSSLと異なり、（先進的な）手法を用いています。これらの手法はモダンなブラウザでは対応していますが、残念ことに、Windows XP上のInternet ExplorerやIce Cream Sandwichより前のAndroidではサポートされません。
これらの環境でもHTTPSをサポートする必要がある場合、有償の上位CloudFlareプランへ移行する必要があります。
HTTPSとHTTPどちらでもアクセスできるようにすることは無料アカウントでも可能ですが、間違って古い環境のユーザがアクセスした場合「エラー画面」が表示されるのは感じ悪いですよね＞＜
デフォルト設定だとあんまりセキュアじゃないよ
Some rights reserved by samstockton
ユーザと（オリジン）サーバーの間の送受信にCloudFlareが入ることでUniversal SSLおよびCloud FlareのCDNは実現しています。このブログで言うと、ビジター -> CloudFlare -> srytk.comのサーバー という流れと、srytk.comのサーバー -> CloudFlare -> ビジターという流れがあります。
ここでポイントなのが、無料プランのCloudFlareのSSL設定は「Flexible SSL」というのがデフォルトなのですが、これはビジターとCloudFlareの間だけ通信が暗号化される、ということです。
暗号化されていない、空港等の公衆無線LANからの接続を、まわりの同席している悪い人たちからの傍受を防いだり、学校や職場のインターネットからの接続で、管理者に通信内容を知られたくない、程度の事なら意味がありそうです。下の画像がイメージしやすそう。
しかし、ユーザと（オリジン）サーバーの間の暗号化が不完全なので、（パスワードやメールなど）重要な情報を送受信するサイトには「Flexible SSL」は使えません。CloudFlareとオリジンサーバーとの間の通信を傍受されてしまうかもしれないからです。
Universal SSLでオリジンサーバーと暗号化された通信を行うには「Full SSL」か「Full SSL(strict)」を選択し、オリジンサーバーでSSLを有効化しなければなりません。これは前述したとおり、場合によってはレンタルサーバーなどに追加のお金がかかります。また「Full SSL」は中間者攻撃を防ぎきれないので、caから証明書を買って「Full SSL(strict)」をオススメします。なお、将来的にはCSRをCloudFlareに送って「Full SSL」でもOKになるかもしれません。
デメリットというと大袈裟ですが、「SSLだから無条件に安心」というわけではないことは、心に止めておく必要があります。
あと、セキュリティは重要なポイントですが、私は詳しいこと、技術的な事はさっぱり分からなかったので、Cloud Flareのブログをしっかりと読むと良さそうです。
Mixed Contentに注意しなければならない
Some rights reserved by Andreas Solberg
HTMLは通常、外部リソースへの参照が記述されています。<img src=”https://example.com/image.jpg”>みたいなやつです。httpsでサーブされたhtmlに（たとえ同じドメインであっても）「http」での参照が含まれている場合、そのhtmlに参照されているhttpなコンテンツは「mixed content」と呼ばれる状態です。MDNのMixed Contentのページによれば、「http」なコンテンツは「https」なコンテンツと違って中間者攻撃によって改竄可能です。
If the HTTPS page includes content retrieved through regular, cleartext HTTP, then the connection is only partially encrypted: the unencrypted content is accessible to sniffers and can be modified by man-in-the-middle attackers, and therefore the connection is not safeguarded anymore. When a webpage exhibits this behavior, it is called a mixed content page.
mixed contentは2つのカテゴリに分けることができます
Mixed passive/display content
このmixed contentは他の部分を改変出来ないようなmixed contentを指します。次のものが該当します。
- <audio> (src attribute)
- <img> (src attribute)
- <video> (src attribute)
- <object> subresources (when an <object> performs HTTP requests)
Mixed active content
このmixed contentはhttpsページのDOMにアクセスできるようなコンテンツです。それゆえ、情報が盗んだり、意図しない動作を引き起こす可能性を秘めています。
Mixed Active Content is content that has access to all or parts of the Document Object Model of the HTTPS page. This type of mixed content can alter the behavior of the HTTPS page and potentially steal sensitive data from the user. Hence, in addition to the risks described for Mixed Display Content above, Mixed Active Content is vulnerable to a few other attack vectors.
次のものが該当します。
<script> (src attribute)
<link> (href attribute) (this includes CSS stylesheets)
XMLHttpRequest object requests
<iframe> (src attributes)
All cases in CSS where a url value is used (@font-face, cursor, background-image, etc.)
<object> (data attribute)
Firefox ではバージョン23からmixed active contentをデフォルトでブロックします。詳しいことは知りませんが、chromeもブロックします。ieもブロックします。
つまり、モダンなブラウザはmixed active contentをブロックしちゃうかもしれないのでUniversal SSLを有効化する前に、既存ページの<script>や<link>などをチェックしなければなりません。mixed contentになってしまうと一部が表示されなかったり、最悪ページが崩れます。
httpなscriptやiframeというと「ニコニコ動画の外部プレイヤ」とか「amazonとかの広告コード」とか「google web fonts」（デフォルトでhttpなコードが表示される）とか、枚挙にいとまがない状態で、しかもhttpsな代替コードが用意されてなかったりすると、お手上げ状態になります。
つまりブログなどがhttps化すると面倒くさいのです。
SPDYでサイトがスピーディーになるとは限らない
Some rights reserved by freefotouk
技術的な事だから詳しくはわからないですが、SPDYの売りはコネクションを出来るだけ効率的に利用できることのように思えます。ですが、一般的なブログはソーシャルボタンやら埋め込みやらで外部サイトのスクリプトやiframeを貼りまくりで、ドメインがかなり分散されていて、コネクション貼りまくりです。このような状況ではSPDYの旨味は薄そう。例えば「Web表示の高速化を実現するSPDYとHTTP/2.0の標準化」では次のようにあります。
SPDYを導入しても、必ずしも全てのサイトが無条件に高速化されるわけではありません。SPDYの技術的な特徴を活かせる構成では性能向上を期待することができますが、既存の環境をそのままでSPDYを適応すると、逆効果になるケースも考えられます。そのような構成を3つほど例示します。
例1：多数のドメインに分割してコンテンツを配置しているサイト
SPDYは1つのTCP接続を最大限に効率化することで高速化を図るプロトコルです。しかしWebコンテンツ内のリソースを多数のドメインに分割配置している場合、ブラウザはそれぞれのドメインのホストに対してTCP接続を生成することが必要となります。そのため、このようなサイトでは、TCP接続のオーバヘッドを小さくするメリットを生かすことができません。CDN等を利用して、地域的に多数のホスト・ドメインにコンテンツリソースを分割配置しているケースが当てはまります。（先述したワイルドカード証明書とDNS情報を共有してChromeで接続する場合は事情が異なります。）
SPDYが生きるのは同じドメインから画像のサムネイルが大量に表示されるようなページなどかと思われます。しかも、従来のhttpでの最適化テクニックは逆にスピードを落とす要因になったりします。ドメインシャーディング（笑） そこらのポイントは「Guy Podjarny「SPDYはみんな思ってるものと違う」」でも指摘されています。
このように、SPDYの恩恵にはサイトのSPDYに最適化が必要だろう、ということです。面倒くさいですね 🙁
Windows 7以下のIEはSPDY対応してない
Some rights reserved by ieteam
IEユーザでSPDYが利用できるのはwindow7 より上のwindowsだけです。
Internet Explorer 11 では SPDY/3 をサポートしています。これは、複数の HTTP 要求を 1 つの TCP 接続に多重化 (結合) する方法を定義するプロトコルです。 このプロトコルによって、Web ページの要求で必要となる個々の TCP 接続の数が減り、パフォーマンスが向上します。
詳しくは、SPDY プロトコル仕様 (草案 3) に関するページをご覧ください。
重要 Windows 7 の Internet Explorer 11 では、この機能はサポートされていません。
ということで、多くのieユーザは遅くなることはあっても速くなることはありません。過度期ということで耐えるしかないですね。
まとめ
Universal SSLは多くのウェブ利用者にとって、スピードの向上とセキュリティが向上される素晴らしいサービスなのは間違い無いとおもいます。しかし、ウェブ制作者やブロガーにとっては、負担が増えることになりかねません。特に私のように趣味でブログやホームページをやっているような場合は、よく考えてhttps化したほうが良さそうです。