前言
由于在TCP、UDP等方式傳輸數(shù)據(jù)時(shí),數(shù)據(jù)包有可能被其他人截獲,并解析出信息,這就給信息安全帶來(lái)了很大的挑戰(zhàn)。最初的SSL協(xié)議被網(wǎng)景公司提出,它不會(huì)影響上層協(xié)議(如HTTP、電子郵件等),但可以保證上層協(xié)議的通信安全。如果正確的使用SSL,第三方只能推斷連接的兩端地址、加密類型,以及數(shù)據(jù)頻率和發(fā)送的大概數(shù)據(jù)量,但無(wú)法讀取或修改任何實(shí)際數(shù)據(jù)。IETF后來(lái)在標(biāo)準(zhǔn)化SSL協(xié)議時(shí),將其改為了TLS。很多人會(huì)混用SSL與TLS,但嚴(yán)格來(lái)說(shuō)它們指代的協(xié)議版本不同(SSL3.0的升級(jí)版才是TLS1.0)。本文重在講述TLS的概念和原理及其網(wǎng)絡(luò)優(yōu)化。
1.加密、身份驗(yàn)證與完整性
TLS協(xié)議的目標(biāo)是為信息傳輸提供三個(gè)基本的保證:加密、身份驗(yàn)證和數(shù)據(jù)完整性。這三種服務(wù)并不是必須的,可以根據(jù)具體的應(yīng)用場(chǎng)景進(jìn)行選擇。
加密:混淆數(shù)據(jù)的機(jī)制。
身份驗(yàn)證:驗(yàn)證身份標(biāo)識(shí)有效性的機(jī)制。
完整性:檢測(cè)消息是否被篡改或偽造的機(jī)制。
2.TLS握手
客戶端與服務(wù)器在通過(guò)TLS交換數(shù)據(jù)之前,必須協(xié)商建立加密信道。協(xié)商內(nèi)容包括:TLS版本、加密套件,必要時(shí)還要驗(yàn)證證書(shū)。其每次協(xié)商,都需要在客戶端和服務(wù)端往返,大致過(guò)程如下:
0 ms:TLS運(yùn)行在TCP基礎(chǔ)之上,這意味著我們必須首先完成TCP 三次握手“ ,這需要一個(gè)完整的來(lái)回交互(RTT)。
56 ms:TCP連接建立后,客戶端發(fā)送一些協(xié)商信息,如TLS協(xié)議版本,支持的密碼套件的列表,和其他TLS選項(xiàng)。
84 ms:服務(wù)器挑選TLS協(xié)議版本,在加密套件列表中挑選一個(gè)密碼套件,附帶自己的證書(shū),并將響應(yīng)返回給客戶端??蛇x的,服務(wù)器也可以發(fā)送對(duì)客戶端的證書(shū)認(rèn)證請(qǐng)求和其他TLS擴(kuò)展參數(shù)。
112 ms:假設(shè)雙方協(xié)商好一個(gè)共同的TLS版本和加密算法,客戶端使用服務(wù)器提供的證書(shū),生成新的對(duì)稱密鑰,并用服務(wù)器的公鑰進(jìn)行加密,并告訴服務(wù)器切換到加密通信流程。到現(xiàn)在為止,所有被交換的數(shù)據(jù)都是以明文方式傳輸,除了對(duì)稱密鑰外,它采用的是服務(wù)器端的公鑰加密。
140 ms:服務(wù)器用自己的私鑰解密客戶端發(fā)過(guò)來(lái)的對(duì)稱密鑰,并通過(guò)驗(yàn)證MAC檢查消息的完整性,并返回給客戶端一個(gè)加密的“Finished”的消息。
168 ms:客戶端采用對(duì)稱密鑰解密消息,并驗(yàn)證MAC,如果一切OK,加密隧道就建立好了。應(yīng)用程序數(shù)據(jù)就可以發(fā)送了。
應(yīng)用層協(xié)議協(xié)商
理論上,兩個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)可能使用一個(gè)自定義的應(yīng)用程序協(xié)議進(jìn)行互相通信。解決這個(gè)問(wèn)題的方法之一是在確定協(xié)議的前期,給它分配一個(gè)眾所周知的端口(例如,端口80用于HTTP,TLS的端口443),并配置所有客戶端和服務(wù)器使用它。然而,在實(shí)踐中,這是一個(gè)緩慢和不切實(shí)際的過(guò)程:每個(gè)端口的分配必須批準(zhǔn),更糟的是防火墻及其他中間服務(wù)器往往只允許使用80和443進(jìn)行通信。為了簡(jiǎn)化自定義協(xié)議的部署,需要重用80或443端口,再通過(guò)額外的機(jī)制協(xié)商確定協(xié)議。80端口被保留用于HTTP,HTTP規(guī)范提供了一個(gè)特殊的Upgrade流程來(lái)完成這個(gè)目標(biāo)。然而,使用Upgrade可能帶來(lái)額外的網(wǎng)絡(luò)往返延遲,并在實(shí)際應(yīng)用中往往因?yàn)樵S多中間服務(wù)器的存在是不可靠的。
既然80端口不太適合用來(lái)協(xié)商協(xié)議,那就使用443端口,這是給安全HTTPS會(huì)話保留的。端到端的加密隧道對(duì)中間設(shè)備模糊了數(shù)據(jù),因此這就成為了一種可以快速和可靠的方式實(shí)現(xiàn)和部署任意的應(yīng)用程序協(xié)議。然而,使用TLS解決了可靠性,我們?nèi)匀恍枰环N方式來(lái)協(xié)商應(yīng)用協(xié)議!作為HTTPS會(huì)話,當(dāng)然可以復(fù)用了HTTP的Upgrade機(jī)制來(lái)協(xié)商,但這會(huì)帶來(lái)一個(gè)額外完整的往返延遲(RTT)。如果在把TLS握手的同時(shí)協(xié)商確定協(xié)議可行嗎?
應(yīng)用層協(xié)議談判(ALPN)是一個(gè)TLS擴(kuò)展,支持在TLS握手過(guò)程中進(jìn)行協(xié)議協(xié)商,從而省去通過(guò)HTTP的Upgrade機(jī)制所需的額外往返延遲。過(guò)程如下:
客戶在ClientHello消息添加新的ProtocolNameList字段,包含支持的應(yīng)用程序協(xié)議列表。
該服務(wù)器檢查ProtocolNameList字段,并在ServerHello消息中返回一個(gè)ProtocolName字段,用來(lái)指示服務(wù)器端選擇的協(xié)議。
服務(wù)器可能只響應(yīng)其中一個(gè)協(xié)議,如果它不支持任何客戶端要求的協(xié)議,那么它可能選擇中止連接。其結(jié)果是,TLS握手完成后,安全隧道建立好了,客戶端和服務(wù)端也協(xié)商好了所使用的應(yīng)用協(xié)議 - 它們可以立即開(kāi)始通信。
服務(wù)器名稱指示
任意兩個(gè)TCP端之間都可以建立加密的TLS隧道:客戶端只需要知道對(duì)端的IP地址就可以建立連接,并執(zhí)行TLS握手。但是,如果服務(wù)器需要部署多個(gè)獨(dú)立的網(wǎng)站,每個(gè)與自己的TLS證書(shū),但使用同一個(gè)IP地址 - 請(qǐng)問(wèn)如何處理?為了解決上述問(wèn)題,SNI(服務(wù)器名稱指示)擴(kuò)展被引入到TLS協(xié)議中,它允許客戶端在握手開(kāi)始指示他想要連接的主機(jī)名。服務(wù)器檢查SNI主機(jī)名,選擇適當(dāng)?shù)淖C書(shū),并繼續(xù)握手。
注:TLS + SNI工作流程和HTTP的Host頭域宣告流程是相同的,客戶端在頭域中指示它要請(qǐng)求的Host:同一IP地址可能會(huì)部署許多不同domain,SNI和Host都是用來(lái)區(qū)分不同的Host或者Domain。
3.TLS會(huì)話恢復(fù)
完整的TLS握手需要額外延遲和計(jì)算,為所有需要安全通信的應(yīng)用帶來(lái)了嚴(yán)重的性能損耗。為了幫助減少一些性能損耗,TLS提供恢復(fù)機(jī)制,即多個(gè)連接之間共享相同的協(xié)商密鑰數(shù)據(jù)。
會(huì)話標(biāo)識(shí)符
“會(huì)話標(biāo)識(shí)符”(RFC 5246)恢復(fù)機(jī)制在SSL 2.0中首次被引入,支持服務(wù)器端創(chuàng)建32字節(jié)的會(huì)話標(biāo)識(shí)符,并將其作為“ServerHello”消息的一部分進(jìn)行發(fā)送。在服務(wù)器內(nèi)部,服務(wù)器保存一個(gè)會(huì)話ID和其對(duì)應(yīng)的協(xié)商參數(shù)。對(duì)應(yīng)地,客戶端也同時(shí)存儲(chǔ)會(huì)話ID信息,在后續(xù)的會(huì)話中,可以在“ClientHello”消息中攜帶session ID信息,告訴服務(wù)器客戶端還記著session ID對(duì)應(yīng)的密鑰和加密算法等信息,并且可以重用這些信息。假設(shè)在客戶端和服務(wù)器都能在它們各自的緩存中找到共享的會(huì)話ID參數(shù),那么就可以縮減握手了,如下圖所示。否則,開(kāi)始一個(gè)新的會(huì)話協(xié)商,生成新的會(huì)話ID。
借助會(huì)話標(biāo)識(shí)符,我們能夠減少一個(gè)完整的往返,以及用于協(xié)商的共享密鑰的公鑰加密算法開(kāi)銷(xiāo)。這讓我們能快速的建立安全連接,而不損失安全性。然而,“會(huì)話標(biāo)識(shí)符”機(jī)制的一個(gè)限制就是要求服務(wù)器為每個(gè)客戶端創(chuàng)建和維護(hù)一個(gè)會(huì)話緩存。這會(huì)為服務(wù)器上帶來(lái)幾個(gè)問(wèn)題,對(duì)于一些每天同時(shí)幾萬(wàn),甚至幾百萬(wàn)的單獨(dú)連接的服務(wù)器來(lái)說(shuō):由于緩存session ID所需要的內(nèi)存消耗將非常大,同時(shí)還有session ID清除策略的問(wèn)題。這對(duì)一些流量大的網(wǎng)站來(lái)說(shuō)不是一個(gè)簡(jiǎn)單的任務(wù),理想的情況下,使用一個(gè)共享的TLS會(huì)話緩存可以獲得最佳性能。上述問(wèn)題沒(méi)有是不可能解決的,許多高流量的網(wǎng)站成功的使用了會(huì)話標(biāo)識(shí)符。但是,對(duì)任何多服務(wù)主機(jī)的部署,會(huì)話標(biāo)識(shí)符方案需要一些認(rèn)真的思考和好的系統(tǒng)架構(gòu),以確保良好的的會(huì)話緩存。
會(huì)話記錄單
由于在服務(wù)器訪問(wèn)量很大的情況下,緩存會(huì)話信息是一個(gè)很大的負(fù)擔(dān),為消除服務(wù)器需要維護(hù)每個(gè)客戶端的會(huì)話狀態(tài)緩存的要求,“Sesion Ticket”機(jī)制被引入--服務(wù)器端不再需要保存客戶端的會(huì)話狀態(tài)。如果客戶端表明它支持Session Ticket,則在服務(wù)器完成TLS握手的最后一步中將包含一個(gè)“New Session Ticket”信息,這個(gè)信息包含一個(gè)加密通信所需要的信息,這些數(shù)據(jù)采用一個(gè)只有服務(wù)器知道的密鑰進(jìn)行加密。這個(gè)Session Ticket由客戶端進(jìn)行存儲(chǔ),并可以在隨后的會(huì)話中添加到ClientHello消息的SessionTicket擴(kuò)展中。因此,所有的會(huì)話信息只存儲(chǔ)在客戶端上,Session Ticket仍然是安全的,因?yàn)樗怯芍挥蟹?wù)器知道的密鑰加密的。
會(huì)話標(biāo)識(shí)符和會(huì)話記錄單機(jī)制,通常分別被稱為“會(huì)話緩存”和“無(wú)狀態(tài)恢復(fù)”機(jī)制。無(wú)狀態(tài)恢復(fù)的主要改進(jìn)是消除服務(wù)器端的會(huì)話緩存,從而簡(jiǎn)化了部署,它要求客戶在每一個(gè)新的會(huì)話開(kāi)始時(shí)提供Session Ticket,直到Ticket過(guò)期。
注:在實(shí)際應(yīng)用中,在一組負(fù)載平衡服務(wù)器中部署Session Ticket,也需要仔細(xì)考慮:所有的服務(wù)器都必須用相同的會(huì)話密鑰,或者可能需要額外的機(jī)制,定期輪流在所有服務(wù)器上的共享密鑰。
4.證書(shū)頒發(fā)與撤銷(xiāo)
身份驗(yàn)證是建立每個(gè)TLS連接一個(gè)重要的組成部分。畢竟,TLS可以與任何端通過(guò)一個(gè)加密的隧道進(jìn)行通信,包括攻擊者,除非我們可以確信和我們通信的對(duì)方是可信任的,不然所有的加密工作都是無(wú)效的。如何證明某個(gè)主機(jī)是可信的呢?這就需要用證書(shū),只有具有合法證書(shū)的主機(jī)才是可信。證書(shū)的來(lái)源有哪些呢?
手動(dòng)指定的用戶證書(shū):每一個(gè)瀏覽器和操作系統(tǒng)都提供了手動(dòng)導(dǎo)入任何您信任的證書(shū)的機(jī)制。如何獲得證書(shū),并驗(yàn)證其完整性完全取決于你。
證書(shū)頒發(fā)機(jī)構(gòu) :證書(shū)頒發(fā)機(jī)構(gòu)(CA)是一個(gè)值得信賴的第三方的機(jī)構(gòu)(所有者),其證書(shū)值得信任。
瀏覽器和操作系統(tǒng):每個(gè)操作系統(tǒng)和大多數(shù)瀏覽器都包含了知名的證書(shū)頒發(fā)機(jī)構(gòu)的列表。因此,你也可以信任這個(gè)軟件的供應(yīng)商,提供并維護(hù)的信任列表。
在實(shí)際應(yīng)用中,手動(dòng)驗(yàn)證為每一個(gè)網(wǎng)站的證書(shū)(盡管你可以,如果你是這樣的傾向)是不切實(shí)際。因此,最常見(jiàn)的解決方案是借助證書(shū)頒發(fā)機(jī)構(gòu)(CA)做這項(xiàng)工作(如下圖) :在瀏覽器中指定哪些CA是可信任(根CA證書(shū)),CA負(fù)責(zé)驗(yàn)證你訪問(wèn)的每個(gè)網(wǎng)站,并進(jìn)行審核,以確認(rèn)這些證書(shū)沒(méi)有被濫用或受損害。如果任何網(wǎng)站違反了CA的證書(shū)的安全性規(guī)定,那么CA有責(zé)任撤銷(xiāo)其證書(shū)。
偶爾證書(shū)的頒發(fā)機(jī)構(gòu)可能需要撤銷(xiāo)或作廢證書(shū),這可能由于證書(shū)的私鑰被攻破了,證書(shū)頒發(fā)機(jī)構(gòu)本身被攻破,或者其他一些正常的原因譬如證書(shū)替換、證書(shū)簽發(fā)機(jī)構(gòu)發(fā)生變化,等等。為了解決這個(gè)問(wèn)題,證書(shū)本身包含了檢查是否已吊銷(xiāo)的邏輯。因此,為了確保信任鏈不會(huì)受到攻擊影響,每個(gè)節(jié)點(diǎn)都可以檢查每個(gè)證書(shū)的狀態(tài),連同簽名。
證書(shū)撤銷(xiāo)名單(CRL):每個(gè)證書(shū)頒發(fā)機(jī)構(gòu)維護(hù)并定期發(fā)布一份吊銷(xiāo)證書(shū)序列號(hào)列表。要想驗(yàn)證證書(shū)的可靠性,直接查詢CRL名單即可。
CRL文件本身可以定期公布,或在每次更新時(shí)都公布,CRL文件可以通過(guò)HTTP,或任何其他文件傳輸協(xié)議傳輸。該名單也是由CA簽名,通常允許以指定的時(shí)間間隔緩存。在實(shí)際應(yīng)用中,這個(gè)流程運(yùn)行得很好,但也有一些場(chǎng)景CRL機(jī)制可能存在缺陷:
越來(lái)越多的撤銷(xiāo)意味著CRL列表只會(huì)越來(lái)越長(zhǎng),每個(gè)客戶端必須獲取整個(gè)序列號(hào)列表
沒(méi)有證書(shū)吊銷(xiāo)即時(shí)通知機(jī)制 - 如果在客戶端緩存期間,證書(shū)被吊銷(xiāo),客戶端將認(rèn)為證書(shū)是有效的,直到緩存過(guò)期。
在線證書(shū)狀態(tài)協(xié)議(OCSP):提供一種實(shí)時(shí)檢查證書(shū)狀態(tài)的機(jī)制,支持驗(yàn)證端直接查詢證書(shū)數(shù)據(jù)庫(kù)中的序列號(hào),從而驗(yàn)證證書(shū)是否有效。
OSCP占用帶寬更少,支持實(shí)時(shí)驗(yàn)證,也帶來(lái)了一些問(wèn)題。如下:
CA必須能夠處理實(shí)時(shí)查詢的實(shí)時(shí)性和負(fù)荷。
CA必須確保該服務(wù)在任何時(shí)候全球都可用。
客戶端在進(jìn)行任何協(xié)商前都必須等待OCSP請(qǐng)求。
因?yàn)镃A知道哪些網(wǎng)站的客戶端訪問(wèn),實(shí)時(shí)的OCSP請(qǐng)求可能暴露客戶的隱私。
5.TLS記錄協(xié)議
TLS記錄協(xié)議主要用來(lái)識(shí)別TLS中的消息類型(通過(guò)“Content Type”字段的數(shù)據(jù)來(lái)識(shí)別握手,警告或數(shù)據(jù)),以及每個(gè)消息的完整性保護(hù)和驗(yàn)證。交付應(yīng)用數(shù)據(jù)的典型流程如下:
記錄協(xié)議接收到應(yīng)用數(shù)據(jù);
數(shù)據(jù)分塊,每個(gè)塊最大2^14即16 KB;
數(shù)據(jù)壓縮(可選);
添加消息認(rèn)證碼(MAC)或HMAC(用于驗(yàn)證消息的完整性和可靠性);
使用協(xié)商的加密算法加密數(shù)據(jù)。
一旦上述步驟完成后,加密的數(shù)據(jù)被向下傳遞到TCP層進(jìn)行傳輸。在接收端,采用反向相同的工作流程:使用協(xié)商的加密算法對(duì)數(shù)據(jù)進(jìn)行解密,驗(yàn)證MAC,提取的應(yīng)用數(shù)據(jù)給應(yīng)用層。另一個(gè)好消息,所有上述的處理都是TLS層本身處理,對(duì)大多數(shù)應(yīng)用程序是完全透明的。
當(dāng)然,TLS記錄協(xié)議也帶來(lái)了一些重要限制:
TLS記錄的最大大小為16KB;
每個(gè)記錄包含一個(gè)5字節(jié)的頭部,MAC(SSLv3,TLS 1.0,TLS 1.1最多20個(gè)字節(jié),TLS 1.2的多達(dá)32個(gè)字節(jié)),如果采用塊加密算法則還有填充塊(padding);
為了解密和驗(yàn)證每一塊數(shù)據(jù),必須保證所有數(shù)據(jù)都已收到。
6.TLS優(yōu)化
計(jì)算成本
盡早完成(握手)
會(huì)話緩存與無(wú)狀態(tài)恢復(fù)
TLS記錄大小
TLS壓縮
證書(shū)鏈的長(zhǎng)度
OCSP封套
HTTP嚴(yán)格傳輸安全
編輯:hfy
-
TCP
+關(guān)注
關(guān)注
8文章
1402瀏覽量
81033 -
UDP
+關(guān)注
關(guān)注
0文章
330瀏覽量
34641 -
SSL
+關(guān)注
關(guān)注
0文章
130瀏覽量
26202 -
通信網(wǎng)絡(luò)
+關(guān)注
關(guān)注
22文章
2077瀏覽量
53005 -
TLS
+關(guān)注
關(guān)注
0文章
46瀏覽量
4562
發(fā)布評(píng)論請(qǐng)先 登錄
廣州郵科通信電源系統(tǒng):現(xiàn)代通信網(wǎng)絡(luò)的堅(jiān)實(shí)后盾

數(shù)據(jù)中心和通信網(wǎng)絡(luò)有什么區(qū)別

廣州郵科通信電源系統(tǒng):賦能現(xiàn)代通信網(wǎng)絡(luò)的穩(wěn)定動(dòng)力
智能通信網(wǎng)絡(luò)設(shè)計(jì)引擎:VDE Cloud賦能未來(lái)汽車(chē)網(wǎng)絡(luò)研發(fā)

基于CAN的娛樂(lè)車(chē)通信網(wǎng)絡(luò)RV-C介紹
華為贏得巴西通信網(wǎng)絡(luò)大單
MPLS網(wǎng)絡(luò)性能優(yōu)化技巧
光通信網(wǎng)絡(luò)故障排除技巧
光通信網(wǎng)絡(luò)的優(yōu)勢(shì)分析
Dali通信網(wǎng)絡(luò)的最佳配置
網(wǎng)絡(luò)協(xié)議與網(wǎng)關(guān)的關(guān)聯(lián)
如何構(gòu)建RS485通信網(wǎng)絡(luò) RS485串口助手的使用與配置
波分復(fù)用和和光傳輸網(wǎng)絡(luò)的比較
Linux網(wǎng)絡(luò)協(xié)議棧的實(shí)現(xiàn)

以太網(wǎng)通信網(wǎng)關(guān)是什么

評(píng)論