ELBのセキュリティアップデートによるTLS 1.1対応

AWS

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Elastic Load Balancing(ELB)は、EC2インスタンスへのトラフィックを自動的に分散するAWSのサービスです。負荷分散や可用性を高める目的で利用されます。今回は、2014年2月に追加されたELBのセキュリティを強化するための新機能について解説します。

結論としては、AWSでELBを利用してHTTPS通信を行っているのであれば、特別な事情が無い限り、直ちにセキュリティポリシーの設定を「ELBSecurityPolicy-2014-01」に変更し、セキュリティを強化してください。

設定方法

AWS Management Consoleにログインし、EC2 Dashboardを開き、NETWORK & SECURITYのLoad Balancersをクリックします。変更するELBを選択したならば、Listenersタブを開いてください。

ELB

次にHTTPSのプロトコルのCipherの「Change」をクリックします。Select a Cipherダイアログが開くので、Predefined Security Policyから「ELBSecurityPolicy-2014-01」を選択して、Saveしてください。

ELB_Cipher

主な変更内容

セキュリティポリシーを変更することで主に以下の機能が有効になります。

  • TLS 1.1/1.2
  • Perfect Forward Secrecy
  • Server Order Preference

これにより、クライアントがTLS1.1に対応したブラウザであれば、TLS1.1以上のプロトコルが選択されるようになり、SSLv3.0/TLSv1.0におけるBCモードの脆弱性(CVE-2011-3389)等への対策となります。この脆弱性は、古くから知られていたようですが、近年になって有効な攻撃方法が発見され、各ベンダで対応を進めている段階です。そのような流れの中でAWSによるアップデートも行われました。

解説

アプリケーション開発者など、「セキュリティを意識しなければならないが、セキュリティの専門家ではない」といった層が理解しやすいように説明します。なお、自分自身はセキュリティの専門家ではないので、もし間違った記述などがありましたらばご指摘ください。

TLS 1.1 / 1.2対応

TLS(Transport Layer Security)は、セキュリティを確保するためのトランスポート層の上部に位置するプロトコルです。SSL(Secure Sockets Layer)の技術をベースに作られているため、しばしばTLSとSSLは同じ意味として用いられます。TLS/SSLは、主にHTTPと合わせて利用されます。このHTTP over TLS/SSLは、一般的にHTTPSとして知られ、Webシステムに対し機密性の高い通信を行う場合に利用されます。

2014年現在、TLSの最新バージョンは2008年に制定された1.2ですが、サーバもクライアントもやっと対応しはじめたという段階です。TLS1.1も似たような状況です。最新のブラウザでなければTLS1.0しか対応していないと考えて良い段階であり、脆弱性などが発見されているため、オプション機能などを併用して脆弱性の脅威に対応しなければなりません。

ELBは、これまでTLS1.0にのみ対応していましたが、このアップデートにより、TLS1.1 /1.2に対応できるようになりました。

Perfect Forward Secrecy

Perfect Forward Secrecy(PFS)は暗号化通信のセキュリティを高めるための仕組み(概念)です。

万が一、暗号化通信に用いる鍵が漏洩してしまった場合、キャプチャして保存していた通信内容は過去に渡って復号化されてしまう可能性があります。そこで、一時的な情報であるセッションキーを暗号化通信に利用します。これにより、万が一、鍵が漏洩してしまった場合でも、通信内容が復元される可能性を低くするわけです。

Server Order Preference

暗号化通信の技術は常に進化しており、同時に脆弱性も新しく発見されていきます。しかし、常に最新の技術を利用すれば良いとも限りません。

サーバサイドは兎も角、クライアントサイド、すなわちブラウザが最新のセキュリティ方式に対応していなければ通信そのものが出来なくなってしまいます。古いブラウザを利用せざるを得ないこともあります(最新のOS/ブラウザにアップデートすることは必要かと思いますが)。

Server Order Preferenceを有効にすることで、ELBは適切な暗号化技術を選択して適用します。TLS1.2に対応していないブラウザからのアクセスであれば、TLS1.0で適切な暗号化技術を組み合わせて通信を行うようになるため、自動的に最適なセキュリティ対策を行ってくれると考えてよいでしょう。

ただし、古いOSやブラウザからのアクセスであれば対応する暗号化技術も古いため、セキュリティは弱くなります。可能な限り最新のOS/ブラウザを利用した方が良いことは変わりません。

まとめ

ELBのセキュリティ設定を見直し、アップデート後のセキュリティ設定を適用してください。また、利用者に最新バージョンのOS/ブラウザを利用するよう促しましょう。セキュリティを強化するには、両方のアップデートが必要です。

参考リンク

  • http://github.com/sowawa Keisuke Sogawa

    CVE-2014-0160でELB周りのSSL事情に興味が出てきて拝見させていただきました。

    ELBSecurityPolicy-2014-01を選ぶだけではCVE-2011-3389の対策にはならないと思います。
    ELBSecurityPolicy-2014-01はTLS1.0を含んでいて、かつ暗号化方式にいくつかのブロック暗号が含まれてしまってるのでCVE-2011-3389の脆弱性が残ってしまうと思います。実際に、ELBにELBSecurityPolicy-2014-01を設定して脆弱性Scanツールで調べたのですがCVE-2011-3389はunsupportedでした。私が調べた結果がFalse Positiveで筆者さんの環境で使われたscanツールによっては対策済みになっていたのかもしれませんが。

  • SHUJI

    コメントありがとうございます。
    > ELBSecurityPolicy-2014-01を選ぶだけではCVE-2011-3389の対策にはならないと思います
    はい、その認識です。

    > クライアントがTLS1.1に対応したブラウザであれば、TLS1.1以上のプロトコルが選択されるようになり
    と書いたように、TSL1.0しか対応していないクライアントである限り、CVE-2011-3389対策はできないとの認識です。

    技術的にできないのであれば、ユーザに最新のブラウザを利用するよう喚起することも対策にはならないでしょうか?

  • http://github.com/sowawa Keisuke Sogawa

    クライアントへの注意喚起が目的であったということ承知いたしました。
    セキュリティポリシーをELBSecurityPolicy-2014-01変更することが
    直接的にCVE-2011-3389に対応することになるという意味と取り違えておりました。
    大変申し訳ございませんでした。

    お詫びも兼ねて私の方で調べてみたところ、こちらはCustomPolicyで対応することが出来ます。
    AWSがPCIDSSを取得しており、ELBはコンプライアントなサービスであることになっているため
    CVE-2011-3389に技術的な対応ができないということはさすがにないだろうと思い、
    技術サポート側に具体的な対策について聞いたところCustomPolicyで暗号化方式にブロック暗号が
    含まれないように選択することで対応できるという回答をいただきました。

    検証を兼ねて、実際私の方でブロック暗号を取り除いたところ
    PCIDSSの認定のASV Scaningでも問題がないことを確認しました。