原文: 高性能網(wǎng)絡(luò)瀏覽器-第四章傳輸層安全性(Transport Layer Security,TLS)
翻譯: outshineamaze

介紹:

SSL協(xié)議在網(wǎng)景公司最初開發(fā)支持電子商務(wù)網(wǎng)絡(luò)交易安全,需要加密 http 請(qǐng)求 來保護(hù)客戶的個(gè)人資料,以及身份驗(yàn)證和完整性保證,以確保一個(gè)安全的交易围详。為了達(dá)到這個(gè)目標(biāo),SSL協(xié)議在應(yīng)用程序?qū)訉?shí)現(xiàn),直接上TCP(圖4 - 1上面),使協(xié)議(HTTP、電子郵件铣猩、即時(shí)消息和許多其他人)在使用上不做改變,同時(shí)提供安全通信時(shí)的通信網(wǎng)絡(luò)俄讹。

正確使用SSL時(shí),第三方觀察者只能推斷出連接端點(diǎn)類型的加密,以及頻率和一個(gè)近似發(fā)送的數(shù)據(jù)量,但不能讀取或修改任何實(shí)際的數(shù)據(jù)较曼。

圖片描述

圖4 - 1涌攻。傳輸層安全性(Transport Layer Security,TLS)

SSL協(xié)議由IETF標(biāo)準(zhǔn)化時(shí),它被命名為傳輸層安全性(TLS)膛堤。許多地方不太區(qū)分SSL和TLS名稱,但從技術(shù)上講,它們是不同的,因?yàn)槊總€(gè)描述了不同版本的協(xié)議漓拾。

SSL協(xié)議的2.0是第一個(gè)公開發(fā)布的版本,由于發(fā)現(xiàn)安全漏洞,但它很快就被SSL 3.0取代了. 因?yàn)镾SL協(xié)議是網(wǎng)景私有的,努力形成的IETF標(biāo)準(zhǔn)化協(xié)議,最終定稿為RFC 2246,這是1999年1月出版,被稱為TLS 1.0乌企。此后,IETF繼續(xù)迭代協(xié)議來解決安全漏洞,以及擴(kuò)大其功能:TLS 1.1(RFC 2246)發(fā)表在2006年4月,TLS 1.2(RFC 5246)2008年8月,現(xiàn)在正在開發(fā)中的版本,將定義為TLS 1.3揽乱。

不要讓大量的版本號(hào)誤導(dǎo)你:

服務(wù)器會(huì)更加傾向于選擇最新穩(wěn)定版本TLS協(xié)議,以確保最好的安全,功能和性能保證箱亿。事實(shí)上,一些性能關(guān)鍵型特性,比如HTTP / 2,明確需要使用TLS 1.2或更高版本,否則將終止連接态贤。良好的安全性和性能齊頭并進(jìn)得哆。

notice

TLS是被設(shè)計(jì)用于支持的可靠傳輸?shù)膮f(xié)議(如TCP。然而,它也被適應(yīng)碾如UDP數(shù)據(jù)報(bào)協(xié)議虽画。數(shù)據(jù)報(bào)傳輸層安全(迪泰)),在RFC 6347中定義的是: 基于TLS協(xié)議能夠提供類似的安全保障,同時(shí)保留數(shù)據(jù)報(bào)傳遞模型舞蔽。

加密、身份驗(yàn)證码撰、完整性 (Encryption, Authentication, Integrity)

TLS協(xié)議旨在提供三個(gè)基本服務(wù)上面運(yùn)行的應(yīng)用程序:加密渗柿、認(rèn)證和數(shù)據(jù)完整性。從技術(shù)上講,你不需要在所有的情況中全部使用上面三個(gè)特性脖岛。你可以決定接受證書沒有驗(yàn)證其真實(shí)性,但是你應(yīng)該清楚這樣做的安全風(fēng)險(xiǎn)和影響朵栖。在實(shí)踐中,一個(gè)安全的web應(yīng)用程序?qū)⒗盟腥齻€(gè)服務(wù)。

加密
主機(jī)發(fā)送數(shù)據(jù)到到另一個(gè)終端的一種混淆機(jī)制柴梆。

身份驗(yàn)證
提供一種機(jī)制來驗(yàn)證的有效性身份資料陨溅。

完整性
一種機(jī)制來檢測消息篡改和偽造。

為了建立一個(gè)密碼安全的數(shù)據(jù)通道,peers 之間的連接必須同意使用密碼套件和密鑰用于加密數(shù)據(jù)绍在。TLS協(xié)議定義了一個(gè)明確的握手順序來執(zhí)行這個(gè)交換,我們將詳細(xì)檢查TLS握手门扇。TLS 設(shè)計(jì)巧妙并且可靠原因,是由于其使用公鑰加密(也稱為非對(duì)稱密鑰加密),它允許同伴協(xié)商共享密鑰,而無需建立彼此的任何先驗(yàn)知識(shí),并通過未加密的通道。

TLS協(xié)議允許兩個(gè) peer 在握手的過程中驗(yàn)證對(duì)方的身份偿渡。當(dāng)在瀏覽器中使用TSL 協(xié)議時(shí),這種驗(yàn)證機(jī)制允許客戶端驗(yàn)證服務(wù)器是誰(如臼寄。,你的銀行),而不是一個(gè)虛假的名稱或IP地址。這個(gè)驗(yàn)證是基于信任的建立的——看到的鏈的信任和證書頒發(fā)機(jī)構(gòu)溜宽。此外,服務(wù)器還可以選擇驗(yàn)證客戶端的身份——如吉拳。公司代理服務(wù)器可以驗(yàn)證所有員工,每個(gè)人都可以有公司為自己簽署唯一的的證書。

最后,包含加密和認(rèn)證的地方,TLS協(xié)議還提供自己的消息框架機(jī)制和信號(hào)每個(gè)消息與消息身份驗(yàn)證代碼(MAC)适揉。MAC算法是單向加密哈希函數(shù)(有效校驗(yàn)和),談判的兩個(gè)連接的關(guān)鍵留攒。每當(dāng)TLS發(fā)送記錄,MAC值是生成和附加信息,然后接收者是能夠計(jì)算和驗(yàn)證發(fā)送MAC值,以確保消息的完整性和真實(shí)性煤惩。

所有三個(gè)機(jī)制結(jié)合在一起,作為網(wǎng)絡(luò)安全通信的基礎(chǔ)。所有現(xiàn)代web瀏覽器提供支持多種密碼套件,可以對(duì)客戶端和服務(wù)器進(jìn)行身份驗(yàn)證,并透明地為每一個(gè)記錄執(zhí)行消息完整性檢查稼跳。

代理,中介機(jī)構(gòu),TLS,web 上的新協(xié)議

HTTP的可擴(kuò)展性和成功創(chuàng)造了一個(gè)充滿活力的網(wǎng)上代理和中介機(jī)構(gòu):緩存服務(wù)器,安全網(wǎng)關(guān),網(wǎng)絡(luò)加速器,內(nèi)容過濾器,和許多其它生態(tài)系統(tǒng)盟庞。在某些顯式的代理,我們可以意識(shí)到它們的存在,最終對(duì)于用戶是完全透明的吃沪。
在實(shí)踐中, 在80端口上常常會(huì)部署不可靠的服務(wù),這些服務(wù)偏離的定義良好的HTTP / 1語義, 一些客戶沒有問題,一些客戶的不可預(yù)知汤善。相同的客戶端在不同的網(wǎng)絡(luò)環(huán)境中可能會(huì)看到不同的結(jié)果,

由于這些行為,新協(xié)議和HTTP擴(kuò)展,比如WebSocket,HTTP / 2等,必須依靠建立一個(gè)HTTPS隧道繞過中間代理, 加密隧道可以很好的保護(hù)數(shù)據(jù)通過中間機(jī)構(gòu)。如果你曾經(jīng)想知道為什么大多數(shù)WebSocket指南會(huì)告訴你使用HTTPS來傳送數(shù)據(jù)到移動(dòng)客戶端,這就是為什么票彪。

HTTPS無處不在

未加密的HTTP和其他protocols-creates通信提供大量的隱私红淡、安全性和完整性的漏洞。這樣的連接很容易被攔截降铸、操縱和模擬,并能暴露用戶憑證,歷史,身份,和其他敏感信息在旱。HTTPS可以很好的為用戶的隱私提供保護(hù) 。

HTTPS保護(hù)網(wǎng)站的完整性

加密可以防止入侵者篡改data-e.g交換推掸。重寫內(nèi)容桶蝎、注入 廣告的和惡意的內(nèi)容等等。

HTTPS保護(hù)用戶的隱私和安全

加密可以防止入侵者監(jiān)聽傳輸?shù)臄?shù)據(jù)谅畅。每個(gè)未受保護(hù)的請(qǐng)求可以暴露用戶的敏感信息,當(dāng)這些數(shù)據(jù)包含很多的 session 信息,可以用來推測用戶的身份和其他敏感信息登渣。

HTTPS支持強(qiáng)大的功能

越來越多的新的網(wǎng)絡(luò)平臺(tái)特性,如訪問用戶地理位置,拍照,錄音錄像,支持離線應(yīng)用經(jīng)驗(yàn),,需要顯式的用戶選擇,反過來,需要HTTPS。HTTPS提供的安全性和完整性保證至關(guān)重要的一部分在一個(gè)安全的用戶權(quán)限工作環(huán)境中
進(jìn)一步指出,因特網(wǎng)工程任務(wù)組(IETF)和互聯(lián)網(wǎng)架構(gòu)委員會(huì)(IAB)發(fā)布了指導(dǎo)開發(fā)人員和強(qiáng)烈鼓勵(lì)采用HTTPS協(xié)議設(shè)計(jì)師:

IETF:無處不在的監(jiān)控是攻擊

內(nèi)勤局:互聯(lián)網(wǎng)保密聲明

當(dāng)我們依賴互聯(lián)網(wǎng)的發(fā)展,所以對(duì)每個(gè)依賴它的人來說都有風(fēng)險(xiǎn),它是我們的責(zé)任,作為應(yīng)用程序開發(fā)人員和用戶,以確保我們保護(hù)自己通過啟用HTTPS無處不在毡泻。

Let’s Encrypt

對(duì)廣泛采用HTTPS常見的疑問和障礙的要求是 從一個(gè)可信證書頒發(fā)機(jī)構(gòu)購買證書胜茧。

“Let’s Encrypt是一個(gè)免費(fèi)的、自動(dòng)化的仇味、開放的證書頒發(fā)機(jī)構(gòu)為您的網(wǎng)絡(luò)安全研究小組(ISRG)呻顽。讓我們加密和ACME協(xié)議的目的是能夠建立一個(gè)HTTPS服務(wù)器并讓它自動(dòng)獲得browser-trusted證書,沒有任何人工干預(yù)〉つ”

訪問項(xiàng)目網(wǎng)站學(xué)習(xí)如何設(shè)置它在你自己的站點(diǎn)上廊遍。沒有限制,現(xiàn)在任何人都可以獲得一個(gè)受信任的證書的網(wǎng)站,免費(fèi)的。

TLS握手

之前,客戶機(jī)和服務(wù)器可以交換應(yīng)用程序數(shù)據(jù)/ TLS加密隧道必須協(xié)商:客戶端和服務(wù)器必須同意TLS協(xié)議的版本,如果有必要選擇密碼套件,并驗(yàn)證證書贩挣。不幸的是,每一個(gè)步驟需要新的數(shù)據(jù)包往返(圖4 - 2客戶機(jī)和服務(wù)器之間的),這增加了啟動(dòng)延遲所有TLS連接昧碉。

圖片描述

圖4 - 2。TLS握手協(xié)議
圖4 - 2假設(shè)相同(樂觀的情況)28日毫秒的“光纖”延遲紐約和倫敦之間的使用在以前的TCP連接建立的例子,看看表1 - 1.

0 ms
TLS運(yùn)行在一個(gè)可靠的運(yùn)輸(TCP),這意味著我們必須首先完成TCP三方握手,這需要一個(gè)完整的往返揽惹。

56 ms
與TCP連接,客戶端發(fā)送一個(gè)純文本的規(guī)范,如TLS協(xié)議的版本運(yùn)行,支持的密碼套件列表和其他可能想使用TLS選項(xiàng)被饿。

84 ms
服務(wù)器選擇TLS協(xié)議版本進(jìn)行進(jìn)一步的溝通,決定從列表所提供的客戶端密碼套件,高度的證書,并將響應(yīng)發(fā)送回客戶端√虏可選地,服務(wù)器也可以發(fā)送一個(gè)請(qǐng)求客戶機(jī)的證書和其他參數(shù)TLS擴(kuò)展狭握。

112 ms
假設(shè)雙方可以協(xié)商一個(gè)共同的版本和密碼,和客戶滿意提供的證書服務(wù)器,客戶端發(fā)起RSA或diffie - hellman密鑰交換,這是建立對(duì)稱密鑰用于隨后的會(huì)話。

140 ms
服務(wù)器處理客戶端發(fā)送的密鑰交換參數(shù),檢查消息完整性通過驗(yàn)證MAC,并返回一個(gè)加密 Finished消息發(fā)送回客戶端疯溺。

168 ms
客戶端與談判對(duì)稱密鑰解密消息,驗(yàn)證MAC,如果一切順利,那么建立了隧道和應(yīng)用程序數(shù)據(jù)現(xiàn)在可以發(fā)送论颅。

如上述所示,新的TLS連接需要兩個(gè)往返的“握手”哎垦。然而,在實(shí)踐中,優(yōu)化部署可以做得更好并提供一個(gè)一致的1-RTT TLS握手:

False Start 是TLS協(xié)議的擴(kuò)展,它允許客戶端和服務(wù)器上開始傳輸加密應(yīng)用程序數(shù)據(jù)只是部分complete-i.e握手時(shí)。,一旦 ChangeCipherSpec和 Finished消息被發(fā)送,但沒有等待另一側(cè)做同樣的事情恃疯。這種優(yōu)化降低了新TLS握手開銷連接一個(gè)往返,明白了支持TLS FALSE Start.

如果客戶曾與服務(wù)器通信,可以使用一個(gè)“縮寫握手”,這就需要一個(gè)往返,還允許客戶端和服務(wù)器CPU開銷降低安全會(huì)話重用先前商定的參數(shù);看到TLS會(huì)話恢復(fù).

上述優(yōu)化的組合使我們能夠?yàn)槭状卧L問的和非首次訪問的訪客提供一個(gè) 1-RTT TLS握手,加上計(jì)算儲(chǔ)存先前的會(huì)話,可以恢復(fù)協(xié)商會(huì)話參數(shù)漏设。確保在部署中利用這些優(yōu)化點(diǎn)。

TLS 1.3的設(shè)計(jì)目標(biāo)之一是減少建立安全連接的延遲開銷:新會(huì)話1-RTT,和恢復(fù)會(huì)話0-RTT!

RSA今妄、diffie - hellman和保密

由于各種歷史和商業(yè)原因RSA握手一直大多數(shù)TLS實(shí)現(xiàn)中占主導(dǎo)地位的密鑰交換機(jī)制:客戶端生成一個(gè)對(duì)稱密鑰,與服務(wù)器的公鑰進(jìn)行加密,并將它發(fā)送到服務(wù)器使用的對(duì)稱密鑰建立會(huì)話郑口。反過來,服務(wù)器使用自己的私鑰解密對(duì)稱密鑰和密鑰交換完成發(fā)送。從這個(gè)角度提出了客戶端和服務(wù)器使用對(duì)稱密鑰來加密會(huì)話協(xié)商盾鳞。

RSA的握手,但有一個(gè)重要缺點(diǎn):使用相同的公私密鑰對(duì)服務(wù)器進(jìn)行身份驗(yàn)證和加密對(duì)稱會(huì)話密鑰發(fā)送到服務(wù)器犬性。結(jié)果,如果一個(gè)攻擊者可以訪問服務(wù)器的私鑰和并監(jiān)聽數(shù)據(jù)傳輸,他們可以就解密整個(gè)會(huì)話。更糟糕的是,即使攻擊者目前沒有訪問私鑰,他們?nèi)匀豢梢杂涗浖用艿臅?huì)話,之后一旦在獲得私鑰就可以解密它腾仅。

相比之下,diffie - hellman密鑰交換允許客戶端和服務(wù)器協(xié)商共享密鑰沒有明確溝通的握手:服務(wù)器的私鑰用于簽名和驗(yàn)證的握手,但對(duì)稱密鑰從未離開過客戶機(jī)或服務(wù)器,攻擊者無法攔截即使他們獲得私鑰乒裆。

維基百科文章diffie - hellman密鑰交換

最重要的是,diffie - hellman密鑰交換可以用來減少傳遞 session 的風(fēng)險(xiǎn):我們可以為每個(gè)對(duì)話生成一個(gè)新的“短暫”對(duì)稱密鑰,每一個(gè)密鑰交換后丟棄之前的鑰匙。因?yàn)?暫時(shí)的 key 是從來沒有溝通,新的會(huì)話會(huì)導(dǎo)致重新協(xié)商,最壞的情況是,攻擊者可以破解的客戶端或服務(wù)器,拿到的當(dāng)前會(huì)話密鑰和未來的會(huì)話密鑰推励。然而,知道現(xiàn)在的私鑰,不能幫助攻擊者解密任何先前的會(huì)話!

結(jié)合,使用diffie - hellman密鑰交換和臨時(shí)會(huì)話密鑰使“完美向前保密”(PFS):長期密鑰的妥協(xié)(如服務(wù)器的私鑰)和過期的會(huì)話密鑰 不允許攻擊者解密以前記錄的會(huì)話鹤耍。一個(gè)高度可取的屬性,至少可以這樣說!

結(jié)果,這個(gè)不應(yīng)該感到驚訝,RSA握手在漸漸的被淘汰:所有流行的瀏覽器選跟先進(jìn)的加密算法(即依靠diffie - hellman密鑰交換),作為額外的獎(jiǎng)勵(lì),可能使某些協(xié)議優(yōu)化只有當(dāng)保密是available-e.g向前發(fā)展。通過TLS的 False Start 實(shí)現(xiàn)1-RTT握手验辞。

公共與對(duì)稱密鑰加密的性能

使用公開密匙加密只在初始設(shè)置的TLS隧道:證書認(rèn)證和密鑰交換算法執(zhí)行稿黄。

對(duì)稱密鑰加密,使用對(duì)稱密鑰是用于建立客戶機(jī)和服務(wù)器之間的所有進(jìn)一步溝通在會(huì)話。這樣做,在很大程度上,提高performance-public密鑰加密計(jì)算昂貴得多受神。為了說明不同,如果你有OpenSSL安裝在您的計(jì)算機(jī)上,您可以運(yùn)行下面的測試:

$> openssl speed ecdh

$> openssl speed aes

注意,兩次測試之間的單位不具有直接可比性:橢圓曲線diffie - hellman(ECDH)測試提供了一個(gè)匯總表的操作每秒對(duì)于不同大小的關(guān)鍵,同時(shí)AES性能以字節(jié)每秒抛猖。盡管如此,它應(yīng)該很容易看到ECDH操作計(jì)算昂貴得多。

使用的具體性能數(shù)據(jù)建立在不同硬件鼻听、核心數(shù)量,TLS版本,服務(wù)器配置,和其他因素财著。不要愛上一個(gè)過時(shí)的基準(zhǔn)!總是在自己的硬件上運(yùn)行性能測試和參考降低計(jì)算成本額外的上下文。

應(yīng)用程序?qū)訁f(xié)議談判(ALPN)

兩個(gè)peer 可能想要使用一個(gè)自定義協(xié)議相互通信撑碴。解決這個(gè)問題的一個(gè)方法是確定協(xié)議的前期,分配一個(gè)使用比較廣泛的端口(如撑教。HTTP 80端口, TLS端口443), 然后配置所有客戶端和服務(wù)器使用它。然而,在實(shí)踐中,這是一個(gè)緩慢而不切實(shí)際的過程:每個(gè)端口分配必須批準(zhǔn),更糟糕的是,防火墻和其他中介機(jī)構(gòu)常常允許流量只在端口80和443醉拓。

為了使自定義協(xié)議容易部署,我們必須復(fù)用端口80或443,使用一個(gè)額外的機(jī)制應(yīng)用協(xié)議進(jìn)行協(xié)商伟姐。端口80是用于HTTP,HTTP規(guī)范提供了一個(gè)特殊的 Upgrade流這一目的。然而,使用 Upgrade可以添加一個(gè)額外的網(wǎng)絡(luò)往返延遲,在實(shí)踐中往往是不可靠的許多中介機(jī)構(gòu), 代理,中介機(jī)構(gòu),TLS,新協(xié)議在網(wǎng)絡(luò)上.

notice

HTTP操作示例的升級(jí)流程,提前翻轉(zhuǎn)升級(jí)到HTTP / 2.

解決方法是使用端口443,它是用于安全的HTTPS會(huì)話運(yùn)行/ TLS亿卤。使用端到端加密通道, 一種快速而可靠的方法來部署新應(yīng)用程序協(xié)議愤兵。然而,我們還需要另一種機(jī)制談判中的協(xié)議,它將使用于TLS會(huì)話。

應(yīng)用程序?qū)訁f(xié)議談判(ALPN)

顧名思義,是一個(gè)TLS擴(kuò)展排吴。它擴(kuò)展了TLS握手(圖4 - 2),并允許在同行談判協(xié)議沒有額外的循環(huán)秆乳。具體來說,過程如下:

客戶端添加一個(gè)新的 ProtocolNameList領(lǐng)域,包含支持的應(yīng)用程序協(xié)議列表,進(jìn)入 ClientHello消息。

服務(wù)器檢查 ProtocolNameList場,并返回一個(gè) ProtocolName字段顯示選中的協(xié)議的一部分 ServerHello消息。

服務(wù)器可能只有一個(gè)響應(yīng)協(xié)議名稱,如果它不支持任何客戶機(jī)請(qǐng)求,那么可以選擇終止連接屹堰。因此,一旦TLS握手完成后,建立安全的隧道,和客戶端和服務(wù)器協(xié)議將使用哪些應(yīng)用協(xié)議;客戶端和服務(wù)器可以立即開始通過協(xié)商協(xié)議交換消息肛冶。

歷史和NPN型和ALPN的關(guān)系

(NPN)是一個(gè)TLS擴(kuò)展,谷歌開發(fā)它作為SPDY功能的一部分,使應(yīng)用程序在TLS握手高效地協(xié)議談判。聽起來是不是很熟悉?最終的結(jié)果是功能上相當(dāng)于ALPN扯键。

ALPN修訂和IETF批準(zhǔn)版的NPN型擴(kuò)展睦袖。廣告在NPN型中,服務(wù)器所支持的協(xié)議,然后客戶端選擇和確認(rèn)協(xié)議。在ALPN,這種交換是逆轉(zhuǎn):現(xiàn)在客戶端指定它所支持的協(xié)議,然后,服務(wù)器選擇并確認(rèn)協(xié)議荣刑。變化的基本原理是,這讓ALPN更為契合其他協(xié)議談判的標(biāo)準(zhǔn)馅笙。

簡而言之,ALPN是NPN型的一個(gè)接班人。

服務(wù)器名稱指示(SNI)

可以建立一個(gè)加密的TLS隧道之間的任何兩個(gè)TCP同行:客戶端只需要知道其他同行的IP地址進(jìn)行連接和執(zhí)行TLS握手嘶摊。然而,如果服務(wù)器希望托管多個(gè)獨(dú)立站點(diǎn),每個(gè)都有自己的TLS證書,在相同的IP地址——這是如何工作的呢?技巧問題;它不延蟹。

解決前面的問題,服務(wù)器名稱指示(SNI)擴(kuò)展了TLS協(xié)議,它允許客戶端顯示客戶機(jī)試圖連接到主機(jī)名的TLS握手评矩。反過來,服務(wù)器可以檢查SNI主機(jī)發(fā)送的 ClientHello信息,選擇合適的證書,并完成所需主機(jī)的TLS握手叶堆。

TLS、HTTP和專用IPs

TLS + SNI工作流是相同的 Host在HTTP頭聲明,客戶端顯示站點(diǎn)的主機(jī)名要求:一個(gè)IP地址可能會(huì) host 過個(gè)域名,SNI和 Host他們之間需要消除歧義斥杜。

不幸的是,一些老客戶(如虱颗。,大多數(shù)IE版本上運(yùn)行Windows XP,Android 2.2,和其他人)不支持SNI。因此,如果您需要提供TLS這樣的客戶,那么你可能需要一個(gè)專用的IP地址為每一個(gè)主機(jī)蔗喂。

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

額外的延遲和成本計(jì)算完整的TLS握手一個(gè)嚴(yán)重的性能損失強(qiáng)加給所有的應(yīng)用程序都需要安全通信忘渔。為了降低延時(shí)上的成本,TLS提供一個(gè)機(jī)制來共享多個(gè)連接之間相同的協(xié)商密鑰數(shù)據(jù)。

會(huì)話標(biāo)識(shí)符

第一個(gè)會(huì)話標(biāo)識(shí)符(RFC 5246)恢復(fù)機(jī)制是在SSL 2.0中引入的,它允許服務(wù)器創(chuàng)建和發(fā)送32字節(jié)的會(huì)話標(biāo)識(shí)符的一部分 在TLS協(xié)商之前發(fā)送ServerHello消息缰儿。與會(huì)話ID,客戶機(jī)和服務(wù)器可以存儲(chǔ)之前協(xié)商會(huì)話parameters-keyed會(huì)話ID和后續(xù)會(huì)話重用它們畦粮。

具體來說,客戶端可以包括的會(huì)話ID ClientHello消息告訴服務(wù)器它還記得密碼套件和密鑰協(xié)商從先前的握手和能夠重用它們。反過來,如果服務(wù)器能夠找到會(huì)話參數(shù)與廣告相關(guān)的緩存ID,然后縮寫握手(圖4 - 3)可以發(fā)生乖阵。否則,就需要一個(gè)完整的新會(huì)話協(xié)商過程了,這將生成一個(gè)新的會(huì)話ID宣赔。

圖片描述

圖4 - 3〉山縮寫TLS握手協(xié)議

利用會(huì)話標(biāo)識(shí)符允許我們減少一個(gè)完整的往返,以及公鑰密碼學(xué)的開銷,用于協(xié)商共享密鑰儒将。這樣子在建立一個(gè)安全快速的連接同時(shí), 也不會(huì)損失的安全性,因?yàn)槲覀兪侵赜靡郧皡f(xié)商會(huì)話數(shù)據(jù)。

對(duì)于HTTP / 1會(huì)話恢復(fù)是一個(gè)重要的優(yōu)化对蒲。HTTP / 2 x的應(yīng)用可以消除了一個(gè)完整的往返延遲和顯著減少計(jì)算雙方的成本钩蚊。

事實(shí)上,如果瀏覽器需要多個(gè)連接相同的主機(jī)(例如當(dāng)HTTP / 1.x是使用),它往往會(huì)故意等待第一個(gè)TLS協(xié)商完成之后才連接到同一臺(tái)服務(wù)器上,這樣他們可以“恢復(fù)”和重用相同的會(huì)話參數(shù)。如果你曾經(jīng)看著網(wǎng)絡(luò)跟蹤,想知道為什么你很少看到同一主機(jī)TLS多個(gè)談判并行,這就是為什么!

然而實(shí)際的限制要求服務(wù)器會(huì)話標(biāo)識(shí)符機(jī)制來創(chuàng)建和維護(hù)一個(gè)會(huì)話緩存為每一個(gè)客戶蹈矮。這導(dǎo)致服務(wù)器上的幾個(gè)問題,這可能會(huì)每一天看到成千上萬甚至上百萬獨(dú)特的連接:每打開TLS連接消耗內(nèi)存,要求一個(gè)會(huì)話ID緩存和拆遷政策,對(duì)于擁有大量服務(wù)器的熱門網(wǎng)站是一個(gè)重要挑戰(zhàn),在理想情況下,使用一個(gè)共享TLS會(huì)話緩存可以獲得最佳性能砰逻。

前面的問題都無法解決,但是許多高流量網(wǎng)站如今使用會(huì)話標(biāo)識(shí)符依舊很成功。但對(duì)于任何多服務(wù)器部署泛鸟、會(huì)話標(biāo)識(shí)符需要仔細(xì)思考和系統(tǒng)架構(gòu),確保會(huì)話緩存的合理性蝠咆。

Session Tickets

為解決服務(wù)器端部署TLS會(huì)話緩存這個(gè)問題,“Session Ticket”(RFC 5077)替換機(jī)制被引入,服務(wù)器不需要保持每個(gè)客戶機(jī)會(huì)話狀態(tài)。相反,如果客戶表示它支持Session Ticket,服務(wù)器可以包含一個(gè) New Session Ticket記錄,包括所有協(xié)商會(huì)話數(shù)據(jù), 這些會(huì)話數(shù)據(jù)用一個(gè)只有服務(wù)器知道的密匙加密谈况。

這次會(huì)話Ticket然后會(huì)被存儲(chǔ)在客戶端,可以包含在 Session Ticket內(nèi)的擴(kuò)展 ClientHello消息的后續(xù)會(huì)話勺美。因此,所有會(huì)話數(shù)據(jù)只存儲(chǔ)在客戶端,但Ticket仍然是安全的,因?yàn)樗怯靡粋€(gè)只有服務(wù)器知道的密鑰加密递胧。

會(huì)話標(biāo)識(shí)符和會(huì)話票機(jī)制通常分別稱為會(huì)話緩存和無狀態(tài)恢復(fù)機(jī)制。無狀態(tài)恢復(fù)的主要改進(jìn)是服務(wù)器端會(huì)話緩存,這簡化了部署,每個(gè)新連接服務(wù)端要求客戶端提供session ticket,直到ticket已經(jīng)過期赡茸。

在實(shí)踐中,票在一組負(fù)載均衡服務(wù)器中部署session Tickets 也需要仔細(xì)思考和系統(tǒng)架構(gòu):所有服務(wù)器必須使用相同的初始化會(huì)話密鑰,和一個(gè)額外的安全機(jī)制需要定期和旋轉(zhuǎn)所有服務(wù)器的共享密鑰缎脾。

信任鏈和證書頒發(fā)機(jī)構(gòu)

身份驗(yàn)證是不可分割的一部分,建立每一個(gè)TLS連接。畢竟,可以進(jìn)行一次談話在一個(gè)與任何同行加密通道,包括攻擊者,除非我們可以確定主人對(duì)我們信任,那么所有的加密工作可以占卧。了解我們?nèi)绾悟?yàn)證對(duì)等的身份,讓我們看看一個(gè)簡單的驗(yàn)證工作流之間的愛麗絲和鮑勃:

愛麗絲和鮑勃生成自己的公鑰和私鑰遗菠。

愛麗絲和鮑勃隱藏各自的私鑰。

愛麗絲和鮑勃,分享她的公鑰和鮑勃分享了他與愛麗絲华蜒。

愛麗絲為鮑勃和跡象表明,它生成一個(gè)新消息與她的私鑰辙纬。

Bob使用愛麗絲的公鑰驗(yàn)證提供消息簽名。

信任是一個(gè)關(guān)鍵組成部分前面的交換叭喜。具體來說,公鑰加密允許我們使用發(fā)送方的公鑰來驗(yàn)證消息正確的私鑰簽署,但決定批準(zhǔn)發(fā)送方仍是建立在信任的基礎(chǔ)之上的贺拣。在交換顯示,Alice和Bob可以交換他們的公鑰親自會(huì)面時(shí),因?yàn)樗麄儽舜撕芰私?他們確信他們的交流不被黑客impostor-perhaps他們甚至通過另一個(gè)驗(yàn)證他們的身份,秘密(物理)握手他們?cè)缦冉⒘?

接下來,愛麗絲收到消息從查理,她從來沒有見過誰,而是誰聲稱是鮑勃的朋友。事實(shí)上,證明他的朋友鮑勃,查理問鮑勃簽署自己與鮑勃的公鑰私鑰,并與他的消息(這個(gè)簽名圖4 - 4)捂蕴。在這種情況下,愛麗絲首先檢查鮑勃的簽名的查理的關(guān)鍵譬涡。她知道鮑勃的公鑰,因而能夠確認(rèn)鮑勃確實(shí)簽查理的關(guān)鍵。因?yàn)樗嘈捧U勃決定驗(yàn)證查理,她接受消息和對(duì)查理的消??執(zhí)行類似的完整性檢查,以確保它是,事實(shí)上,從查理啥辨。

圖片描述

圖4 - 4涡匀。信任鏈的愛麗絲,鮑勃,和查理
我們剛剛做的就是建立信任鏈:愛麗絲相信鮑勃,鮑勃信托查理,傳遞信任,愛麗絲決定相信查理。只要沒有人鏈中的妥協(xié),這讓我們構(gòu)建出一個(gè)信任方的列表溉知。

網(wǎng)絡(luò)身份驗(yàn)證和在瀏覽器中遵循相同的過程如圖所示陨瘩。這意味著在這一點(diǎn)上你應(yīng)該問:你的瀏覽器信任誰,你信任誰,是你本人在使用瀏覽器嗎?至少有三種回答這個(gè)問題:

手動(dòng)指定證書
所有瀏覽器和操作系統(tǒng)提供了一種機(jī)制讓你手動(dòng)導(dǎo)入任何你信任的證書。你如何獲得證書并驗(yàn)證其完整性是完全取決于你级乍。

證書頒發(fā)機(jī)構(gòu)
一個(gè)證書頒發(fā)機(jī)構(gòu)(CA)是一個(gè)受信任的第三方信任的證書的主體(所有者)舌劳。

瀏覽器和操作系統(tǒng)
每一個(gè)操作系統(tǒng)和大多數(shù)瀏覽器附帶一個(gè)知名證書頒發(fā)機(jī)構(gòu)列表。因此,您應(yīng)該相信這個(gè)軟件的供應(yīng)商提供和維護(hù)的信任方列表卡者。

在實(shí)踐中,手動(dòng)的去儲(chǔ)存每個(gè)網(wǎng)站證書是不切實(shí)際(盡管你可以)蒿囤。因此,最常見的解決方案是使用證書頒發(fā)機(jī)構(gòu)(ca)為我們做這個(gè)工作(圖4 - 5):瀏覽器指定ca信任(根ca), 中科院的作用就是用來驗(yàn)證每個(gè)站點(diǎn)的sign,審計(jì)和驗(yàn)證這些證書不被誤用或妥協(xié)。如果任何站點(diǎn)的安全與CA的證書被打破,那么它的責(zé)任,CA撤銷妥協(xié)證書崇决。

圖片描述

圖4 - 5材诽。CA簽名的數(shù)字證書
每個(gè)瀏覽器都允許你檢查的信任鏈安全連接(圖4 - 6),通常可以通過單擊鎖定圖標(biāo)旁邊的URL恒傻。

圖片描述

StartCom類1主要中間服務(wù)器證書簽署的StartCom認(rèn)證權(quán)威盈厘。

StartCom認(rèn)證中心是公認(rèn)的根證書頒發(fā)機(jī)構(gòu)睁枕。

整個(gè)鏈的“信任錨”是根證書權(quán)威,這只是顯示,StartCom認(rèn)證權(quán)威。所有瀏覽器附帶一個(gè)預(yù)表受信任的證書頒發(fā)機(jī)構(gòu)(“根”),在這種情況下,瀏覽器信托和能夠驗(yàn)證StartCom根證書。因此,通過傳遞信任鏈的瀏覽器,瀏覽器廠商和StartCom證書頒發(fā)機(jī)構(gòu),我們擴(kuò)展信任我們的目的地網(wǎng)站外遇。

證書的透明度

每一個(gè)操作系統(tǒng)供應(yīng)商和每一個(gè)瀏覽器提供一個(gè)他們信任并且公開上市的默認(rèn)證書頒發(fā)機(jī)構(gòu)注簿。可以搜索引擎來查找和調(diào)查這些列表跳仿。在實(shí)踐中,你會(huì)發(fā)現(xiàn)大多數(shù)系統(tǒng)依賴數(shù)以百計(jì)的受信任的證書頒發(fā)機(jī)構(gòu),這也是一個(gè)對(duì)系統(tǒng)常見的抱怨:大量的受信任的ca在您的瀏覽器中創(chuàng)建一個(gè)大型攻擊表面積的信任鏈诡渴。

好消息是,證書的透明度項(xiàng)目正在努力解決這些缺陷通過提供一個(gè)框架公開日志監(jiān)控和審核發(fā)行的新證書。訪問項(xiàng)目網(wǎng)站,了解更多信息菲语。

證書撤銷

偶爾的發(fā)行者證書需要撤銷或無效證書由于許多可能的原因:證書的私鑰被入侵,證書頒發(fā)機(jī)構(gòu)本身已經(jīng)遭到破壞,或由于各種良性原因取代證書等的變化關(guān)系,等等妄辩。為了解決這個(gè)問題,自己的證書包含指令(圖4 - 7)如何檢查是否已被撤消。因此,為了確保信任鏈不是妥協(xié),每個(gè)同行都可以檢查每個(gè)證書的狀態(tài)根據(jù)嵌入式的指導(dǎo),以及簽名,驗(yàn)證證書鏈山上。

圖片描述

圖4 - 7眼耀。CRL和OCSP指令為igvita.com(Google Chrome,25節(jié))

證書撤銷列表(CRL)

證書撤銷列表(CRL)由RFC 5280定義和指定了一個(gè)簡單的機(jī)制來檢查每一個(gè)證書的狀態(tài):每個(gè)證書頒發(fā)機(jī)構(gòu)維護(hù)和定期發(fā)布撤銷證書編號(hào)的列表。任何一個(gè)試圖驗(yàn)證證書的人就能下載撤銷列表,緩存,并檢查特定序列號(hào)的存在,如果它存在,那么它被撤銷佩憾。

這個(gè)過程簡單明了,但有很多限制:

越來越多的撤銷簽證意味著CRL列表只會(huì)變得更長,和每個(gè)客戶端必須獲取序列號(hào)的完整列表哮伟。

沒有即時(shí)通知證書機(jī)制revocation-if CRL證書被撤銷前由客戶端緩存,然后CRL認(rèn)為撤銷證書有效,直到緩存到期。

需要獲取最新的CRL, CA可能會(huì)阻止證書驗(yàn)證列表,這將顯著延長TLS握手時(shí)間鸯屿。

CRL獲取可能會(huì)失敗,由于各種原因,在這種情況下,瀏覽器的行為是未定義的澈吨。大多數(shù)瀏覽器把這種情況下定義為“軟失敗”,允許驗(yàn)證proceed-yes把敢。

在線證書狀態(tài)協(xié)議(OCSP)

解決一些CRL機(jī)制的局限性,介紹了在線證書狀態(tài)協(xié)議(OCSP)由RFC 2560,這提供了一種機(jī)制來執(zhí)行一個(gè)實(shí)時(shí)檢查證書的狀態(tài)寄摆。不像CRL文件,其中包含所有的撤銷序列號(hào),OCSP允許客戶端直接查詢CA的證書數(shù)據(jù)庫序列號(hào)的問題,同時(shí)驗(yàn)證證書鏈。

因此,消耗更少的帶寬和OCSP機(jī)制能夠提供實(shí)時(shí)驗(yàn)證修赞。然而,要求執(zhí)行實(shí)時(shí)OCSP查詢創(chuàng)建自己的一組問題:

CA必須能夠處理負(fù)載的實(shí)時(shí)查詢婶恼。

CA必須確保服務(wù)和全局可用。

實(shí)時(shí)OCSP請(qǐng)求可能損害客戶的隱私因?yàn)镃A知道哪些網(wǎng)站客戶端訪問柏副。

客戶端必須阻止OCSP請(qǐng)求而驗(yàn)證證書鏈勾邦。

瀏覽器行為,再一次,未定義,通常導(dǎo)致“軟失敗”如果OCSP獲取失敗由于網(wǎng)絡(luò)超時(shí)或其他錯(cuò)誤。

作為一個(gè)現(xiàn)實(shí)世界的數(shù)據(jù)點(diǎn),Firefox遙測表明OCSP請(qǐng)求時(shí)間高達(dá)15%的時(shí)間,并添加TLS握手當(dāng)successful-see大約350毫秒hpbn.co / ocsp-performance.

OCSP裝訂

上面列出的原因,無論是CRL或OSCP撤銷機(jī)制提供了安全性和性能保證我們渴望我們的應(yīng)用程序割择。但是,不要絕望,因?yàn)镺CSP裝訂(RFC 6066,“證書狀態(tài)請(qǐng)求”擴(kuò)展)解決了大部分的問題我們之前看到通過允許執(zhí)行驗(yàn)證的服務(wù)器和發(fā)送(“釘”)的TLS握手到客戶端:

而不是客戶OCSP請(qǐng)求,服務(wù)器,定期檢索簽署和時(shí)間戳OCSP CA的響應(yīng)眷篇。

然后,服務(wù)器(即附加內(nèi)容±笥荆“主食”)簽署了OCSP響應(yīng)作為TLS握手的一部分,允許客戶端驗(yàn)證證書和附加OCSP撤銷CA簽署的記錄蕉饼。

這角色轉(zhuǎn)換是安全的,因?yàn)閜ing CA簽署的記錄,可以由客戶端驗(yàn)證,并提供一些重要的好處:

客戶不會(huì)流失,其導(dǎo)航歷史。

客戶端沒有阻止和查詢OCSP服務(wù)器玛歌。

客戶端可能“hard-fail”撤銷處理如果服務(wù)器選擇加入(通過廣告OSCP Must-Staple國旗)和驗(yàn)證失敗昧港。

簡而言之,兩個(gè)最好的安全性和性能保證,確保在您的服務(wù)器上配置和測試OCSP裝訂支子。

TLS協(xié)議記錄

不同的IP或TCP層下面,TLS會(huì)話中的所有數(shù)據(jù)交換框架使用一個(gè)定義良好的協(xié)議(圖4 - 8)。TLS協(xié)議記錄負(fù)責(zé)識(shí)別不同類型的消息(握手巩搏、警告或數(shù)據(jù)通過“內(nèi)容類型”字段),以及保護(hù)和驗(yàn)證每個(gè)消息的完整性。

圖片描述

圖4 - 8趾代。TLS記錄結(jié)構(gòu)
交付應(yīng)用程序的典型工作流數(shù)據(jù)如下:

記錄協(xié)議接收應(yīng)用程序數(shù)據(jù)塔猾。

接收的數(shù)據(jù)分為塊:最多214字節(jié),或16 KB /記錄。

消息驗(yàn)證碼(MAC)或HMAC被添加到每個(gè)記錄稽坤。

數(shù)據(jù)在每個(gè)記錄是使用協(xié)商加密密碼丈甸。

一旦完成了這些步驟,加密的數(shù)據(jù)傳遞到TCP層的傳輸。在接收端,相同的工作流程,但是反過來說,由同行應(yīng)用:解密使用密碼談判記錄,核實(shí)MAC,提取和交付應(yīng)用程序上面的數(shù)據(jù)尿褪。

好消息是,所有的工作就顯示由TLS層本身,對(duì)于大多數(shù)應(yīng)用程序是完全透明的睦擂。然而,記錄協(xié)議并介紹幾個(gè)重要的意義,我們需要注意的:

最大TLS記錄大小是16 KB

每條記錄包含一個(gè)5字節(jié)的頭,一個(gè)MAC(SSLv3 20字節(jié),TLS 1.0,TLS 1.1,TLS 1.2)和32字節(jié),如果使用分組密碼和填充。

解密和驗(yàn)證記錄,整個(gè)記錄必須是可用的杖玲。

為應(yīng)用程序選擇正確的記錄大小,如果你有這樣做的能力,可以是一個(gè)重要的優(yōu)化顿仇。小記錄招致更大的CPU和開銷字節(jié)由于框架和MAC驗(yàn)證記錄,而大的記錄必須交付和重組的TCP層之前,他們可以處理的TLS層和提前送到你application-skip優(yōu)化TLS記錄大小全部細(xì)節(jié)。

優(yōu)化TLS

部署您的應(yīng)用程序在TLS需要一些額外的工作,在您的應(yīng)用程序(如資源遷移到HTTPS以避免混合內(nèi)容),以及基礎(chǔ)設(shè)施的配置負(fù)責(zé)交付應(yīng)用程序數(shù)據(jù)在TLS摆马。調(diào)整部署可以使一個(gè)巨大的不同凡響的觀測性能,用戶體驗(yàn),和整體運(yùn)營成本臼闻。就讓我們一探究竟吧。

降低計(jì)算成本

建立和維護(hù)一個(gè)加密的通道同行介紹了附加的計(jì)算成本囤采。具體來說,首先是不對(duì)稱的(公鑰)加密中使用TLS握手(解釋道TLS握手)述呐。然后,一旦建立共享密鑰,它被用作一個(gè)對(duì)稱密鑰加密所有TLS記錄。

正如我們前面提到的,公鑰密碼術(shù)更計(jì)算昂貴的相比,對(duì)稱密鑰加密,并在早期的Web通常需要額外的硬件來執(zhí)行“SSL卸載蕉毯∨野幔“好消息是,這不再是必要的,一旦需要專用硬件在CPU上直接就可以完成。大型組織如Facebook代虾、Twitter和谷歌提供TLS數(shù)十億的用戶,在計(jì)算軟件和硬件執(zhí)行所有必要的TLS協(xié)商进肯。

2010年1月,Gmail將默認(rèn)為所有使用HTTPS。之前它被引入作為一個(gè)選項(xiàng),但現(xiàn)在我們所有的用戶使用HTTPS來保護(hù)他們的瀏覽器和谷歌之間他們的電子郵件,所有的時(shí)間棉磨。為了做到這一點(diǎn)我們還沒有部署額外的機(jī)器,沒有特殊硬件江掩。在我們的前端生產(chǎn)環(huán)境服務(wù)器機(jī),SSL / TLS占不到1%的CPU負(fù)載、每個(gè)連接不到10 KB的內(nèi)存和不到2%的網(wǎng)絡(luò)開銷乘瓤。許多人認(rèn)為,SSL / TLS需要大量的CPU時(shí)間,我們希望前面的數(shù)字(公共)可以幫助大家打消那個(gè)誤解环形。

如果你現(xiàn)在停止閱讀你只需要記住一件事:SSL / TLS不再計(jì)算昂貴了。

亞當(dāng)·蘭利(谷歌)
我們?cè)诖笠?guī)模部署TLS使用硬件和軟件負(fù)載平衡器馅扣。我們發(fā)現(xiàn),現(xiàn)代的基于軟件的TLS實(shí)現(xiàn)產(chǎn)品, 高速cpu來處理大量HTTPS流量負(fù)載,而不需要采取專門的加密硬件斟赚。我們的服務(wù)所有的HTTPS都使用軟件來運(yùn)行.

Doug海貍(Facebook)
橢圓曲線diffie - hellman(ECDHE)僅僅是一個(gè)更昂貴的比RSA同等安全級(jí)別…在實(shí)際部署中,我們發(fā)現(xiàn),啟用和優(yōu)先ECDHE密碼套件是微不足道的CPU使用量的增加引起的。HTTP keepalives和會(huì)話恢復(fù)意味著大多數(shù)請(qǐng)求不需要一個(gè)完整的握手,握手操作并不占用我們的CPU使用率差油。我們發(fā)現(xiàn)75%的Twitter客戶端使用ECDHE在連接建立請(qǐng)求被發(fā)送拗军。剩下的25%主要由老客戶還不支持ECDHE密碼套件任洞。

雅各Hoffman-Andrews(Twitter)
在自己的部署過程中得到最好的結(jié)果,啟動(dòng)最好的TLS會(huì)話恢復(fù),優(yōu)化其成功率。消除每一個(gè)握手需要執(zhí)行昂貴的公鑰密碼學(xué)操作將明顯降低計(jì)算成本,同時(shí)減少TLS延遲;沒有理由把CPU周期浪費(fèi)在本不需要做的事情上面发侵。

談到優(yōu)化CPU周期,請(qǐng)一定要保持你的服務(wù)器更新與TLS庫的最新版本!除了安全改進(jìn),你也會(huì)經(jīng)辰惶停看到性能優(yōu)勢。安全性和性能是密不可分的刃鳄。

啟用 1-RTT TLS握手

一個(gè)未優(yōu)化的TLS部署可以輕松添加許多額外的往返和介紹user-e.g明顯延遲盅弛。multi-RTT握手,緩慢而無效的證書撤銷支票、大TLS記錄,需要多次往返的

調(diào)優(yōu)的TLS部署應(yīng)該最多添加一個(gè)額外的往返談判TLS連接,不管它是新的或恢復(fù),并避免其他延遲陷阱:配置會(huì)話恢復(fù),并使向前保密支持TLS FALSE Start叔锐。

要獲得最佳的端到端性能,確保審計(jì)自己的和第三方服務(wù)和服務(wù)器所使用的應(yīng)用程序,包括你的CDN提供商挪鹏。快速,與流行的服務(wù)器和發(fā)布商的概述,請(qǐng)查看istlsfastyet.com.

優(yōu)化連接重用

最好的方法減少計(jì)算開銷和延遲設(shè)置新的TCP + TLS連接優(yōu)化連接重用愉烙。這樣平攤到了設(shè)置成本在請(qǐng)求和向用戶提供更快的體驗(yàn)讨盒。

驗(yàn)證您的服務(wù)器和代理配置設(shè)置允許keepalive連接,和審計(jì)連接超時(shí)設(shè)置。許多流行的服務(wù)器組積極的連接超時(shí)(例如Apache版本默認(rèn)為5 s超時(shí)),迫使很多不必要的協(xié)議步责。為達(dá)到最佳效果,使用你的日志和分析來確定最優(yōu)超時(shí)值返顺。

利用提前終止

正如我們討論的Primer on Latency and Bandwidth,我們可能無法使我們的包跑得更快,但我們可以讓他們更短的距離。通過將我們的“邊緣”服務(wù)器接近用戶(圖4 - 9日),我們可以顯著減少往返時(shí)間和TCP和TLS握手的總成本蔓肯。

圖片描述

圖4 - 9日遂鹊。客戶端連接的早期終止
一個(gè)簡單的方法來做到這一點(diǎn)是利用內(nèi)容分發(fā)網(wǎng)絡(luò)(CDN)的服務(wù),維護(hù)全球的邊緣服務(wù)器池,或者自己部署蔗包。通過允許用戶終止與附近的服務(wù)器,而不是穿越在海洋和大陸鏈接你的來源,客戶得到的好處與短循環(huán)“提前終止”秉扑。這種技術(shù)同樣是有用的和重要的靜態(tài)和動(dòng)態(tài)內(nèi)容:靜態(tài)內(nèi)容也可以由邊緣服務(wù)器緩存,而動(dòng)態(tài)請(qǐng)求可以在建立路由連接從邊緣到原點(diǎn)。

CDN獲取資源

使用CDN技術(shù)或代理服務(wù)器來獲取資源,這可能需要每個(gè)用戶定制的或包含其它私人數(shù)據(jù),因此不是一個(gè)全球緩存資源的優(yōu)勢,通常被稱為一個(gè)“未取回起源气忠×诖ⅲ”

而cdn效果最好,當(dāng)數(shù)據(jù)被緩存在geo-distributed服務(wù)器在全世界范圍內(nèi),仍未起源獲取提供了一個(gè)非常重要的優(yōu)化:客戶端連接終止與附近的服務(wù)器,這可以大大減少握手延遲成本。反過來,CDN,或者自己的代理服務(wù)器,可以維持一個(gè)“溫暖的連接池”起源服務(wù)器傳遞數(shù)據(jù),允許您返回一個(gè)快速響應(yīng)返回到客戶機(jī)旧噪。

事實(shí)上,作為一個(gè)額外的一層優(yōu)化,附近一些CDN提供商使用服務(wù)器連接兩岸的!客戶端連接終止在附近的一個(gè)CDN節(jié)點(diǎn),然后將請(qǐng)求到CDN節(jié)點(diǎn)接近原點(diǎn),然后請(qǐng)求被路由到原點(diǎn)。跳在CDN網(wǎng)絡(luò)允許流量路由優(yōu)化CDN骨干,這有助于進(jìn)一步減少客戶端和起源服務(wù)器之間的延遲脓匿。

配置會(huì)話緩存和無狀態(tài)恢復(fù)

終止接近用戶的連接是一種優(yōu)化,有助于降低延遲為用戶在所有情況下,但再一次,沒有一點(diǎn)比一點(diǎn)快sent-send更少的比特淘钟。支持TLS會(huì)話緩存和無狀態(tài)恢復(fù)允許我們消除整個(gè)往返重復(fù)訪客的延遲和減少計(jì)算開銷。

會(huì)話標(biāo)識(shí)符,TLS會(huì)話緩存依賴,介紹了SSL寬2.0,大多數(shù)客戶端和服務(wù)器的支持陪毡。然而,如果你是在您的服務(wù)器上配置TLS,不要認(rèn)為會(huì)話將在默認(rèn)情況下支持米母。事實(shí)上,它是更常見的在大多數(shù)服務(wù)器的默認(rèn)設(shè)置你知道更好!仔細(xì)檢查并驗(yàn)證您的服務(wù)器、代理和CDN配置:

服務(wù)器有多個(gè)進(jìn)程或員工應(yīng)該使用一個(gè)共享會(huì)話緩存毡琉。

共享會(huì)話緩存的大小應(yīng)該調(diào)整你的交通水平铁瞒。

應(yīng)提供會(huì)話超時(shí)時(shí)間。

在一個(gè)多服務(wù)器的設(shè)置中,客戶端IP路由一樣,或TLS會(huì)話ID相同,相同的服務(wù)器是一種提供良好的會(huì)話緩存利用率桅滋。

“粘性”負(fù)載平衡在哪里并不是一個(gè)選擇,應(yīng)該使用一個(gè)共享緩存不同服務(wù)器之間提供良好的會(huì)話緩存利用率,并建立安全機(jī)制需要分享和更新提供會(huì)話密鑰來解密票慧耍。

檢查和監(jiān)控你的TLS會(huì)話緩存統(tǒng)計(jì)數(shù)據(jù)最佳性能身辨。

在實(shí)踐中,為達(dá)到最佳效果,你應(yīng)配置兩個(gè)會(huì)話緩存機(jī)制和會(huì)話ticket。這些機(jī)制共同努力,為新老客戶提供最好的報(bào)道芍碧。

支持TLS False Start

會(huì)話恢復(fù)提供了兩個(gè)重要的好處:它消除了額外的握手往返返回游客和降低計(jì)算成本的握手,允許重用之前協(xié)商會(huì)話參數(shù)煌珊。然而,它在第一次與服務(wù)器通信,或者前一交易日已經(jīng)過期是無效的。

得到最好的兩個(gè)全世界一個(gè)往返握手為新和重復(fù)訪客,和計(jì)算節(jié)省重復(fù)visitors-we可以使用TLS FALSE Start,這是一個(gè)可選的擴(kuò)展協(xié)議,允許發(fā)送方發(fā)送應(yīng)用程序數(shù)據(jù)(圖4到10)握手時(shí)只有部分完成泌豆。

圖片描述

圖4到10定庵。TLS握手與錯(cuò)誤的開始
FALSE Start不修改TLS握手協(xié)議,相反,它只會(huì)影響協(xié)議的時(shí)機(jī)當(dāng)應(yīng)用程序可以發(fā)送數(shù)據(jù)。直觀地說,一旦客戶端發(fā)送 ClientKeyExchange記錄,它已經(jīng)知道加密密鑰,就可以開始發(fā)送應(yīng)用程序數(shù)據(jù),剩下的握手是花握手確認(rèn)沒有人篡改記錄,并且可以并行完成的踪危。因此,錯(cuò)誤的開始讓我們保持TLS握手一次往返不管我們是否執(zhí)行一個(gè)完整的或縮寫握手蔬浙。

部署TLS False Start

因?yàn)殄e(cuò)誤的開始只是握手協(xié)議的修改時(shí)間,它不需要任何更新TLS協(xié)議本身和可以u(píng)nilaterally-i.e實(shí)現(xiàn)。,客戶端可以開始傳輸加密的應(yīng)用程序數(shù)據(jù)贞远。理論上是這樣的敛滋。

在實(shí)踐中,盡管TLS False Start應(yīng)該向后兼容所有現(xiàn)有的TLS客戶機(jī)和服務(wù)器,使其默認(rèn)為所有TLS連接問題被證明是由于一些糟糕的服務(wù)器實(shí)現(xiàn)。因此,所有現(xiàn)代瀏覽器都能夠使用TLS FALSE Start,但某些條件得到滿足時(shí)才會(huì)這么做的服務(wù)器:

Chrome和Firefox需要ALPN協(xié)議聲明出現(xiàn)在服務(wù)器的握手,和選擇的密碼套件服務(wù)器使保密兴革。

Safari要求密碼組合要求服務(wù)器支持向前保密绎晃。

Internet Explorer使用黑名單的網(wǎng)站的結(jié)合,打破啟用TLS False Start 時(shí),和一個(gè)超時(shí)重復(fù)握手如果TLS FALSE Start握手失敗了。

所有瀏覽器支持TLS FALSE Start服務(wù)器應(yīng)該做廣告支持的協(xié)議的列表通過ALPN extension-e.g杂曲∈“h2,http / 1.1”——被配置為支持和更喜歡密碼套件,使保密。

優(yōu)化TLS記錄大小

所有應(yīng)用程序數(shù)據(jù)通過TLS內(nèi)運(yùn)輸記錄協(xié)議(圖4 - 8)擎勘。每個(gè)記錄是16 KB的最大大小,取決于所選的密碼,每個(gè)記錄將增加20到40字節(jié)的頭開銷,MAC和可選的填充咱揍。如果記錄符合一個(gè)TCP數(shù)據(jù)包,然后我們還必須添加TCP / IP開銷:IP 20-byte頭,20-byte頭不為TCP選項(xiàng)。因此,有可能為每一個(gè)記錄60到100字節(jié)的開銷棚饵。對(duì)于一個(gè)典型的最大傳輸單元(MTU)線大小為1500字節(jié),這包結(jié)構(gòu)轉(zhuǎn)化為最小幀開銷的6%煤裙。

記錄越小,幀開銷越高。然而,僅僅增加記錄其最大尺寸的大小(16 KB)并不一定是一個(gè)好主意噪漾。如果記錄多個(gè)TCP數(shù)據(jù)包,那么TLS層必須等待所有TCP數(shù)據(jù)包到達(dá)才能解密數(shù)據(jù)(圖4 -)硼砰。如果這些TCP數(shù)據(jù)包迷路了,重新排序,或限制由于擁塞控制,然后TLS的各個(gè)片段記錄必須緩沖之前可以解碼,導(dǎo)致額外的延遲。在實(shí)踐中,這些延遲可以為瀏覽器創(chuàng)建的重要瓶頸,更愿意消費(fèi)數(shù)據(jù)以流的方式欣硼。

圖片描述

圖4题翰。WireShark捕獲的11211字節(jié)的TLS記錄分歧8 TCP段
小記錄產(chǎn)生開銷,大型記錄產(chǎn)生延遲,沒有一個(gè)“最優(yōu)”記錄的值大小。相反,為web應(yīng)用程序,使用瀏覽器,最好的策略是動(dòng)態(tài)調(diào)整記錄大小基于TCP連接的狀態(tài):

當(dāng)連接是新的和TCP擁塞窗口較低,或當(dāng)連接閑置一段時(shí)間(見緩慢的開始重啟),每個(gè)TCP包應(yīng)該攜帶一個(gè)TLS記錄,和TLS記錄應(yīng)該占領(lǐng)整個(gè)最大段大小由TCP(MSS)分配诈胜。

當(dāng)連接擁塞窗口很大,如果我們將一個(gè)大型流(如豹障。流媒體視頻),TLS記錄的大小可以增加跨多個(gè)TCP數(shù)據(jù)包(16 kb)減少框架和客戶端和服務(wù)器上的CPU開銷。

如果TCP連接一直閑置,即使慢啟動(dòng)重啟服務(wù)器上禁用,最好的策略是減少數(shù)據(jù)的記錄大小在發(fā)送一個(gè)新的破裂:條件可能改變了自去年傳播,我們的目標(biāo)是最小化的概率緩沖在應(yīng)用程序?qū)佑捎趤G包,重新排序,重發(fā)焦匈。

使用一個(gè)動(dòng)態(tài)交互式交通戰(zhàn)略提供最佳性能:小記錄大小可以消除不必要的緩沖延遲和提高time-to-first - { HTML字節(jié),…,視頻幀},和一個(gè)更大的記錄大小優(yōu)化吞吐量為長壽流TLS的開銷最小化血公。

確定最優(yōu)記錄大小為每個(gè)狀態(tài)讓我們從最初的開始一個(gè)新的或閑置的TCP連接,我們希望避免TLS記錄跨越多個(gè)TCP數(shù)據(jù)包:

IPv4分配20字節(jié)幀開銷和40個(gè)字節(jié)為IPv6。

為TCP框架的開銷分配20字節(jié)缓熟。

分配40字節(jié)TCP選項(xiàng)開銷(時(shí)間戳,袋)累魔。

假設(shè)一個(gè)常見的1500字節(jié)的MTU開始,這使得1420字節(jié)的TLS記錄交付在IPv4,并為IPv6 1400字節(jié)摔笤。不會(huì)過時(shí)的技術(shù),使用IPv6大小,留下1400字節(jié)為每個(gè)TLS記錄,并根據(jù)需要調(diào)整如果你的MTU低。

接下來,決定當(dāng)記錄大小應(yīng)該增加和復(fù)位如果連接一直閑置,可以設(shè)置基于預(yù)配置的閾值:記錄大小增加到16 KB XKB的數(shù)據(jù)傳輸,重置后記錄大小 Y空閑時(shí)間的毫秒薛夜。

通常情況下,配置TLS記錄大小不是我們可以控制在應(yīng)用程序?qū)蛹搿Ｏ喾?通常這是一個(gè)設(shè)置,有時(shí)TLS服務(wù)器的編譯時(shí)常量。檢查您的服務(wù)器的文檔有關(guān)如何配置這些值梯澜。

TLS在谷歌優(yōu)化

2014年初,谷歌的服務(wù)器使用小TLS記錄,符合一個(gè)TCP段第一1 MB的數(shù)據(jù),記錄大小增加到16 KB之后優(yōu)化吞吐量,然后重置記錄大小回到一段inactivity-lather一秒鐘之后,沖洗,重復(fù)寞冯。

同樣,如果您的服務(wù)器處理大量的TLS連接,然后最小化優(yōu)化內(nèi)存使用每個(gè)連接可以是至關(guān)重要的。默認(rèn)情況下,OpenSSL等流行的庫將50 KB的內(nèi)存分配每個(gè)連接,但與記錄大小,它可能值得檢查文件或源代碼如何調(diào)整這個(gè)值晚伙。谷歌服務(wù)器減少OpenSSL緩沖區(qū)下降到5 KB吮龄。

優(yōu)化證書鏈

驗(yàn)證信任鏈遍歷鏈要求瀏覽器,從網(wǎng)站的證書,并遞歸地驗(yàn)證證書的父母,直到達(dá)到一個(gè)可信的根。因此,它是至關(guān)重要的,提供鏈包括所有中級(jí)證書咆疗。如果有遺漏,瀏覽器將被迫暫停驗(yàn)證過程和獲取丟失的證書,添加額外的DNS查找,TCP握手和HTTP請(qǐng)求到流程中漓帚。

瀏覽器如何知道從哪里獲取丟失的證書嗎?每個(gè)孩子父母證書通常包含一個(gè)URL。如果省略的URL和所需的證書是不包括的,然后驗(yàn)證將會(huì)失敗午磁。

相反,不包括不必要的證書,如受信任的根證書中那些添加不必要的字節(jié)尝抖。回想一下,發(fā)送服務(wù)器證書鏈的TLS握手,這是可能發(fā)生在一個(gè)新的TCP連接,在早期階段的慢啟動(dòng)算法迅皇。如果證書鏈的大小超過最初TCP的擁塞窗口,然后我們將無意中添加額外的次往返TLS握手:證書長度將溢出擁塞窗口,導(dǎo)致服務(wù)器停止,等待客戶ACK之前昧辽。

在實(shí)踐中,證書鏈的大小和深度是一個(gè)更大的擔(dān)憂和問題在舊TCP堆棧初始化其初始4 TCP segments-see擁塞窗口慢啟動(dòng)。對(duì)于更新的部署,最初的TCP擁塞窗口已經(jīng)提高到10段,應(yīng)該足夠大多數(shù)證書鏈登颓。

也就是說,驗(yàn)證您的服務(wù)器使用的是最新的TCP協(xié)議棧和設(shè)置,并優(yōu)化,減少你的證書鏈的大小搅荞。少發(fā)送字節(jié)總是良好的和有價(jià)值的優(yōu)化。

配置OCSP裝訂

每一個(gè)新的TLS連接要求,瀏覽器必須驗(yàn)證發(fā)送的簽名證書鏈框咙。然而,還有一個(gè)重要的步驟,我們不能忘記:瀏覽器也需要驗(yàn)證證書沒有被撤銷咕痛。

驗(yàn)證證書的狀態(tài)瀏覽器可以使用幾種方法之一:證書撤銷列表(CRL),在線證書狀態(tài)協(xié)議(OCSP),或OCSP裝訂。每種方法都有自己的局限性,但OCSP裝訂提供,到目前為止,最好的安全性和性能guarantees-refer早期部分的細(xì)節(jié)喇嘱。確保配置你的服務(wù)器包括(主食)提供證書的CA的OCSP反應(yīng)鏈茉贡。這樣做允許瀏覽器執(zhí)行撤銷檢查沒有任何額外的網(wǎng)絡(luò)數(shù)據(jù)傳輸次數(shù)和提高安全保證。

OCSP響應(yīng)可以改變從400年到4000字節(jié)大小婉称。裝訂這個(gè)響應(yīng)你的證書鏈將增加其size-pay密切關(guān)注證書鏈的總大小,這樣它不會(huì)溢出的初始擁塞窗口新的TCP連接块仆。

當(dāng)前OCSP裝訂實(shí)現(xiàn)只允許一個(gè)單一的OCSP響應(yīng)包含,這意味著瀏覽器可能要回退到另一個(gè)如果它需要驗(yàn)證其他證書撤銷機(jī)制的chain-reduce證書鏈的長度。在未來,OCSP Multi-Stapling應(yīng)該解決這個(gè)問題王暗。

最受歡迎的服務(wù)器支持OCSP裝訂。檢查相關(guān)文檔的支持和配置說明庄敛。同樣,如果使用或決定一個(gè)CDN,檢查他們的TLS堆棧支持和配置為使用OCSP裝訂俗壹。

啟用HTTP嚴(yán)格的傳輸安全性(hst)

HTTP嚴(yán)格的交通安全是一個(gè)重要的安全策略機(jī)制,允許一個(gè)起源宣布訪問規(guī)則通過一個(gè)簡單的HTTP header-e.g兼容的瀏覽器≡蹇荆“Strict-Transport-Security:信息= 31536000”绷雏。具體地說,它指示用戶代理執(zhí)行以下規(guī)定:

所有請(qǐng)求的起源應(yīng)該發(fā)送/ HTTPS头滔。這包括導(dǎo)航和所有其他同源子資源requests-e.g。如果用戶類型沒有https URL前綴用戶代理應(yīng)該自動(dòng)將它轉(zhuǎn)換成一個(gè)https請(qǐng)求;如果一個(gè)頁面包含一個(gè)引用非http資源,用戶代理應(yīng)該自動(dòng)轉(zhuǎn)換成請(qǐng)求https版本涎显。

如果不能建立一個(gè)安全連接,用戶不允許繞過HTTP version-i.e警告和請(qǐng)求坤检。origin的協(xié)議是是https。

信息在幾秒鐘內(nèi)指定指定hst的生命周期規(guī)則集(例如, max-age=31536000等于365天一生的廣告策略)期吓。

includeSubdomains表明當(dāng)前的政策應(yīng)該適用于所有子域早歇。

hst origin 轉(zhuǎn)換為一個(gè)https目的地和幫助保護(hù)應(yīng)用程序從各種各樣的被動(dòng)和主動(dòng)網(wǎng)絡(luò)的攻擊。還有一個(gè)額外的好處,它還提供了一個(gè)不錯(cuò)的性能優(yōu)化通過消除需要HTTP-to-HTTPS重定向:客戶端自動(dòng)重寫所有請(qǐng)求安全起源之前派遣!

確保啟用hst之前徹底地測試您的TLS部署讨勤。一旦政策是由客戶端緩存,未能協(xié)商將導(dǎo)致hard-fail-i.e TLS連接箭跳。用戶將看到瀏覽器錯(cuò)誤頁面,不會(huì)被允許繼續(xù)下去。這種行為是明確的和必要的設(shè)計(jì)選擇,以防止網(wǎng)絡(luò)攻擊者騙取客戶沒有HTTPS訪問你的網(wǎng)站潭千。

hst預(yù)加載列表

hst機(jī)制留下第一個(gè)請(qǐng)求的來源不受保護(hù)的積極attacks-e.g谱姓。惡意方可以降低客戶的請(qǐng)求,并防止它注冊(cè)hst政策。為了解決這個(gè)問題,大多數(shù)瀏覽器提供一個(gè)單獨(dú)的“hst預(yù)加載列表”機(jī)制,該機(jī)制允許一個(gè)起源請(qǐng)求包含列表中的HSTS-enabled附帶瀏覽器的網(wǎng)站刨晴。

一旦你有信心在你的HTTPS部署,考慮提交你的網(wǎng)站到hst通過預(yù)加載列表hstspreload.appspot.com.

啟用 HTTP Public Key Pinning (HPKP)

的缺點(diǎn)之一,當(dāng)前系統(tǒng)中討論鏈的信任和證書頒發(fā)機(jī)構(gòu)是我們的依賴大量的受信任的證書頒發(fā)機(jī)構(gòu)(CA)屉来。一方面,這是方便的,因?yàn)樗馕吨覀兛梢垣@得一個(gè)有效的證書從一個(gè)大池的實(shí)體。然而,這也意味著其中任何一個(gè)實(shí)體也能夠發(fā)出有效的證書給我們

DigiNotar認(rèn)證權(quán)威的妥協(xié)的引人注目的例子之一是一個(gè)攻擊者能夠發(fā)行和使用虛假但有效證件與數(shù)以百計(jì)的高調(diào)的網(wǎng)站狈癞。

HPKP允許一個(gè)站點(diǎn)發(fā)送一個(gè)HTTP頭指示瀏覽器記住(“pin”)一個(gè)或多個(gè)證書的證書鏈茄靠。通過這樣做,它可以范圍證書,或者發(fā)行人,應(yīng)該接受瀏覽器在隨后的訪問:

origin可以銷毀葉證書。這是最安全的策略,因?yàn)?實(shí)際上,硬編碼一個(gè)小的特定證書簽名應(yīng)該接受瀏覽器亿驾。

父的起源可以銷一個(gè)證書的證書鏈嘹黔。例如,原點(diǎn)可以銷中級(jí)證書的CA,告訴瀏覽器,這個(gè)特殊的起源,它應(yīng)該只信任證書簽署的證書頒發(fā)機(jī)構(gòu)。

銷哪個(gè)證書,選擇正確的戰(zhàn)略和多少備份提供,時(shí)間,和其他標(biāo)準(zhǔn)部署HPKP是重要的,微妙的,超出了我們的討論范圍。咨詢你的最喜歡的搜索引擎,或者你當(dāng)?shù)氐陌踩珜＜?以獲取更多信息。

HPKP還公開一個(gè)“報(bào)告”模式,不執(zhí)行提供銷但能夠檢測到故障報(bào)告窜管。這是一個(gè)偉大的第一步驗(yàn)證您的部署,和作為一種機(jī)制來檢測違規(guī)劝篷。

更新網(wǎng)站內(nèi)容,HTTPS

得到最好的安全性和性能擔(dān)保實(shí)際上是至關(guān)重要的,網(wǎng)站使用HTTPS來獲取它的所有資源。否則,我們遇到一些問題,最壞的就是網(wǎng)站崩潰

將被瀏覽器混合的“活躍”內(nèi)容(如HTTP上的腳本和樣式表傳遞)可能會(huì)破壞網(wǎng)站的功能汁蝶。

混合的“被動(dòng)”內(nèi)容(如圖片、視頻、音頻等,交付通過HTTP)將獲取,但將允許攻擊者觀察和推斷用戶活動(dòng),并降低性能要求額外的連接和握手获询。

審計(jì)內(nèi)容和更新你的資源和鏈接,包括第三方的內(nèi)容,使用HTTPS。的內(nèi)容安全政策(CSP)機(jī)制可以很大的幫助,確定違反HTTPS和執(zhí)行所需的政策拐袜。

Content-Security-Policy: upgrade-insecure-requests
Content-Security-Policy-Report-Only: default-src https:;
report-uri https://example.com/reporting/endpoint
告訴瀏覽器升級(jí)所有(自己的和第三方)請(qǐng)求HTTPS吉嚣。
告訴瀏覽器報(bào)告任何違反非http指定端點(diǎn)。
CSP提供了一個(gè)高度可配置的機(jī)制來控制哪些資產(chǎn)可以被使用,以及如何,從那里他們可以獲取蹬铺。利用這些功能,可以保護(hù)你的網(wǎng)站和你的用戶尝哆。

性能檢查表

作為應(yīng)用程序開發(fā)人員我們免受大多數(shù)TLS協(xié)議的復(fù)雜性客戶機(jī)和服務(wù)器代表我們做最困難的工作。然而,正如我們?cè)诒菊轮锌吹降?這并不意味著我們可以忽視在TLS交付我們的應(yīng)用程序的性能方面甜攀。優(yōu)化我們的服務(wù)器,使關(guān)鍵TLS優(yōu)化和配置應(yīng)用程序啟用客戶端利用這些特性支付高額股息:更快的握手,減少延遲,更好的安全保障,等等秋泄。

考慮到這一點(diǎn),一個(gè)簡短的清單放在議事日程:

從TCP獲得最佳性能;請(qǐng)參閱優(yōu)化TCP.

TLS庫升級(jí)到最新版本,和(重新)構(gòu)建服務(wù)器琐馆。

啟用和配置會(huì)話緩存和無狀態(tài)的恢復(fù)。

監(jiān)控你的會(huì)話緩存命中率,并相應(yīng)地調(diào)整配置恒序。

配置向前保密密碼啟用TLS FALSE Start瘦麸。

終止TLS會(huì)話更接近用戶往返延遲最小化。

使用動(dòng)態(tài)TLS記錄分級(jí)優(yōu)化延遲和吞吐量歧胁。

審計(jì)和優(yōu)化你的證書鏈的大小滋饲。

配置OCSP裝訂。

配置hst和HPKP与帆。

配置CSP的政策了赌。

啟用HTTP / 2;看到HTTP / 2.

測試和驗(yàn)證

最后,為了驗(yàn)證和測試您的配置,您可以使用一個(gè)在線服務(wù),比如Qualys SSL服務(wù)器測試掃描你的公共服務(wù)器常見配置和安全漏洞。此外,你應(yīng)該熟悉 openssl命令行界面,這將幫助你檢查整個(gè)握手并在本地配置你的服務(wù)器玄糟。

$ > openssl s_client狀態(tài)-CAfile startssl.ca勿她。crt連接igvita.com:443

連接(00000003)
SSL_connect:前/連接初始化
SSL_connect:SSLv2的站點(diǎn)時(shí)/ v3寫客戶你好
SSL_connect:SSLv3讀服務(wù)器你好
深度= 2 / C = IL / O = StartCom有限公司/ OU =安全數(shù)字證書簽名
/ CN = StartCom認(rèn)證權(quán)威
驗(yàn)證返回:1
深度= 1 / C = IL / O = StartCom有限公司/ OU =安全數(shù)字證書簽名
/ CN = StartCom類1主要中間服務(wù)器
驗(yàn)證返回:1
深度= 0 = ABjQuqt3nPv7ebEG /描述/ C =
/ CN =www.igvita.com/emailAddress=ilya@igvita.com
驗(yàn)證返回:1
SSL_connect:SSLv3讀服務(wù)器證書
SSL_connect:SSLv3讀服務(wù)器做了
  SSL_connect:SSLv3 write client key exchange A
  SSL_connect:SSLv3 write change cipher spec A
  SSL_connect:SSLv3 write finished A
  SSL_connect:SSLv3 flush data
  SSL_connect:SSLv3 read finished A
  ---
  Certificate chain 
   0 s:/description=ABjQuqt3nPv7ebEG/C=US
       /CN=www.igvita.com/emailAddress=ilya@igvita.com
     i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing
       /CN=StartCom Class 1 Primary Intermediate Server CA
   1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing
       /CN=StartCom Class 1 Primary Intermediate Server CA
     i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing
       /CN=StartCom Certification Authority
  ---
  Server certificate
  -----BEGIN CERTIFICATE-----
  ... snip ...
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 3571 bytes and written 444 bytes 
  ---
  New, TLSv1/SSLv3, Cipher is RC4-SHA
  Server public key is 2048 bit
  Secure Renegotiation IS supported
  Compression: NONE
  Expansion: NONE
  SSL-Session:
      Protocol  : TLSv1
      Cipher    : RC4-SHA
      Session-ID: 269349C84A4702EFA7 ... 
      Session-ID-ctx:
      Master-Key: 1F5F5F33D50BE6228A ...
      Key-Arg   : None
      Start Time: 1354037095
      Timeout   : 300 (sec)
      Verify return code: 0 (ok)
  ---

客戶端完成驗(yàn)證收到的證書鏈。
收到證書鏈(兩個(gè)證書)阵翎。
收到了證書鏈的大小逢并。
發(fā)布了有狀態(tài)的會(huì)話標(biāo)識(shí)符TLS的簡歷。
在前面的例子中,我們連接igvita.com在默認(rèn)的TLS端口(443),并執(zhí)行TLS握手郭卫。因?yàn)?s_client沒有假設(shè)已知的根證書,我們手動(dòng)指定路徑StartSSL證書的根證書Authority-this是很重要的砍聊。瀏覽器已經(jīng)StartSSL的根證書,因此能夠驗(yàn)證鏈,但是 s_client沒有這樣的假設(shè)。試著刪除根證書,你將看到一個(gè)驗(yàn)證錯(cuò)誤日志中贰军。

檢查證書鏈顯示服務(wù)器發(fā)送兩個(gè)證書,加起來3571個(gè)字節(jié)玻蝌。同時(shí),我們可以看到協(xié)商會(huì)話variables-chosen TLS協(xié)議,密碼,鑰匙,我們還可以看到服務(wù)器發(fā)布當(dāng)前會(huì)話的會(huì)話標(biāo)識(shí)符。

outshineamaze: 時(shí)間匆忙, 如有錯(cuò)誤, 多多包涵