本記事では、Amazon CloudFront を例として、CDNでHTTPSを利用するための設定について解説します。
HTTPSの設定で必要な項目は次の3つです。これらについて順に解説していきます。
- HTTP/HTTPSの許可
- サポートするTLSバージョンと暗号スイート
- 証明書の発行
HTTP/HTTPSの許可
現在、HTTPSがWeb通信の基本となっており、HTTPはできるだけ使わない方が良い状況です。そのため、多くのCDNではHTTPでの通信を許可するかを選択できるようになっています。
CloudFrontでは、次の3つの選択肢が提供されています。
- HTTPとHTTPSの両方を許可
- HTTPSのみ許可
- HTTPをHTTPSにリダイレクト
この中で弊社のおすすめは、3番目のHTTPをHTTPSにリダイレクトです。
この設定であれば、ユーザーは確実にHTTPSでサーバーと通信することになり、セキュリティを担保することができます。2番目のHTTPSのみ許可の設定にした場合は、HTTPで通信しようとするとエラー画面が表示されてしまいます。これでは、Web技術に明るくないユーザーはビックリしてサイトから離脱してしまうことでしょう。
そのため、セキュリティとユーザーへのフォローが可能なHTTPをHTTPSにリダイレクトを推奨しています。
HTTPをHTTPSにリダイレクト設定をした時にHTTPで通信をしようとした時は、次の図のようになります。CDNでリダイレクトのレスポンスを返すので、オリジンサーバーに余計な負荷がかからない点が優れています。
サポートするTLSバージョンと暗号スイート
次に、サポートするTLSバージョンと暗号スイート(Cipher Suite)を決めます。
ここでのポイントは、クライアントとサーバーが同じTLSバージョンと暗号スイートに対応していなければ、TLSのセッションが確立できないということです。暗号スイートは、TLSの通信に使うアルゴリズムの組み合わせのことを指しています(後ほど詳しく解説します)。
TLSバージョン
現在、利用可能なTLS(およびSSL)のバージョンは5つあります。TLSv1.3、TLSv1.2、TLSv1.1、TLSv1.0、SSLv3の5つです。
このうち、現在利用が推奨されているのはTLSv1.2とTLSv1.3の2つだけです。これ以前のバージョンは、特別な理由がない限り使用すべきではありません。TLSv1.2より古いバージョンには深刻な脆弱性があり、暗号化された通信内容を解読されたり、Cookieの情報が盗まれるといったリスクがあります。
暗号スイート
TLSのバージョンと共に指定するのが暗号スイートです。TLSv1.3とTLSv1.2では、利用可能な暗号スイートが事前に定義されています。特に、最新のTLSv1.3では、セキュリティを強化し実装の複雑さを減らすため、一緒に利用できる暗号スイートの数が5つまで絞られました。
暗号スイートには以下の要素が含まれています。
- 鍵交換アルゴリズム: 通信の両当事者間でセッションキー(共通鍵)を安全に交換するための方法を定義します。例ば、ECDHE(楕円曲線Diffie-Hellman Ephemeral)などがあります。
- 暗号化アルゴリズム: データを暗号化するためのアルゴリズムと、そのキーの長さを指定します。例えば、AES(Advanced Encryption Standard)128ビットや256ビットなどがあります。
- メッセージ認証コード(MAC)アルゴリズム: 送信されたメッセージの整合性と認証を確認するために使用されるアルゴリズムを定義します。例えば、SHA-256(Secure Hash Algorithm 256ビット)などがあります。
暗号スイートは、これらのアルゴリズムを組み合わせることで、通信の暗号化とデータの完全性保証の2つの機能を提供しています。 通信の暗号化は暗号化アルゴリズム、データの完全性保証はメッセージ認証アルゴリズムによって提供されます。
(※ TLSv1,3では、鍵交換アルゴリズムと暗号化およびメッセージ認証コードアルゴリズムが切り離されており、暗号スイート名に鍵交換アルゴリズムは含まれません。)
ここで、例として暗号スイートの一つであるTLS_AES_128_GCM_SHA256を見てみます。TLS_AES_128_GCM_SHA256は、TLSv1.3を使う場合にしなければならない暗号スイートとして、TLSv1.3の標準をまとめたRFC8446で定義されています。
TLS_AES_128_GCM_SHA256は次の暗号アルゴリズム群を表しています。ただし、HTTPSのWebサイトを運用する立場であれば、暗号スイートの詳細まで理解する必要はありません。クライアントとサーバーで同じTLSバージョンと暗号スイートが使用できれば良いことだけ覚えておけば十分です。
そのため、下記はあくまで参考として説明します。
- AES_128_GCM: 暗号化アルゴリズムとそのモードを示します。
- AES (Advanced Encryption Standard)は、広く使用されている共通鍵暗号化アルゴリズムです。
- 128 は、使用される鍵のビット長を示しており、ここでは128ビットの鍵が使用されます。
- GCM (Galois/Counter Mode)は、AESを使用した際の暗号化モードの一つで、暗号化と同時にデータの整合性保護を提供します。
- SHA256: データの整合性チェックに使用されるハッシュ関数です。SHA-256は、SHA-2ファミリーの一部で、256ビットのハッシュ値を生成します。
このように暗号スイートは、使用している暗号化アルゴリズムを連結した名前になっています。
証明書の発行
ここまでで説明してきたHTTPSの設定項目のうち、Webサイトの運営者にとって最も深く理解する必要があるのが、この証明書の発行です。
CDNを導入する場合、証明書は2箇所で必要となります。オリジンサーバー用とCDN用です。
オリジンサーバーの証明書発行
オリジンサーバーの証明書発行は簡単です。多くのケースでは、Let’s Encryptで発行した無料のDV証明書とCertBotなどの自動更新プログラムを利用しています。Let’s Encryptは、HTTPSを普及させるために無料でDV証明書を発行している組織です。
エッジサーバー-オリジン間の通信はユーザーから見えないため、DV証明書で十分です。 前回記事で解説したように、証明書の種類と暗号の強度は無関係であり、証明書を発行する際のチェックの厳格さだけが異なっています。
オリジンサーバーの証明書発行の注意点は、必ずオリジンサーバーのドメイン名で証明書を発行することです。上の図の例では、origin.bloomblock.netがCNかSANに含まれている必要があります。
CDNの証明書発行
CDNの証明書は、オリジンサーバーの証明書と異なり、ユーザーから直接見える証明書です。そのため、企業規模に応じて証明書の種類を検討することになります。
CloudFrontを利用している場合、DV証明書であれば、証明書管理のサービスであるACM(AWS Certificate Manager)を使って無料で発行できます。一方で、OV/EV証明書の場合は、認証局による身元確認などのチェックが必要となります。OV/EV証明書の場合は、証明書発行をサービスを提供している認証局に依頼し、発行された証明書をACMにインポートすることでCloudFrontで利用可能になります。
証明書の発行と設定は次のプロセスで行います。
- CSRを作成し、認証局に送信
- 認証局でのチェックの後、証明書が発行される
- ACMに証明書をインポート
- CloudFrontにACM経由で証明書を設定
CSR(Certificate Signing Request)は、証明書の発行に必要なリクエストです。公開鍵、組織の識別情報、ドメイン名を含みます。CSRには、公開鍵、組織名、ドメイン名などの情報が含まれています。 サーバーの秘密鍵を使って署名され、認証局に提出されることで、認証局の証明書発行プロセスが開始します。
次に、認証局はドメインの管理権限を持っていることをチェックします。一般的に次の2つの認証方法があります。 他の認証局でも同じ認証方法のことが多いです。どちらの方法でも対応できる場合は、自動化しやすく、トラブルが少ないため、DNS認証が推奨されています。
- DNS認証: ドメインのDNSレコードに特定の検証レコードを追加することでドメインの管理権限を証明します。Route53では、特定のCNAMEレコードを追加するように指示されます。CNAMEレコードを登録できる = ドメインの管理権限を持っていることを証明します。
- Email認証: ドメインに関連付けられたメールアドレスに検証リンクが送信され、そのリンクをクリックすることで所有権を証明します。ドメイン登録をする際に管理者のメールアドレスを記載しますが、その情報はWHOISと呼ばれるデータベースに載っています。筆者の経験上、Email認証は、管理者への認証メールが迷惑メールに入っていて気づかない、WHOISに登録されているメールアドレスが利用者が退職して使えないといったトラブルが起こりやすいです。
DV証明書の場合は以上の作業で証明書が発行されますが、OV/EV証明書の場合は、登記情報などの追加のチェックが認証局によって行われます。
証明書が発行されたら、それをACMに登録し、CloudFrontで利用をする設定をすれば完了です。
まとめ
2回に渡って、HTTPSとそれを支えるTLSの解説を行いました。 HTTPSへの対応は必須であり、適切に設定されていないサイトはブラウザが警告を出します。 警告が出るとWeb技術に明るくないユーザーは離脱し、逆に技術に明るいユーザーはサイトに対して不信感を持つことになります。そのため、ブラウザで証明書の情報を見るなどして、十分にTLSについて理解しておくことをおすすめします。
本記事で解説した中で特に重要な点は次の3つです。
- クライアントとサーバーでは同じTLSバージョンと暗号スイートが使用できる必要がある
- TLSのバージョンは、v1.2かv1.3にする
- CDNを導入する場合、CDNの証明書とオリジンサーバーの証明書の2つの証明書を発行、更新する必要がある
次回の記事では、このシリーズの総まとめとして、CDNの導入手順を最初から最後まで一気通貫で解説します。 ここまでで得た知識を総動員して読んで頂ければ嬉しいです。
CDN入門の記事一覧ページはこちらです。