[PR] あなたが Kindle で読みたいその本、Kindle に対応したら Twitter でお知らせします。

ELB, CloudFront が対応する SSL/TLS の暗号スイートとプロトコル

Posted on

AWS でエンドユーザーに対して SSL/TLS による暗号化通信を実現するためにはいくつかの方法が考えられますが、フルマネージドなら ELB と CloudFront を採用することになると思います。

2014 年から今年にかけて SSL/TLS の脆弱性がいくつも報告され、暗号スイートやプロトコルの設定を見直す機会も増えました。そこで ELB と CloudFront が対応する SSL/TLS の暗号スイートとプロトコルを調べてみました。

※ 2015/09/16 時点の AWS 公式ドキュメントをベースにしています。

ELB が対応する暗号スイート

ELB には AWS が事前定義したポリシーがあり、特別な理由がない限り最新のものを使うことが推奨されています。最新バージョンは 2015-05 なので、これを見てみます。

  • プロトコル
    • TLS v1
    • TLS v1.1
    • TLS v1.2
  • 暗号スイート
    • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256)
    • ECDHE-RSA-AES128-GCM-SHA256 (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256)
    • ECDHE-ECDSA-AES128-SHA256 (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256)
    • ECDHE-RSA-AES128-SHA256 (TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256)
    • ECDHE-ECDSA-AES128-SHA (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA)
    • ECDHE-RSA-AES128-SHA (TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA)
    • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384)
    • ECDHE-RSA-AES256-GCM-SHA384 (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
    • ECDHE-ECDSA-AES256-SHA384 (TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384)
    • ECDHE-RSA-AES256-SHA384 (TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384)
    • ECDHE-RSA-AES256-SHA (TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA)
    • ECDHE-ECDSA-AES256-SHA (TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA)
    • AES128-GCM-SHA256 (TLS_RSA_WITH_AES_128_GCM_SHA256)
    • AES128-SHA256 (TLS_RSA_WITH_AES_128_CBC_SHA256)
    • AES128-SHA (TLS_RSA_WITH_AES_128_CBC_SHA)
    • AES256-GCM-SHA384 (TLS_RSA_WITH_AES_256_GCM_SHA384)
    • AES256-SHA256 (TLS_RSA_WITH_AES_256_CBC_SHA256)
    • AES256-SHA (TLS_RSA_WITH_AES_256_CBC_SHA)
    • DES-CBC3-SHA (TLS_RSA_WITH_3DES_EDE_CBC_SHA)

ドキュメントは OpenSSL の形式で書かれているので、かっこ内に正式な表記を載せています。暗号スイートの見方は「プロトコル_鍵交換_署名_暗号化_ハッシュ関数」です。

このリストからわかることは、

  • TLS v1.2 の暗号スイートが大半を占めている
  • ブロック暗号に認証付き暗号 (GCM) が使われている
  • 鍵交換、署名共に RSA 暗号より楕円曲線暗号が優先されている

また 2014-01 のバージョンと比べてわかることは、

  • SSL v3 が無効になった
  • ストリーム暗号の RC4 が使われなくなった

CloudFront が対応する暗号スイート

CloudFront は ELB のように自由にポリシーを選択できません。選択できるのは SSL v3 を使うかどうかだけです。

  • プロトコル
    • SSL v3 (明示的に選んだ場合のみ)
    • TLS v1
    • TLS v1.1
    • TLS v1.2
  • 暗号スイート
    • ECDHE-RSA-AES128-GCM-SHA256 (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256)
    • ECDHE-RSA-AES128-SHA256 (TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256)
    • ECDHE-RSA-AES128-SHA (TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA)
    • ECDHE-RSA-AES256-GCM-SHA384 (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
    • ECDHE-RSA-AES256-SHA384 (TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384)
    • ECDHE-RSA-AES256-SHA (TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA)
    • AES128-GCM-SHA256 (TLS_RSA_WITH_AES_128_GCM_SHA256)
    • AES256-GCM-SHA384 (TLS_RSA_WITH_AES_256_GCM_SHA384)
    • AES128-SHA256 (TLS_RSA_WITH_AES_128_CBC_SHA256)
    • AES256-SHA (TLS_RSA_WITH_AES_256_CBC_SHA)
    • AES128-SHA (TLS_RSA_WITH_AES_128_CBC_SHA)
    • DES-CBC3-SHA (TLS_RSA_WITH_3DES_EDE_CBC_SHA)
    • RC4-MD5 (SSL_RSA_WITH_RC4_128_MD5)

ELB と比べると若干少ないですが、TLS に対応したクライアントで問題になることはないでしょう。

このリストからわかることは、

  • TLS v1.2 の暗号スイートが大半を占めている
  • ブロック暗号に認証付き暗号 (GCM) が使われている
  • 鍵交換、署名共に RSA 暗号より楕円曲線暗号が優先されている
  • 例外的に SSL v3 を使うこともできる

基本的には ELB と同じですが、CDN というサービスの特性上、幅広いクライアントに対応する必要があるため例外的に SSL v3 を使うこともできます。

RSA 暗号より楕円曲線暗号が優先されているのは、短い鍵長でも安全性を落とさずに低負荷で処理できる楕円曲線暗号のメリットを得るためだと思います(専門分野ではないので、間違っていたら突っ込んでください)。 ELB や CloudFront にとってセキュリティとスケーラビリティを両立させることは非常に重要だからです。

Qualys SSL Labs のテスト結果

実際に ELB と CloudFront にサーバ証明書を設定して Qualys SSL Labs でテストしてみたので、参考までにサマリーを載せておきます。

Qualys SSL Labs のテスト結果

ELB と CloudFront どちらもまったく同じ結果で A のレーティングでした。もうひとつ上の A+ もあるようですが、Strict Transport Security や Public Key Pinning を設定しているかどうかなので、アプリケーション側の対応が必要になります。

まとめ

オンプレミスのロードバランサだと新しい暗号スイートに対応するだけでも大変な労力がかかります。

新しい暗号スイートやプロトコルにほぼ手間をかけることなく移行できるのも AWS ならではのメリットだと思います。