MS_SSLTLS

SSL/TLS

• 戻る（証明書、HTTP、VPN）
  • SSL/TLS
  • PKCS
  • 証明書失効リスト (CRL)

概要

• デジタル証明書を使用してエンドポイントを証明し通信の暗号化を行う。
• エンドポイントには、クライアント、サーバなどがあり、
  対応する証明書にクライアント証明書、サーバ証明書がある。
• しかし、IC カードなどに格納して、特定のマシンに限定しない使用方法もある。

経緯

	内容
SSL	Netscape Communications 社が開発。標準化はされていない（後日、歴史的文書として RFC が公開）。
TLS	SSL 3.0 を標準化したもの。SSL を継承するものと言う位置付け。

脆弱性

• SSL の全バージョンと
• TLS の 1.0 と 1.1 の実装の一部には

脆弱性が発見され、TLS 1.2 以上への移行が促されている。

補足（最新化）: 現在は TLS 1.3（RFC 8446） が主流。 TLS 1.0 / 1.1 は主要ブラウザで 2020年に無効化済み。 TLS 1.3 では、

• ハンドシェイクが 1-RTT（再開時は 0-RTT）に短縮
• 鍵交換は (EC)DHE のみ（RSA 鍵交換は廃止 → 前方秘匿性が常に確保される）
• CBC モードや RC4 など脆弱な暗号スイートを全廃（AEAD のみ）

このため、後述の POODLE / FREAK / Logjam などの多くは TLS 1.3 では構造的に成立しない。

X over SSL/TLS

SSL/TLS はアプリケーション層とトランスポート層の間のプロトコルなので、
アプリケーション層プロトコルの下に差し込んで使う。

• HTTPS（SSL/TLS の最も多いユースケース）
• SMTPS(SMTP) / LDAPS(LDAP) / FTPS(FTP) / IMAPS(IMAP) / POP3S(POP3)

機能

機能	内容
証明	サーバー証明書やクライアント証明書を用い、サーバー認証やクライアント認証を行う
暗号化	上記の証明書を使用して鍵の生成と交換を行い暗号化通信を行う
メッセージ認証	MAC によるメッセージ認証を行う

詳細

プロトコル構造

層	プロトコル
アプリケーション層
SSL/TLS 上位	Hand Shake / Change Cipher Spec / Alert / Application Data
SSL/TLS 下位	Record
トランスポート層	TCP

プロトコル	役割
Hand Shake	ネゴシエーションにより鍵交換を行い、マスタシークレットを生成する。セッション確立のハンド・シェイク
Change Cipher Spec	暗号化に関するパラメタの決定、若しくはパラメタの変更通知
Alert	通信中に発生したエラーを相手に通知する（Warning / Fatal（即中断））
Application Data	ネゴシエーションのパラメタに従い、透過的に送受信
Record	ブロック暗号化されたペイロード部分。2^14 バイト以下のブロックに分割し、圧縮、MAC の生成、暗号化を行う

シーケンス（コネクション確立）

網掛け（※）はオプショナル。

#	クライアント	方向	サーバ	説明
1		←	Hello Request ※	Client Hello をリクエスト
2	Client Hello	→		暗号化/圧縮アルゴリズムの一覧
3		←	Server Hello	暗号化/圧縮アルゴリズムの選択
4		←	Server Certificate	サーバ証明書を送信（証明書チェーンを含む）
5		←	Server Key Exchange	鍵交換メッセージその1（RSA か DH で）
6		←	Certificate Request ※	クライアント証明書を要求
7		←	Server Hello Done	サーバからの送信終了を示すエンドマーク
8	Client Certificate ※	→		クライアント証明書を送信
9	Client Key Exchange	→		鍵交換メッセージその2
10	Certificate Verify	→		クライアントが正しい秘密鍵を持つことを証明する署名
11	Change Cipher Spec	→		無暗号通信の終了を示すエンドマーク
12	Finished	→		Client Hello からのメッセージを暗号化して送信
13		←	Change Cipher Spec	無暗号通信の終了を示すエンドマーク
14		←	Finished	Server Hello からのメッセージを暗号化して送信
15	Application Data	⇔	Application Data	暗号通信

※ これは TLS 1.2 までのシーケンス。TLS 1.3 では大幅に簡略化されている。

データ送受信（Record プロトコル）

• 暗号化：ブロック分割 → 圧縮 → HMAC による MAC 生成 → 連結とパディング → 暗号化 → 送信
• 復号化：復号化 → MAC 認証 → 圧縮の解凍 → ブロックの連結

用語解説

セッションとコネクション

• セッション … 共通鍵生成までのネゴシエーションのこと（仮想的概念）。
  特に負荷が高いのは鍵交換処理。
• コネクション … 実際の TCP/IP コネクションで、セッションは共有する。
  ただし、コネクション毎に別々に暗号化/復号化パラメタを生成する。

※ セッション再開（Session ID / Session Ticket）により、
2回目以降の接続ではハンドシェイクを省略できる。
HTTPS サイトの体感速度に効く重要な仕組み。

プリマスタシークレットとマスタシークレット

• プリマスタシークレット … キー交換アルゴリズムで使用する値。
• マスタシークレット ＝ 共通鍵
  プリマスタシークレット・サーバランダム・クライアントランダムに PRF 演算を施したもの。
  さらに PRF を行って、MAC シークレット／暗号化キー／初期ベクタ（IV）を生成する
  （それぞれクライアント用とサーバ用がある）。

脆弱性

中間者攻撃

基本的に、相互に信頼された認証局を使用することで
（ルート証明書を信頼されたルート証明機関に追加し、証明書チェーンをチェックする）、
サーバ / クライアントを認証できるので中間者攻撃から守られる。

• HTTP化 … Web サーバが HTTPS を強制していても、中間者攻撃が介入することで、
  Web ブラウザが HTTP で接続してしまい、そこをキャプチャされれば盗聴される。
• リダイレクト … HTTP でアクセスされた場合、強制的に HTTPS にリダイレクトする。
  ただ、このリダイレクトの前の HTTP アクセスに MITM の可能性がある。
• HSTS（HTTP Strict Transport Security）
  • RFC 6797 で規定されたセキュリティ機構
  • Web サーバーが Web ブラウザに対して、次回以降 HTTPS の使用を強制する（max-age の期間まで）。
    この通知には Strict-Transport-Security ヘッダを使用する
    （セキュリティ強化のHTTPヘッダ）。
  • ただし、HSTS でも初回の HTTP アクセスに MITM の可能性がある。

※ 初回問題の解決策が HSTS プリロード（ブラウザにドメインを事前登録する仕組み）。

ダウングレード攻撃

名称	内容
バージョンロールバック攻撃	Hello を改ざんし、より低いバージョン／暗号強度を使用するよう仕向ける
FREAK	輸出規制由来の弱い RSA 鍵（512bit）を受け入れる実装上の問題
Logjam	同様に輸出用の 512bit の一時鍵を受け入れる。こちらは TLS プロトコル自体の脆弱性

パディングオラクル攻撃

名称	内容
Lucky Thirteen	CBC モードの MAC 検証にかかる時間差から平文を推測
POODLE	SSL 3.0 の設計上の脆弱性。平均 256 回のリクエストで 1 バイト解読

POODLE の対処法

• クライアント、サーバのどちらかで SSL 3.0 を無効化する。
• クライアント側とサーバ側で TLS_FALLBACK_SCSV 対応を行う（ダウングレードを抑止する）。

実装上の脆弱性

• Heartbleed … OpenSSL 1.0.1 - 1.0.1f で発見された深刻な脆弱性。保護されているはずの情報を盗める。
• 脆弱なソフトウェア … 証明書のチェックが適切に行われていない実装がある。
  • OS 標準の証明書ストアの利用
  • 失効のチェック（証明書失効リスト (CRL)）
  • 証明書チェーンのチェック
  • クライアント API の使用方法

参考

• Transport Layer Security - Wikipedia
• RFC 8446 - TLS 1.3
• エンジニアなら知っておきたい、絵で見てわかるセキュア通信の基本 - Qiita
• SSTP / VPN（SSL-VPN）

---

Tags: IT国際標準, インフラストラクチャ, セキュリティ, 暗号化, 通信技術, IIS