Movatterモバイル変換

TLS, HTTP/2演習IIJ 大津繁樹2015年12月12∼13日セキュリティ・ミニキャンプ in 北海道 2015

自己紹介• 大津繁樹• 株式会社インターネットイニシアティブ(IIJ)• Node.js Core Technical Committee メンバー• IETF httpbis WGでHTTP/2相互接続試験など使用策定に参画• ブログ： http://d.hatena.ne.jp/jovi0608/

本講義・演習の目的• ２日間の講義・演習を通じてTLS, HTTP/2の仕組みを学んで頂きます。• 演習は、できるだけプログラミングを行う要素をなくし、Wireshark、Linux上のコマンドやファイル編集で収まるようにしています。• TLS, HTTP/2ともに幅広く深い技術です。２日間で完全に理解するのは難しいでしょう。でも基本的な部分をおさえて将来の理解に役立ててください。

本講義・演習の内容(TLS)• 講義：TLS概要• 講義：TLSを理解する準備(暗号技術など)• 講義：事前学習解説(サーバ証明書取得までのPKIの仕組み)• 講義：TLSの仕組みの理解 (Wiresharkの画面を見つつ)• 演習：nginxでTLSサーバを構築• 演習：SSLLabでA＋を目指す• 演習：RSA を解読してTLSを破る（FREAK攻撃)

本講義・演習の内容(HTTP/2)• 講義： HTTP/2が必要になった背景• 講義： HTTP/2の仕組み解説• 演習： nginxサーバをHTTP/2対応に• 講義・演習： HTTP/2のTLS制限について• 演習：HTTP/2によるHTTP Head of Blockingの解消

謝辞• 本演習では、さくらインターネット株式会社様より参加者全員にクラウドサーバをご提供いただきました。厚く御礼申し上げます。

演習課題の手順書https://gist.github.com/shigeki/fb40645dfe0ce343565eできるだけコピペ作業は止めよう。

インターネットの脅威盗聴パスワードやクレジットカード番号を盗み見

インターネットの脅威改ざん通信途中でデータを書き換え

インターネットの脅威なりすましユーザになりすまして通信を行う

インターネットの脅威否認そんな通信してませんとキャンセル

インターネットの脅威から守るセキュリティ対策盗聴改ざん成りすまし否認暗号化完全性チェック認証署名

各レイヤーにおけるセキュリティ通信WPAIPsecTLS,DTLS,SSHS/MIME, PGP無線LANIPTCP, UDPデータ

TLSの目的• TLSプロトコルの最重要なゴールは、通信する２つのアプリケーションの間でプライバシーとデータの完全性を提供することです。RFC5246: The Transport Layer Security (TLS) Protocol Version 1.21. IntroductionThe primary goal of the TLS protocol is to provide privacy and dataintegrity between two communicating applications.アプリアプリ完全性プライバシー

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現在の利用推奨様々な拡張仕様の追加

TLSの要素技術X509証明書PKI対称暗号暗号モード公開暗号デジタル署名メッセージ認証乱数生成TLS交換一方向ハッシュTLSプロトコルは、これらの要素技術を組み合わせてアプリ間のセキュア通信を確立する手順を決める

TLS要素技術の依存性X509証明書PKI対称暗号暗号モード公開暗号デジタル署名メッセージ認証乱数生成交換一方向ハッシュ本来はこの一つ一つをきちんと理解することが必要

TLS要素技術はどこで使われる？ClientHelloServerHelloDoneChangeCipherSpecFinishedChangeCipherSpecFinishedApplication DataApplication Data乱数生成対称暗号・暗号モード・一方向ハッシュ・乱数生成PKI・X509証明書・デジタル署名乱数生成ServerHelloCertificateClientKeyExchangeServerKeyExchange(*)乱数生成・交換・公開暗号・デジタル署名メッセージ認証対称暗号・暗号モードメッセージ認証対称暗号・暗号モード乱数生成・交換デジタル署名(* オプションで必須ではない）

TLS要素技術はどこで使われる？乱数生成 Client/ServerHelloのNonce, ペアの生成データ暗号化のIVPKI CAによるサーバ証明書の署名と発行X509証明書 Certiﬁcateによるサーバ・クライアントの認証・公開の取得電子署名証明書の署名・交換で交換する公開の署名交換 Server/ClientKeyExchangeによる(EC)DH公開の交換公開暗号 RSA 交換時にPreMasterSecretの暗号送信一方向ハッシュ CBCなどの暗号モード利用時にアプリデータのMAC生成メッセージ認証MasterSecretの生成、Finishedによるハンドシェイクデータの完全性検証対称暗号・暗号モード ChangeCipherSpec以降のハンドシェイクとアプリケーションデータの暗号化（注：他にも細かいところで使われています。)

今回使うTLS要素技術GCM AESDHEECDHE RSASHA256HMACX509証明書PKI対称暗号暗号モード公開暗号デジタル署名メッセージ認証乱数生成交換一方向ハッシュWoSignFree DV Cert手入力？？

セットメニュー化されたTLSの要素技術TLS CipherSuitesTLS_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を割り当て

対称暗号暗号文平文共通共通平文ストリーム暗号：データを逐次暗号化(RC4, Chacha20)ブロック暗号：データをブロック毎に暗号化(DES, AES)幾つかの暗号では既に危殆化：DES: 2005年 NIST FPS46-3規格の廃止(2030年までは許容)RC4: RFC7455: Prohibiting RC4 Cipher Suites暗号化復号化

対称暗号 AES• 1997年よりプロジェクト開始、2000年選定、2001年仕様発行• ブロックサイズ 128bit• 長： 128bits, 192bits, 256bits の３種類• Intel/AMDのCPUでハードウェア処理のサポート(AES-NI)

暗号モード• ブロック暗号は同じデータを同じで暗号化すると毎回同一の暗号文になる。• ブロック長より長いデータを暗号化する場合に暗号モードを利用して繰り返しを避ける。• CBC：「(平文 XOR ベクトル) を暗号化」を続ける• CTR：「カウンターを暗号化 XOR 平文」を続ける実際にTLSで利用するには改ざん検知のためのMAC(メッセージ認証）との組み合わせる(AEAD)。これまでの主流これからの主流に（GCM後述）

認証タグAEAD（認証付き暗号)暗号化しないけど改ざん• • • • • • • • • • •防止が必要なデータ• • • • • • • • •（ヘッダ等）• • • •暗号化する平文AEAD暗号化暗号文共通初期ベクトル

AEAD（認証付き暗号)平文AEAD復号化改ざんチェック暗号化しないけど改ざん防止が必要なデータ（ヘッダ等）暗号文認証タグ共通初期ベクトル

GCM• GCM (Galois Counter Mode: ガロアカウンターモード）• CTRとGHASHを組み合わせたAEAD• ハードウェア処理で高速化が可能• AESと組み合わせて AES-GCMとして利用

一方向ハッシュデータ一方向ハッシュ関数ハッシュ値ハッシュ値を比較することでデータの改ざんをチェックすることができる。

一方向ハッシュ• md5• SHA-1• SHA-2(SHA-256など6種)• SHA-3(SHA3-256など6種)2018年ぐらいには現実的なコストで衝突データを探せる見込み(*2)既に現実的な攻撃手法が存在(*2) Cryptanalysis of SHA-1https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html(*1) how to Break MD5 and Other Hash Functionshttp://merlot.usc.edu/csac-f06/papers/Wang05a.pdf8/5にNISTより正式公開

メッセージ認証(HMAC)• 事前に共通を共有• 共通とデータを組み合わせたハッシュ値を作成• データの完全性とハッシュ作成者を認証するデータ一方向ハッシュ関数ハッシュ値共通

公開暗号512bit RSAの危険性 FREAK https://freakattack.com/• 解を求めるのが困難な数学的問題を利用して暗号を生成。• 公開と秘密のペアを生成。公開はさらして大丈夫。• 公開で暗号化し秘密で復号化。• RSA 素因数分解• ECC(楕円曲線暗号）楕円曲線上の離散対数問題公開秘密暗号化復号化

交換• 2者間で安全にを共有する仕組み• 互いに公開を交換しあい、共有を生成する。• 通信経路上で共有のやり取りがない。• DH (Diffie-Hellman)• ECDH(楕円曲線DH)脆弱性：DH Logjam https://weakdh.org/公開公開秘密秘密

デジタル署名• データの完全性のチェックが可能となる。• データの送信元の認証が可能となる。• 公開の信頼性の範囲で否認防止が可能となる。• RSA• DSA,ECDSA公開秘密データ＋デジタル署名データハッシュ値を暗号化しデジタル署名を生成デジタル署名を復号化。データハッシュ値と比較し検証する

事前課題の解説・復習演習で利用するTLSサーバ証明書(DV)を取得するまでの一連の手続きを行う1.乱数データの生成2.秘密 (RSA)の生成・確認・保護3.CSRの生成・確認・提出4.CAに申請・サーバ証明書発行5.サーバ証明書の取得・確認https://gist.github.com/shigeki/102cd71b34627c5bf330openssl genrsa, openssl rsaopenssl reqopenssl x509

乱数生成利用用途：• 暗号 (対称暗号：秘密、公開暗号：ペア）の生成• 暗号モードの初期ベクトルやNonce(*)の生成• MAC（メッセージ認証）用求められる機能:無作為性：偏りがなく等しい数である。予測不可能性：次の乱数が予想できない。制限負可能性：同じ乱数列を再現できない。(* Nonce(number used once)一度だけ使い捨て用に使われる数字)

乱数生成• 実際の利用は、疑似乱数生成。seedが必要。• OppenSSLのdefault built-inでは、seedはLinuxの/dev/urandom+pid+uid+timeを利用。WindowsではOSのAPIのCryptGenRandomだけでなく画面スクリーンのビットマップハッシュやヒープメモリも利用。脆弱性：• CVE-2008-0166: DebianやUbuntuのOpenSSLに予測可能な乱数を生成してしまう脆弱性• SSH公開にブルートフォース攻撃

Linuxのエントロピー• /dev/urandom• ブロックしない• 外部デバイス（キーボードやディスクなど）の割り込みをエントロピーソースにして溜める。加工したデータのハッシュ値を取る。• エントロピーが十分溜まっているかが重要(特にインストール直後)• /proc/sys/kernel/random/entropy_avail で値を確認できる。（Max 4k) 1k以下だったらエントロピーの追加を検討。• ﬁndなどでDisk I/Oを人為的に増やしたり、rng-tools, Virtio_RNG,Haveged 等ツールを使う

演習1.1: エントロピーの確認• サーバに入り、プールしているエントロピーを確認します。• cat /proc/sys/kernel/random/entropy_avail• Disk I/Oを発生させます。• ﬁnd / > /dev/null• エントロピーが変わったかどうか確認します。• /dev/urandom からデータを読み込みます。その後エントロピープールが減ったことを確認します。• head -10 /dev/urandom > /dev/null

事前学習の復習• 事前学習で作成したファイルの中身を見てみる秘密$ openssl rsa -text -in private.key -nooutCSR$ openssl req -text -in server.csr -nooutサーバ証明書$ openssl x509 -text -in server.crt -noout

ASN.1, DER, PEMPEM: DER形式をBase64に変換してBEGINヘッダ∼ENDフッタをつけたテキストASN.1: データ構造を表す書式DER:ASN.1のデータ構造をタグ+長さ+データでエンコードしたバイナリ

秘密 (RSA)• 公開暗号やデジタル署名で利用するデータ。実際は公開と秘密のペアを生成している。• TLS通信のセキュリティを確保する要の一つ。厳重に管理。• 秘密が漏洩するなど危殆化するとTLS通信のセキュリティは確保できなくなる。• PKCS#1(RFC3447)で規定• 秘密は暗号化してPKCS#5形式で保管する、パスワードで復号化。

RSA秘密の中身Private-Key: (2048 bit)modulus:publicExponent:privateExponent:prime1:prime2:exponent1:exponent2:coeﬃcient:長N=PxQ (素数P,Qの積）公開値E 暗号化する指数通常2^16+1 公開値D=1/E mod((P-1)(Q-1)) 復号化する指数秘密値素数P 秘密値素数Q 秘密値中国剰余定理で計算するための値秘密値D, P, Qから計算できる

CSR• Certiﬁcate Signing Request(証明書署名要求)• PKCS#10(RFC2986)で規定• サーバ証明書の識別子(サーバ名など）と公開を含んだもの。CA（認証局）にCSRを申請してサーバ証明書を発行してもらう。

CSRの中身• Version: バージョン 0x0• Subject：証明書を発行してもらうサーバの識別名Subject: C=JP, ST=Hokkaido, O=Security Camp, CN=server21.hokkaido.koulayer.com• 公開：アルゴリズムや公開のデータ• 署名：上記データの署名CN: Common Nameサーバ名が入る

PKI概要CA(Certiﬁcate Authority) VA(Validation Authority)RA(Registration Authority)CRL/OCSPCSRペア実在確認サーバ証明書https://∼失効確認論理的に複数の役割に分かれているが物理的に１つでもよいRoot証明書OS・ブラウザベンダー

サーバ証明書(X509)• TLS通信の信頼性を担保する要• ビルトインのルート証明書からサーバ証明書まで証明書チェーンの署名検証• オンライン以外で信頼性を担保(PKI)ビルトインのルート証明書サーバ証明書中間証明書ビルトインのルート証明書サーバ証明書中間証明書トラストアンカー

証明書の種類EV証明書(ExtendedValidation)CA共通の厳格な組織の実在証明(物理的実在, 書面やデータ, 口座取引による実在審査・署名提出・電話確認など)アドレスバーが緑色OV証明書(OrganizationValidation)各CAポリシー(CPS)に従った組織の実在証明（書面やデータ審査・電話確認など)DV証明書(DomainValidation)各CAポリシー(CPS)に従ったドメイン保持証明(メールの到達性確認など)今回利用ネットワーク以外の実在証明

サーバ証明書の中身バージョン、シリアル番号、発行者情報、有効期限、サーバ識別子、公開情報、拡張情報(利用用途、別名や失効情報・ポリシー参照先)、デジタル署名

サーバ証明書の確認サーバ証明書と秘密の対応が間違っていたらTLSサーバは起動しない。なのでサーバ証明書と秘密の公開が一致するか必ずチェックする。サーバ証明書秘密openssl x509 -pubkey -inserver.crt -noout > server_pubkey.pemopenssl rsa -pubout -in private.key -out private_pubkey.pem公開公開

TLSのセキュリティTLSのセキュリティ乱数生成PKI秘密の管理暗号技術エントロピー不足不正発行漏洩アルゴリズム・強度の危殆化TLSは、この４つの外部要素の上でインターネットで安全な通信を提供する仕組みである。

TLSの仕組みまずは TLS_RSA_WITH_AES_128_GCM_SHA256 の時から

演習1.2https://html5.ohtsu.org/seccamp_hokkaido_2015/exam.pcapから pcap データをダウンロードして Wiresharkで開くWiresharkのデータを見比べながらTLSハンドシェイクを解説します。

TLSハンドシェイク(full handshake)ClientHelloServerHelloCertificateServerHelloDoneClientKeyExchangeChangeCipherSpecFinishedChangeCipherSpecFinishedApplication DataApplication Data(赤文字はハンドシェイク）ClientHelloとServerHelloのやり取りで双方が利用するTLSバージョンや暗号化方式などを合意する。

TLSハンドシェイク(resumption)ClientHelloServerHelloChangeCipherSpecFinishedChangeCipherSpecFinishedApplication DataApplication Data(赤文字はハンドシェイク）SessionIDによるTLSセッションの再開。交換や証明書送付をスキップ。今回は演習の対象外です

TLSハンドシェイクの意味ClientHello/ServerHello/ServerHelloDoneTLSのための情報交換バージョン・乱数・暗号方式・拡張情報Certificate公開情報の送付エンドポイントの認証ClientKeyExchange/ServerKeyExchange共有交換ChangeCipherSpec暗号開始の合図Finishedハンドシェイクデータの改ざんチェック

TLS1.2の構造IPヘッダTCPヘッダTLS Record Layer(5バイト)タイプ（４種類）(1byte)バージョン(2byte)長さ(2byte)Handshake (タイプ:0x16)msgタイプ（１０種類）長さ（3バイト長）ハンドシェイクデータAlert (タイプ:0x15)レベル理由ChangeCipherSpec (タイプ:0x14)タイプApplication Data (タイプ:0x17)暗号化されたデータmsgタイプハンドシェイクデータの種類0x00 HelloRequest0x01 ClientHello0x02 ServerHello0x0b Certificate0x0c ServerKeyExchange0x0d CertificateRequest0x0e ServerHelloDone0x0f CertificateVerify0x10 ClientKeyExchange0x14 FinishedTLS Record Layerデータに続いて、次の４種類のTLSデータのいずれかが続く。TLS Handshakeは、この１０種類に分かれる。

ClientHello項目要素サイズ先頭の長さ情報client_version uint8 major, uint8 minor 2 N/Arandom uint32 gmt_unix_time, opaquerandom_bytes[28]4 + 28 N/Asession_id opaque SessionID <0..32> 1バイト分cipher_suites uint8 CipherSuite[2] <2..2^16-2> 2バイト分compression_methodsnull(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 1type データ長データ type データ長データ type データ長データExtension長 Extensionsデータ例

ClientHelloRecord Layer Handshake (ClientHello)type protocolversionlength(2byte)msgtypelength(3byte)clientversionrandom sessionidciphersuitecompressionExtensionmajorminormajor minor0x16 0x03 0x01 ?? ?? 0x01 ?? ?? ?? 0x03 0x03 32 byte 可変可変可変可変Version0x03,0x00 = SSLv30x03,0x01= TLSv1.00x03,0x02=TLSv1.10x03,0x03=TLSv1.2クライアントが利用できる最高のTLSバージョンを指定、サーバがどのバージョンを使うか選択する

ServerHello項目要素サイズ先頭の長さ情報server_version uint8 major, uint8 minor 2 N/Arandom uint32 gmt_unix_time, opaquerandom_bytes[28]4 + 28 N/Asession_id opaque SessionID <0..32> 1cipher_suite uint8 CipherSuite[2] 2 N/Acompression_method null(0) 1 N/Aextensions extension_type,extension_data<0..2^16-1><0..2^16-1> 2バイト分Record Layer(5bytes) Handshake (ServerHello)type protocolversionlength(2bytes)msgtypelength(3byte)serverversionrandom32bytessession id ciphersuite2bytescompressionmajorminor major minor0x16 0x03 0x03 ? + 4 0x01 ? 0x03 0x03 ? 長さ1byte 0x00,0x9c 長さ2bytes

Certificate項目要素サイズcertificate_list ASN.1Cert<2^24-1> <0..2^24-1>全証明書長証明書#1長証明書データ#1 証明書#2長証明書データ#2複数の証明書データを送付最初は必ずサーバ証明書 2つ目以降は中間証明書など

ServerHelloDonehandshaketypehandshake長0x0e 0x00 0x00 0x00ServerHelloの終了の合図ハンドシェイクヘッダのみ

ClientKeyExchange (RSA 交換の場合)Record Layer(5bytes) Handshake(ClientKeyExchange)type protocolversionlength(2bytes)msgtypelength(3byte)Encrypted PreMasterSecretmajor minor0x16 0x03 0x03 ? + 4 0x10 ? 長さ2バイト ?PreMasterSecretclient version random 46bytesmajor minor

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

PreMasterSecret/MasterSecret• TLSで利用するIV(初期ベクトル)、共有、MAC のデータ元• MasterSecretは48バイト長。PreMasterSecretの長さは交換方式に依存する。• MasterSecretは、PreMasterSecret、ClientRandom、ServerRandom、固定ラベルから生成する。• Clinet/ServerRandomは全て丸見え。PreMasterSecretは、必ず死守して守らないといけない。これが漏えいするとTLSの安全性は全ておじゃん。Freak/Logjam

ChangeCipherSpec送信元が暗号開始を宣言。これを送信した後は暗号通信を行う。Record Layer ChangeCipherSpecContentTypeVersion length(2byte)major minor0x14 0x03 0x03 0x00 0x01 0x01

Finishedstruct {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を受信すると、これまで送受信したハンドシェイクデータから計算した値と比較。ハンドシェイクデータが改ざんされてないことを確認する。

Forward SecretTLS_DHE_RSA_WITH_AES_128_GCM_SHA256 とTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256を使う

Forward Secret• 前方秘匿性 (PFS: Perfect Forward Secrecyとも書かれることも)• セッション毎に一時的な公開を使う。• 証明書の秘密は、一時的な公開への署名に利用する。• ハンドシェイクを含む全暗号データを取得されているような状況でも、将来的な証明書の秘密漏洩などのリスクに対応する。TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256Ephemeral:一時的な交換手法接続ごとに公開を変更する

DHE vs ECDHE• DH: Diﬀe-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より長・計算量が少なくてすむ。

DHEのハンドシェイクClientHelloServerHelloCertificateServerKeyExchangeServerHelloDoneClientKeyExchangeChangeCipherSpecFinished ChangeCipherSpecFinishedApplication Data(赤文字が追加変更されるところ）Clientの公開を送付TLS_DHE_RSA_WITH_AES_128_GCM_SHA256P,G,サーバ公開を署名して送付公開は毎回ランダムに生成されますhttps://html5.ohtsu.org/seccamp_hokkaido_2015/dhe.pcap

ECDHEのハンドシェイクClientHello+ elliptic_curves+ ec_point_formatsServerHello+ ec_point_formatsCertificateServerKeyExchangeServerHelloDoneClientKeyExchangeChangeCipherSpecFinished ChangeCipherSpecFinishedApplication Data(赤文字が追加変更されるところ）ClientHello拡張を追加ServerHello拡張を追加楕円曲線名とServerの公開を署名付きで送付Clientの公開を送付楕円点の書式を合意使える楕円曲線名と楕円点書式を通知TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256公開は毎回ランダムに生成されますhttps://html5.ohtsu.org/seccamp_hokkaido_2015/ ecdhe.pcap

TLSサーバを作る目指せ SSLlab A+判定

演習1.3：nginxの構築https://gist.github.com/shigeki/b70bd5433e95722b5fa3

演習1.4：SSLLabのテストhttps://www.ssllabs.com/ssltest/index.html

default設定の結果DHの長(1024bits)が弱いです

Logjam攻撃• DHE 交換に対する攻撃(2015年５月に公開)• あらかじめ素数Pがわかっていれば従来より離散対数問題を効率的に解けるようになった。• DHでは標準素数が規定されており幾つかの実装ではそれを利用している。• 512bit長の標準素数は数十秒で解ける。1024bit長も国家予算並みのお金をかければ解読できる。2048bit長以上の利用を推奨。

演習1.5：DHEの長増加• nginxはデフォルトで1024bitの標準素数でDHEを利用している。• 2048bit長以上にするにはユーザが独自にDHパラメータ(P,g)を生成し設定する。$ openssl dhparam -out dhparam.pem 2048$ openssl dhparam -text -in dhparam.pem -nooutdhparamファイルを /usr/local/nginx/conf にコピーし、nginx.confにssl_dhparam dhparam.pem;を追加する。

演習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";

HSTSの確認一度ブラウザでTLS接続してからchrome://net-internals/#hstsをあける。Query domain にサーバ名を入力mode が STRICT になっていれば設定OK

HSTS設定後ブラウザーから一度httpsで接続してから、http://∼ で接続してみる。

演習2：TLSを破るFREAK攻撃

このRSA を破るhttps://html5.ohtsu.org/seccamp_hokkaido_2015/nopfs.hokkaido.koulayer.com_sha256_en.zipなんか変な素数の積だぞ

因数分解して秘密をゲット因数分解した答え（素数)を入力公開 PxQとE

暗号化されたPreMasterSecretを入手バイナリーデータを直接扱えるならパケットバイトをエキスポートの方が楽

PreMasterSecretをゲット！$ cat > encrypted_premaster_secret.txt0d9909953798f・・・・・721$ xxd -p -r encrypted_premaster_secret.txt > encrypted_premaster_secret.der$ openssl rsautl -decrypt -pkcs -inkey private.key -inencrypted_premaster_secret.der -hexdump0000 - ・・・・・・ ..F.y.....)i,`.00010 - ・・・・・・ P......}.?C..c..0020 - ・・・・・・ .x..Z.p..OK..ep.テキスト形式でコピーした場合バイナリーに変換してください。トータル何バイト長でしょうか頭の２オクテットは何ですか？

3. 上級者向け課題https://html5.ohtsu.org/seccamp_hokkaido_2015/exam.pcapを解析して、PreMasterSecretを入手MasterSecretを生成し、復号化用を入手暗号化されたアプリケーションデータを解読してください。平文文字列が入手できればミッションクリアhttp://www.slideshare.net/shigeki_ohtsu/security-camp2015-tlsのp76以降を参照

HTTP/2演習の内容• HTTP/1.1からHTTP/2へ• HTTP/2の仕組み概要• 演習：HTTP/2サーバを作る• 演習：HTTP/2プロトコル解析EthernetIP(v4/v6)TCPTLSHTTP/2Frame LayerHTTP/1.1Semantics

HTTPプロトコルの年表1990 1995 2000 2005 2010 2015Webの始まりHTTP/0.9 HTTP/1.0RFC1945HTTP/1.1RFC2068HTTP/1.1RFC2616HTTP/1.1RFC7230-5HTTP/2RFC7540SPDY/2SPDY/3SPDY/3.1httpbis WG暗黒の時代HTTP-NG中止HPACKRFC7541

HTTP/2サポート状況http://caniuse.com/#feat=http2

HTTP転送サイズとリクエスト数の遷移 (2012/7/1∼2015/7/1)http://httparchive.org/trends.php?s=All&minlabel=Jul+1+2012&maxlabel=Jul+1+2015#bytesTotal&reqTotal3年で転送サイズ: 96%増リクエスト数：20%増（単一Webサイトの統計平均）

回線帯域を増速していくとHTTP経由のダウンロード時間[ms]0800160024003200回線帯域[MBps]0 3 5 8 10More Bandwidth does’nt matter よりデータ引用http://docs.google.com/a/chromium.org/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDoxMzcyOWI1N2I4YzI3NzE2ページの表示時間は、これ以上短縮できない。Make the Web Faster: Google の試験

RTT(Round Trip Time)を小さくしていくとHTTP経由のダウンロード時間[ms]01000200030004000RTT[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=Y2hyb21pdW0ub3JnfGRldnxneDoxMzcyOWI1N2I4YzI3NzE2Webページの表示速度を速くするには、回線速度増強よりRTT（の影響）を小さくするかが重要。でも物理的な制限で難しい。Make the Web Faster: Google の試験

ＳＰＤＹ(スピーディ）の登場（2009年）• RTTの影響をできるだけ避けるべくGoogleはSPDYを開発した。• SPDYは、Ｗｅｂページの表示速度を速くするためのプロトコルとして当初社内プロジェクトから生まれた。• 既に3年以上に渡りGoogleの全サービスで利用され、TwitterやFacebook、LINEなど大規模なシステムに導入されている。ブラウザの拡張プラグイン(SPDY Indicator)を使うとSPDYを使っているサイトがわかる

演習： SPDY indicatorのインストール• https://chrome.google.com/webstore/category/extensions から検索・インストール• HTTP/2サイトにアクセスして確認• chrome://net-internals/#http2 でHTTP/2の接続状況を確認

HTTP/1.1の問題点のおさらい1. HTTP Head of Line Blocking2. ネットワーク通信の利用が非効率3. 曖昧でテキスト処理が煩雑

1. HTTP Head of Line BlockingクライアントサーバHTTP/1.11本のTCP接続HTTP リクエストHTTPレスポンス待ち時間HTTP リクエスト

HTTP/1.1 ブラウザは最大同時4∼6TCP接続に制限最大同時並列6

HTTP/2 100以上の同時リクエストが可能全部同時

2. HTTP/1.1はネットワーク通信の利用が非効率クライアントサーバTCP接続TCP接続TCP接続TCP接続TCP接続TCP接続それぞれのTCP接続が独立して輻輳制御を行う

HTTP/1.1は非効率なプロトコルHTTP/1.1+SSLの輻輳ウィンドウサイズの変遷輻輳ウィンドウサイズ(mss)013253850時間(sec)10 18.75 27.5 36.25 45SSL1 SSL2SSL3 SSL4SSL5 SSL66本のTCPがバラバラに輻輳制御。帯域を有効に使いきれてない

HTTP/2(SPDY)は効率的なプロトコルSPDY利用時の輻輳ウィンドウサイズの変遷輻輳ウィンドウサイズ(mss)013253850時間(sec)60 68.75 77.5 86.25 95SPDY1本のTCPで最高速まで利用。帯域を最大限に効率的に使っている。

3. HTTP/1.1は処理が煩雑なテキストプロトコルHTTP/1.1 200 OKContent-Type: image/jpegTransfer-Encoding: chunkedTrailer: Foo123{binary data}0Foo: barStatus-Lineは一行目空白は1つヘッダ名は大文字・小文字区別せずヘッダ領域の区切りはCRLF一つ:の後に空白を許可CRLFで改行、複数行対応は廃止レスポンスデータがchunkedであり、サイズはまだ不定一番最後にFooヘッダが付与されることを宣言続くデータが123バイトであることを宣言データ終了の合図Trailヘッダchunk終了合図のCRLF

HTTP/2はきっちりしたバイナリープロトコル00 00 00 0101 0400 00 1a88 5c 82 08・・・・・・73 ff00 00 00 0100 0000 00 7b{binary data}:status = 200content-length = 123content-type = image/jpegtrailer = FooHEADERSDATAフレーム長：28バイトフレーム長：123バイトフレームタイプ：HEADERS, END_HEADERSフラグストリームID: 1ストリームID: 1フレームタイプ：DATA, フラグなし(* 記載スペースの都合上Trailer HEADERSは省いています）データの位置・サイズ・型が明確

HTTP/2の技術的な特徴• HTTP/1.1のセマンティックスを変えない。• サーバへのTCP接続数を１つに限定• TLSと連携してプロトコルを自動選択• バイナリープロトコル（テキストデータの曖昧さを排除）• 全２重多重化通信• フロー制御、優先度指定• サーバプッシュ機能

HTTP/2の技術的な特徴• SPDYのプロトコルアーキテクチャはそのまま利用• SPDYの無駄なヘッダフィールドやフレームタイプを統廃合し、簡略化• SPDYの実運用で明らかとなったフロー制御・優先度制御といった課題へ対応する• TLS利用を前提とするSPDYに対し、平文接続も利用可能にする。• ヘッダ圧縮脆弱性(CRIME)対策として新しくHTTPに特化したヘッダ送受信仕様(HPACK)を策定する

HTTP/2初期ニゴシエーション  3種類で2段階（その１）あらかじめサーバがHTTP/2対応とわかっている場合、直接第２段階の接続方法を行う。(DNSレコードや HTTPヘッダによるリダイレクト）HTTP/1.1の接続後 Upgradeヘッダを使って、HTTP/2 に接続をアップグレードする。TLS接続時にALPN拡張フィールドを利用してHTTP/2に接続を行う。(1) TLS + ALPN(2) HTTP Upgrade(3) 事前知識によるDirect接続詳細後述WebSocketと一緒詳細仕様検討中暗号化通信平文通信

ALPN (Application Layer Protocol Negotiation)クライアントサーバー1. ClientHello + ALPN拡張2. ServerHello + ALPN拡張サーバ側でプロトコルを決定し、通知するh23. TLS 証明書・暗号化情報交換プロトコルリストをサーバに送信h2,spdy/3.1,http/1.1HTTP/2で通信TLSハンドシェイクhttps://html5.ohtsu.org/seccamp_hokkaido_2015/ http2.pcap

HTTP/2初期ニゴシエーション 3種類で2段階（その２）505249202a20485454502f322e300d0a0d0a534d0d0a0d0aPRI * HTTP/2.0rnrnSMrnrnクライアントからの24byteのマジックコードをサーバに送り、初期情報(SETTINGSフレームを交換する）SETTINGS(初期ウィンドウサイズ、ストリームの最大同時オープン数等の設定情報を含む）間違えてHTTP/1.1サーバに接続した場合は即切断される

HTTP/2のデータフレーム(binary)ペイロード長(24bit)タイプ(8bit) フラグ(8bit)X ストリームID(31bit)ペイロードデータ(ペイロード長bit)タイプフレーム種類タイプフレーム種類0x00 DATA 0x05 PUSH_PROMISE0x01 HEADERS 0x06 PING0x02 PRIORITY 0x07 GOAWAY0x03 RST_STREAM 0x08 WINDOW_UPDATE0x04 SETTINGS 0x09 CONTINUATIONデフォルトは14bit(16K),24bit(16M)まで拡張可フレームヘッダ 9バイト

フロー制御クライアントサーバAサーバBReverseProxy高速低速AとBからのデータをバランスよく返すWINDOW_UPDATEWINDOW_UPDATEサーバは、Window Size が０になったらデータ送信を停止Window Sizeを増加させるサーバA,B へのウィンドウサイズ更新を調整TCPコネクション、ストリーム毎にフロー制御が可能

プライオリティクライアントReverseProxyコンテンツHTML画像CSS, jsHTMLCSS JS画像１画像2 画像3 画像4依存性と重みを指定weight:16 weight:16プライオリティのユースケース• ファイルタイプ(HTML/CSS/JS/画像）に応じた返答順序の指定• タブ切り替えによる重みの上げ下げ• 分割されたビデオデータなど順番が明示的に決められている場合

サーバプッシュ機能コンテンツリクエストクライアントサーバ画像のHTTPリクエストを予約コンテンツのレスポンス画像データキャッシュサーバはコンテンツの中身を判断し，あらかじめコンテンツに含まれている画像のリクエストを予約する．予約された画像リクエストはクライアントからサーバに送らずに，クライアントはサーバ側からの画像データの送付を待つサーバから送信された画像データは，クライアントのキャッシュに保存

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の利用条件を制限すべきかどうか大きな議論になったが、新しいプロトコルはよりセキュアな状態で提供すべきとの意見で合意

演習4.1: nginx を http2対応にするserver {listen 443 ssl http2;・・・・}わずかこれだけ

しかしエラーでつながりませんセキュリティが十分でない

比べて見よう Cipher Listnginxのデフォルト設定はサーバ側のリストを優先に選択Chromeの Cipher Listnginxの Cipher ListサーバはECDHE_RSA_WITH_AES_256_CBC_SHAを選択→AEAD(GCM)じゃないのでHTTP/２の条件外RSA認証でサーバリストの上から合うのを探していくと

もう一度HTTP/2のTLS条件を思い出せ！• 長 (DHE 2048bit以上、ECDHE 224bit以上)サポート必須 • PFS必須 (DHE, ECDHE)• AEAD(GCM/CCM)以外の暗号方式をブラックリストとして利用禁止(注: openssl-1.0.2以上限定です)これならいけるはず

演習4.2:nginxでHTTP/2サーバを作るHTTP/2のTLS接続条件クリアHTTP/2WiresharkでTLSハンドシェイクを取得Client/ServerHello のALPN Extension を確認する

演習5: HTTP HoLを再現させる$ git clone https://github.com/shigeki/seccamp-imageserver/$ cd seccamp-imageserver/lib~/seccamp-imageserver/lib$ node ./server.jsLitening on port 8080location / {root /home/seccamp/seccamp-imageserver/html;index index.html index.htm;}location /images {proxy_pass http://localhost:8080;}nginx.confの変更imageサーバを立ち上げすぐ返す３秒後返す

HTTP/1.1の表示Head ofLine Blocking泣き顔画像がブロック

HTTP/2の表示泣き顔画像がブロックしないface-xx.pngの数字が３で割り切れると泣き顔表示自分でHTMLを変更して画像数を変えて比較してみよう

Movatterモバイル変換

Change Language

TLS, HTTP/2演習

Embed presentation

Recommended

More Related Content

What's hot

Viewers also liked

Similar to TLS, HTTP/2演習

More from shigeki_ohtsu

TLS, HTTP/2演習