SNIで1台のサーバ上に複数のSSLサイトを運用 – 前編

ご無沙汰しております。細羽です。

昨年、AndroidにおけるSNI対応状況という記事で、SSL/TLSの拡張仕様であるSNI(Server Name Indication)について触れました。

少しニッチなテーマだと思っていましたが、つい先日、さくらのレンタルサーバでSNI SSLを提供開始というプレスリリースが発表されました。広いサービスでSSL/TLS導入への需要が高まっている今、このような事例は今後増えていくものと考えられます。

そこで本記事では、重要度が高まっているSNIについて、その技術の概要を改めて理解し、実際の運用に役立てられるように整理をしたいと思います。

知識の整理を目的にした前編と、実践を目的にした後編の2部構成でお届けします。
以下が前編の内容です。

SNIで何が出来るようになるのか
SNIで複数ドメインが運用可能になるまで
SNIが重要になりつつある背景
SSL運用方法の比較メリット・デメリット
SNI対応ブラウザ

SSL/TLSの基本は理解していることを前提としますが、不安な方は改めて知ろう、SSLサーバー証明書とは？などで事前に理解しておくと、スムーズになります。

1.SNIで何が出来るようになるのか
2.SNIで複数ドメインが運用可能になるまで
3.SNIが重要になりつつある背景
4.SSL運用方法の比較メリット・デメリット
5.SNI対応ブラウザ
最後に

1.SNIで何が出来るようになるのか

SNI(Server Name Indication)とは、RFC6066内で定義されている、SSL/TLSの拡張仕様の一つです。

SNIに対応することで何が出来るようになるのでしょうか。

結論としては、対応ブラウザの制約はあるものの、「1台のサーバ(IPアドレス)で複数ドメインのSSL証明書を運用できるようになる」ということになります。逆に、SNI非対応の場合だと、1台のサーバ(IPアドレス)で、SSL証明書は1ドメインしか運用できないことになります。

具体例を交えた方が分かりやすいので、さくらのレンタルサーバを例にお話します。

レンタルサーバでは1台のサーバに複数のユーザが同居するため、1つのグローバルIPアドレスを全ユーザ、つまり同居している全サイトで共有することになります。そのため、独自ドメイン・SSLサーバ証明書で独自SSL対応のサイトを、運用することが出来ません。

このイメージを表したものが下図になります。

とは言え、SSL/TLSを利用する状況もあるため、共有SSLという方式でSSLがサポートされています。共有SSLは、1つのドメイン（さくらインターネットならsecure”NNN”.sakura.ne.jp）を全ユーザで共有してSSLを利用する形式です。

この場合、サイトを訪れたユーザから見ると、SSLページのアドレスバーのドメインが突然変わり、違和感を与えてしまうかもしれません。

SNIに対応することで、独自ドメインでSSLの運用が可能になり、こういった違和感を無くすことが出来るようになります。

2.SNIで複数ドメインが運用可能になるまで

1つのサーバに複数ドメインのサイトを同居させることは簡単にできるのに、なぜSSL/TLSの対応は出来なかったのか？
そのことを理解するためには、HTTPとSSL/TLSに関する技術的な背景を理解しておく必要があります。

HTTPによる複数ドメイン運用の仕組み

まず、HTTPで複数ドメインの運用が可能なWEBサーバの仕組みを紹介します。
これは主に、HTTPのHostヘッダを利用して実現されています。

下図が通信の流れをイメージ化したものになりますが、クライアントからWEBサーバにアクセスする時に、Hostヘッダを利用してアクセス対象のホスト名を一緒に送信しています。

WEBサーバは、受信したHostヘッダの中身を見て、適切なコンテンツをクライアントに返す処理を行います。
これはネームベースのVirtualHostなどと呼ばれる運用方法として一般的に知られており、多くのWEBサーバでこの仕組みが実装されています。

HTTPSの仕組み

次に、HTTPSの仕組みを見ていきます。HTTPSはHTTP over SSLの略称ですが、「SSL通信路の上でHTTPの通信を行う」ための仕組みです。

「SSLの通信路の上で」というのがポイントで、通信の手順としては以下のステップを踏みます。

クライアントとサーバの間でSSLのセッションを生成する (SSLハンドシェイク)
確立されたSSLセッションの上でHTTPの通信を行う

ポイントは、サーバは自身に設定されたSSLサーバ証明書を返すことしか出来ない点です。
WEBサーバとしては複数ドメインで運用されていても、SSL/TLSとしては設定された1ドメインのSSLサーバ証明書しか返すことが出来ないのです。

「SSLセッションの上でHostヘッダを利用すれば、複数ドメイン対応できるのでは？」という疑問が生じますが、SSL/TLSが持つ本質的な機能である「サーバ証明」に違反することになり、セキュアな通信を保証することが出来ません。

とは言え、1つの証明書しか扱えないというのは、窮屈な運用を強いられることにもなります。

SNIによる複数ドメイン運用の仕組み

この運用上の課題を解消するため、SSL/TLSの拡張仕様としてSNIがRFC6066として定義されました。

仕組みとしてはシンプルで、SSLハンドシェイクの過程で通信対象のサーバ名を通知するようになりました。これにより、サーバはアクセス毎にどのSSLサーバ証明書を利用すればよいか判別することが出来、複数ドメインの運用が可能になります。

3.SNIが重要になりつつある背景

SNIという拡張仕様自体、新しいものではありません。しかし近年、その重要度が増しています。

その背景には以下の理由があるように思います。

独自SSLに対応したCDNやPaaSの登場
SSL/TLS導入需要の高まり

独自SSLに対応したCDNやPaaSの登場

近年、WEBサービスの運用環境として、クラウドの利用が一般的になってきました。
高機能化も進み、以下のようなプロダクトも登場してきました。

独自ドメインSSLに対応したCDN
独自ドメインSSLに対応したPaaS

これらの多くは、SNIを利用して運用されています。

SSL/TLS導入需要の高まり

SSL/TLSというと、セキュリティの確保が必要な一部のサービスで導入されるもの、という認識でしたが、近年は一般的に導入されるべきという認識が広まっています。

その事例として昨年、GoogleからHTTPSをランキングシグナルに使用するというアナウンスがありました。
まだウェイトとしては大きくはないものの、SSL対応がSEOに影響するようになりました。

また、Webを支える技術は、近年もの凄いスピードで進化を続けています。
例えば、HTTP/2,SPDY,WebSocketなどの新しいプロトコルの登場もその一つです。

これらの新しいプロトコルと、既存の環境とシームレスに統合運用するための手段として、SSL/TLSは重要なプロトコルとして位置づけられています。

4.SSL運用方法の比較メリット・デメリット

運用の幅を広げてくれるSNIですが、当然メリット・デメリットもあるので、それらをよく理解して運用することが重要です。
ここまで見てきたSSLについて、メリット・デメリットを表にまとめました。

	共有SSL	独自SSL(IPベース)	独自SSL(SNI)
メリット	導入が手軽である証明書の維持管理をサーバ会社に任せられる	独自ドメインで証明出来る対応ブラウザの制約は少なく、最も安定して運用出来る	独自ドメインで証明出来る 1台のサーバ(IPアドレス)で、複数ドメインの証明書を運用出来る
デメリット	SSLページだけ共有ドメインに切り替わるので違和感がある共有ドメインの証明にすぎない	導入に多少の手間がかかる 1台のサーバ(IPアドレス)で、単一ドメインの証明書しか運用出来ない証明書の維持管理は、運用者自身で行う必要がある	導入に多少の手間がかかる証明書の維持管理は、運用者自身で行う必要がある対応ブラウザの制約がある

5.SNI対応ブラウザ

SNIの重要なデメリットの一つに、対応ブラウザの制約があります。
時間が解決する問題ではありますが、まだ考慮する必要があるというのが現状です。

前編の最後に、SNI対応ブラウザの情報をまとめておきます。

PC
- Internet Explorer: 7以降（Windows Vista以降）
- Chrome: Windows Vista以降・Mac OS X 10.5.7 以降でChrome 5.0.342.1以降
- Mozilla Firefox: 2.0以降
- Safari: 2.0以降 (Windows Vista以降・Mac OS X 10.5.6 以降)
- Opera: 8.0以降
iOS
- Safari: 3.0 以降 (iOS 4.0以降)
Android
- 標準ブラウザ: Android 3.0 (Honeycomb) 以降
フィーチャーフォン
- 未確認ですが、ほぼ未対応です。