🔐

ALBのTLSセキュリティポリシー選定をまとめ

に公開
AWS
Security
ALB
TLS
運用
tech

※ 執筆当時（26/02）の情報です。

ALBのTLSセキュリティポリシー

ALBを使っている場合、ユーザーの通信で使用されるTLSはセキュリティポリシー設定に左右されます。

https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/describe-ssl-policies.html#tls-security-policies

選択可能なセキュリティポリシーの名称の規則は
ELBSecurityPolicy-(TLS上限)-(TLS下限)-(使用する暗号の条件)-(日付)
のようになっています。

今回はALBのTLSセキュリティポリシーとして用意されている選択肢たちがそれぞれどう違っているかを体系的にまとめてみます。

記事の最後にはセキュリティポリシー選定のフローチャートを用意してみたので、まずそちらからご覧いただくのも良いかもです。

TLSバージョンの範囲

TLSなので、サーバーとクライアントのハンドシェイクを経て、通信に使用するバージョンが決定します。サーバー側が持つのは許可するTLSバージョンの「範囲」で、つまり上限と下限です。

上限

バージョン上限については単純です。1.3か1.2ですが1.3が使えないことのメリットはないので、1.3が良いです。

一方で下限は慎重な判断が必要です。下限を引き上げた結果、仮にユーザーがサービスにアクセスできなくなれば大きな損害を生じ得ます。一般論がどうあれ、そういったリスクを念頭に「目の前のサービスにとって最適なセキュリティポリシーが何か」を判断しましょう。

下限:1.0, 1.1

可用性を最大化するなら下限は1.0や1.1です。しかし1.0, 1.1は既に脆弱なバージョンのため、基本的に外したいです。

下限を1.0や1.1で妥協するのは、現在1.0や1.1が下限となっている状況で「かといって1.2まで引き上げることは厳しい」ときだと思います。アクセスログなど[1]を参考に現在このバージョンからアクセスしているユーザーがどれほどいるかを確認の上で下限を1.2以上に引き上げられるかを検討すると良いでしょう。

ただ、今どき多くのWebサイトは1.0, 1.1は許可していないため、「既に多くのWebサイトが閲覧できない環境を見切る」だけ、というのはヒントとして持っておいても良いと思います。

下限:1.2

TLS1.2はまだまだ現役のバージョンです。ので、下限としては1.2を選ぶことが多いと思います。デフォルトのポリシーでも下限は1.2となっています。

下限:1.3

秘匿性を最大化するなら下限は1.3です。まだ安全とされている1.2を切ることになります。サービスの必須環境が厳密にあるなどで常に1.3が利用可能である場合には下限を1.3まで引き上げる判断が可能かもしれません。

たいていのサービスは「一人でも多くのユーザーに使ってもらいたい」という経済主義がベースにあるので、必須環境や推奨環境がどうあれ、制限的なポリシーを選択することはそれに遡行する判断としての側面があることを理解しておきたいところです。

使用する暗号の条件

PQ

Post Quantumの略で、量子計算が実用化されても解読困難とされる暗号を採用することを意味します。古典コンピュータでは安全な暗号も、理論上は現実的な時間で解読可能になる[2]ことが知られています。そのため将来のリスクを現実的に見据えて鍵交換アルゴリズムに耐量子のML-KEMを利用可能にする先進的なポリシーとなっています。

TLS1.2以下の暗号スイートは
鍵交換-署名-暗号化-ハッシュ関数（例：ECDHE-RSA-AES128-SHA256）
のように先頭部分が鍵交換方式になっています。TLS1.2以下の暗号スイートの先頭の文字列はいずれもECDHEかAESとなっており、TLS1.2以下ではML-KEMが使用不可であることが分かります。

Res

現在脆弱とは言えないものの潜在的な脆弱性を孕む、CBCモードを排除した暗号のみをサポートします。具体的にはChaCha20かGCMを強制しています。

ちなみにTLS1.3ではChaCha20かGCMが強制される[3]ので、下限が1.3の場合はResの条件は暗黙的になっています。逆にTLS1.1以下を許容する場合はGCMを強制できないのでResの選択肢がそもそも用意されていません。

Ext

一時的ディフィー・ヘルマン鍵交換（DHE）を強制しないポリシーです。DHEは、前方秘匿性を担保します。つまり、通信のたび使い捨ての鍵を生成する仕組みなので一度鍵が漏洩したことで過去の暗号文全て解読されるといったリスクがありません。レガシーなクライアント端末ではサポートされていない場合があるようです。

Res同様、TLS1.3では暗黙的にDHEが使用されるため下限が1.3の場合はExtの条件も考慮不要です。

（余談）こう聞くと「DHEは強制するがCBCモードは容認するセキュリティポリシーがあっても良いんじゃないか？」と思えてきますが、そういったセキュリティポリシーは用意されていません。これに関してAIに意見を聞いてみたところ

  • クラウドベンダー視点では多様なカスタマイズ性を持たせるより「推奨」「標準」「拡張的」のように順序付された形で提供してユーザーを混乱させない方向に設計したい
  • 将来の漏洩の心配（=DHE）は今の通信の心配（=CGM, ChaCha20）の後。今通信を解読していけるなら過去の情報より先に狙われる

という感じの回答を得て、ある程度腑に落ちました。

Ext1 or Ext2

Ext2の方が緩和的なポリシーで、Ext2は改竄耐性に懸念がある暗号スイートも許可しています。Ext1では署名に用いるハッシュはSHA-256かSHA-384を使用します。Ext2ではSHA-1も許可しています。

ハッシュの偽造耐性として最も重要なのは「第2次原像耐性の有無」です。これは「元の値とハッシュ値が分かっている時に、そのハッシュ値となる別の値を探すことが困難である」という性質です。SHA-1も、そこはクリアしています。

しかしSHA-1は次点で重要な「強衝突耐性」がないことが明らかにされています[4]。技術や理論の進歩に伴って第2次原像耐性をも脅かされることが現実的な問題として危惧され、SHA-1はもはや安全ではないと考えられつつあるというわけです。

結局どう考えればいい？

記事のまとめとしてポリシー選択のフローを載せて終わります。ゴールが上にあるほどセキュアで、抑制的です。

フロー

  • A -> TLS 1.3のみのポリシー
  • B -> TLS 1.2~1.3のResのポリシー
  • C -> TLS 1.2~1.3の無印のポリシー
  • D -> TLS 1.2~1.3のExt1のポリシー
  • E -> TLS 1.2~1.3のExt2のポリシー
  • F -> TLS 1.0~1.3または1.1~1.3のポリシー
  • 耐量子暗号を使いたい場合はPQの方のポリシーを選択（フロー上は省略しています）

まとめた感想

TLSが結局どういうルールを規定しているかの解像度が自然と上がってよかったです。漠然と「通信を暗号化するときのプロトコル」だったのが「通信における鍵交換、署名、ハッシュ化などの複合的な技術を統合するプロトコル」として捉えられるようになりました（あとガロア理論学び直したくなった）。

脚注

  1. ALBのアクセスログについて ↩︎

  2. Shorのアルゴリズムなどで検索 ↩︎

  3. IPA「TLS暗号設定ガイドライン」P11 ↩︎

  4. https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html ↩︎

Discussion