![• TLS1.2についての解説 RFC5246参照
• TLS record = ヘッダ | メッセージデータ
• ヘッダ = contenttype | version | レコード長
• シーケンス番号
• 64ビット
• 送受信データには含まれない
• 通信の双方で保持
• リプレイ攻撃に対する防除
2章プロトコル
struct {
uint8 major;
uint8 minor;
} ProtocolVersion;
enum {
change_cipher_spec (20),
alert (21),
handshake (22),
application_data (23)
} ContentType;
struct {
ContentType type;
ProtocolVersion version;
uint16 length; / * 最長 2^14 （ 16,384 ） バイト * /
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
15 / 27](https://image.slidesharecdn.com/prof1-170410101450/85/SSL-TLS-1-2-15-320.jpg)
![• クライアントの認証はしない一般的なケース
p.27図2.2
サーバ認証を伴うフルハンドェイク
client server
ClientHello
ServerHello
Certificate
ServerHelloDone
ServerKeyExchange
ClientKeyExchange
[ChangeCipherSpec]
Finished
[ChangeCipherSpec]
Finished
17 / 27](https://image.slidesharecdn.com/prof1-170410101450/85/SSL-TLS-1-2-17-320.jpg)
![• p.32 図2.3
クライアント認証時のフルハンドシェイク
client server
ClientHello
ServerHello
Certificate
ServerHelloDone
ServerKeyExchange
ClientKeyExchange
[ChangeCipherSpec]
Finished
[ChangeCipherSpec]
Finished
CertificateRequest
Certificate
CertificateVerify
19 / 27](https://image.slidesharecdn.com/prof1-170410101450/85/SSL-TLS-1-2-19-320.jpg)
プロフェッショナルSSL/TLS 1.2章
- 2. • 『Bulletproof SSL and TLS』（Ivan Ristic/齋藤孝道訳） • 1～2 TLSの復習 • 3～4 PKI • 5～7 各種攻撃 • 8～ 安全なサーバの設定 • 9 パフォーマンス • 10 TSTS, CSP, 公開鍵pinning • 11, 12 OpenSSL • 13 Apache • 14 Java, Tomcat • 15 IIS • 16 Nginx 概要 2 / 27
- 3. • TLSの目標 • 暗号学的なセキュリティ • 安全な通信が最優先 • 相互運用性 • 異なるプログラムやライブラリが同じパラメータで通信可能 • 拡張性 • プロトコルを作り直さなくても新しい技術に対応できる • 効率性 • コストの高い暗号処理を最小限にする 1章 SSL/TLSと暗号技術 3 / 27
- 4. • OSIモデル • SSL/TLSはアプリケーション層（HTTP, SMTPなど）とトラン スポート層（TCP, UDP）の間にある • TLSを取り除いてもTCPの上でHTTPが動く • 暗号技術 • confidentiality ; 機密性 ; 秘密が守られること • authenticity ; 真正性 ; 本人であることを検証できること • integrity ; 完全性 ; 改竄されることなく転送されること OSIモデル、暗号技術 4 / 27
- 5. • 暗号システムは鍵以外の全てが攻撃者に掌握されても 安全でなければならない • 暗号アルゴリズムは複数人で共有する • 共有する相手が増えると敵対する相手にアルゴリズムが漏れ る可能性が高くなる • 鍵がないと人数が増えたときに多数の人が復号できてしまう • 優れた暗号アルゴリズムを作るのは難しい • たくさんの人が精査して初めて安全と思われる Kerckhoffsの原則 5 / 27
- 6. • 事前に秘密鍵を共有しておきデータを暗号化する • 他人は途中経路で眺めても分からない • 全数探索 • 鍵の種類だけ試すこと • p.6では全数探索しか暗号を破る方法が無いとき計算量的安全 と読めなくもないが必ずしもそういうわけではない • 全数探索しなくて破る方法があったとしても、その方法の計 算量が十分大きければ安全 共通鍵暗号 6 / 27
- 7. • ストリーム暗号 • 鍵ストリーム ; ランダムなデータの無限列（バイト列） • 暗号化はこれと排他的論理和を求める • 同じ鍵を使い回さないことが重要 • ブロック暗号 • データの固まりごとに暗号化 • 16バイト単位のものが多い • 任意の長さのデータを扱うには暗号化モードと併用 • パディングなど • 暗号モード • ECB, CBC, CFB, OFB, CTR, GCM • 最近はGCMを推奨 ストリーム暗号とブロック暗号 7 / 27
- 8. • データの完全性の検証 • 原像計算困難性（preimage resistance） • 第2原像計算困難性（second preimage resistance） • 衝突耐性（collision resistatnce） • MAC（メッセージ認証コード） • ハッシュ関数でハッシュ値はデータと一緒に送信できない • 秘密鍵（MAC鍵ともいう）とデータからハッシュ関数を組み 合わせてハッシュ値（MAC値ともいう）を作る • MAC鍵は別途秘密に共有しておく ハッシュ関数とMAC 8 / 27
- 9. • 公開鍵暗号 • 暗号化する鍵と復号する鍵を別々にした • 共通鍵暗号はn人のうち二人が秘密に通信し合おうとすると n(n-1)/2個の秘密鍵が必要 • 同じ鍵を使い回すと第三者に漏れやすい • 共通鍵暗号より計算時間がかかることが多い • デジタル署名 • 真正性を検証可能にする技術 • MACはMAC鍵の共有が面倒 • 秘密鍵で署名をつけて公開鍵（検証鍵）で真正性を確認 公開鍵暗号とデジタル署名 9 / 27
- 11. • AliceとBobが安全に通信できるにはどうするか • 機密性のために共通鍵暗号を使う • 途中で改竄されないためにMACを使う • リプレイ攻撃を防ぐために番号をつける • 共通鍵暗号とMAC鍵を交換するために公開鍵暗号を使う • 本人であることを確認するためにデジタル署名を使う • このあたりの一連の流れをハンドシェイクという プロトコル 11 / 27
- 13. • 中間者攻撃（man in the middle attack） • 通信会社と結託して通信機器を乗っ取る • ARP spoofing • 任意のIPアドレスをMACアドレスに結びつける • WPAD hijacking • HTTPプロキシの設定を取得するプロトコルに対する攻撃 • DNS hijacking • ドメイン名を乗っ取る • DNSの設定を変更する • DNS cache poisoning • DNSサーバのキャッシュの脆弱性にたいする攻撃 • BGP route hijacking • ルータが利用する経路制御プロトコルにたいする攻撃 MITM 13 / 27
- 14. • 受動的攻撃 • 大規模期間による継続的なモニタリング • FS • （日和見暗号） • 能動的な攻撃 • 不正な証明書を利用 受動的攻撃と能動的な攻撃 14 / 27
- 15. • TLS1.2についての解説 RFC5246参照 • TLS record = ヘッダ | メッセージデータ • ヘッダ = contenttype | version | レコード長 • シーケンス番号 • 64ビット • 送受信データには含まれない • 通信の双方で保持 • リプレイ攻撃に対する防除 2章プロトコル struct { uint8 major; uint8 minor; } ProtocolVersion; enum { change_cipher_spec (20), alert (21), handshake (22), application_data (23) } ContentType; struct { ContentType type; ProtocolVersion version; uint16 length; / * 最長 2^14 （ 16,384 ） バイト * / opaque fragment[TLSPlaintext.length]; } TLSPlaintext; 15 / 27
- 16. • ハンドシェイクの種類 • サーバ認証を行うフルハンドシェイク • セッション再開のためのハンドシェイク • クライアントとサーバの認証を伴うハンドシェイク • フルハンドシェイク • 接続で使いたいパラメータを双方が提示して合意する • 鍵確立 • 提示された証明書の認証 • マスターシークレットの共有 • ハンドシェイクが書き換えられていないことの検証 handshakeプロトコル 16 / 27
- 18. • Certificate • サーバの証明書を送信する • ServerKeyExchange/ClientKeyExchange • マスターシークレットの生成に必要な情報を送る • ChangeCipherSpec • 接続に必要な情報を全て手に入れて暗号鍵を生成したことを 相手に伝えるメッセージ • 完全性検証の対象外 • 実装が難しいためOpenSSLでCCS injectio攻撃を受けた • Finished • ハンドシェイクのMACを送る（verify_data） 18 / 27
- 19. • p.32 図2.3 クライアント認証時のフルハンドシェイク client server ClientHello ServerHello Certificate ServerHelloDone ServerKeyExchange ClientKeyExchange [ChangeCipherSpec] Finished [ChangeCipherSpec] Finished CertificateRequest Certificate CertificateVerify 19 / 27
- 20. • CertificateRequest • クライアントに対する認証の要求と許容できる証明書の種類 • CertificateVerify • クライアント証明書に含まれる公開鍵に対応する署名 追加部分 20 / 27
- 21. • フルハンドシェイクは重たい処理 • 認証などを省略したい • session resumption • session IDを用いてセッションを再開する仕組み • プロトコル • クライアントがClientHelloにsession IDを含めて送信 • サーバは同じsession IDをServerHelloに含めて送信 • 以前共有したマスターシークレットを使って新しい鍵を生成 • ECDHE_ECDSA • FSの実現のために利用 • 詳細は今まで解説したので省略 セッションリザンプション 21 / 27
- 22. • 以前Lucky13攻撃で紹介した図 • MAC(Seq|Header|data)計算してpaddingをつける • IVを作ってEnc • MAC-then-encrypt（MACしてから暗号化） • pading oracleの攻撃（勉強会1, 2回目） • Encrypt-then-MACという拡張（2014） • AEAD（認証つき暗号） • 64ビットのnonceを付与して暗号化（GCM/ChaCha20） ブロック暗号を使った場合 Seq data MAC(Seq|Header|data) padding Enc(data|MAC|padding) Header ヘッダ IV 22 / 27
- 23. • 新しい接続のセキュリティパラメータの合意をえる • クライアント証明書 • サイトの全接続に対してクライアント証明書を要求すると • 証明書を持っていないと何も見えない • エラーも分からない • サイトのトップページはクライアント証明書なしを許可 • そこからクライアント証明書での接続に誘導 • このときに再ネゴシエーションを使う • 情報の隠蔽 • 2回目のハンドシェイクが暗号化されるのでクライアント証明 書が覗かれない • 暗号の強度変更 再ネゴシエーション 23 / 27
- 24. • 片方が通信を閉じたらclose_notifyを送信 • 相手は書き込み中の内容を破棄してclose_notifyを送信 • 強制切断攻撃（truncation attack）を防ぐ • 攻撃者がやりとりを途中で横取りしてブロック • 正しく実装する必要あり Finished 24 / 27
- 25. • PRF（pseudorandom function） • secret, seed, labelを入力としてHMACを使って構成する • PRF(secret, label, seed) = P_hash(secret, label + seed) • P_hash(secret, seed) = H(secret, A(1) + seed) + H(secret, A(2) + seed) + ... where A(1) = H(secret, seed), A(i) = H(secret, A(i – 1)) • マスターシークレット（Ms : master secret） • Ms = PRF(pre_Ms, “master secret”, client_rand + server_rand) • key_block = PRF(Ms, “key expansion”, server_rand + client_rand) • 鍵ブロックkey_blockを分割してMAC鍵や暗号鍵にする • セッション再開時はMsは同じでclient_rand, server_randは新 しく取得する 擬似乱数生成器と鍵生成 25 / 27
- 26. • 暗号処理の方法を決めるパラメータの集まり • TLS_鍵交換_認証_アルゴリズム_長さ_モード_MAC/PRF • 例）TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 • 2章残りの節 • ALPN ; application-layer protocol negotiation • CT ; certificate transparency • Heartbeat • NPN ; nextprotocol negotiation • 標準化にはならずALPNに移行 • OCSPステープル • サーバからクライアントに証明書の失効情報を送る 暗号スイート 26 / 27
- 27. • TCPデータは暗号化されるがメタデータや下位のレイ ヤは平文のまま • 送信元と宛て先のIPアドレスは分かる • 最初のハンドシェイクは平文 • ブラウザの各種情報を袖手する • ホストの証明書を調査する • クライアント証明書を使う場合のユーザ識別情報を収集 • メッセージの長さ プロトコルの限界 27 / 27