CloudFrontのSSL/TLS対応 まとめ

ども、大瀧です。
先ほどCloudFrontに新しいオプションとして、SNIカスタムSSLが追加されました。これ、追加費用無しで手軽にCloudFrontでSSLが使える画期的アップデートなのですが、「おおっ」と反応するのは既にCloudFrontでカスタムSSLを検討している方に限られると思うので、今回のアップデートを含めCloudFrontのTLS/SSL対応としてどのような選択ができるのかをまとめてみたいと思います。

CloudFrontのSSL対応方法3つ

現在のCloudFrontでSSLを使うために選択できるオプションと選ぶときのポイントを示します。

オプション	費用	説明
1.共用SSL証明書 (*.cloudfront.net)	CloudFrontの利用料のみ	CloudFrontの設定(ディストリビューション)毎に作成されるXXXXXX.cloudfront.netに対応するSSL証明書が利用できる
2.独自SSL証明書 (IPベースモード)	CloudFrontの利用料 + 独自SSL証明書オプション(月額600ドル) + SSL証明書の費用(AWSとは関係なし)	全てのクライアントで利用できる
[NEW] 3.独自SSL証明書 (ネームベース(SNI)モード)	CloudFrontの利用料 + SSL証明書の費用(AWSとは関係なし)	独自SSL証明書オプションはかかりませんが、一部クライアントは対応しません

それぞれ解説します。

1. 共用SSL証明書

最も手軽にSSLを利用する方法です。特に事前準備無く、手軽にCloudFrontでHTTPS通信ができるようになります。

2.独自SSL証明書(IPベースモード)

こちらは昨年6月に追加された機能で、あらかじめユーザーでSSL証明書一式を準備しアップロードして利用するタイプです。具体的な手順は、以下のブログエントリーを参考にしてください。

• CloudFrontの独自ドメインSSL証明書対応を試してみた ｜ Developers.IO

ここではちょっと横道に逸れて、なぜ追加料金がかかるのかを考察してみます。
Webサーバーでは1台のサーバーで複数ドメインをホストするバーチャルホスト構成として、以下の2つの方式を利用します。

ネームベース

サーバーは、クライアントからのHTTPリクエストヘッダに含まれるHOSTヘッダでどのドメイン宛かを判断します。

IPベース

あらかじめサーバーに複数のIPアドレスを設定、それぞれドメインとひもづけておき、クライアントからのHTTPリクエストがどのサーバーのIPアドレスに届いたかによってドメインを判断します。

通常のHTTP(暗号化なし)通信であれば要件によって好きな方式を選択できるのですが、HTTPS(SSL暗号化)通信の場合ドメインごとに異なる証明書を用意するので、サーバーはリクエストの復号前(≒HTTPリクエストヘッダを見る前)にどのドメイン宛なのか判断する必要があり、IPベースの方式しか利用できないという制約があります。

CloudFrontの実装は公開されていませんが、CloudFrontを提供するために世界中に分散配置されているAWSのデータセンター(エッジロケーションと呼びます)では、様々なユーザーのコンテンツを提供するためにバーチャルホストが構成されていることが想像できます。そこでHTTPS通信かつ独自SSLをサービスするためには、やはりドメインごとに一意なIPアドレスが必要になり、エッジロケーションの数だけそれを用意するのにはそれなりのコストがかかることが想像できると思います。独自SSL証明書オプション費はそこに係るものと考えられます。

また、IPベースの独自SSLオプションを利用するためには事前に利用者情報をAWSに登録する必要があり、数日のリードタイムが必要な点にも注意しましょう。

3.独自SSL証明書(ネームベース(SNI)モード)

2の項目でHTTPS(SSL暗号化)通信のバーチャルホストはIPベースでしか動作しないと書きましたが、それだと大量のドメインに対して1対1でグローバルIPアドレスを用意しなければならず、使いにくいという声がありました。

そこで、ネームベースのバーチャルホストでもHTTPS通信ができる仕組みとして、SNI(Server Name Indication)がTLS 1.1の拡張仕様としてRFC4366にて標準化されています。

SNIは、クライアントからWebサーバーに送信するリクエストの中に暗号化されたリクエストデータと別にアクセスするドメイン名を含めるようになっており、Webサーバーではリクエストデータの復号前の段階でどのドメイン宛のアクセスかを判断できるようになっています。そのため、1つのグローバルIPアドレスのみでもネームベースのバーチャルホストでHTTPS通信が可能になります。

ただし、SNIはサーバー、クライアント共にSNIをサポートする必要があるため、以下の主なクライアントでは正常な通信ができないことに注意する必要があります。(Wikipediaより転載)

• Internet Explorer 6 もしくはWindows XP以前での全バージョン
• Safari （Windows XP上)
• BlackBerry ブラウザ (7.1またはそれ以前)
• Windows Mobile 6.5
• Android 2.x のブラウザ(Honeycomb for tablets と Ice Cream Sandwich for phones では対応)
• wget 1.14未満 (パッチによって対応可)

CloudFrontのエッジロケーションでも、ネームベースのバーチャルホストで構成することでドメイン専用のグローバルIPが必要ないことから、オプション料金がかからないではと考えます。ちなみに、IPベースモードにあった事前申請も不要ですので、証明書さえアップロードすればすぐに設定することが可能です。

まとめ

今回のSNI対応で、CloudFrontのSSL対応がぐっと身近になりました。とはいえ、クライアントの制限など注意するべき要件もありますので、ケースによって上手く使い分けると良いと思います。