SSLと暗号スイートの基本から違いまで徹底解説

2025 11/29

2025/11/29

はじめに

本書の目的

本ドキュメントは、SSLプロトコルにおける「暗号スイート」という概念をやさしく丁寧に解説することを目的としています。専門用語をできるだけ減らし、具体例を交えて仕組みと役割を分かりやすく説明します。

読者対象

ウェブサイト運営者、開発者、セキュリティに関心のある方、初めて暗号スイートを学ぶ方を想定しています。技術的な深掘りは後の章で扱いますので、まずは全体像をつかみたい方に向けています。

本書で学べること

暗号スイートの基本的な定義と役割
暗号スイートを構成する主要な要素（暗号化、認証、ハッシュなど）の概要
SSLとTLSでの違いと具体例
ハンドシェイク時にどのように暗号スイートが決まるか
実務での重要性と選び方の指針

進め方のアドバイス

各章は段階的に理解できるように構成しています。まずは本章で全体像を把握し、次章以降で細部を順に学んでください。実例や図を交えつつ進めますので、専門用語に不安があっても安心して読み進められます。

SSL（Secure Sockets Layer）とは

概要

SSLはインターネットの通信を暗号化して安全にする仕組みです。1995年にNetscapeが開発しました。クレジットカード番号や個人情報などを第三者から守るために使われます。バージョンは1.0、2.0、3.0が存在しますが、現在はTLS（Transport Layer Security）という後継プロトコルの使用が推奨されます。

仕組み（簡単な流れ）

通信の始めに公開鍵と証明書で相手を確認します（ハンドシェイク）。
確認後は、高速な共通鍵暗号でデータをやり取りします。これにより安全かつ効率的に通信できます。
証明書は信頼できる認証局（CA）が発行します。ブラウザの鍵アイコンは証明書が有効であることを示します。

なぜSSLは大切か

SSLがあると通信内容を盗み見や改ざんから守れます。オンライン決済やログイン情報の送受信に不可欠です。古いSSLは脆弱性が見つかっているため、最新のTLSと強い暗号スイートを使うことが重要です。

利用例と注意点

利用例: ウェブサイトのHTTPS、メールの暗号化、API通信。
注意点: 証明書の有効期限切れや自己署名証明書は信頼されません。混在コンテンツ（HTTPSページ内のHTTPリソース）にも注意が必要です。

実務では、SSLという名称はよく使われますが、実際の運用はTLSを前提に考えると分かりやすいです。

暗号スイート（Cipher Suite）の定義

定義

暗号スイートとは、通信を安全にするために使う暗号の組み合わせを一つにまとめたものです。具体的には、鍵交換や認証の方法、実際にデータを暗号化する方式（暗号アルゴリズム）、データの改ざんを検出するためのハッシュ関数やメッセージ認証、鍵長や動作モードなどを含みます。ひとつの設定としてクライアントとサーバが合意して使います。

合意の仕組み（概略）

通信の開始時にクライアントは使える暗号スイートの一覧を提示し、サーバがその中から一つを選びます。こうして双方が同じ組み合わせを使って安全な通信を始めます。選択は互換性や安全性、性能を見て行われます。

他のプロトコルでの利用

暗号スイートの考え方はSSL/TLS以外でも使います。例えば無線LANのWPA/WPA2/WPA3でも、暗号アルゴリズムや認証方式の組み合わせを決めて安全性を保ちます。

例（簡単な読み方）

例: TLS_RSA_WITH_AES_128_CBC_SHA
– 最初の部分は鍵交換や認証の方式（ここではRSA）
– 次が暗号化方式と鍵長・動作モード（AES 128ビット、CBCモード）
– 最後が改ざん検出に使うハッシュ（SHA）
このように短い表記で複数の設定を表します。

暗号スイートの構成要素

1. 共通鍵暗号（対称暗号）

共通鍵暗号は通信の中身を速く暗号化します。送信者と受信者が同じ鍵を使います。例としてAESがあり、AES-GCMのようなAEAD（認証付き暗号）は暗号化と改ざん検出を同時に行います。鍵長（128/256ビット）で安全性が変わります。

2. 公開鍵暗号（鍵交換と認証）

公開鍵暗号は安全な鍵交換やサーバ認証に使います。RSAやECDHE（楕円曲線ディフィー–ヘルマン）があります。ECDHEは一時鍵を使うため、通信の将来漏えいから過去の通信を守る「フォワードシークレシー（前方秘匿性）」を提供します。証明書はサーバの身元を確認します。

3. ハッシュ関数とメッセージ認証

ハッシュ関数（例：SHA-256）はデータの要約を作り、改ざん検出に使います。HMACのような方式でメッセージ認証コード（MAC）を作成します。TLSではハッシュを鍵派生や署名検証にも使います。

これら三つが組み合わさって、暗号スイートは「誰と通信するかの確認」「安全な鍵を作ること」「通信内容の暗号化と改ざん検出」を実現します。

SSL における暗号スイートの具体例

代表的な暗号スイート表記

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

各要素のやさしい説明

ECDHE（鍵交換）: 毎回新しい一時鍵を作る仕組みです。これにより、もし将来サーバーの秘密鍵が漏れても過去の通信内容は守られます（前方秘匿）。
RSA（認証）: サーバーはRSA鍵を使った証明書で自分を証明します。ブラウザは証明書を確認して相手が正しいか判断します。
AES_128_GCM（通信暗号化と認証）: AESでデータを暗号化し、GCMモードで改ざん検出も行います。AES-128は鍵長が128ビットで、速くて安全です。
SHA256（ハッシュ/ハンドシェイク用）: ハンドシェイクでメッセージの整合性確認や鍵導出に使われます。GCMは追加の改ざん検出を行うため高速です。

実際の動き（簡単な流れ）

クライアントとサーバーが暗号スイート候補を交換します。
ECDHEで一時鍵を合意し、RSA証明書でサーバーを認証します。
その後はAES-GCMで暗号化された通信を行います。

この構成は性能と安全性のバランスが良く、現在でも広く使われています。

SSLとTLSにおける暗号スイートの違い

概要

SSL（古い規格）とTLS（現在主流の規格）は、サポートする暗号スイートに重要な違いがあります。本章では、互換性・前方秘匿（PFS）・暗号方式の選択肢・性能面での差を分かりやすく説明します。

歴史と互換性

SSLは歴史的に限られた暗号スイートを扱いました。初期の実装ではRSA鍵交換が多く使われ、1024ビット前後の鍵長が一般的でした。これらは当時は実用的でしたが、現在では安全性が不足します。一方、TLSは設計段階から拡張性を重視し、多様な暗号アルゴリズムや鍵長をサポートします。

前方秘匿（PFS）の扱い

SSLの多くの組み合わせではRSA鍵交換を使い、セッション鍵が長期鍵に依存しました。つまり長期鍵が漏れると過去の通信も解読される可能性があります。TLSではDHEやECDHEなどの一時鍵交換を標準的に使えます。これにより完全前方秘匿（PFS）を実現し、過去の通信が守られます。

TLS 1.2 と TLS 1.3 の差

TLS 1.2までは多彩な暗号スイートが共存しました（例：ECDHE-RSA-AES128-GCM-SHA256）。TLS 1.3では設計を簡素化し、AEAD（認証付き暗号）を中心に限定された強力なスイートのみを許容します。これにより安全性と通信効率が向上します。

実用上のポイント

古いSSLのみ対応のサーバーは安全性で劣ります。可能ならTLS 1.2以上を使ってください。
PFSを有効にするには、サーバーでDHEかECDHEを優先してください。
TLS 1.3は暗号スイートを絞ることで設定ミスを減らします。

以上が、SSLとTLSにおける暗号スイートの主な違いです。

SSL/TLSハンドシェイクにおける暗号スイートの合意プロセス

ハンドシェイクの流れ（簡潔）

通信開始時、クライアントが最初にClientHelloを送ります。そこにクライアントが対応する暗号スイート一覧を載せます。サーバーはServerHelloでその中から一つを選び返します。選択に基づき鍵交換と認証が進み、安全な通信路を構築します。

暗号スイートの提示と選択

ClientHelloには優先順位付きの暗号スイートリストが含まれます。サーバーは自分の方針（性能・安全性など）とクライアントのリストを照らし合わせ、最適な一つを選びます。たとえばクライアントがECDHEとRSAの両方を送った場合、サーバーはECDHEを選べば前方秘密性が得られます。

マスターシークレットと共通鍵の生成

鍵交換で得た共通の材料（プリマスターシークレットなど）をもとに、TLSの擬似乱数関数（PRF）でマスターシークレットを生成します。マスターシークレットからさらに通信に使う対称鍵（暗号・MAC鍵・初期化ベクトル）を導出します。

鍵交換方式と前方秘密性

RSA鍵暗号での鍵配送ではサーバーの秘密鍵が漏れると過去の通信が解読される可能性があります。DHE/ECDHEなどの一時鍵を使う方式では、そのリスクを低減し前方秘密性を確保します。

完了の検証（Finishedメッセージ）

鍵が確立した後、両者はChangeCipherSpecで以降の暗号を切り替え、Finishedメッセージでハンドシェイク全体が改変されていないかを確認します。Finishedの中身はこれまでのメッセージを基にした検証データで、成功すれば安全なアプリケーションデータの送受信が始まります。

実例（具体的な流れ）

1) クライアント: ClientHello（暗号スイート例: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA）
2) サーバー: ServerHello（選択: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256）＋証明書
3) 鍵交換: ECDHEパラメータ交換→共通材料生成
4) 両者: マスターシークレット生成→鍵導出
5) ChangeCipherSpec→Finishedで検証→データ通信開始

上記の流れで、暗号スイートの合意は安全な通信を支える重要な役割を果たします。