[技術メモ] 常時SSLが進む背景と今後の課題

今年に入って、常時SSL(Webサーバとの通信をすべてHTTPS化すること)の話題が増えています。
その背景と今後の課題についてまとめました。

常時SSL01

常時SSLが進む背景には、次の理由があります。

  • 低コスト化と運用負荷軽減
  • SNI対応環境の変化
  • HTTP/2による高速化
  • GoogleによるHTTPSの評価

今後の常時SSLの課題としては次のことが考えられます。

  • HTTPS=安全 ではなくなる
  • HTTPSの高コスト化
  • 証明書の有効期限切れの管理

なお記事を書くにあたって、以下のように用語を統一させていただきました。

  • WebのSSL/TLS対応については、「HTTPS対応」としました。
  • SSL/TLS証明書については、「証明書」としました。
  • できるだけSSL、TLSという言葉は使用しないようにしました。

低コスト化と運用負荷軽減

HTTPS対応の費用には、証明書自体の費用、証明書の登録・更新を行うための費用があります。
Let’s Encryptは、2015年に運用がはじまりましたが、発行費用が無料化、証明書の取得・更新がコマンドラインから実行と、運用が容易になりました。またLet’s Encryptを採用するサーバホスティング事業者も現れてきました。
AWSのAWS Certificate Managerでは、CloudFrontとELB(対象リージョンに制限あり)においてHTTPS対応が無料で利用できるようになりました。AWS Certificate Managerで証明書を管理し、コンソール・API・CLIでCloudFrontとELBへ展開できるため運用が容易になりました。
WordPress.comやMovableType.netといったブログサービスでは、独自ドメインも常時SSLに対応しました。(すべての WordPress.com サイトを HTTPS 化常時SSL化に対応。さらにアクセシビリティを考慮した新テーマ「Public Organization」も公開)

このように、無料化や運用の負担を下げる取り組みが進んできています。

SNI対応環境の変化

HTTPS対応のWebサーバを運用するためには、1サーバ名=1IPアドレスが一般的でした。その後複数ホスト名を1IPで運用するための拡張仕様としてSNI(Server Name Indication)が登場しましたが利用できる端末に制限がありました。
非対応の端末には、WindowsXP、ガラケー、Android2.xなどがありました。2016年になり非対応の端末は極めて少なくなりました(SNI非対応完了の多くは、証明書のSHA-2にも非対応です)。
結果として、大多数の端末がSNIに対応するようになり、利用しやすくなりました。

HTTP/2による高速化

GoogleのSPDYプロトコルを基に、2015年5月にHTTP/2が制定されました。HTTP/2ではリクエスト・レスポンスの多重化が実装され、高速化が期待されます。HTTP/2では実質的にHTTPSが必要となります(仕様上はHTTPでも可ですが、実装はHTTPSが中心)。特にページ遷移なしに更新を行うコンテンツがあるようなサイト等を中心に利用が進むと思われます。

GoogleによるHTTPSの評価

Googleは2014/8に「HTTPS をランキング シグナルに使用します」をウェブマスター向け公式ブログに掲載しました。このなかでGoogleは検索順位を決定する要因としてHTTPSを評価している旨を発表し、ウェブの安全性を高めるためにHTTPSを利用することを次のように推奨しています。
ユーザーがもっと安全にサイトを閲覧できるよう、すべてのサイト所有者の皆様に HTTP から HTTPS への切り替えをおすすめしたいと考えています。
2016年現在でも、検索結果にどの程度の影響があるのかは明確ではありませんが、Googleはそれ以前にもHTTPS everywhereを提唱しており、少しづつ変化していくのではないでしょうか。

常時SSL、今後の課題

環境が整ってきた常時SSLですが、課題についても整理してみたいと思います。
(課題は筆者の考えです)

HTTPS=安全 ではなくなる

日本ユーザー対象の不正広告攻撃にLet’s Encryptが悪用される」という記事が2016/1に掲出されました。攻撃者がLet’s Encryptを利用することでHTTPS対応しやすくなるため、攻撃サイトのHTTPS対応が進むと考えられます。またLet’s Encryptがフィッシングサイトなどに利用されても証明書を失効しないなど、その運用にも不安材料があります。
したがって、HTTPSだからといって正しいサイトというのは今後通用しなくなります。

HTTPSの高コスト化

HTTPS化されたサイトの多くは証明書に、DV証明書が使用されています。DV証明書は、ドメインを所有状態をメールにて確認するのが一般的です。したがって、そのサイトがたとえ実在しない組織であっても発行されます。DV証明書は「通信経路」の安全性を担保するのが目的であり、「運営者」の正当性を担保するものではありません。
証明書には、DV証明書の他にOV証明書、EV証明書があります。OV証明書は、組織の存在を確認するためインターネットを介さない電話で存在確認が行われます。EV証明書はさらに厳格な存在確認手順が定められておりインターネットバンキングなどにも利用されています。OV証明書やEV証明書を使用することにより、サイトの運営者の正当性が担保しやすくなります。
GoogleはEV証明書・OV証明書で運用されているのほうが安全性が高いと判断する可能性は考えられます。もしランキングシグナルに適応するようになれば、多くのサイトは移行せざるを得なくなります。しかしOV証明書・EV証明書は高価(1年あたり数万〜)です。結果的に運用コストが上がる可能性が考えられます。
常時SSL02
(EV証明書は、上図の通りアドレスバーに組織名が表示されるため、利用者にもわかりやすいです)

証明書の有効期限の管理

証明書を手動で更新している場合には、更新時に証明書の有効期限を確認することで、有効期限に問題ないことが確認できます。
しかしLet’s Encryptのように自動的に証明書の更新する場合、万一不具合等で更新されなかった場合、証明書の有効期限が切れたまま運用されてしまう危険性があります。なんらかの方法で自動的に証明書の確認を行い、問題がある場合には通知する仕組みが必要となります。

上記のほかにも、HTTPS対応により暗号化を行うためのCPU負荷、今後発生しうるTLS 1.3への移行が正常に行えるか?といった課題も考えられます。

「常時SSL」という用語はおかしくないのか?

最後に、筆者が気になっていることがあります。
すでにSSLからTLSに移行している(SSL3.0までのバージョンは非推奨のため、SSLは実質存在しない)にもかかわらずなぜ「常時SSL」なのでしょうか…。せめて「常時TLS」か「常時HTTPS」ならいいのですが…

以上、常時SSLが進む背景と今後の課題について書きました。