TLS 暗号スイート｜OpenSSL・GnuTLS・NSS での名前

TLS_NULL_WITH_NULL_NULL

最初のハンドシェイクが完了する前の接続に置かれる、仮のスイートです。鍵交換も認証も保護もありません。

TLS_NULL_WITH_NULL_NULL（0x00,0x00）は TLS 1.2 接続の初期状態を表します（RFC 5246 §6.1）。ネゴシエートされることはなく、これを選択するサーバーには深刻なバグがあります。

TLS_RSA_WITH_RC4_128_SHA

SHA-1 と RSA 鍵輸送を使う RC4 のスイートです。かつては BEAST への対策として広く選ばれましたが、現在は RFC 7465 で禁止されています。

RC4 は 2011〜2013年の CBC への攻撃を受けないため、一時期はその理由で推奨されていました。しかし、キーストリームの偏りにより、Cookie のように繰り返し送信される平文を攻撃者が復元できてしまいます。RFC 7465 §2 は、クライアントは ClientHello に RC4 のスイートを含めてはいけない（MUST NOT）、サーバーはそれを選択してはいけない（MUST NOT）と定めています。

TLS_RSA_WITH_3DES_EDE_CBC_SHA

TLS 1.1 で実装必須とされたスイートです。ブロック長が 64 ビットのため、Sweet32 の誕生日攻撃に対して脆弱になりました。

RFC 4346 §9 は、TLS 1.1 の実装に TLS_RSA_WITH_3DES_EDE_CBC_SHA（OpenSSL：DES-CBC3-SHA）のサポートを求めていました。トリプル DES のブロックは 64 ビットなので、1 つの鍵で約 2^32 ブロックを処理すると、衝突から平文が漏れます。2016年の Sweet32 攻撃は、この方法で長時間続く接続から HTTP の Cookie を復元しました。

前方秘匿性もありません。最近のライブラリはデフォルトで無効にしており、IANA は非推奨としています。

TLS_RSA_WITH_AES_128_CBC_SHA

TLS 1.2 で実装必須とされたスイートです。前方秘匿性がなく、CBC を使います。現在は RFC 10015 で禁止されています。

RFC 5246 §9 はすべての TLS 1.2 実装に TLS_RSA_WITH_AES_128_CBC_SHA（OpenSSL：AES128-SHA）のサポートを求めていたため、多くの古いクライアントにとって最後の手段となるスイートです。RSA 鍵輸送では、クライアントがサーバー証明書の鍵でプリマスターシークレットを暗号化します。そのため、後でその鍵を入手した者は誰でも、記録されたすべてのセッションを復号できます。

MAC-then-encrypt 方式の CBC により、Lucky Thirteen などのパディングオラクル攻撃を受けやすくなっていました。現在、RFC 10015 §4 は、TLS 1.2 の RSA 鍵交換スイートについて、クライアントは提示してはいけない（MUST NOT）、サーバーは選択してはいけない（MUST NOT）と定めています。

TLS_EMPTY_RENEGOTIATION_INFO_SCSV

実在のスイートではなくシグナリング用の値で、クライアントが安全な再ネゴシエーションに対応していることを示します（RFC 5746）。

クライアントは TLS_EMPTY_RENEGOTIATION_INFO_SCSV（0x00,0xFF）を暗号スイートのリストに入れ、拡張を送らずに安全な再ネゴシエーションへの対応を通知します。一部のサーバーが拡張を正しく処理できなかったため、RFC 5746 §3.3 で導入されました。この値は「ネゴシエートできない」ものです。再ネゴシエーションの修正により、攻撃者がクライアントの再ネゴシエートされたセッションの前に自分のデータを差し込む 2009年の攻撃が防がれました。

TLS_AES_128_GCM_SHA256

すべての TLS 1.3 実装がサポートしなければならない暗号スイートです。GCM モードの AES-128 と、鍵スケジュール用の SHA-256 を使います。

RFC 8446 §9.1 は TLS 1.3 で TLS_AES_128_GCM_SHA256 の実装を必須とし、その後継である RFC 9846 もこの要件を引き継いでいます。TLS 1.3 のスイートが指定するのは AEAD と HKDF のハッシュだけで、鍵交換（たとえば X25519MLKEM768）と署名（たとえば ecdsa_secp256r1_sha256）は別の拡張でネゴシエートされます。

OpenSSL では TLS 1.3 のスイートを -ciphersuites で設定し、TLS 1.2 で使う -cipher 文字列では設定しません。そのため、サーバーの暗号リストを変更しても TLS 1.3 には影響しないことがよくあります。

TLS_AES_256_GCM_SHA384

SHA-384 を使う AES-256-GCM で、実装がサポートすべき（SHOULD）と RFC 8446 が定めている 2 つの TLS 1.3 スイートの 1 つです。

TLS_AES_256_GCM_SHA384 は、256 ビットの AES 鍵と鍵スケジュールの SHA-384 を組み合わせます。RFC 8446 §9.1 では、TLS_CHACHA20_POLY1305_SHA256 とともに SHOULD として挙げられています。ほとんどのサーバーが提供しており、CNSA に沿ったプロファイルでは必須です。

量子コンピューターを使う攻撃者に対しても、グローバーのアルゴリズムで AES の実効鍵長はせいぜい半分になるだけなので、AES-256 には十分な余裕があります。こうした攻撃は並列化しにくいため、NIST は AES-128 でも十分だとしています。

TLS_CHACHA20_POLY1305_SHA256

ChaCha20-Poly1305 は、AES 命令を持たないデバイスでもソフトウェアで高速に動作する TLS 1.3 スイートです。

TLS_CHACHA20_POLY1305_SHA256 は、ChaCha20 ストリーム暗号と Poly1305 メッセージ認証コードを使います（RFC 8439）。ハードウェアの支援がなくても定数時間で動作するため、AES 命令を持たないモバイルデバイスで優先されるスイートになりました。クライアントがこれを先頭に挙げた場合、サーバーはその選択に従うのが一般的です。

RFC 8446 §9.1 は、TLS 1.3 の実装がこれをサポートすべき（SHOULD）としています。TLS 1.2 で対応するスイートは TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 と TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 です（RFC 7905）。

TLS_AES_128_CCM_SHA256

TLS 1.3 の AES-128-CCM で、AES-CCM 用のハードウェアをすでに備えた、リソースの限られたデバイスで主に使われます。

CCM は AES-CTR による暗号化と AES-CBC-MAC を組み合わせたもので、IoT の無線通信でよく使われます。IANA は TLS_AES_128_CCM_SHA256 を推奨としていますが、8 バイトのタグを使う TLS_AES_128_CCM_8_SHA256 は一般用途には推奨していません。

TLS_FALLBACK_SCSV

クライアントがより低いプロトコルバージョンで再試行していることをサーバーに伝える、シグナリング用の値です（RFC 7507）。

失敗したハンドシェイクを古いプロトコルバージョンで再試行するクライアントは、攻撃者によって SSL 3.0 まで引き下げられるおそれがあり、2014年には POODLE がこれを悪用しました。クライアントはこうした再試行の際に TLS_FALLBACK_SCSV（0x56,0x00）を送ります。クライアントが提示したバージョンより高いバージョンに対応するサーバーは、処理を続けずに inappropriate_fallback で中断します。TLS 1.3 では ServerHello.random にダウングレード検出用のセンチネルが入るため、TLS 1.3 同士ではこの仕組みは不要です。

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

ECDSA 証明書で一般的な TLS 1.2 スイートです。ECDHE による鍵交換、ECDSA による認証、AES-128-GCM を組み合わせます。

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256（RFC 5289）は、ECDHE の一時鍵によって前方秘匿性を実現し、通常は P-256 の ECDSA 証明書でサーバーを認証します。サーバーが ECDSA 証明書を持つ場合に、ブラウザーが優先する TLS 1.2 スイートです。

OpenSSL の暗号リスト文字列では ECDHE-ECDSA-AES128-GCM-SHA256 です。RSA 証明書しか持たないサーバーは、このスイートをネゴシエートできません。TLS 1.2 のスイートの認証部分は、証明書の鍵の種類と一致しなければならないからです。

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

HTTP/2 が必須とする TLS 1.2 スイートです。ECDHE による鍵交換、RSA による認証、AES-128-GCM を組み合わせます。

RFC 9113 §9.2.2 は、TLS 1.2 を使う HTTP/2 の環境に、P-256 曲線での TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 のサポートを求めています。これにより、TLS 1.2 に対する HTTP/2 の制限に従うクライアントとサーバーの間には、必ず共通のスイートが存在します。

OpenSSL での名前は ECDHE-RSA-AES128-GCM-SHA256 です。名前に RSA とありますが、RSA 鍵はハンドシェイクに署名するだけで、セッション鍵は一時的な ECDHE 交換から得られます。そのため、このスイートには前方秘匿性があります。

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

最も一般的な TLS 1.2 スイートの 256 ビット版です。ECDHE、RSA による認証、AES-256-GCM、SHA-384 の PRF を組み合わせます。

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384（RFC 5289）は、RSA 証明書を持つほぼすべての TLS 1.2 サーバーが提供しています。名前にある SHA384 は TLS 1.2 の PRF のハッシュを決めるもので、GCM 自体には別の MAC は必要ありません。

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

ECDHE 鍵交換と ECDSA 証明書を使う、TLS 1.2 の ChaCha20-Poly1305 です（RFC 7905）。

2016年に TLS 1.2 に追加されたこのスイートにより、まだ TLS 1.3 を提供できないサーバーでも、ソフトウェア実装に向いた AEAD である ChaCha20-Poly1305 を使えるようになりました。IANA はこれを推奨としています。OpenSSL での名前は ECDHE-ECDSA-CHACHA20-POLY1305 です。