[科普中國]-傳輸層安全性協(xié)議

傳輸層安全性協(xié)議（英語：Transport Layer Security，縮寫作 TLS），及其前身安全套接層（Secure Sockets Layer，縮寫作 SSL）是一種安全協(xié)議，目的是為互聯(lián)網(wǎng)通信，提供安全及數(shù)據(jù)完整性保障。網(wǎng)景公司（Netscape）在1994年推出首版網(wǎng)頁瀏覽器，網(wǎng)景導(dǎo)航者時(shí)，推出HTTPS協(xié)議，以SSL進(jìn)行加密，這是SSL的起源。IETF將SSL進(jìn)行標(biāo)準(zhǔn)化，1999年公布第一版TLS標(biāo)準(zhǔn)文件。隨后又公布RFC 5246 （2008年8月）與 RFC 6176 （2011年3月）。在瀏覽器、電子郵件、即時(shí)通信、VoIP、網(wǎng)絡(luò)傳真等應(yīng)用程序中，廣泛支持這個(gè)協(xié)議。主要的網(wǎng)站，如Google、Facebook等也以這個(gè)協(xié)議來創(chuàng)建安全連接，發(fā)送數(shù)據(jù)。目前已成為互聯(lián)網(wǎng)上保密通信的工業(yè)標(biāo)準(zhǔn)。

SSL包含記錄層（Record Layer）和傳輸層，記錄層協(xié)議確定傳輸層數(shù)據(jù)的封裝格式。傳輸層安全協(xié)議使用X.509認(rèn)證，之后利用非對(duì)稱加密演算來對(duì)通信方做身份認(rèn)證，之后交換對(duì)稱密鑰作為會(huì)談密鑰（Session key）。這個(gè)會(huì)談密鑰是用來將通信兩方交換的數(shù)據(jù)做加密，保證兩個(gè)應(yīng)用間通信的保密性和可靠性，使客戶與服務(wù)器應(yīng)用之間的通信不被攻擊者竊聽。

概論TLS協(xié)議采用主從式架構(gòu)模型，用于在兩個(gè)應(yīng)用程序間通過網(wǎng)絡(luò)創(chuàng)建起安全的連接，防止在交換數(shù)據(jù)時(shí)受到竊聽及篡改。

TLS協(xié)議的優(yōu)勢(shì)是與高層的應(yīng)用層協(xié)議（如HTTP、FTP、Telnet等）無耦合。應(yīng)用層協(xié)議能透明地運(yùn)行在TLS協(xié)議之上，由TLS協(xié)議進(jìn)行創(chuàng)建加密通道需要的協(xié)商和認(rèn)證。應(yīng)用層協(xié)議傳送的數(shù)據(jù)在通過TLS協(xié)議時(shí)都會(huì)被加密，從而保證通信的私密性。

TLS協(xié)議是可選的，必須配置客戶端和服務(wù)器才能使用。主要有兩種方式實(shí)現(xiàn)這一目標(biāo)：一個(gè)是使用統(tǒng)一的TLS協(xié)議通信端口（例如：用于HTTPS的端口443）；另一個(gè)是客戶端請(qǐng)求服務(wù)器連接到TLS時(shí)使用特定的協(xié)議機(jī)制（例如：郵件、新聞協(xié)議和STARTTLS）。一旦客戶端和服務(wù)器都同意使用TLS協(xié)議，他們通過使用一個(gè)握手過程協(xié)商出一個(gè)有狀態(tài)的連接以傳輸數(shù)據(jù)。通過握手，客戶端和服務(wù)器協(xié)商各種參數(shù)用于創(chuàng)建安全連接：

當(dāng)客戶端連接到支持TLS協(xié)議的服務(wù)器要求創(chuàng)建安全連接并列出了受支持的密碼組合（加密密碼算法和加密哈希函數(shù)），握手開始。

服務(wù)器從該列表中決定加密和散列函數(shù)，并通知客戶端。

服務(wù)器發(fā)回其數(shù)字證書，此證書通常包含服務(wù)器的名稱、受信任的證書頒發(fā)機(jī)構(gòu)（CA）和服務(wù)器的公鑰。

客戶端確認(rèn)其頒發(fā)的證書的有效性。

為了生成會(huì)話密鑰用于安全連接，客戶端使用服務(wù)器的公鑰加密隨機(jī)生成的密鑰，并將其發(fā)送到服務(wù)器，只有服務(wù)器才能使用自己的私鑰解密。

利用隨機(jī)數(shù)，雙方生成用于加密和解密的對(duì)稱密鑰。這就是TLS協(xié)議的握手，握手完畢后的連接是安全的，直到連接（被）關(guān)閉。如果上述任何一個(gè)步驟失敗，TLS握手過程就會(huì)失敗，并且斷開所有的連接。1

發(fā)展歷史安全網(wǎng)絡(luò)編程早期的研究工作，為方便改造原有網(wǎng)絡(luò)應(yīng)用程序，在1993年已經(jīng)有了相似的Berkeley套接字安全傳輸層API方法。

SSL 1.0、2.0和3.0SSL（Secure Sockets Layer）是網(wǎng)景公司（Netscape）設(shè)計(jì)的主要用于Web的安全傳輸協(xié)議，這種協(xié)議在Web上獲得了廣泛的應(yīng)用。

基礎(chǔ)算法由作為網(wǎng)景公司的首席科學(xué)家塔希爾·蓋莫爾（Taher Elgamal）編寫，所以他被人稱為“SSL之父”。

2014年10月，Google發(fā)布在SSL 3.0中發(fā)現(xiàn)設(shè)計(jì)缺陷，建議禁用此一協(xié)議。攻擊者可以向TLS發(fā)送虛假錯(cuò)誤提示，然后將安全連接強(qiáng)行降級(jí)到過時(shí)且不安全的SSL 3.0，然后就可以利用其中的設(shè)計(jì)漏洞竊取敏感信息。Google在自己公司相關(guān)產(chǎn)品中陸續(xù)禁止向后兼容，強(qiáng)制使用TLS協(xié)議。Mozilla也在11月25日發(fā)布的Firefox34中徹底禁用了SSL 3.0。微軟同樣發(fā)出了安全通告。

1.0版本從未公開過，因?yàn)榇嬖趪?yán)重的安全漏洞。

2.0版本在1995年2月發(fā)布，但因?yàn)榇嬖跀?shù)個(gè)嚴(yán)重的安全漏洞而被3.0版本替代。

3.0版本在1996年發(fā)布，是由網(wǎng)景工程師Paul Kocher、Phil Karlton和Alan Freier完全重新設(shè)計(jì)的。較新版本的SSL/TLS基于SSL 3.0。SSL 3.0作為歷史文獻(xiàn)IETF通過RFC 6101發(fā)表。2

TLS 1.0IETF將SSL標(biāo)準(zhǔn)化，即RFC 2246，并將其稱為TLS（Transport Layer Security）。從技術(shù)上講，TLS 1.0與SSL 3.0的差異非常微小。但正如RFC所述"the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough to preclude interoperability between TLS 1.0 and SSL 3.0"（本協(xié)議和SSL 3.0之間的差異并不是顯著，卻足以排除TLS 1.0和SSL 3.0之間的互操作性）。TLS 1.0包括可以降級(jí)到SSL 3.0的實(shí)現(xiàn)，這削弱了連接的安全性。2

TLS 1.1TLS 1.1在RFC 4346中定義，于2006年4月發(fā)表，它是TLS 1.0的更新。在此版本中的差異包括：

添加對(duì)CBC攻擊的保護(hù)：

隱式IV被替換成一個(gè)顯式的IV。

更改分組密碼模式中的填充錯(cuò)誤。

支持IANA登記的參數(shù)。2

TLS 1.2TLS 1.2在RFC 5246中定義，于2008年8月發(fā)表。它基于更早的TLS 1.1規(guī)范。主要區(qū)別包括：

可使用密碼組合選項(xiàng)指定偽隨機(jī)函數(shù)使用SHA-256替換MD5-SHA-1組合。

可使用密碼組合選項(xiàng)指定在完成消息的哈希認(rèn)證中使用SHA-256替換MD5-SHA-1算法，但完成消息中哈希值的長度仍然被截?cái)酁?6位。

在握手期間MD5-SHA-1組合的數(shù)字簽名被替換為使用單一Hash方法，默認(rèn)為SHA-1。

增強(qiáng)服務(wù)器和客戶端指定Hash和簽名算法的能力。

擴(kuò)大經(jīng)過身份驗(yàn)證的加密密碼，主要用于GCM和CCM模式的AES加密的支持。

添加TLS擴(kuò)展定義和AES密碼組合。所有TLS版本在2011年3月發(fā)布的RFC 6176中刪除了對(duì)SSL的兼容，這樣TLS會(huì)話將永遠(yuǎn)無法協(xié)商使用的SSL 2.0以避免安全問題。2

TLS 1.3截至2018年3月21日，TLS 1.3是一個(gè)已經(jīng)成為建議標(biāo)準(zhǔn)（Proposed Standard）的互聯(lián)網(wǎng)草案。它基于更早的TLS 1.2規(guī)范，與TLS 1.2的主要區(qū)別包括：

將密鑰協(xié)商和認(rèn)證算法從密碼包中分離出來。

移除脆弱和較少使用的命名橢圓曲線支持（參見橢圓曲線密碼學(xué)）

移除MD5和SHA-224密碼散列函數(shù)的支持

請(qǐng)求數(shù)字簽名，即便使用之前的配置

集成HKDF和半短暫DH提議

替換使用PSK和票據(jù)的恢復(fù)

支持1-RTT握手并初步支持0-RTT

通過在(EC)DH密鑰協(xié)議期間使用臨時(shí)密鑰來保證完善的前向安全性。

放棄許多不安全或過時(shí)特性的支持，包括數(shù)據(jù)壓縮、重新協(xié)商、非AEAD密碼本、靜態(tài)RSA和靜態(tài)DH密鑰交換、自定義DHE分組、點(diǎn)格式協(xié)商、更改密碼本規(guī)范的協(xié)議、UNIX時(shí)間的Hello消息，以及長度字段AD輸入到AEAD密碼本

禁止用于向后兼容性的SSL和RC4協(xié)商

集成會(huì)話散列的使用

棄用記錄層版本號(hào)和凍結(jié)數(shù)以改進(jìn)向后兼容性

將一些安全相關(guān)的算法細(xì)節(jié)從附錄移動(dòng)到標(biāo)準(zhǔn)，并將ClientKeyShare降級(jí)到附錄

添加帶有Poly1305消息驗(yàn)證碼的ChaCha20流加密

添加Ed25519和Ed448數(shù)字簽名算法

添加x25519和x448密鑰交換協(xié)議2

過程以下簡要介紹SSL協(xié)議的工作方式。客戶端要收發(fā)幾個(gè)握手信號(hào)：

發(fā)送一個(gè)“ClientHello”消息，內(nèi)容包括：支持的協(xié)議版本，比如TLS1.0版，一個(gè)客戶端生成的隨機(jī)數(shù)（稍后用于生成“會(huì)話密鑰”），支持的加密算法（如RSA公鑰加密）和支持的壓縮算法。

然后收到一個(gè)“ServerHello”消息，內(nèi)容包括：確認(rèn)使用的加密通信協(xié)議版本，比如TLS 1.0版本（如果瀏覽器與服務(wù)器支持的版本不一致，服務(wù)器關(guān)閉加密通信），一個(gè)服務(wù)器生成的隨機(jī)數(shù)（稍后用于生成“對(duì)話密鑰”），確認(rèn)使用的加密方法（如RSA公鑰加密），服務(wù)器證書。

當(dāng)雙方知道了連接參數(shù)，客戶端與服務(wù)器交換證書（依靠被選擇的公鑰系統(tǒng)）。這些證書通?；赬.509，不過已有草案支持以O(shè)penPGP為基礎(chǔ)的證書。

服務(wù)器請(qǐng)求客戶端公鑰。客戶端有證書即雙向身份認(rèn)證，沒證書時(shí)隨機(jī)生成公鑰。

客戶端與服務(wù)器通過公鑰保密協(xié)商共同的主私鑰（雙方隨機(jī)協(xié)商），這通過精心謹(jǐn)慎設(shè)計(jì)的偽隨機(jī)數(shù)功能實(shí)現(xiàn)。結(jié)果可能使用Diffie-Hellman交換，或簡化的公鑰加密，雙方各自用私鑰解密。所有其他關(guān)鍵數(shù)據(jù)的加密均使用這個(gè)“主密鑰”。數(shù)據(jù)傳輸中記錄層（Record layer）用于封裝更高層的HTTP等協(xié)議。記錄層數(shù)據(jù)可以被隨意壓縮、加密，與消息驗(yàn)證碼壓縮在一起。每個(gè)記錄層包都有一個(gè)Content-Type段用以記錄更上層用的協(xié)議。2

本詞條內(nèi)容貢獻(xiàn)者為:

宋春霖 - 副教授 - 江南大學(xué)