1.7　可信通信

比特幣、以太坊和超級(jí)賬本在建立網(wǎng)絡(luò)連接保證節(jié)點(diǎn)間可信通信時(shí)，都直接采用了傳輸層安全性（Transport Layer Security，TLS）協(xié)議，TLS協(xié)議的前身為安全套接字層（Secure Sockets Layer，SSL）協(xié)議，SSL協(xié)議最初由Netscape公司開發(fā)，是一種為網(wǎng)絡(luò)通信提供安全性及數(shù)據(jù)完整性的一種安全協(xié)議。SSL協(xié)議的擴(kuò)展版本TLS協(xié)議自從1999年發(fā)布以來(lái)已經(jīng)廣泛地應(yīng)用在瀏覽器、電子郵件等應(yīng)用中。并且，TLS協(xié)議經(jīng)過(guò)了大規(guī)模的驗(yàn)證，已經(jīng)成為了互聯(lián)網(wǎng)上保密通信的工業(yè)標(biāo)準(zhǔn)，可以說(shuō)是目前構(gòu)建區(qū)塊鏈網(wǎng)絡(luò)節(jié)點(diǎn)間可信通信的最佳選擇。

1.7.1　TLS協(xié)議

握手是TLS協(xié)議中最精密復(fù)雜的部分。在這個(gè)過(guò)程中，通信雙方協(xié)商連接參數(shù)，并完成身份驗(yàn)證。TLS協(xié)議在握手階段使用混合加密的方式建立安全信道。TLS協(xié)議可以通過(guò)未加密的信道進(jìn)行初始密鑰交換，一旦建立共享密鑰就可以使用對(duì)稱加密的方式確保通信安全，在這個(gè)過(guò)程中，每個(gè)加密方式、協(xié)議版本等都是可選的，均通過(guò)雙方協(xié)商進(jìn)行。

每一個(gè)TLS連接都會(huì)從握手開始，在握手過(guò)程中，客戶端和服務(wù)端將會(huì)進(jìn)行四個(gè)主要步驟。本節(jié)只討論常見(jiàn)的TLS協(xié)議握手過(guò)程，即不需要身份驗(yàn)證的客戶端與需要身份驗(yàn)證的服務(wù)端之間的握手。

下面通過(guò)客戶端（Client）如何向服務(wù)端（Server）建立連接來(lái)展示TLS協(xié)議的握手過(guò)程，整個(gè)過(guò)程如圖1-3所示。

第一步，客戶端以明文的形式發(fā)出請(qǐng)求消息（client_hello），這條消息將客戶端的功能和首選項(xiàng)發(fā)送給服務(wù)端，其中包含如下內(nèi)容。

? 客戶端生成的隨機(jī)數(shù)random_C。

? 客戶端支持的最高TLS協(xié)議版本。

? 客戶端支持的加密套件（Cipher Suites）。

? 客戶端支持的壓縮算法列表，默認(rèn)值是null，代表沒(méi)有壓縮。

? 擴(kuò)展字段，可能會(huì)攜帶額外的數(shù)據(jù)。

? 加密套件包括身份驗(yàn)證算法Au、采用的密鑰交換算法（用于密鑰協(xié)商）、對(duì)稱加密算法和消息摘要算法（校驗(yàn)消息的完整性）。

第二步，服務(wù)端收到客戶端發(fā)來(lái)的請(qǐng)求消息以后，返回協(xié)商消息（server_hello），server_hello消息的意義在于將選擇的連接參數(shù)傳遞回客戶端。這條消息的結(jié)構(gòu)與client_hello消息類似，其中包括如下內(nèi)容。

? 服務(wù)端生成的隨機(jī)數(shù)random_S。

? 服務(wù)端使用的TLS協(xié)議的版本。

? 服務(wù)端選擇使用的壓縮算法版本。

? 服務(wù)端選擇的加密套件（Cipher Suites）。

? 服務(wù)端配置的對(duì)應(yīng)的證書鏈（可選）。

第三步，客戶端收到服務(wù)端發(fā)來(lái)的協(xié)商消息以后，會(huì)向服務(wù)端發(fā)送client_key_exchange消息。這條消息的意義在于設(shè)置預(yù)主密鑰，通過(guò)傳遞密鑰協(xié)商算法所需的參數(shù)來(lái)允許雙方協(xié)商出一致的預(yù)主密鑰。當(dāng)服務(wù)端收到server_hello消息后，首先會(huì)檢查服務(wù)端證書的合法性，如果合法就會(huì)進(jìn)行如下操作。

? 客戶端生成預(yù)主密鑰（Pre-Master）。

? 計(jì)算最終對(duì)稱加密中使用的協(xié)商密鑰，計(jì)算方法為enc_key=Func（random_C, random_S, Pre-Master）。

? 計(jì)算之前通信的所有參數(shù)的哈希值作為SessionSecret。

? 將SessionSecret和用數(shù)字證書攜帶的公鑰加密Pre-Master后發(fā)送給服務(wù)端。

第四步，服務(wù)端收到客戶端發(fā)來(lái)的client_key_exchange消息后，會(huì)進(jìn)行如下操作。

? 用服務(wù)端的私鑰解密客戶端用服務(wù)端證書中的公鑰加密的Pre-Master的值。

? 基于random_S、random_C和Pre-Master計(jì)算雙方協(xié)商得到的密鑰enc_key=Func （random_C, random_S, Pre-Master）。

? 最后與客戶端使用同樣的方式將雙方通信所用參數(shù)進(jìn)行哈希計(jì)算，驗(yàn)證得到的SessionSecret是否正確。

至此，整個(gè)握手過(guò)程全部結(jié)束。接下來(lái)，客戶端與服務(wù)端進(jìn)入加密通信，通信的消息均通過(guò)雙方協(xié)商出來(lái)的共享密鑰加密。enc_key就是TLS協(xié)議傳輸階段對(duì)稱加密所用到的密鑰。這里省略了TLS協(xié)議很多細(xì)節(jié)和采用不同加密套件后，一些可選的握手過(guò)程，如果想要深入探究TLS協(xié)議握手過(guò)程可以參考TLS協(xié)議1.2版本的規(guī)范（RFC 5246）。

1.7.2　雙向認(rèn)證

在上面的整個(gè)過(guò)程中，都是客戶端單向認(rèn)證服務(wù)端的，這是TLS協(xié)議常用的場(chǎng)景。同時(shí)，服務(wù)端可以要求驗(yàn)證客戶端，比較常見(jiàn)的場(chǎng)景就是大額網(wǎng)銀匯款轉(zhuǎn)賬需要在計(jì)算機(jī)上插入U(xiǎn)盾。

U盾中包含銀行簽發(fā)的證書用來(lái)驗(yàn)證客戶端。雙向認(rèn)證在單向認(rèn)證第二步的時(shí)候，服務(wù)端會(huì)要求客戶端發(fā)送證書，來(lái)驗(yàn)證客戶端證書的有效性。

TLS協(xié)議通過(guò)上面的四個(gè)步驟完成了密鑰的協(xié)商，其中用到了三個(gè)隨機(jī)數(shù)random_C，random_S和Pre-Master，如何通過(guò)三個(gè)隨機(jī)數(shù)完成密鑰交換需要用到密鑰協(xié)商算法。