本文是對(duì)HTTP—TCP/IP—SOCKET理解及淺析的補(bǔ)充延塑，如有需要音诈，請(qǐng)查看上篇文章幻碱。

SSL與TLS

2345678.jpeg

SSL協(xié)議由Netscape公司開(kāi)發(fā)，歷史可以追溯到Netscape Navigator瀏覽器統(tǒng)治互聯(lián)網(wǎng)的時(shí)代细溅。

1996年5月褥傍， TLS工作組成立，開(kāi)始將SSL從Netscape遷移至IETF喇聊。由于Microsoft和Netscape當(dāng)時(shí)正在為Web的統(tǒng)治權(quán)爭(zhēng)得不可開(kāi)交恍风，整個(gè)遷移過(guò)程進(jìn)行得非常緩慢、艱難誓篱。最終朋贬， TLS 1.0于1999年1月問(wèn)世，見(jiàn)RFC 2246燕鸽。

盡管與SSL 3相比兄世，版本修改并不大啼辣，但是為了取悅Microsoft啊研，協(xié)議還是進(jìn)行了更名??。

2006年4月鸥拧，下一個(gè)版本TLS 1.1才問(wèn)世党远，僅僅修復(fù)了一些關(guān)鍵的安全問(wèn)題。然而富弦，協(xié)議的重要更改是作為TLS擴(kuò)展于2003年6月發(fā)布的沟娱，并被集成到了協(xié)議中，這比大家的預(yù)期早了好幾年腕柜。
2008年8月济似， TLS 1.2發(fā)布。該版本添加了對(duì)已驗(yàn)證加密的支持盏缤，并且基本上刪除了協(xié)議說(shuō)明中所有硬編碼的安全基元砰蠢，使協(xié)議完全彈性化。

SSL和TLS都是加密協(xié)議唉铜，旨在基于不安全的基礎(chǔ)設(shè)施提供安全通信台舱。

這意味著，如果正確部署這些協(xié)議潭流，你就可以對(duì)互聯(lián)網(wǎng)上的任意一個(gè)服務(wù)打開(kāi)通信信道竞惋，并且可以確信你會(huì)與正確的服務(wù)器通信柜去，安全地交換信息（你的數(shù)據(jù)不會(huì)被他人截取，而且在接收時(shí)會(huì)保持原樣）拆宛。這些協(xié)議保護(hù)著通信鏈路即傳輸層嗓奢，這也是TLS名稱的由來(lái)。
安全不是TLS的唯一目標(biāo)浑厚。 TLS實(shí)際上有以下四個(gè)主要目標(biāo)（按優(yōu)先順序排列）蔓罚。

• 加密安全
  這是主要問(wèn)題：為任意愿意交換信息的雙方啟用安全通信。
• 互操作性
  獨(dú)立的編程人員應(yīng)該能夠使用通用的加密參數(shù)開(kāi)發(fā)程序和庫(kù)瞻颂，使它們可以相互通信豺谈。
• 可擴(kuò)展性
  你很快就會(huì)看到， TLS是一種能高效開(kāi)發(fā)和部署加密協(xié)議的框架贡这。其重要目標(biāo)是獨(dú)立于實(shí)
  際使用的加密基元（例如密碼和散列函數(shù)）茬末，從而不需要?jiǎng)?chuàng)建新的協(xié)議，就允許從一個(gè)基
  元遷移到另一個(gè)盖矫。
• 效率
  最終的目標(biāo)是在實(shí)現(xiàn)上述所有目標(biāo)的基礎(chǔ)上保持性能成本在可接受的范圍內(nèi)丽惭。這需要盡
  量減少昂貴的加密操作的執(zhí)行次數(shù)，并提供一個(gè)會(huì)話緩存方案辈双，以避免這些加密操作在
  隨后的連接中被執(zhí)行责掏。

互聯(lián)網(wǎng)的核心是建立在IP（ internet protocol）和TCP（ transmission control protocol）協(xié)議之上的，這些協(xié)議用于將數(shù)據(jù)分割成小數(shù)據(jù)包進(jìn)行傳輸湃望。IP和TCP不是唯一易受攻擊的協(xié)議换衬，還有一系列其他路由協(xié)議用于協(xié)助發(fā)現(xiàn)網(wǎng)絡(luò)上的其他計(jì)算機(jī)。

如果部署了加密证芭，攻擊者也許有能力得到加密數(shù)據(jù)的訪問(wèn)權(quán)限瞳浦，但是不能解密數(shù)據(jù)或者篡改數(shù)據(jù)。為了避免偽裝攻擊废士， SSL和TLS依賴另外一項(xiàng)被稱為公鑰基礎(chǔ)設(shè)施（ public key infrastructure叫潦，PKI）的重要技術(shù)，確保將流量發(fā)送到正確的接收端官硝。

為了理解SSL和TLS的運(yùn)作矗蕊，我們需要從描述網(wǎng)絡(luò)通信的理論模型入手，即開(kāi)放系統(tǒng)互聯(lián)（ open systems interconnection氢架， OSI）模型傻咖，參見(jiàn)表1-1。簡(jiǎn)單來(lái)說(shuō)达箍，所有功能都被映射到七個(gè)層上没龙。最底層是最接近物理通信鏈路的層，后面的層依次建立在其他層之上，提供更高級(jí)別的抽象硬纤。最頂層就是應(yīng)用層解滓，攜帶著應(yīng)用數(shù)據(jù)。

pic_002.png

以這種方式安排通信可以清晰地劃分概念：高層的協(xié)議不必?fù)?dān)心在底層實(shí)現(xiàn)的功能筝家。進(jìn)一步說(shuō)洼裤，不同層次的協(xié)議可以加入通信或者從通信中刪除，一種底層協(xié)議可以服務(wù)于多種上層協(xié)議SSL和TLS是這一原則如何在實(shí)踐中運(yùn)用的一個(gè)重要示例溪王。它用于TCP協(xié)議之上腮鞍，上層協(xié)議（如HTTP）之下。當(dāng)不需要加密時(shí)莹菱，可以將TLS從模型中去掉移国，這并不會(huì)對(duì)上層協(xié)議產(chǎn)生影響（它們將直接與TCP協(xié)同工作）。當(dāng)需要加密時(shí)道伟，就可以利用TLS加密HTTP迹缀，以及其他TCP協(xié)議（比如SMTP、 IMAP等）蜜徽。

TLS中的握手協(xié)議

握手是TLS協(xié)議中最精密復(fù)雜的部分祝懂。在這個(gè)過(guò)程中，通信雙方協(xié)商連接參數(shù)拘鞋，并且完成身份驗(yàn)證砚蓬。根據(jù)使用的功能的不同，整個(gè)過(guò)程通常需要交換6~10條消息盆色。根據(jù)配置和支持的協(xié)議擴(kuò)展的不同灰蛙，交換過(guò)程可能有許多變種。

在使用中經(jīng)掣凳拢可以觀察到以下三種流程：

• (1) 完整的握手缕允，對(duì)服務(wù)器進(jìn)行身份驗(yàn)證；

• (2) 恢復(fù)之前的會(huì)話采用的簡(jiǎn)短握手蹭越；

• (3) 對(duì)客戶端和服務(wù)器都進(jìn)行身份驗(yàn)證的握手。

  握手協(xié)議消息的標(biāo)頭信息包含消息類型（ 1字節(jié)）和長(zhǎng)度（ 3字節(jié)）教届，余下的信息則取決于消息類型：

struct {
    HandshakeType msg_type;
    uint24 length;
    HandshakeMessage message;
} Handshake;

2.2.1 完整的握手
每一個(gè)TLS連接都會(huì)以握手開(kāi)始响鹃。如果客戶端此前并未與服務(wù)器建立會(huì)話，那么雙方會(huì)執(zhí)行一次完整的握手流程來(lái)協(xié)商TLS會(huì)話案训。握手過(guò)程中买置，客戶端和服務(wù)器將進(jìn)行以下四個(gè)主要步驟。

• (1) 交換各自支持的功能强霎，對(duì)需要的連接參數(shù)達(dá)成一致忿项。
• (2) 驗(yàn)證出示的證書(shū)，或使用其他方式進(jìn)行身份驗(yàn)證。
• (3) 對(duì)將用于保護(hù)會(huì)話的共享主密鑰達(dá)成一致轩触。
• (4) 驗(yàn)證握手消息并未被第三方團(tuán)體修改寞酿。

在實(shí)際使用中，第2步和第3步都是密鑰交換（更通用的說(shuō)法是密鑰生成）的一部分脱柱，
密鑰交換是一個(gè)單獨(dú)的步驟伐弹。我更喜歡將它們分開(kāi)來(lái)說(shuō)，用以強(qiáng)調(diào)協(xié)議的安全性取決
于正確的身份驗(yàn)證榨为。身份驗(yàn)證有效地在TLS的外層工作惨好。如果沒(méi)有身份驗(yàn)證，主動(dòng)攻
擊者就可以將自身嵌入會(huì)話随闺，并冒充會(huì)話的另一端日川。

本節(jié)會(huì)討論最常見(jiàn)的TLS握手流程，就是一種在不需要身份驗(yàn)證的客戶端與需要身份驗(yàn)證的服務(wù)器之間的握手矩乐，如圖2-2所示逗鸣。

009876_003.png

• (1) 客戶端開(kāi)始新的握手，并將自身支持的功能提交給服務(wù)器绰精。

• (2) 服務(wù)器選擇連接參數(shù)撒璧。

• (3) 服務(wù)器發(fā)送其證書(shū)鏈（僅當(dāng)需要服務(wù)器身份驗(yàn)證時(shí)）。

• (4) 根據(jù)選擇的密鑰交換方式笨使，服務(wù)器發(fā)送生成主密鑰的額外信息卿樱。

• (5) 服務(wù)器通知自己完成了協(xié)商過(guò)程。

• (6) 客戶端發(fā)送生成主密鑰所需的額外信息硫椰。

• (7) 客戶端切換加密方式并通知服務(wù)器繁调。

• (8) 客戶端計(jì)算發(fā)送和接收到的握手消息的MAC并發(fā)送。

• (9) 服務(wù)器切換加密方式并通知客戶端靶草。

• (10) 服務(wù)器計(jì)算發(fā)送和接收到的握手消息的MAC并發(fā)送蹄胰。

  假設(shè)沒(méi)有出現(xiàn)錯(cuò)誤，到這一步奕翔，連接就建立起來(lái)了裕寨，可以開(kāi)始發(fā)送應(yīng)用數(shù)據(jù)。現(xiàn)在讓我們了
  解一下這些握手消息的更多細(xì)節(jié)派继。

1. ClientHello
   在一次新的握手流程中宾袜， ClientHello消息總是第一條消息。這條消息將客戶端的功能和首選項(xiàng)傳送給服務(wù)器驾窟∏烀ǎ客戶端會(huì)在新建連接后，希望重新協(xié)商或者響應(yīng)服務(wù)器發(fā)起的重新協(xié)商請(qǐng)求（由HelloRequest消息指示）時(shí)绅络，發(fā)送這條消息月培。在下面的例子中嘁字，你可以觀察到ClientHello消息。為了更簡(jiǎn)潔杉畜，我減少了一些信息展示纪蜒，但是包含了所有的關(guān)鍵元素。

Handshake protocol: ClientHello
    Version: TLS 1.2
    Random
        Client time: May 22, 2030 02:43:46 GMT
        Random bytes: b76b0e61829557eb4c611adfd2d36eb232dc1332fe29802e321ee871
    Session ID: (empty)
    Cipher Suites
        Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
        Suite: TLS_RSA_WITH_AES_128_GCM_SHA256
        Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
        Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA
        Suite: TLS_RSA_WITH_AES_128_CBC_SHA
        Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA
        Suite: TLS_RSA_WITH_RC4_128_SHA
    Compression methods
        Method: null
    Extensions
        Extension: server_name
            Hostname: www.feistyduck.com
        Extension: renegotiation_info
        Extension: elliptic_curves
            Named curve: secp256r1
            Named curve: secp384r1
        Extension: signature_algorithms
            Algorithm: sha1/rsa
            Algorithm: sha256/rsa
            Algorithm: sha1/ecdsa
            Algorithm: sha256/ecdsa

可以看到寻行，絕大多數(shù)消息字段光看名稱就很容易理解霍掺，而且消息的結(jié)構(gòu)也很容易理解。

• Version
  協(xié)議版本（ protocol version）指示客戶端支持的最佳協(xié)議版本拌蜘。
• Random
  隨機(jī)數(shù)（ random）字段包含32字節(jié)的 數(shù)據(jù)杆烁。當(dāng)然，只有28字節(jié)是隨機(jī)生成的简卧；剩余的4字節(jié)包含額外的信息兔魂，受客戶端時(shí)鐘的影響。準(zhǔn)確來(lái)說(shuō)举娩，客戶端時(shí)間與協(xié)議不相關(guān)析校，而且協(xié)議規(guī)格文檔中言及此事時(shí)也很清楚（“基本的TLS協(xié)議不需要正確設(shè)置時(shí)鐘，更高層或應(yīng)用協(xié)議可以定義額外的需求項(xiàng)铜涉≈遣＃”）；該字段是1994年在Netscape Navigator中發(fā)現(xiàn)了一個(gè)嚴(yán)重故障之后芙代，為了防御弱隨機(jī)數(shù)生成器而引入的吊奢。盡管這個(gè)字段曾經(jīng)一直含有精確時(shí)間的部分，但現(xiàn)在仍然有人擔(dān)心客戶端時(shí)間可能被用于大規(guī)模瀏覽器指紋采集纹烹，所以一些瀏覽器會(huì)給它們的時(shí)間添加時(shí)鐘扭曲（正如你在示例中所看到的那樣）页滚，或者簡(jiǎn)單地發(fā)送隨機(jī)的4字節(jié)。在握手時(shí)铺呵，客戶端和服務(wù)器都會(huì)提供隨機(jī)數(shù)裹驰。這種隨機(jī)性對(duì)每次握手都是獨(dú)一無(wú)二的，在身份驗(yàn)證中起著舉足輕重的作用片挂。它可以防止重放攻擊幻林，并確認(rèn)初始數(shù)據(jù)交換的完整性。
• Session ID
  在第一次連接時(shí)宴卖，會(huì)話ID（ session ID）字段是空的滋将，這表示客戶端并不希望恢復(fù)某個(gè)已存在的會(huì)話。在后續(xù)的連接中症昏，這個(gè)字段可以保存會(huì)話的唯一標(biāo)識(shí)。服務(wù)器可以借助會(huì)話ID在自己的緩存中找到對(duì)應(yīng)的會(huì)話狀態(tài)父丰。典型的會(huì)話ID包含32字節(jié)隨機(jī)生成的數(shù)據(jù)肝谭，這些數(shù)據(jù)本身并沒(méi)有什么價(jià)值掘宪。
• Cipher Suites
  密碼套件（ cipher suite）塊是由客戶端支持的所有密碼套件組成的列表，該列表是按優(yōu)先級(jí)順序排列的攘烛。
• Compression
  客戶端可以提交一個(gè)或多個(gè)支持壓縮的方法魏滚。默認(rèn)的壓縮方法是null，代表沒(méi)有壓縮坟漱。
• Extensions
  擴(kuò)展（ extension）塊由任意數(shù)量的擴(kuò)展組成鼠次。這些擴(kuò)展會(huì)攜帶額外數(shù)據(jù)。我會(huì)在本章后面對(duì)最常見(jiàn)的擴(kuò)展進(jìn)行討論芋齿。

2. ServerHello
   ServerHello消息的意義是將服務(wù)器選擇的連接參數(shù)傳送回客戶端腥寇。這個(gè)消息的結(jié)構(gòu)與ClientHello類似，只是每個(gè)字段只包含一個(gè)選項(xiàng)觅捆。

Handshake protocol: ServerHello
    Version: TLS 1.2
    Random
        Server time: Mar 10, 2059 02:35:57 GMT
        Random bytes: 8469b09b480c1978182ce1b59290487609f41132312ca22aacaf5012
    Session ID: 4cae75c91cf5adf55f93c9fb5dd36d19903b1182029af3d527b7a42ef1c32c80
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    Compression method: null
    Extensions
        Extension: server_name
        Extension: renegotiation_info

服務(wù)器無(wú)需支持客戶端支持的最佳版本赦役。如果服務(wù)器不支持與客戶端相同的版本，可以提供某個(gè)其他版本以期待客戶端能夠接受栅炒。

3. Certificate
   典型的Certificate消息用于攜帶服務(wù)器X.509證書(shū)鏈掂摔。<u>證書(shū)鏈?zhǔn)且訟SN.1 DER編碼的一系列證書(shū)，一個(gè)接著一個(gè)組合而成赢赊。</u>主證書(shū)必須第一個(gè)發(fā)送乙漓，中間證書(shū)按照正確的順序跟在主證書(shū)之后。根證書(shū)可以并且應(yīng)該省略掉释移，因?yàn)樵谶@個(gè)場(chǎng)景中它沒(méi)有用處叭披。服務(wù)器必須保證它發(fā)送的證書(shū)與選擇的算法套件一致。

比方說(shuō)秀鞭，公鑰算法與套件中使用的必須匹配趋观。除此以外，一些密鑰交換算法依賴嵌入證書(shū)的特定數(shù)據(jù)锋边，而且要求證書(shū)必須以客戶端支持的算法簽名皱坛。所有這些都表明服務(wù)器需要配置多個(gè)證書(shū)（每個(gè)證書(shū)可能會(huì)配備不同的證書(shū)鏈，Certificate消息是可選的豆巨，因?yàn)椴⒎撬刑准际褂蒙矸蒡?yàn)證剩辟，也并非所有身份驗(yàn)證方法都需要證書(shū)。

更進(jìn)一步說(shuō)往扔，雖然消息默認(rèn)使用X.509證書(shū)贩猎，但是也可以攜帶其他形式的標(biāo)志；一些套件就依賴PGP密鑰萍膛。

4. ServerKeyExchange
   ServerKeyExchange消息的目的是攜帶密鑰交換的額外數(shù)據(jù)吭服。消息內(nèi)容對(duì)于不同的協(xié)商算法套件都會(huì)存在差異。在某些場(chǎng)景中蝗罗，服務(wù)器不需要發(fā)送任何內(nèi)容艇棕，這意味著在這些場(chǎng)景中根本不會(huì)發(fā)送ServerKeyExchange消息蝌戒。

5. ServerHelloDone
   ServerHelloDone消息表明服務(wù)器已經(jīng)將所有預(yù)計(jì)的握手消息發(fā)送完畢。在此之后沼琉，服務(wù)器會(huì)等待客戶端發(fā)送消息北苟。

6. ClientKeyExchange
   ClientKeyExchange消息攜帶客戶端為密鑰交換提供的所有信息。這個(gè)消息受協(xié)商的密碼套件的影響打瘪，內(nèi)容隨著不同的協(xié)商密碼套件而不同友鼻。

7. ChangeCipherSpec
   ChangeCipherSpec消息表明發(fā)送端已取得用以生成連接參數(shù)的足夠信息，已生成加密密鑰闺骚，并且將切換到加密模式彩扔。客戶端和服務(wù)器在條件成熟時(shí)都會(huì)發(fā)送這個(gè)消息葛碧。

注意ChangeCipherSpec不屬于握手消息借杰，它是另一種協(xié)議，只有一條消息进泼，作為它的子協(xié)議進(jìn)行實(shí)現(xiàn)蔗衡。這個(gè)設(shè)計(jì)的結(jié)果是這條消息不是握手完整性驗(yàn)證算法的一部分，這使得正確實(shí)現(xiàn)TLS更為困難乳绕。

在2014年6月绞惦，人們發(fā)現(xiàn)OpenSSL對(duì)于ChangeCipherSpec消息的處理不正確，使得OpenSSL為主動(dòng)網(wǎng)絡(luò)攻擊敞開(kāi)了大門洋措。同樣的問(wèn)題也出現(xiàn)在其他所有子協(xié)議中济蝉。主動(dòng)網(wǎng)絡(luò)攻擊者利用緩沖機(jī)制在首次握手時(shí)發(fā)送未經(jīng)驗(yàn)證的警報(bào)消息，更可以在開(kāi)始加密以后破環(huán)真正的警報(bào)消息菠发。為了避免更嚴(yán)重的問(wèn)題王滤，應(yīng)用數(shù)據(jù)協(xié)議消息必須等到首次握手完成以后才能開(kāi)始發(fā)送。

8. Finished
   Finished消息意味著握手已經(jīng)完成滓鸠。消息內(nèi)容將加密雁乡，以便雙方可以安全地交換驗(yàn)證整個(gè)握手完整性所需的數(shù)據(jù)。這個(gè)消息包含verify_data字段糜俗，它的值是握手過(guò)程中所有消息的散列值踱稍。

這些消息在連接兩端都按照各自所見(jiàn)的順序排列，并以協(xié)商新得到的主密鑰計(jì)算散列悠抹。這個(gè)過(guò)程是通過(guò)一個(gè)偽隨機(jī)函數(shù)（ pseudorandom function珠月， PRF）來(lái)完成的，這個(gè)函數(shù)可以生成任意數(shù)量的偽隨機(jī)數(shù)據(jù)楔敌。我將在本章的后續(xù)部分中對(duì)其進(jìn)行介紹啤挎。散列函數(shù)與PRF一致，除非協(xié)商的套件指定使用其他算法卵凑。

兩端的計(jì)算方法一致侵浸，但會(huì)使用不同的標(biāo)簽：客戶端使用client finished旺韭，而服務(wù)器則使用serverfinished氛谜。verify_data = PRF(master_secret, finished_label, Hash(handshake_messages))

因?yàn)镕inished消息是加密的掏觉，并且它們的完整性由協(xié)商MAC算法保證，所以主動(dòng)網(wǎng)絡(luò)攻擊者不能改變握手消息并對(duì)vertify_data的值造假值漫。
理論上攻擊者也可以嘗試找到一組偽造的握手消息澳腹，得到的值與真正消息計(jì)算出的verity_data的值完全一致。這種攻擊本身就非常不容易杨何，而且因?yàn)樯⒘兄谢烊肓酥髅荑€（攻擊者不知道主密鑰）酱塔，所以攻擊者根本不會(huì)嘗試。

在TLS 1.2版本中危虱， Finished消息的長(zhǎng)度默認(rèn)是12字節(jié)（ 96位）羊娃，并且允許密碼套件使用更長(zhǎng)的
長(zhǎng)度。在此之前的版本埃跷，除了SSL 3使用36字節(jié)的定長(zhǎng)消息蕊玷，其他版本都使用12字節(jié)的定長(zhǎng)消息。

客戶端身份驗(yàn)證

盡管可以選擇對(duì)任意一端進(jìn)行身份驗(yàn)證弥雹，但人們幾乎都啟用了對(duì)服務(wù)器的身份驗(yàn)證垃帅。

如果服務(wù)器選擇的套件不是匿名的，那么就需要在Certificate消息中跟上自己的證書(shū)剪勿。相比之下贸诚，服務(wù)器通過(guò)發(fā)送CertificateRequest消息請(qǐng)求對(duì)客戶端進(jìn)行身份驗(yàn)證。消息中列出所有可接受的客戶端證書(shū)厕吉。作為響應(yīng)酱固，客戶端發(fā)送自己的Certificate消息（使用與服務(wù)器發(fā)送證書(shū)相同的格式），并附上證書(shū)头朱。此后运悲，客戶端發(fā)CertificateVerify消息，證明自己擁有對(duì)應(yīng)的私鑰髓窜。

完整的握手如圖2-3所示扇苞。

096534234004.png

只有已經(jīng)過(guò)身份驗(yàn)證的服務(wù)器才被允許請(qǐng)求客戶端身份驗(yàn)證〖淖荩基于這個(gè)原因鳖敷，這個(gè)選項(xiàng)被稱
為相互身份驗(yàn)證（ mutual authentication）。

1. CertificateRequest
   服務(wù)器使用CertificateRequest消息請(qǐng)求對(duì)客戶端進(jìn)行身份驗(yàn)證程拭，并將其接受的證書(shū)的公鑰和簽名算法傳送給客戶端定踱。它也可以選擇發(fā)送一份自己接受的證書(shū)頒發(fā)機(jī)構(gòu)列表，這些機(jī)構(gòu)都用其可分辨名稱來(lái)表示：

struct {
  ClientCertificateType certificate_types;
  SignatureAndHashAlgorithm supported_signature_algorithms;
  DistinguishedName certificate_authorities;
} CertificateRequest;

2. CertificateVerify
   客戶端使用CertificateVerify消息證明自己擁有的私鑰與之前發(fā)送的客戶端證書(shū)中的公鑰相對(duì)應(yīng)恃鞋。消息中包含一條到這一步為止的所有握手消息的簽名：

struct {
  Signature handshake_messages_signature;
} CertificateVerify;

會(huì)話恢復(fù)

完整的握手協(xié)議非常復(fù)雜崖媚，需要很多握手消息和兩次網(wǎng)絡(luò)往返才能開(kāi)始發(fā)送客戶端應(yīng)用數(shù)
據(jù)亦歉。此外，握手執(zhí)行的密鑰學(xué)操作通常需要密集的CPU處理畅哑。身份驗(yàn)證通常以客戶端和服務(wù)器證
書(shū)驗(yàn)證（以及證書(shū)吊銷檢查）的形式完成肴楷，需要更多的工作。這其中的許多消耗都可以通過(guò)簡(jiǎn)短
握手的方式節(jié)約下來(lái)荠呐。

9087865_005.png

最初的會(huì)話恢復(fù)機(jī)制是赛蔫，在一次完整協(xié)商的連接斷開(kāi)時(shí)，客戶端和服務(wù)器都會(huì)將會(huì)話的安全參數(shù)保存一段時(shí)間泥张。

希望使用會(huì)話恢復(fù)的服務(wù)器為會(huì)話指定唯一的標(biāo)識(shí)呵恢，稱為會(huì)話ID。服務(wù)器在 ServerHello消息中將會(huì)話ID發(fā)回客戶端（請(qǐng)參見(jiàn)2.2.2節(jié)中的示例）媚创。

希望恢復(fù)早先會(huì)話的客戶端將適當(dāng)?shù)臅?huì)話ID放入ClientHello消息渗钉，然后提交。服務(wù)器如果 愿意恢復(fù)會(huì)話钞钙，就將相同的會(huì)話ID放入ServerHello消息返回鳄橘，接著使用之前協(xié)商的主密鑰生成 一套新的密鑰，再切換到加密模式歇竟，發(fā)送Finished消息挥唠。客戶端收到會(huì)話已恢復(fù)的消息以后焕议，也 進(jìn)行相同的操作宝磨。這樣的結(jié)果是握手只需要一次網(wǎng)絡(luò)往返。簡(jiǎn)短握手如圖2-4所示盅安。圖2-4 簡(jiǎn)短握手唤锉，用于恢復(fù)已經(jīng)建立的會(huì)話用來(lái)替代服務(wù)器會(huì)話緩存和恢復(fù)的方案是使用會(huì)話票證（ sesession ticket）。它是2006年引入 的（參見(jiàn)RFC 4507）别瞭，隨后在2008年進(jìn)行了更新（參見(jiàn)RFC 5077）窿祥。使用這種方式，除了所有的狀態(tài)都保持在客戶端（與HTTP Cookie的原理類似）之外蝙寨，其消息流與服務(wù)器會(huì)話緩存是一樣的晒衩。

此文為18年讀《HTTPS權(quán)威指南》記錄內(nèi)容。如有錯(cuò)誤墙歪，請(qǐng)批評(píng)指正听系。