TLS/SSL で用いられる暗号スイートについて

公開日:2025/09/26

1 はじめに
2 TLS/SSL の暗号スイートとは
3 暗号スイート選択の流れ
4 脆弱な暗号スイートについて
- 4.1 なぜ問題か？
- 4.2 対策
5 暗号スイートに脆弱性が発見された場合の対応
6 実際に利用されている暗号スイートリストの確認方法
7 まとめ

はじめに

現代の Web セキュリティにおいて、HTTPS 通信はもはや欠かせない存在となりました。その仕組みを支える要素のひとつが、TLS/SSL における「暗号スイート」です。暗号スイートは、安全な通信を実現するうえで重要な役割を担っており、その定義や仕組みを理解することで、セキュリティをより正しく捉えられるようになります。

本記事では、この暗号スイートについて、基本的な考え方と実際の利用場面をわかりやすく紹介します。

TLS/SSL の暗号スイートとは

暗号スイート（Cipher Suite）とは、TLS/SSL 通信で利用される暗号技術の組み合わせを、ひとつのパッケージとして定義したものです。これにより、通信の開始から終了までに「どの方式で暗号化や認証を行うか」が決まります。

TLS 1.2 までの暗号スイートは、主に次の 4 つの要素で構成されます。

鍵交換アルゴリズム：通信開始時に暗号化鍵を安全に共有する仕組み（例：RSA、DHE、ECDHE）
認証アルゴリズム：サーバーの身元が正しいことを証明する仕組み（例：RSA、ECDSA、DSA）
対称暗号化アルゴリズム：実際のデータを暗号化する方式（例：AES、ChaCha20）
メッセージ認証コード（MAC）：データが改ざんされていないかを確認する方式（例：SHA-256/384）

これら 4 種類のアルゴリズムの組み合わせによって暗号スイートが定義されます。利用可能なスイートは IANA によって標準化されており（RFC 5246, RFC 8446 など）、実際の通信では 2 バイトのID値として表現されます。

一方、最新の TLS 1.3 では「鍵交換」や「認証方式」を暗号スイートには含めず、別の仕組みで交渉されるようになり、構成が大幅にシンプル化されました。これは、運用上の問題を解決したり、通信の効率化を目的としています。

具体例として、従来の「4 要素セット」だと新しいアルゴリズムが導入されるたびに大量のスイートを定義する必要があります。そのため、管理者が設定を誤りやすいという問題があり、シンプルな方式ではこの問題を解消できます。

暗号スイート選択の流れ

TLS の通信が始まると、最初に「ハンドシェイク」と呼ばれるやり取りが行われます。この過程で、どの暗号スイートを使うかが決定されます。大きな流れは TLS 1.2 でも TLS 1.3 でも共通です。

■ ClientHello（クライアント → サーバー）
TLS 通信を開始するクライアント（例：ブラウザ）は、まず「自分が対応できる暗号スイートの一覧」をサーバーに送ります。これが ClientHello メッセージです。ここには暗号スイートのリスト以外にも、サポートする TLS バージョンや拡張機能などが含まれます。

■ ServerHello（サーバー → クライアント）
サーバーは、クライアントから送られたリストの中から「自分も対応できる暗号スイート」を 1 つ選びます。選択方式には「サーバー優先」と「クライアント優先」の両方がありますが、一般的にはサーバー優先が用いられます。セキュリティを重視する場合はサーバー優先が望ましく、パフォーマンスを重視する場合（例えば Cloudflare などの CDN など）はクライアント優先を選ぶこともあります。選ばれたスイートは ServerHello メッセージに含まれ、以後の通信はこのスイートに従って暗号化や認証が行われます。

■ 合意形成後のやり取り
暗号スイートが決まると、その方式に基づいて鍵交換、証明書の検証、暗号化通信の確立と処理が進みます。

この流れにより、サーバーとクライアントは「両方が対応できる最も適切な暗号スイート」を選び、安全に通信を開始できるのです。

脆弱な暗号スイートについて

TLS/SSL の歴史の中では、多くの暗号スイートが提案されてきました。しかし、その中には現在では「安全でない」と判断され、利用が推奨されないものもあります。こうした暗号スイートをまとめて「脆弱な暗号スイート」と呼びます。

具体的な例は次の通りです。

NULL 暗号スイート：データを暗号化せずに送信する方式。平文なので暗号化通信の意味がなく、極めて危険。
RC4 を用いるスイート：ストリーム暗号 RC4 を利用。統計的な偏りや既知の攻撃手法により、解読可能となっている。
古いハッシュ関数を用いるスイート（MD5, SHA-1）：衝突攻撃などが実用化されており、安全性が失われている。

なお、各暗号スイートの安全性についてはまとめられているウェブサイトがあり、例えば以下のページを参照できます。

https://ciphersuite.info/cs/

なぜ問題か？

サーバー側が脆弱な暗号スイートを残していると、クライアントがそれを選択してしまい、実用的な時間で解読可能な通信方式が使われてしまう危険があります。通信が傍受されれば、内容が読み取られたり改ざんされたりして、安全性が担保できません。

また、攻撃者は「ダウングレード攻撃」と呼ばれる手法を使い、強いスイートではなく弱いスイートを強制的に使わせることがあります。そのため、脆弱な暗号スイートを残しておくこと自体がリスクとなります。

対策

サーバー設定で脆弱な暗号スイートを無効化する。
TLS の最低バージョンを TLS 1.2 以上に引き上げる。
定期的にベストプラクティス（Mozilla SSL Configuration Generator など）を確認し、推奨設定に従う。

なお、TLS のバージョンを引き上げると、一部の古いクライアントからは接続できなくなる点には注意が必要です。

暗号スイートに脆弱性が発見された場合の対応

実運用中に利用している暗号スイートに脆弱性が発見された場合は、サーバー側の設定から該当するスイートを無効化（削除）することで対応できます。
これは TLS の通信開始時、ClientHello → ServerHello の流れで暗号スイートを交渉しているため、サーバーが「安全なスイートだけを選択肢として提示する」ことで回避できる仕組みになっているからです。サーバー設定だけで対処可能になっているのは TLS/SSL の優れた点といえます。

ただし例外として、クライアント側が特定の脆弱なスイートしか対応していない場合、そのクライアントとは通信できなくなってしまいます。そのような環境で暗号化通信を行う場合、事前に鍵を共有する方式などの TLS/SSL とは別の暗号化技術を用いるべきです。すべての環境に TLS/SSL が最適というわけではない、という点は理解しておく必要があります。

実際に利用されている暗号スイートリストの確認方法

実際にサーバーが提供している暗号スイートを確認する方法はいくつかありますが、ここでは nmap の Scripting Engine を利用して確認してみます。

以下は、CloudFront で TLSv1.2_2021 を指定している場合に確認した結果の例です。

$ nmap --script ssl-enum-ciphers -p 443 <ウェブサイトのドメイン>
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.3:
|     ciphers:
|       TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|     cipher preference: server
|_  least strength: A

この結果から分かるように、TLS 1.2 以上に対応し、現在推奨されている安全な暗号スイートのみが提供されていることが確認できます。