最適なSSL/TLS化の設定ガイドライン

Home » Blog » 最適なSSL/TLS化の設定ガイドライン

Try CDNetworks For Free

Most of our products have a 14 day free trail. No credit card needed.

Googleがhttps化（SSL/TLS化）されていないWebページについて「Not secure」メッセージをChrome上で表示させる取り組みがいよいよ2018年7月にスタートします。今後httpの場合にはアラートメッセージがもれなく表示されることになります。

そこで、これからはログインなどの入力フォームを利用していない単純なホームページであっても、基本的にhttpsに対応しておく必要があるでしょう。

SSL/TLS化する際にネックとなる複雑な問題については、以前のブログで解説をしていますので、是非こちらをご覧ください。

SSL/TLS化については、特にSSLサーバ証明書（certificate）の準備からプロトコルおよびcipher（暗号）の設定が複雑です。そこで本ブログでは、SSL/TLS化の設定時に最適なSSL/TLSプロトコルおよびcipherの設定構成について解説します。

無料でApache WebサーバにSSL/TLSサーバ証明書を構築する

SSL/TLSの利用には、まずSSLサーバ証明書の設定から始めなければなりません。ただし、同時にCDNを利用する（している）場合には、比較的簡単にこれを構築することができます。

Webサーバ（オリジン）に直接httpsを構築するには、comodoやdigicertのようなSSLサービス（暗号化通信）の利用が一般的ですが、最近はほぼすべての最新ブラウザとの互換性を維持しつつ無料でサービスを提供するLet’s Encrypt（https://letsencrypt.org/）を利用するケースが急増しています。

ここではApache Webサーバを運用する前提で、Let’s Encryptを設定する方法について解説します。Let’s Encrypt を利用してSSLサーバ証明書を設定する方法はとても簡単です。まず、gitで関連ファイルをインストールしてスクリプトを実行するだけで完了です。

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt/
/etc/init.d/httpd stop
./letsencrypt-auto certonly --standalone
vi /etc/httpd/conf.d/ssl.conf
/etc/init.d/httpd start

<表１>

次に<表２>は、viでssl.confを設定する際に、追加する必要がある内容の例です。<表1>のスクリプトで生成したSSLサーバ証明書関連ファイルの場所を「SSLCertificate*」の指定子で指定します。

<VirtualHost www.example.com:443>
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn
SSLEngine on
SSLProtocol TLSv1.2 -SSLv2 -SSLv3 -SSLv2 -TLSv1 -TLSv1.1
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"
SSLCertificateFile /etc/letsencrypt/live/www.example.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.example.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/www.example.com/chain.pem
Header always set Strict-Transport-Security "max-age=15552000; includeSubdomains;"  # HSTS
</VirtualHost>

<表２>

一般的にSSLサーバ証明書には有効期限があり、期間満了前に延長手続きが必要です。なお、Let’s EncryptのSSLサーバ証明書は、あらかじめ90日間のみ有効と決められているため、90日を経過する前に延長手続きをしなければなりません。これは、<表３>のスクリプトを/etc/cron.monthlyにインストールすることで毎月チェックが行われて、必要時には自動で契約延長してくれるためとても便利です。

#!/bin/sh
/etc/init.d/httpd stop >/dev/null 2>&1
/root/letsencrypt/letsencrypt-auto renew >/dev/null 2>&1
/etc/init.d/httpd start >/dev/null 2>&1

< 表３>

なお、SSL設定後に https://www.ssllabs.com/ssltest/ でhttpsのセキュリティレベルをチェックすると、最高点の「A+」であることが確認できます。

<画像2>

余談になりますが、A+を獲得するためにはWebサーバにHSTSを適用して有効にしなければなりません。HSTSは「HTTP Strict Transport Security」の略で、<表4>の設定を追加することで簡単に実行できます。これは、一度設定しておけば過去に1回でもアクセスのあるクライアントは、期間中 (この場合180日)に該当するドメインにアクセスすると、httpにアクセスしてもブラウザ上でhttpsに自動的に切り替わります。この情報はブラウザのキャッシュのように記憶され、ユーザが別途設定を削除しないかぎり維持されるため、httpのみで運用しているドメインがないかどうかを事前に確認しておく必要があります。

＊最初はmax-ageを短く設定し、問題がなければ180日程度にすることを推奨します。

>Header always set Strict-Transport-Security "max-age=15552000; includeSubdomains;"  # HSTS

<表４>

プロトコルおよび cipher の具体的な設定方法

前述で解説したSSL/TLSの具体的な設定方法について、一つずつ確認をしてみましょう。

まず、SSL/TLSプロトコルはSSLv2からSSLv3、TLSv1.0、TLSv1.1、TLSv1.2などがあり、最近ではTLSv1.3が一部で試用され始めています。このうちSSLv2およびSSLv3は、各々DrownやPoodleのように暗号化 (encryption)しても平文(plain text)に復号化(decryption)できるセキュリティ脆弱性が見つかったため、絶対に使用してはいけないプロトコルです。最も一般的に使用されているプロトコルは、TLSv1.0からv1.1、v1.2ですが、PCI DSSのコンプライアンスでは、TLSv1.0もミドル攻撃や潜在的な脆弱性があるためにこれ以上使用を続けないことを推奨しています。

一方でTLSv1.0を無効にする場合は、Windows Vistaや7のMSIE 8-10バージョンを使用するユーザは、httpsアクセスができません。そこで、アクセスユーザの利用環境やセキュリティを考慮してプロトコルを設定することをお奨めしますが、FacebookやGoogle、Twitterなどはまだ古い環境のユーザも考慮し「TLSv1.0、v1.1、v1.2」のすべてに対応しています。

また、Apache 設定においての解釈は、最新の暗号化アルゴリズムを提供するTLSv1.2のみを有効にし、その他のプロトコルは「-」を指定しており、これはサポートしないことを意味しています。

SSLProtocol TLSv1.2 -SSLv2 -SSLv3 -SSLv2 -TLSv1 -TLSv1.1

<表５>

次に暗号スイートについて解説します。これは複雑な暗号のように構成されていますが、まずはその意味を理解しましょう。

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
<表6>

「WITH」を基準として、前の部分はクライアントとWebサーバ間の鍵(Key)交換および認証を担当し、実際にデータを暗号化する部分は「WITH」の後ろにあり、暗号スイートを通じて処理されます。

暗号スイートついて、TLSは前述で解説したプロトコルを意味し、ECDHE（ephemeral Elliptic Curve Diffie Hellman）は鍵交換方式を指し、RSAは認証アルゴリズムを意味しています。また、AES_128_GCMは、AESアルゴリズムと128bitの鍵長、GCM(Galois Counter Mode)を意味しており、データが途中で変造される可能性に備えてSHA256というハッシュアルゴリズムを利用して暗号化したことを意味しています。

httpsでクライアントとWebサーバは前述の6つの条件に従う交渉(Negotiation)を通じて通信しますが、当然ながら安全な通信のためには脆弱性のある暗号化Cipherを取り除き、強力な暗号化Cipherの利用を推奨しています。

なお、CDNetworksでクライアントユーザのブラウザ互換性をサポートしつつ、安全にサービスできる暗号スイートの推奨構成は<表７>のとおりです。

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)

<表７>

Webサーバで暗号スイートを設定する際には、特に順番(order)が大切ですが、これはクライアントとのSSL/TLS交渉の過程で、先にマッチングされるcipherで通信するため、できればより安全かつ強力なcipherを先に定義したほうがよいでしょう。cipherの順番を定義する際は<表8>を参照してください。

◇CBC cipheはできる限り下段に設定しましょう
円滑なHTTP/2 サポートのために、HTTP/2 ブラックリストに指定した次のCBC(Cipher block chaining) モードはできる限り下段に設定することを推奨しています。
:: https://tools.ietf.org/html/rfc7540#page-83 参照

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

<表８>

◇PFSに対応するcipherをまず定義しましょう
PFS(perfect forward secrecy)に対応する場合、もし秘密鍵（private key）が漏れてもPFSを通じて暗号化されたパケットで復号化できないようにする特徴があります。そこで、PFSに対応するECDHE cipherを先に定義し、PFSに対応しない<表9>のTSL_RSA cipherは下段に定義するなどして、優先順位を調整しましょう。

TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256

<表9>

◇3DESはなるべく優先順位を下げるか無効にしましょう
暗号化する時には最低でも128bit以上のcipherを利用することが推奨されますが、3DESは112bitを利用するために脆弱性があることで知られています。従って、SSL/TLS化したとしても、特定の条件の下で暗号化を解除し、平文(plain text)に解読できるsweet32という脆弱性が (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2183)発見されています。これはもちろんさまざまな条件が整った上での攻撃ですが、攻撃成功の可能性があると確認されただけに、より安全な顧客サービスのためにあらかじめ備えておくことを推奨しています。ただし、3DESを無効にした場合に、Windows XPのMSIE8を利用してhttpsにアクセスすると、正常にアクセスができなくなるため注意が必要です。

◇その他の安全でないcipherは無効にしましょう
ADH(Anonymous Diffie-Hellman) , NULL, RC4 など

まとめ

最後に、SSL/TSL化する際には、すべてのコンテンツに対して適用することを推奨しています。

ほとんどのコンテンツはhttpsでサービスをしつつも、cssファイルやイメージファイルは誤ってhttpでサービスをしているケースも多く見られます。たった1つのファイル設定ミスによりミドル攻撃 (man-in-the-middle attack)にさらされたり、セッション全体を乗っ取られる恐れもあるため、調査と検証、そして現状把握を怠ることなく、適切な対処および体制を整えることがとても大切です。

本日解説した「最適なSSL/TLS化の設定ガイドライン」について、より多くの情報を入手されたい方は下記URLを参照してください。
https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices

CDNetworksでは、CDNサービスを利用してWebサイトの高速化やWebサーバの負荷分散対策を行うことを検討している（行っている）お客様で、https通信を希望するお客様に向けたSSLサービスを提供しています。CDN経由のSSL利用は、自社で構築するよりも比較的手軽に行える上に、暗号化/複合化処理により増大するWEBサーバの負荷とパフォーマンスの低下を、豊富なキャパシティを持つCDNのプラットフォーム上でこれに対処することで解消することができます。

CDNの利用を検討されている場合には、是非SSLの利用も併せてご相談ください。
CDNetworksでは、SSL/TSLサービスの詳細についてのホワイトペーパーをまとめています。是非一度ご参照ください。