Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

TLS, HTTP/2演習

6,939 views

Published on

セキュリティ・ミニキャンプ in 北海道 2015

Published in: Technology

TLS, HTTP/2演習

  1. 1. TLS, HTTP/2演習 IIJ 大津 繁樹 2015年12月12∼13日 セキュリティ・ミニキャンプ in 北海道 2015
  2. 2. 自己紹介 • 大津 繁樹 • 株式会社インターネットイニシアティブ(IIJ) • Node.js Core Technical Committee メンバー • IETF httpbis WGでHTTP/2相互接続試験など使用 策定に参画 • ブログ: http://d.hatena.ne.jp/jovi0608/
  3. 3. 本講義・演習の目的 • 2日間の講義・演習を通じてTLS, HTTP/2の仕組み を学んで頂きます。 • 演習は、できるだけプログラミングを行う要素をな くし、Wireshark、Linux上のコマンドやファイル編 集で収まるようにしています。 • TLS, HTTP/2ともに幅広く深い技術です。2日間で 完全に理解するのは難しいでしょう。でも基本的な 部分をおさえて将来の理解に役立ててください。
  4. 4. 本講義・演習の内容(TLS) • 講義:TLS概要 • 講義:TLSを理解する準備(暗号技術など) • 講義:事前学習解説(サーバ証明書取得までのPKIの仕組み) • 講義:TLSの仕組みの理解 (Wiresharkの画面を見つつ) • 演習:nginxでTLSサーバを構築 • 演習:SSLLabでA+を目指す • 演習:RSA を解読してTLSを破る(FREAK攻撃)
  5. 5. 本講義・演習の内容(HTTP/2) • 講義: HTTP/2が必要になった背景 • 講義: HTTP/2の仕組み解説 • 演習: nginxサーバをHTTP/2対応に • 講義・演習: HTTP/2のTLS制限について • 演習:HTTP/2によるHTTP Head of Blockingの解消
  6. 6. 謝辞 • 本演習では、さくらインターネット株式会社様より 参加者全員にクラウドサーバをご提供いただきまし た。厚く御礼申し上げます。
  7. 7. 演習課題の手順書 https://gist.github.com/shigeki/fb40645dfe0ce343565e できるだけコピペ作業は止めよう。
  8. 8. TLSの概要
  9. 9. インターネットの脅威 盗聴 パスワードやクレジッ トカード番号を盗み見
  10. 10. インターネットの脅威 改ざん 通信途中でデータを書き換え
  11. 11. インターネットの脅威 なりすまし ユーザになりすま して通信を行う
  12. 12. インターネットの脅威 否認 そんな通信してま せんとキャンセル
  13. 13. インターネットの脅威から守るセキュリティ 対策 盗聴 改ざん 成りす まし 否認 暗号化 完全性チェック 認証 署名
  14. 14. 各レイヤーにおけるセキュリティ通信 WPA IPsec TLS,DTLS,SSH S/MIME, PGP 無線LAN IP TCP, UDP データ
  15. 15. TLSの目的 • TLSプロトコルの最重要なゴールは、通信する2つのアプリケーシ ョンの間でプライバシーとデータの完全性を提供することです。 RFC5246: The Transport Layer Security (TLS) Protocol Version 1.2 1. Introduction The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications. アプリ アプリ 完全性 プライバシー
  16. 16. TLSの簡単な歴史 • SSL 1.0未発表 • 1994年 SSL 2.0 • 1995年 SSL 3.0 • 1996年 IETF TLS WGスタート • 1999年 TLS 1.0 • 2006年 TLS 1.1 • 2008年 TLS 1.2 • 2013年 TLS 1.3検討スタート SSLは、旧ネットスケープ社の 私的プロトコル TLSと名前を変えて標準化 SSL3.0と基本設計は大きく変 えず、内部バージョンは TLS1.0 =SSL 3.1 現在の利用推奨 様々な拡張仕様 の追加
  17. 17. TLSを理解する準備
  18. 18. TLSの要素技術 X509証明書 PKI 対称 暗号 暗号モード 公開 暗号 デジタル 署名 メッセージ認証 乱数 生成 TLS 交換 一方向ハッシュ TLSプロトコルは、これらの要素技術を組み合わせて アプリ間のセキュア通信を確立する手順を決める
  19. 19. TLS要素技術の依存性 X509証明 書 PKI 対称 暗号 暗号モード 公開 暗 号 デジタル 署名 メッセージ認証 乱数 生成 交換 一方向ハッシュ 本来はこの一つ一つをきちんと理解することが必要
  20. 20. TLS要素技術はどこで使われる? ClientHello ServerHelloDone ChangeCipherSpec Finished ChangeCipherSpec Finished Application Data Application Data 乱数生成 対称暗号・暗号モード・一方向ハッシュ・乱数生成 PKI・X509証明書・デジタル署名 乱数生成 ServerHello Certificate ClientKeyExchange ServerKeyExchange(*) 乱数生成・ 交換・ 公開 暗号・デジタル署名 メッセージ認証 対称暗号・暗号モード メッセージ認証 対称暗号・暗号モード 乱数生成・ 交換 デジタル署名 (* オプションで必須ではない)
  21. 21. TLS要素技術はどこで使われる? 乱数生成 Client/ServerHelloのNonce, ペアの生成 データ暗号化のIV PKI CAによるサーバ証明書の署名と発行 X509証明書 Certificateによるサーバ・クライアントの認証・公開 の取得 電子署名 証明書の署名・ 交換で交換する公開 の署名 交換 Server/ClientKeyExchangeによる(EC)DH公開 の交換 公開 暗号 RSA 交換時にPreMasterSecretの暗号送信 一方向ハッシュ CBCなどの暗号モード利用時にアプリデータのMAC生成 メッセージ認証 MasterSecretの生成、Finishedによるハンドシェイクデータの完全 性検証 対称暗号・暗号モード ChangeCipherSpec以降のハンドシェイクとアプリケーションデータの暗号化 (注:他にも細かいところで使われています。)
  22. 22. 今回使うTLS要素技術 GCM AES DHE ECDHE RSA SHA256 HMAC X509証明 書 PKI 対称 暗号 暗号モード 公開 暗 号 デジタル 署名 メッセージ認証 乱数 生成 交換 一方向ハッシュ WoSign Free DV Cert 手入力??
  23. 23. セットメニュー化されたTLSの要素技術 TLS CipherSuites TLS_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9C} TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256= {0xC0,0x2F}; 対称 暗号 暗号モー ド デジタル 署名 メッセージ認証 (ハッシュ) 交換TLS _ _ _WITH_ _ 長 _ _ 交換・デジタル署名にRSA 対称暗号に128bit 長のAES 暗号モードにGCM ハッシュにSHA256 交換にECDHE デジタル署名にRSA 対称暗号に128bit 長のAES 暗号モードにGCM ハッシュにSHA256 番号として 0xC0,0x2Fを割り当て
  24. 24. 対称暗号 暗号文 平文 共通 共通 平文 ストリーム暗号:データを逐次暗号化(RC4, Chacha20) ブロック暗号:データをブロック毎に暗号化(DES, AES) 幾つかの暗号では既に危殆化: DES: 2005年 NIST FPS46-3規格の廃止(2030年までは許容) RC4: RFC7455: Prohibiting RC4 Cipher Suites 暗号化 復号化
  25. 25. 対称暗号 AES • 1997年よりプロジェクト開始、2000年選定、2001 年仕様発行 • ブロックサイズ 128bit • 長: 128bits, 192bits, 256bits の3種類 • Intel/AMDのCPUでハードウェア処理のサポート (AES-NI)
  26. 26. 暗号モード • ブロック暗号は同じデータを同じ で暗号化すると毎回同一の暗 号文になる。 • ブロック長より長いデータを暗号化する場合に暗号モードを利用 して繰り返しを避ける。 • CBC:「(平文 XOR ベクトル) を暗号化」を続ける • CTR: 「カウンターを暗号化 XOR 平文」を続ける 実際にTLSで利用するには改ざん検知のためのMAC(メッセージ認証)との組み合わせる (AEAD)。 これまでの 主流 これからの主流に (GCM後述)
  27. 27. 認証タグ AEAD(認証付き暗号) 暗号化しないけど改ざん • • • • • • • • • • • 防止が必要なデータ • • • • • • • • • (ヘッダ等) • • • • 暗号化する平文 AEAD 暗号化 暗号文 共通 初期ベクトル
  28. 28. AEAD(認証付き暗号) 平文 AEAD 復号化 改ざんチェック 暗号化しないけど改ざ ん防止が必要なデータ (ヘッダ等) 暗号文 認証タグ 共通 初期ベクトル
  29. 29. GCM • GCM (Galois Counter Mode: ガロアカウンター モード) • CTRとGHASHを組み合わせたAEAD • ハードウェア処理で高速化が可能 • AESと組み合わせて AES-GCMとして利用
  30. 30. 一方向ハッシュ データ 一方向 ハッシュ関数 ハッシュ値 ハッシュ値を比較することでデータの改ざんをチェックすることができる。
  31. 31. 一方向ハッシュ • md5 • SHA-1 • SHA-2(SHA-256など6種) • SHA-3(SHA3-256など6種) 2018年ぐらいには現実的なコスト で衝突データを探せる見込み(*2) 既に現実的な攻撃手法が存在 (*2) Cryptanalysis of SHA-1 https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html (*1) how to Break MD5 and Other Hash Functions http://merlot.usc.edu/csac-f06/papers/Wang05a.pdf 8/5にNISTより正式公開
  32. 32. メッセージ認証(HMAC) • 事前に共通 を共有 • 共通 とデータを組み合わせたハッシュ値を作成 • データの完全性とハッシュ作成者を認証する データ 一方向 ハッシュ関数 ハッシュ値 共通
  33. 33. 公開 暗号 512bit RSAの危険性 FREAK https://freakattack.com/ • 解を求めるのが困難な数学的問題を利用して暗号を生成。 • 公開 と秘密 のペアを生成。公開 はさらして大丈夫。 • 公開 で暗号化し秘密 で復号化。 • RSA 素因数分解 • ECC(楕円曲線暗号)楕円曲線上の離散対数問題 公開 秘密 暗号化 復号化
  34. 34. 交換 • 2者間で安全に を共有する仕組み • 互いに公開 を交換しあい、共有 を生成する。 • 通信経路上で共有 のやり取りがない。 • DH (Diffie-Hellman) • ECDH(楕円曲線DH) 脆弱性:DH Logjam https://weakdh.org/ 公開 公開 秘密秘密
  35. 35. デジタル署名 • データの完全性のチェックが可能となる。 • データの送信元の認証が可能となる。 • 公開 の信頼性の範囲で否認防止が可能となる。 • RSA • DSA,ECDSA 公開秘密 データ+デジタル署名 データハッシュ 値を暗号化し デジタル署名を 生成 デジタル署名を復号化。 データハッシュ値と比 較し検証する
  36. 36. 事前課題の解説・復習 演習で利用するTLSサーバ証明書(DV)を取得するまでの一連の 手続きを行う 1.乱数データの生成 2.秘密 (RSA)の生成・確認・保護 3.CSRの生成・確認・提出 4.CAに申請・サーバ証明書発行 5.サーバ証明書の取得・確認 https://gist.github.com/shigeki/102cd71b34627c5bf330 openssl genrsa, openssl rsa openssl req openssl x509
  37. 37. 乱数生成 利用用途: • 暗号 (対称暗号:秘密 、公開 暗号: ペア)の生成 • 暗号モードの初期ベクトルやNonce(*)の生成 • MAC(メッセージ認証)用 求められる機能: 無作為性: 偏りがなく等しい数である。 予測不可能性: 次の乱数が予想できない。 制限負可能性: 同じ乱数列を再現できない。 (* Nonce(number used once)一度だけ使い捨て用に使われる数字)
  38. 38. 乱数生成 • 実際の利用は、疑似乱数生成。seedが必要。 • OppenSSLのdefault built-inでは、seedはLinuxの/dev/ urandom+pid+uid+timeを利用。WindowsではOSのAPIの CryptGenRandomだけでなく画面スクリーンのビットマップハッ シュやヒープメモリも利用。 脆弱性: • CVE-2008-0166: DebianやUbuntuのOpenSSLに予測可能 な乱数を生成してしまう脆弱性 • SSH公開 にブルートフォース攻撃
  39. 39. Linuxのエントロピー • /dev/urandom • ブロックしない • 外部デバイス(キーボードやディスクなど)の割り込みをエントロピー ソースにして溜める。加工したデータのハッシュ値を取る。 • エントロピーが十分溜まっているかが重要(特にインストール直後) • /proc/sys/kernel/random/entropy_avail で値を確認できる。 (Max 4k) 1k以下だったらエントロピーの追加を検討。 • findなどでDisk I/Oを人為的に増やしたり、rng-tools, Virtio_RNG, Haveged 等ツールを使う
  40. 40. 演習1.1: エントロピーの確認 • サーバに入り、プールしているエントロピーを確認します。 • cat /proc/sys/kernel/random/entropy_avail • Disk I/Oを発生させます。 • find / > /dev/null • エントロピーが変わったかどうか確認します。 • /dev/urandom からデータを読み込みます。その後エントロピープー ルが減ったことを確認します。 • head -10 /dev/urandom > /dev/null
  41. 41. 事前学習の復習 • 事前学習で作成したファイルの中身を見てみる 秘密 $ openssl rsa -text -in private.key -noout CSR $ openssl req -text -in server.csr -noout サーバ証明書 $ openssl x509 -text -in server.crt -noout
  42. 42. ASN.1, DER, PEM PEM: DER形式をBase64に変換し てBEGINヘッダ∼ENDフッタをつ けたテキスト ASN.1: データ構造を表す書式 DER: ASN.1のデータ構造をタグ+長さ+データでエンコードしたバイナリ
  43. 43. 秘密 (RSA) • 公開 暗号やデジタル署名で利用する データ。実際は公開 と秘密 の ペアを生成している。 • TLS通信のセキュリティを確保する要の一つ。厳重に管理。 • 秘密 が漏洩するなど危殆化するとTLS通信のセキュリティは 確保できなくなる。 • PKCS#1(RFC3447)で規定 • 秘密 は暗号化してPKCS#5形式で保管する、パスワードで復 号化。
  44. 44. RSA秘密 の中身 Private-Key: (2048 bit) modulus: publicExponent: privateExponent: prime1: prime2: exponent1: exponent2: coefficient: 長 N=PxQ (素数P,Qの積)公開値 E 暗号化する指数 通常2^16+1 公開値 D=1/E mod((P-1)(Q-1)) 復号化する指数 秘密値 素数P 秘密値 素数Q 秘密値 中国剰余定理で計算するための値 秘密値 D, P, Qから計算できる
  45. 45. CSR • Certificate Signing Request(証明書署名要求) • PKCS#10(RFC2986)で規定 • サーバ証明書の識別子(サーバ名など)と公開 を 含んだもの。CA(認証局)にCSRを申請してサー バ証明書を発行してもらう。
  46. 46. CSRの中身 • Version: バージョン 0x0 • Subject: 証明書を発行してもらうサーバの識別名 Subject: C=JP, ST=Hokkaido, O=Security Camp, CN=server21.hokkaido.koulayer.com • 公開 :アルゴリズムや公開 のデータ • 署名:上記データの署名 CN: Common Name サーバ名が入る
  47. 47. PKI概要 CA (Certificate Authority) VA (Validation Authority)RA (Registration Authority) CRL/OCSP CSR ペア 実在確認 サーバ証明書 https://∼ 失効確認 論理的に複数の役割に分かれているが物理的に1つでもよい Root証明書 OS・ブラウザ ベンダー
  48. 48. サーバ証明書(X509) • TLS通信の信頼性を担保する要 • ビルトインのルート証明書からサーバ証 明書まで証明書チェーンの署名検証 • オンライン以外で信頼性を担保(PKI) ビルトインの ルート証明書 サーバ証明書 中間証明書 ビルトインの ルート証明書 サーバ証明書 中間証明書 トラストアンカー
  49. 49. 証明書の種類 EV証明書 (Extended Validation) CA共通の厳格な組織の実在証明 (物理的実在, 書面やデータ, 口座取引による実在審査・署名 提出・電話確認など) アドレスバーが緑色 OV証明書 (Organization Validation) 各CAポリシー(CPS)に従った組織の実在証明 (書面やデータ審査・電話確認など) DV証明書 (Domain Validation) 各CAポリシー(CPS)に従ったドメイン保持証明 (メールの到達性確認など) 今回利用 ネットワーク以外 の実在証明
  50. 50. サーバ証明書の中身 バージョン、シリアル番号、発行者情報、有効期限、サーバ 識別子、公開 情報、拡張情報(利用用途、別名や失効情報・ ポリシー参照先)、デジタル署名
  51. 51. サーバ証明書の確認 サーバ証明書と秘密 の対応が間違っていたらTLS サーバは起動しない。なのでサーバ証明書と秘密 の公開 が一致するか必ずチェックする。 サーバ 証明書 秘密 openssl x509 -pubkey -inserver.crt -noout > server_pubkey.pem openssl rsa -pubout -in private.key -out private_pubkey.pem 公開 公開
  52. 52. TLSのセキュリティ TLSの セキュリティ 乱数生成 PKI 秘密 の 管理 暗号技術 エン トロピー不足 不正 発行 漏洩 アルゴリズム・ 強度の危殆化 TLSは、この4つの外部要素の上でインター ネットで安全な通信を提供する仕組みである。
  53. 53. TLSの仕組み まずは TLS_RSA_WITH_AES_128_GCM_SHA256 の時から
  54. 54. 演習1.2 https://html5.ohtsu.org/seccamp_hokkaido_2015/exam.pcap から pcap データをダウンロードして Wiresharkで開く Wiresharkのデータを見比べながらTLSハンドシェイクを解説します。
  55. 55. TLSハンドシェイク(full handshake) ClientHello ServerHello Certificate ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished Application Data Application Data (赤文字はハンドシェイク) ClientHelloとServerHelloの やり取りで双方が利用するTLS バージョンや暗号化方式など を合意する。
  56. 56. TLSハンドシェイク(resumption) ClientHello ServerHello ChangeCipherSpec Finished ChangeCipherSpec Finished Application Data Application Data (赤文字はハンドシェイク) SessionIDによるTLSセ ッションの再開。 交換や証明書送付をス キップ。 今回は演習の対象外です
  57. 57. TLSハンドシェイクの意味 ClientHello/ServerHello/ServerHelloDone TLSのための情報交換 バージョン・乱数・暗号方式・拡張情報 Certificate 公開 情報の送付 エンドポイントの認証 ClientKeyExchange/ServerKeyExchange 共有 交換 ChangeCipherSpec 暗号開始の合図 Finished ハンドシェイクデータの改ざんチェック
  58. 58. TLS1.2の構造 I P ヘ ッ ダ T C P ヘ ッ ダ TLS Record Layer (5バイト) タイプ (4種 類) (1byte) バージョン (2byte) 長さ (2byte) Handshake (タイプ:0x16) msgタイプ (10種類) 長さ (3バイト長) ハンドシェイクデータ Alert (タイプ:0x15) レベル 理由 ChangeCipherSpec (タイプ:0x14) タイプ Application Data (タイ プ:0x17) 暗号化されたデータ msgタイプ ハンドシェイクデータの種類 0x00 HelloRequest 0x01 ClientHello 0x02 ServerHello 0x0b Certificate 0x0c ServerKeyExchange 0x0d CertificateRequest 0x0e ServerHelloDone 0x0f CertificateVerify 0x10 ClientKeyExchange 0x14 Finished TLS Record Layerデータに 続いて、次の4種類のTLSデ ータのいずれかが続く。 TLS Handshakeは、この 10種類に分かれる。
  59. 59. ClientHello 項目 要素 サイズ 先頭の長さ情 報 client_version uint8 major, uint8 minor 2 N/A random uint32 gmt_unix_time, opaque random_bytes[28] 4 + 28 N/A session_id opaque SessionID <0..32> 1バイト分 cipher_suites uint8 CipherSuite[2] <2..2^16-2> 2バイト分 compression_ methods null(0) <1..2^8-1> 1バイト分 extensions extension_type(65535), extension_data<0..2^16-1> <0..2^16-1> 2バイト分 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 type デー タ長 データ type デー タ長 データ type デー タ長 データ Extension長 Extensionsデータ例
  60. 60. ClientHello Record Layer Handshake (ClientHello) type protocol version length (2byte ) msg type length (3byte) client version random sessi on id cipher suite comp ressi on Exte nsion majo r mino r major minor 0x16 0x03 0x01 ?? ?? 0x01 ?? ?? ?? 0x03 0x03 32 byte 可変 可変 可変 可変 Version 0x03,0x00 = SSLv3 0x03,0x01= TLSv1.0 0x03,0x02=TLSv1.1 0x03,0x03=TLSv1.2 クライアントが利用できる 最高のTLSバージョンを指 定、サーバがどのバージョ ンを使うか選択する
  61. 61. ServerHello 項目 要素 サイズ 先頭の長さ情報 server_version uint8 major, uint8 minor 2 N/A random uint32 gmt_unix_time, opaque random_bytes[28] 4 + 28 N/A session_id opaque SessionID <0..32> 1 cipher_suite uint8 CipherSuite[2] 2 N/A compression_method null(0) 1 N/A extensions extension_type, extension_data<0..2^16-1> <0..2^16-1> 2バイト分 Record Layer(5bytes) Handshake (ServerHello) type protocol version length (2bytes) msg type length (3byte) server version random 32bytes session id cipher suite 2bytes compression majo r minor major minor 0x16 0x03 0x03 ? + 4 0x01 ? 0x03 0x03 ? 長さ1byte 0x00,0x9c 長さ2bytes
  62. 62. Certificate 項目 要素 サイズ certificate_list ASN.1Cert<2^24-1> <0..2^24-1> 全証明書長 証明書#1長 証明書データ#1 証明書#2長 証明書データ#2 複数の証明書データを送付 最初は必ずサーバ証明書 2つ目以降は中間証明書など
  63. 63. ServerHelloDone handshake type handshake長 0x0e 0x00 0x00 0x00 ServerHelloの終了の合図 ハンドシェイクヘッダのみ
  64. 64. ClientKeyExchange (RSA 交換の場合) Record Layer(5bytes) Handshake(ClientKeyExchange) type protocol version length (2bytes) msg type length (3byte) Encrypted PreMasterSecret major minor 0x16 0x03 0x03 ? + 4 0x10 ? 長さ2バイト ? PreMasterSecret client version random 46bytes major minor
  65. 65. TLSの 生成の流れ pre master secret (任意のバイト数: 交換による) サーバ・クライアント間の 交換方式で生成し、秘密的に共有する master secret (48 bytes) PRF(pre_master_secret, "master secret", client_random+server_random) keyblock (任意のバイト数:利用暗号方式による) PRF(master_secret, "key expansion", server_random+client_random) client_write_MAC server_write_MAC client_write_key server_write_key client_write_IV server_write_IV
  66. 66. PreMasterSecret/MasterSecret • TLSで利用するIV(初期ベクトル)、共有 、MAC のデータ元 • MasterSecretは48バイト長。PreMasterSecretの長さは 交換方式に依 存する。 • MasterSecretは、PreMasterSecret、ClientRandom、 ServerRandom、固定ラベルから生成する。 • Clinet/ServerRandomは全て丸見え。PreMasterSecretは、必ず死守し て守らないといけない。これが漏えいするとTLSの安全性は全ておじゃん。 Freak/Logjam
  67. 67. ChangeCipherSpec 送信元が暗号開始を宣言。これを送信した後は暗号 通信を行う。 Record Layer ChangeCipherSpec ContentTy pe Version length (2byte)major minor 0x14 0x03 0x03 0x00 0x01 0x01
  68. 68. Finished struct { opaque verify_data[verify_data_length]; } Finished; verify_data = PRF(master_secret, finished_label, Hash(handshake_messages))[0..11]; finished_label: クライアントは、"client finished"、サーバは"server finished" 12バイト固定 これまでのハンドシェイクデータ(た だし自分は除く)のハッシュを計算 TLS1.2では SHA256を使う Finishedを受信すると、これまで送受信したハンドシェイクデータから計算した値と比較。 ハンドシェイクデータが改ざんされてないことを確認する。
  69. 69. Forward Secret TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 と TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 を使う
  70. 70. Forward Secret • 前方秘匿性 (PFS: Perfect Forward Secrecyとも書かれることも) • セッション毎に一時的な公開 を使う。 • 証明書の秘密 は、一時的な公開 への署名に利用する。 • ハンドシェイクを含む全暗号データを取得されているような状況でも、将 来的な証明書の秘密 漏洩などのリスクに対応する。 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Ephemeral:一時的な 交換手法 接続ごとに公開 を変更する
  71. 71. DHE vs ECDHE • DH: Diffe-Hellman 離散対数問題を利用した 交換 ((g^x) mod P)^y mod P = ((g^y) mod P)^x mod P = g^(xy) mod P 素数P, ジェネレータ g, 公開 (赤字、青字)などの情報を交換。ECDHE より計算量が多い。 • ECDHE: 楕円関数上での離散対数演算を利用した 交換 楕円関数のパラメータ・基点を名前で規定(secp256等)、公開 (楕円 曲線上の点)を交換。DHより 長・計算量が少なくてすむ。
  72. 72. DHEのハンドシェイク ClientHello ServerHello Certificate ServerKeyExchange ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished Application Data (赤文字が追加変更されるところ) Clientの公開 を送付 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 P,G,サーバ公開 を署名して送付 公開 は毎回ランダムに生成されます https://html5.ohtsu.org/seccamp_hokkaido_2015/dhe.pcap
  73. 73. ECDHEのハンドシェイク ClientHello + elliptic_curves + ec_point_formats ServerHello + ec_point_formats Certificate ServerKeyExchange ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished Application Data (赤文字が追加変更されるところ) ClientHello拡張を追加 ServerHello拡張を追加 楕円曲線名とServer の公開 を署名付き で送付 Clientの公開 を送付 楕円点の書式を合意 使える楕円曲線名と楕円点書式を通知 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 公開 は毎回ランダムに生成されます https://html5.ohtsu.org/seccamp_hokkaido_2015/ ecdhe.pcap
  74. 74. TLSサーバを作る 目指せ SSLlab A+判定
  75. 75. 演習1.3:nginxの構築 https://gist.github.com/shigeki/b70bd5433e95722b5fa3
  76. 76. 演習1.4:SSLLabのテスト https://www.ssllabs.com/ssltest/index.html
  77. 77. default設定の結果 DHの 長 (1024bits)が弱いです
  78. 78. Logjam攻撃 • DHE 交換に対する攻撃(2015年5月に公開) • あらかじめ素数Pがわかっていれば従来より離散対数問題 を効率的に解けるようになった。 • DHでは標準素数が規定されており幾つかの実装ではそれ を利用している。 • 512bit長の標準素数は数十秒で解ける。1024bit長も国 家予算並みのお金をかければ解読できる。2048bit長以上 の利用を推奨。
  79. 79. 演習1.5:DHEの 長増加 • nginxはデフォルトで1024bitの標準素数でDHEを 利用している。 • 2048bit長以上にするにはユーザが独自にDHパラ メータ(P,g)を生成し設定する。 $ openssl dhparam -out dhparam.pem 2048 $ openssl dhparam -text -in dhparam.pem -noout dhparamファイルを /usr/local/nginx/conf にコピーし、nginx.confに ssl_dhparam dhparam.pem; を追加する。
  80. 80. DHEの 長変更後
  81. 81. 演習1.6:目指せA+ • いくつかスコアを増加させる方法はあるが、HSTS を設定してスコアを上げる。 • HSTS: HTTP Strict Transport Security • Strict-Transport-Securityヘッダを利用すると指 定した時間内はブラウザーが http:// が強制的に https:// へ接続にいく。nginx.conf に追加。 add_header Strict-Transport-Security "max-age=15768000; includeSubdomains";
  82. 82. HSTSの確認 一度ブラウザでTLS接続してから chrome://net-internals/#hsts をあける。 Query domain にサーバ名を入力 mode が STRICT になっていれば設 定OK
  83. 83. HSTS設定後 ブラウザーから一度httpsで接続してから、 http://∼ で接続してみる。
  84. 84. 演習2:TLSを破る FREAK攻撃
  85. 85. FREAK攻撃
  86. 86. FREAK攻撃
  87. 87. このRSA を破る https://html5.ohtsu.org/seccamp_hokkaido_2015/nopfs.hokkaido.koulayer.com_sha256_en.zip なんか変な 素数の積だぞ
  88. 88. 因数分解して秘密 をゲット 因数分解した答え(素数)を 入力 公開 PxQとE
  89. 89. 暗号化された PreMasterSecretを入手 バイナリーデータを 直接扱えるならパケットバイトをエキ スポートの方が楽
  90. 90. PreMasterSecretをゲット! $ cat > encrypted_premaster_secret.txt 0d9909953798f・・・・・721 $ xxd -p -r encrypted_premaster_secret.txt > encrypted_premaster_secret.der $ openssl rsautl -decrypt -pkcs -inkey private.key -in encrypted_premaster_secret.der -hexdump 0000 - ・・・・・・ ..F.y.....)i,`.0 0010 - ・・・・・・ P......}.?C..c.. 0020 - ・・・・・・ .x..Z.p..OK..ep. テキスト形式でコピーした場合バ イナリーに変換してください。 トータル何バイト長でしょうか 頭の2オクテットは何ですか?
  91. 91. 3. 上級者向け課題 https://html5.ohtsu.org/seccamp_hokkaido_2015/exam.pcap を解析して、PreMasterSecretを入手 MasterSecretを生成し、復号化用 を入手 暗号化されたアプリケーションデータを解読してくだ さい。 平文文字列が入手できればミッションクリア http://www.slideshare.net/shigeki_ohtsu/security-camp2015-tls のp76以降を参照
  92. 92. HTTP/2
  93. 93. HTTP/2演習の内容 • HTTP/1.1からHTTP/2へ • HTTP/2の仕組み概要 • 演習:HTTP/2サーバを作る • 演習:HTTP/2プロトコル解析 Ethernet IP(v4/v6) TCP TLS HTTP/2 Frame Layer HTTP/1.1 Semantics
  94. 94. HTTP/1.1からHTTP/2へ
  95. 95. HTTPプロトコルの年表 1990 1995 2000 2005 2010 2015 Webの 始まり HTTP/0.9 HTTP/1.0 RFC1945 HTTP/1.1 RFC2068 HTTP/1.1 RFC2616 HTTP/1.1 RFC7230-5 HTTP/2 RFC7540 SPDY/2 SPDY/3 SPDY/3.1 httpbis WG 暗黒の時代 HTTP-NG 中止 HPACK RFC7541
  96. 96. HTTP/2サポート状況 http://caniuse.com/#feat=http2
  97. 97. HTTP転送サイズとリクエスト数の遷移
 (2012/7/1∼2015/7/1) http://httparchive.org/trends.php?s=All&minlabel=Jul+1+2012&maxlabel=Jul +1+2015#bytesTotal&reqTotal 3年で 転送サイズ: 96%増 リクエスト数:20%増 (単一Webサイトの統計平均)
  98. 98. 回線帯域を増速していくと HTTP経由のダウンロード 時間[ms] 0 800 1600 2400 3200 回線帯域[MBps] 0 3 5 8 10 More Bandwidth does’nt matter よりデータ引用http://docs.google.com/a/chromium.org/viewer? a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDoxMzcyOWI1N2I4YzI3NzE2 ページの表示時間は、こ れ以上短縮できない。 Make the Web Faster: Google の試験
  99. 99. RTT(Round Trip Time)を小さくしていくと HTTP経由のダウンロード時間 [ms] 0 1000 2000 3000 4000 RTT[ms] 0 50 100 150 200 250 300 ちゃんと下がる More Bandwidth does’nt matter よりデータ引用http://docs.google.com/a/chromium.org/viewer? a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDoxMzcyOWI1N2I4YzI3NzE2 Webページの表示速度を速くするには、回線速度増強より RTT(の影響)を小さくするかが重要。でも物理的な制限 で難しい。 Make the Web Faster: Google の試験
  100. 100. SPDY(スピーディ)の登場(2009年) • RTTの影響をできるだけ避けるべくGoogleはSPDYを開発 した。 • SPDYは、Webページの表示速度を速くするためのプロ トコルとして当初社内プロジェクトから生まれた。 • 既に3年以上に渡りGoogleの全サービスで利用され、 TwitterやFacebook、LINEなど大規模なシステムに導入 されている。 ブラウザの拡張プラグイ ン(SPDY Indicator)を 使うとSPDYを使ってい るサイトがわかる
  101. 101. 演習: SPDY indicatorのインストール • https://chrome.google.com/webstore/ category/extensions から検索・インストール • HTTP/2サイトにアクセスして確認 • chrome://net-internals/#http2 でHTTP/2の 接続状況を確認
  102. 102. HTTP/1.1の問題点のおさらい 1. HTTP Head of Line Blocking 2. ネットワーク通信の利用が非効率 3. 曖昧でテキスト処理が煩雑
  103. 103. 1. HTTP Head of Line Blocking クライアント サーバ HTTP/1.1 1本のTCP接続 HTTP リクエスト HTTPレスポンス待ち時間 HTTP リクエスト
  104. 104. HTTP/1.1
 ブラウザは最大同時4∼6TCP接続に制限 最大同時並列6
  105. 105. HTTP/2
 100以上の同時リクエストが可能 全部同時
  106. 106. 2. HTTP/1.1はネットワーク通信の利用が非効率 クライアント サーバ TCP接続 TCP接続 TCP接続 TCP接続 TCP接続 TCP接続 それぞれのTCP接続が独立して輻輳 制御を行う
  107. 107. HTTP/1.1は非効率なプロトコル HTTP/1.1+SSLの輻輳ウィンドウサイズの変遷 輻輳ウィンドウサイズ(mss) 0 13 25 38 50 時間(sec) 10 18.75 27.5 36.25 45 SSL1 SSL2 SSL3 SSL4 SSL5 SSL6 6本のTCPがバラバラに 輻輳制御。帯域を有効に 使いきれてない
  108. 108. HTTP/2(SPDY)は効率的なプロトコル SPDY利用時の輻輳ウィンドウサイズの変遷 輻輳ウィンドウサイズ(mss) 0 13 25 38 50 時間(sec) 60 68.75 77.5 86.25 95 SPDY 1本のTCPで最高速まで利 用。帯域を最大限に効率的に 使っている。
  109. 109. 3. HTTP/1.1は処理が煩雑なテキストプロトコル HTTP/1.1 200 OK Content-Type: image/jpeg Transfer-Encoding: chunked Trailer: Foo 123 {binary data} 0 Foo: bar Status-Lineは一行目 空白は1つ ヘッダ名は大文字・小文 字区別せず ヘッダ領域の区切りは CRLF一つ :の後に空白を許可 CRLFで改行、複数 行対応は廃止 レスポンスデータがchunkedであ り、サイズはまだ不定 一番最後にFooヘッダが付与され ることを宣言 続くデータが123バイト であることを宣言 データ終了の合図 Trailヘッダ chunk終了合図の CRLF
  110. 110. HTTP/2はきっちりしたバイナリープロトコル 00 00 00 01 01 04 00 00 1a 88 5c 82 08 ・・・・・・ 73 ff 00 00 00 01 00 00 00 00 7b {binary data} :status = 200 content-length = 123 content-type = image/jpeg trailer = Foo HEADERS DATA フレーム長:28バイト フレーム長:123バイト フレームタイプ:HEADERS, END_HEADERSフラグ ストリームID: 1 ストリームID: 1 フレームタイプ:DATA, フラグなし (* 記載スペースの都合上Trailer HEADERSは省いています) データの 位置・サイズ・型 が明確
  111. 111. HTTP/2の仕組み概要
  112. 112. HTTP/2の技術的な特徴 • HTTP/1.1のセマンティックスを変えない。 • サーバへのTCP接続数を1つに限定 • TLSと連携してプロトコルを自動選択 • バイナリープロトコル(テキストデータの曖昧さを排除) • 全2重多重化通信 • フロー制御、優先度指定 • サーバプッシュ機能
  113. 113. HTTP/2の技術的な特徴 • SPDYのプロトコルアーキテクチャはそのまま利用 • SPDYの無駄なヘッダフィールドやフレームタイプを統廃合し、簡略 化 • SPDYの実運用で明らかとなったフロー制御・優先度制御といった 課題へ対応する • TLS利用を前提とするSPDYに対し、平文接続も利用可能にする 。 • ヘッダ圧縮脆弱性(CRIME)対策として新しくHTTPに特化したヘッ ダ送受信仕様(HPACK)を策定する
  114. 114. HTTP/2初期ニゴシエーション 
 3種類で2段階(その1) あらかじめサーバがHTTP/2対応とわかっている場 合、直接第2段階の接続方法を行う。 (DNSレコードや HTTPヘッダによるリダイレクト) HTTP/1.1の接続後 Upgradeヘッダ を使って、HTTP/2 に接続をアップグ レードする。 TLS接続時にALPN拡張フィールド を利用してHTTP/2に接続を行う。 (1) TLS + ALPN (2) HTTP Upgrade (3) 事前知識に よるDirect接続 詳細後 述 WebSock etと一緒 詳細仕様 検討中 暗号化通信 平文通信
  115. 115. ALPN (Application Layer Protocol Negotiation) クライアント サーバー 1. ClientHello + ALPN拡張 2. ServerHello + ALPN拡張 サーバ側でプロトコルを決定し、通知する h2 3. TLS 証明書・暗号化情報交換 プロトコルリストをサーバに送信 h2,spdy/3.1,http/1.1 HTTP/2で通信 TLSハンドシェイク https://html5.ohtsu.org/seccamp_hokkaido_2015/ http2.pcap
  116. 116. HTTP/2初期ニゴシエーション
 3種類で2段階(その2) 505249202a20485454502f322e300d0a0d0a534d0d0a0d0a PRI * HTTP/2.0rn rn SMrn rn クライアントから の24byteのマジックコードをサー バに送り、初期情報(SETTINGSフレームを交換する) SETTINGS (初期ウィンドウサイズ、ストリームの最大同時オープン数等の設定情報を含む) 間違えてHTTP/1.1 サーバに接続した場 合は即切断される
  117. 117. HTTP/2のデータフレーム(binary) ペイロード長(24bit) タイプ(8bit) フラグ(8bit) X ストリームID(31bit) ペイロードデータ(ペイロード長bit) タイプ フレーム種類 タイプ フレーム種類 0x00 DATA 0x05 PUSH_PROMISE 0x01 HEADERS 0x06 PING 0x02 PRIORITY 0x07 GOAWAY 0x03 RST_STREAM 0x08 WINDOW_UPDATE 0x04 SETTINGS 0x09 CONTINUATION デフォルトは14bit(16K), 24bit(16M)まで拡張可 フレームヘッダ 9バイト
  118. 118. フロー制御 クライアント サーバA サーバB Reverse Proxy 高速 低速 AとBからのデータを バランスよく返す WINDOW_UPDATE WINDOW_UPDATE サーバは、Window Size が0になったらデータ送信を停止 Window Size を増加させる サーバA,B へのウィン ドウサイズ更新を調整 TCPコネクション、ストリーム毎にフロー制御が可能
  119. 119. プライオリティ クライアント Reverse Proxy コンテンツ HTML 画像 CSS, js HTML CSS JS 画像1 画像2 画像3 画像4 依存性と重みを指定 weight:16 weight:16 プライオリティのユースケース • ファイルタイプ(HTML/CSS/JS/画像)に 応じた返答順序の指定 • タブ切り替えによる重みの上げ下げ • 分割されたビデオデータなど順番が明示的 に決められている場合
  120. 120. サーバプッシュ機能 コンテンツリクエスト クライアント サーバ 画像のHTTPリクエストを予約 コンテンツのレスポンス 画像データキャッシュ サーバはコンテンツの 中身を判断し,あらか じめコンテンツに含ま れている画像のリクエ ストを予約する. 予約された画像リクエストはク ライアントからサーバに送らず に,クライアントはサーバ側か らの画像データの送付を待つ サーバから送信さ れた画像データは, クライアントの キャッシュに保存
  121. 121. HTTP/2がTLSに求める制限 • TLSのバージョンは1.2以上 • プロトコル選択にALPN(RFC7301)を使う • サーバ認証を共有できる接続は接続共有が可能 • クライアント認証の利用は初期接続時のみ可能 • SNI(Server Name Indicator)拡張必須 • TLS Compression禁止 • Renegotiation禁止 • 長 (DHE 2048bit以上、ECDHE 224bit以上)サポート必須 • PFS必須 (DHE, ECDHE) • AEAD(GCM/CCM)以外の暗号方式をブラックリストとして利用禁止 HTTP/2 仕様でTLSの利用条件を制限すべきかどうか大きな議論になった が、 新しいプロトコルはよりセキュアな状態で提供すべきとの意見で合意
  122. 122. 演習4.1: nginx を http2対応にする server { listen 443 ssl http2; ・・・・ } わずかこれだけ
  123. 123. しかしエラーでつながりません セキュリティ が十分でない
  124. 124. 比べて見よう Cipher List nginxのデフォルト設定はサー バ側のリストを優先に選択 Chromeの Cipher List nginxの Cipher List サーバはECDHE_RSA_WITH_AES_256_CBC_SHAを選択 →AEAD(GCM)じゃないのでHTTP/2の条件外 RSA認証でサーバリストの 上から合うのを探していくと
  125. 125. もう一度HTTP/2のTLS条件を思い出せ! • 長 (DHE 2048bit以上、ECDHE 224bit以 上)サポート必須 • PFS必須 (DHE, ECDHE) • AEAD(GCM/CCM)以外の暗号方式をブラッ クリストとして利用禁止 (注: openssl-1.0.2以上限定です) これならいけるはず
  126. 126. 演習4.2:nginxでHTTP/2サーバを作る HTTP/2のTLS接続 条件クリア HTTP/2 WiresharkでTLSハンドシェイクを取得 Client/ServerHello のALPN Extension を確認する
  127. 127. 演習5: HTTP HoLを再現させる $ git clone https://github.com/shigeki/seccamp-imageserver/ $ cd seccamp-imageserver/lib ~/seccamp-imageserver/lib$ node ./server.js Litening on port 8080 location / { root /home/seccamp/seccamp-imageserver/html; index index.html index.htm; } location /images { proxy_pass http://localhost:8080; } nginx.confの変更 imageサーバを立ち上げ すぐ返す 3秒後返す
  128. 128. HTTP/1.1の表示 Head of Line Blocking 泣き顔画像が ブロック
  129. 129. HTTP/2の表示 泣き顔画像がブ ロックしない face-xx.pngの数字が3で割り切れると泣き顔表示 自分でHTMLを変更して画像数を変えて比較してみよう

×