《HTTPS權威指南》讀書筆記——SSL/TLS協議

• 記錄協議（record protocol）
  • 負責在傳輸連接上交換所有底層資訊
  • 每一條記錄以短標頭開始，標頭包含記錄內容的型別、協議版本和長度
• 握手協議（handshake protocol）
  • 整個程序通常需要6——10個訊息
  • 交換程序有許多變種
    1. 完整的握手，對服務器身份進行驗證
    2. 恢復之前會話采用的簡短握手
    3. 對客戶端和服務器都進行身份驗證的握手
  • 完整的握手
    • 交換各自支持的功能，對需要的連接引數達成一致
    • 驗證出示的證書，或使用其他方式進行身份驗證
    • 對將用于保護會話的共享主密鑰達成一致
    • 驗證握手訊息并未被第三方團體修改
    • 細節：
      • Clienthello：發送客戶端的功能和首選項給服務器，在連接建立后，當希望重協商、或者回應服務器的重協商請求時會發送，
        • version：客戶端支持的最佳協議版本
        • Random：共32位元組，28位元組亂數，4位元組額外資訊，受客戶端時鐘影響（為了避免瀏覽器指紋采集，現在一般會對4位元組時鐘做扭曲）
        • Session ID：32位元組亂數，用于和服務器重建會話，為空表示新建會話
        • cipher suit：客戶端支持的所有密碼套件，按優先級排列
        • Compression：客戶端支持的壓縮演算法，默認無壓縮
        • Extensions：由任意數量的擴展組成，攜帶額外資料
      • ServerHello：
        • 選擇客戶端提供的引數反饋客戶端
        • 服務器無需支持客戶端支持的最佳版本，如果服務器不支持客戶端版本，可以提供其他版本以期待客戶端可以接受
      • Certificate：
        • 用于攜帶服務器X.509證書鏈
        • 主證書必須第一個發送，中間證書按照正確的順序跟在主證書之后
        • 服務器必須保證發送的證書和選擇的演算法套件一致
        • Certificate訊息時可選的
      • ServerKeyExchange: 攜帶密鑰交換的額外資料，取決于加密套件
      • ServerHelloDone：服務器已將所有預計的握手訊息發送完畢
      • ClientkeyExchange：攜帶客戶端為密鑰交換提供的資訊
      • ChangeCipherSpec：發送端已取得用以連接引數的足夠的資訊
      • Finish：握手完成，訊息內容加密，雙方可以交換驗證，整個握手完整性所需的資料
        • 演算法：verrify_data = https://www.cnblogs.com/yurang/p/PRF(master_secret , finished_label,hash(handshake_message))
  • 客戶端身份驗證
    • 只有已經經過身份驗證的服務器才允許請求客戶端身份驗證
    • CertificateRequest：服務器對客戶端進行身份驗證并將其接受的證書的公鑰和簽名演算法傳送給客戶端
    • CertificateVerrify：客戶端通過CertificateVerify訊息證明自己擁有的私鑰與之前發送的客戶端證書中的公鑰相對應（訊息中包含到這一步為止所有握手訊息的簽名）
  • 會話恢復
    • 希望恢復早先會話的客戶端將適當的會話ID放入ClientHello訊息，如果服務器愿意回復，則會將相同的會話ID放入到ServerHello訊息中回傳，接著使用先前協商的主密鑰生成一套新的密鑰，再切換到加密模式，發送Finished訊息
  • 密鑰交換
    • 會話安全性取決于主密鑰（mater secret，48位元組的共享密鑰），密鑰交換用于計算預主密鑰（premaster secret），預主密鑰是主密鑰的來源
    • RSA：不支持前向保密（forward secrecy），客戶端生成預主密鑰，通過服務器公鑰加密傳遞給服務器
    • DHE_RSA:臨時DH演算法，優點是支持前向保密，缺點是執行緩慢
    • ECDHE_RSA和ECDHE_ECDSA:臨時橢圓曲線
    • RSA密鑰交換：
      • 客戶端生成預主密鑰（46位元組亂數），使用服務器公鑰加密，將其包含在ClientKeyExchange中，服務器通過私鑰解密，然后提取生成主密鑰
      • 一旦服務器私鑰被攻破，基于RSA的安全性將不復存在
    • Diffie-Hellman交換：
      • DH密鑰交換需要6個引數：兩個域引數（dh_p dh_g）由服務器選取；協商程序中客戶端和服務器各自生成另外兩個引數，相互發送一個引數到對端，經過結合計算，得到共享密鑰
    • 橢圓曲線DH密鑰交換（ECDH）：
      • 基于橢圓曲線（elliptic curve），代替了域引數的角色
  • 身份驗證
    • 為了避免重復執行密碼操作造成的巨大開銷，身份驗證與密鑰交換緊緊捆綁在一起
    • 在RSA中，客戶端生成隨機值作為預主密鑰，使用服務器公鑰加密傳遞給服務器
    • 在DHE和ECDH中，服務器使用私鑰簽名引數，客戶端用公鑰解密
  • 加密
    • 序列加密：
      • 計算MAC值：包含記錄序列號（防重放）、標頭（防止未加密的標頭被篡改）、明文
      • 加密明文和MAC
    • 分組加密：
      • 計算序列號、標頭、明文MAC
      • 構造填充，確認加密前的資料長度正好是分組大小
      • 生成與分組長度一致的IV
    • 已驗證的加密：
      • 使用關聯資料的已驗證加密（AEAD）
      • 生成一個唯一的64位nonce
      • 使用已驗證加密演算法加密明文，同時也將序列號和記錄標頭作為完整性驗證依據的額外資料交給演算法
      • 將nonce和密文一起發送
  • 重協商
    • 客戶端證書：使用場景為，網站根路徑不需要進行客戶端證書驗證，某個子域需要，當客戶打算瀏覽子區域時，服務器發起重協商請求，
    • 隱藏訊息： 如上場景中的重協商是在加密中進行的，避免了協商被監聽，泄露客戶端身份，Tor就是用這種方式進行重協商的
    • 改變加密級別
    • 協議允許客戶端在任意時間簡單的發送ClientHello訊息請求重協商，如果服務器希望重協商，會發送HelloRequest
  • 警報協議
    • alert level表示警報嚴重程度：可取值warning和fatal
    • 嚴重程度為fatal的訊息會立即終止當前連接并使會話失效
    • 發送告警通知的一端不會主動終止連接，而是交由接收端通過發送它自己的嚴重警報對該警告自行作出反應
  • 關閉連接
    • 關閉連接警告用于以有序的方式關閉TLS連接
    • 一旦一端決定關閉連接，會發送一個close_notify警報，另一端收到后，會丟棄任何還未寫出的資料，并發送自己的 close_notify,在此之后收到的訊息都被丟棄
  • 密碼操作
    • 偽亂數（pseudorandom function，PRF）
      • 使用一條秘密、一顆種子、一個唯一標簽
    • 主密鑰
      • master_secret = PBR（pre_master_secret,'master secret',clienthello.random,serverHello.random）
      • 使用不同的密鑰交換得到的預主密鑰長度不同
      • 使用客戶端和服務器亂數作為種子，所以主密鑰是隨機的，且和協商握手系結
    • 密鑰生成
      • key_block = PRF(master_secret, "key expansion",server_random + client_random)
      • 共六個密鑰，兩個MAC密鑰、兩個加密密鑰、兩個初始化向量
      • 恢復會話使用的是之前的主密鑰，但是由于亂數不同，因此生成的密鑰也不同
  • 密碼套件
    • 密碼套件的元素屬性：
      • 身份驗證方法
      • 密鑰交換方法
      • 加密演算法
      • 加密密鑰大小
      • 密碼模式
      • MAC演算法
      • PRF（只有TLS1.2一定使用，其他版本取決于各自協議）
      • 用于finished訊息的散列函式（TLS1.2）
      • verify_data結構的長度（TLS1.2）
  • 擴展（Extention）
    • 擴展以擴展塊的形式加在ClientHello和ServerHello的末尾
    • 擴展塊由所需的擴展一個個堆疊而成
    • 每個擴展頭是2位元組擴展型別（唯一標志），后接擴展資料
    • 擴展的格式和期望的行為由每個擴展位元組決定
    • 擴展通常用于通知支持某些新功能以及用于在握手階段傳遞所需的額外資料
    • 常見TLS擴展
      • 應用層協議協商（ALPN）
        • 在TLS連接上協商不同的應用層協議
        • 支持ALPN的客戶端在該欄位中提供自己支持的應用層協議串列給服務器，服務器回決定使用的協議并使用相同的擴展向客戶端通知其決定
      • 證書透明度（certificate transparency）
        • 通過保持所有公開的服務器的證書來改進互聯網PKI
        • CA將每一張證書都提交給一組公開的日志服務器，CA將收到日志服務器的提交證明，并中繼給最終用戶
      • 橢圓曲線功能
        • 現在只有兩種曲線得到廣泛支持：secp256r1、secp384r1
      • 心跳（heartbeat）
        • RFC 6520
        • 支持連接保活功能，檢測對端是否可用
        • 為TLS和DTLS發現路徑最大傳輸單元（PMTU）
        • 心跳的目標定位是DTLS，因其作業在不可依賴的協議上
        • 客戶端和服務器通過心跳擴展相互通告支持心跳
        • RFC只允許握手完成后發送心跳，但是，OpenSSL在TLS擴展交換完成以后就立即允許發送
      • 次協議協商
        • 客戶端通過一個新的握手訊息NextProtocol表明期望的應用層資訊
      • 安全重協商
        • 用以驗證重協商的雙方仍是之前完成握手的兩個團體
        • 開始通過擴展通告對方支持重協商
        • 后續通過提交先前握手資訊作為證明：客戶端以先前的Finished訊息作為verify_data，服務器發送客戶端的verrify_data+自己的verify_data
      • 服務器名稱指示（server name indication SNI）
        • 通過server_name擴展實作
        • 為客戶端提供機制，使得客戶端可以向服務器通告自己希望訪問的服務器名稱，服務器基于該擴展可以查詢到對應的證書資訊
        • 實作了一個IP地址可以部署多張證書
      • 會話票證（session ticket）
        • 引入一種新的會話恢復機制，不需要任何服務器端存盤
        • 服務器取出所有的會話狀態并進行加密，再以票證的方式發回客戶端
        • 在接下來的連接中，客戶端發回票證，服務器檢查票證完整性，解密其內容并恢復會話

標籤：其他

上一篇：《圖解密碼技術》閱讀筆記

下一篇：《HTTPS權威指南》讀書筆記——PKI