《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 = 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將收到日誌服務器的提交證實，並中繼給最終用戶
      • 橢圓曲線功能
        • 如今只有兩種曲線獲得普遍支持：secp256r一、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）
        • 引入一種新的會話恢復機制，不須要任何服務器端存儲
        • 服務器取出全部的會話狀態並進行加密，再以票證的方式發回客戶端
        • 在接下來的鏈接中，客戶端發回票證，服務器檢查票證完整性，解密其內容並恢復會話