SSL/TLS では「暗号化」「改ざん検知」「認証機能」を実現するために、SSL通信を開始する一番最初の部分（SSL/TLSハンドシェイク）に様々な技術を組み合わせています。
今回はこの「SSL/TLSハンドシェイク」の部分を解説します。
SSL/TLS ハンドシェイク図解
まずは簡単ですが SSL/TLS ハンドシェイクの部分を図にしました。
こうやってみると複雑そうなことをしているように見えますができる限り分かりやすく解説します。
SSLハンドシェイクで何をしているのかというと、
- どの暗号化スイート（どの暗号化アルゴリズム）を使うのか一致させる
- データの暗号化に使用する鍵を確立させる
- 認証をする
ということをやっています。
①【クライアント側】使用可能な暗号スイートを提案する
クライアントは、サーバーに Client Hello メッセージを送信してセッションを開始します。
「Client Hello」です。
クライアントはサーバーのWebサイト（https://www.yahoo.co.jp など）にアクセスをします。
その際にクライアントは、クライアントがサポートしている暗号スイート一覧をサーバーへ送信します。
暗号スイート（英語：Cipher Suite）とは、SSL/TLS 通信をする際に、サーバーとクライアントでお互いに利用可能な以下の方法をまとめたものです。
- 鍵交換の方法
- サーバー認証の方法
- 暗号化の方法
- MACアルゴリズム
例えば、サーバーとクライアントでバージョンが違いすぎて（古すぎたり新しすぎたりして）許容範囲を超えて一致できなかったら SSL/TLS 通信は失敗します。
IE での場合
たとえば、Internet Explorer の「詳細設定」でわざと「TLS 1.1」と「TLS 1.2」のチェックを外して https://www.yahoo.co.jp にアクセスをしてみます。
この状態で「https://www.yahoo.co.jp」にアクセスをすると以下のエラーメッセージが表示されます。
[詳細設定]で TLS 1.0、TLS 1.1、TLS 1.2 を有効にして、もう一度 https://www.yahoo.co.jp に接続してみてください。引き続きエラーが発生する場合は、サポートされていないプロトコル、または安全とみなされない RC4 などの暗号スイート（詳細情報のリンク）がサイトで使われている可能性があります。サイトの管理者に問い合わせてください。
つまり「SSL 2.0」と「SSL 3.0」だけしか使わないように設定すると暗号スイートに「RC4」が使われてしまい、RC4 暗号は脆弱性があるためサーバ側で拒否をする設定となっており、結果的に Web サイトにアクセスができないということになります。
代表的な暗号スイートの例
以下、代表的な「暗号スイート」の例です。
| 暗号スイート名 | プロトコルバージョン | 鍵交換アルゴリズム | 認証アルゴリズム | 暗号化の方法(鍵長bit) | MACアルゴリズム |
|---|---|---|---|---|---|
| ECDHE-RSA-AES256-GCM-SHA384 | TLSv1.2 | Kx=ECDH | Au=RSA | Enc=AESGCM(256) | Mac=AEAD |
| ECDHE-ECDSA-AES256-GCM-SHA384 | TLSv1.2 | Kx=ECDH | Au=ECDSA | Enc=AESGCM(256) | Mac=AEAD |
| ECDHE-RSA-AES256-SHA384 | TLSv1.2 | Kx=ECDH | Au=RSA | Enc=AES(256) | Mac=SHA384 |
| DH-DSS-AES256-GCM-SHA384 | TLSv1.2 | Kx=DH/DSS | Au=DH | Enc=AESGCM(256) | Mac=AEAD |
| DHE-DSS-AES256-GCM-SHA384 | TLSv1.2 | Kx=DH | Au=DSS | Enc=AESGCM(256) | Mac=AEAD |
| ECDH-RSA-AES256-GCM-SHA384 | TLSv1.2 | Kx=ECDH/RSA | Au=ECDH | Enc=AESGCM(256) | Mac=AEAD |
| AES256-GCM-SHA384 | TLSv1.2 | Kx=RSA | Au=RSA | Enc=AESGCM(256) | Mac=AEAD |
ちなみに現在使用可能な暗号スイートは「openssl ciphers -v」コマンドで確認できます。
|
[test@SAKURA_VPS ~]$ openssl ciphers -v |
■暗号スイート名
鍵交換の方法、サーバ認証の方法、暗号化の方法、MAC アルゴリズムなどを一意に特定できる名称です。
※表はOpenSSLの表記に従っています。
■プロトコルバージョン
TLS 1.2 や SSL 3.0 などサポートするプロトコルのバージョンを指定します。
※SSL 3.0 はセキュリティに重大な脆弱性がありますので使用しないようにしましょう。
■鍵交換アルゴリズム
- Kx ← Key Exchange（鍵交換）の略です。
何の鍵を交換するためのアルゴリズムか？
→ 共通鍵を交換するためのアルゴリズムです。データそのものは「共通鍵」で暗号化します。
セキュリティを考慮して共通鍵はセッションごとに一時的に作成する「使い捨て」的な使い方をします。
SSL/TLS のハンドシェイク時に暗号化通信を行なうための基になる値（プレマスターシークレット）を交換する際に使用するアルゴリズムを指定します。
- ECDH
- DH
- DH/DSS
- ECDH/RSA
- RSA
※暗号化スイートには「E」が付いている？
ECDHE とか DHE とか最後に「E」が付いているものがあります。
|
[test@SAKURA_VPS ~]$ openssl ciphers -v |
この「E」は Ephemeral（一時的）という意味で ECDH や DH の鍵を一時的にしか使わない（時々変更する）ので「E」が付いていないものに比べてセキュリティ上優れています。
■認証アルゴリズム
サーバーの認証を行なうアルゴリズムを指定します。
サーバーが正しいかどうかを判断する訳ですが、サーバーから送られてくるサーバー証明書にはサーバーの公開鍵と認証局による署名が入っています。
サーバー証明書の中には以下が含まれます。
- サーバーの公開鍵
- 認証局による署名
サーバーを認証する上で一番重要なのが「どこの認証局が認証したのか？」です。
- ベリサインが認証している ← 信頼できる
- 自分自身で認証している ← オレオレ証明書かな？
RSA や ECDSA などのアルゴリズムを使用します。
■暗号化の方法(鍵長bit)
SSLの暗号化通信に使用する共通鍵暗号アルゴリズムを示します。
横にあるカッコの中の数字はビット数を表わしています。
DESの脆弱性が報告されて以降は AES が中心になっています。
AESGCM(256)
AES(256)
■MAC アルゴリズム
SSL の暗号化通信時に使用する MAC アルゴリズムを示します。
MAC（Message ｓAuthentication Code、メッセージ認証コード）はメッセージの「検証（途中でメッセージに手が加えられてないこと）」に使用されるハッシュアルゴリズムです。
メッセージダイジェストは、任意の長さのメッセージを入力し、そのメッセージに対応する固定長の文字列を表示する機能で、MAC アルゴリズムはメッセージダイジェストの計算方法を表します。
有名な MAC アルゴリズムとしては、以下が挙げられます。
- MD5
- SHA-1
- SHA-2
AEAD（Authenticated Encryption with Associated Data）は「暗号モード」が「認証付き暗号」を使用していることを表わしています。
Client Hello パケットの中身には以下の情報が入っている
Client Hello パケットの中身を確認すると、「暗号化スイート」だけでなく以下の情報も含まれています。
- プロトコルのバージョン ← SSL/TLS のバージョン（SSL 3.0 とか TLS 1.2 など）
- 時刻 ← メッセージを生成した時刻
- 乱数 ← クライアントが作成した乱数
- セッションID ← 「新規接続」か「再接続」かチェックする
- 暗号化スイート ← 最終的にサーバーが選択した暗号化スイート
- 圧縮アルゴリズム ← サーバーが選択した圧縮アルゴリズム
②【サーバ側】使用する暗号スイートを通知する
「Server Hello」です。
初めにクライアントが暗号スイートの提案をしてサーバーがその中から可能な通信方法を選択します。
もしクライアントが提案した中に、サーバーがサポートしている通信方法がない場合は以下のようにエラーになります。
ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA384 が使えるけどどう！？
Server Hello パケットには暗号化スイートだけでなく以下の情報も含まれている
「Server Hello」のパケットの中身を確認すると「暗号化スイート」と共に以下の情報が含まれています。
- プロトコルのバージョン ← SSL/TLS のバージョン（SSL 3.0 とか TLS 1.2 など）
- 時刻 ← メッセージを生成した時刻
- 乱数 ← サーバーが作成した乱数
- セッションID ← 「新規接続」か「再接続」かチェックする
- 暗号化スイート ← 最終的にサーバーが選択した暗号化スイート
- 圧縮アルゴリズム ← サーバーが選択した圧縮アルゴリズム
③【サーバー側】サーバー証明書をクライアントに送付する
「Server Certificate」です。
次にサーバーは「サーバー証明書」をクライアントに送付します。
実際には以下の情報が入っています。
サーバー証明書 ← X.509v3 証明書。サーバーの公開鍵も含まれている
ルート証明機関の証明書に至るまでの X.509v3 の証明書のリスト（証明書チェーン）
X.509とは？
デジタル証明書の規格の1つです。
X.509 は、1988年7月3日に X.500 標準と関連して公開されました。
バージョン3 は、1997年に公開されました。
SSL/TLS、S/MIME で使用するデジタル証明書は、X.509 を基にしています。
X.509 にはバージョンがあり、現在のバージョンは X.509v3 です。
Wikiより。https://ja.wikipedia.org/wiki/X.509
X.509 v3 デジタル証明書 の構造
- 証明書
- バージョン
- 通し番号
- アルゴリズムID
- 発行者
- 有効期間
・開始
・満了- 主体者
- 主体者の公開鍵情報
・公開鍵アルゴリズム
・主体者の公開鍵- 発行者の一意な識別子 (予備)
- 主体者の一意な識別子 (予備)
- 拡張 (予備)
・…- 証明書の署名アルゴリズム
- 証明書の署名
※署名フィールドには、「標準フィールド」と「拡張フィールド」のデータのハッシュ値を取って CA の秘密鍵で署名した値が入っています。
一般的な X.509 証明書の拡張子
- .CER
- .DER
- .PEM
- .PFX
- .P12
【クライアント側】④⑤プレマスターシークレットの送付
最後に
今後も追加していきます。
コメント