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

介紹:

SSL協議在網景公司最初開發支持電子商務網絡交易安全,需要加密 http 請求 來保護客戶的個人資料,以及身份驗證和完整性保證,以確保一個安全的交易。為了達到這個目標,SSL協議在應用程序層實現,直接上TCP(圖4 - 1上面),使協議(HTTP、電子郵件、即時消息和許多其他人)在使用上不做改變,同時提供安全通信時的通信網絡。

正確使用SSL時,第三方觀察者只能推斷出連接端點類型的加密,以及頻率和一個近似發送的數據量,但不能讀取或修改任何實際的數據。

圖片描述

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

SSL協議由IETF標準化時,它被命名為傳輸層安全性(TLS)。許多地方不太區分SSL和TLS名稱,但從技術上講,它們是不同的,因為每個描述了不同版本的協議。

SSL協議的2.0是第一個公開發布的版本,由于發現安全漏洞,但它很快就被SSL 3.0取代了. 因為SSL協議是網景私有的,努力形成的IETF標準化協議,最終定稿為RFC 2246,這是1999年1月出版,被稱為TLS 1.0。此后,IETF繼續迭代協議來解決安全漏洞,以及擴大其功能:TLS 1.1(RFC 2246)發表在2006年4月,TLS 1.2(RFC 5246)2008年8月,現在正在開發中的版本,將定義為TLS 1.3。

不要讓大量的版本號誤導你:

服務器會更加傾向于選擇最新穩定版本TLS協議,以確保最好的安全,功能和性能保證。事實上,一些性能關鍵型特性,比如HTTP / 2,明確需要使用TLS 1.2或更高版本,否則將終止連接。良好的安全性和性能齊頭并進。

notice

TLS是被設計用于支持的可靠傳輸的協議(如TCP。然而,它也被適應碾如UDP數據報協議。數據報傳輸層安全(迪泰)),在RFC 6347中定義的是: 基于TLS協議能夠提供類似的安全保障,同時保留數據報傳遞模型。

加密、身份驗證、完整性 (Encryption, Authentication, Integrity)

TLS協議旨在提供三個基本服務上面運行的應用程序:加密、認證和數據完整性。從技術上講,你不需要在所有的情況中全部使用上面三個特性。你可以決定接受證書沒有驗證其真實性,但是你應該清楚這樣做的安全風險和影響。在實踐中,一個安全的web應用程序將利用所有三個服務。

加密
主機發送數據到到另一個終端的一種混淆機制。

身份驗證
提供一種機制來驗證的有效性身份資料。

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

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

TLS協議允許兩個 peer 在握手的過程中驗證對方的身份。當在瀏覽器中使用TSL 協議時,這種驗證機制允許客戶端驗證服務器是誰(如。,你的銀行),而不是一個虛假的名稱或IP地址。這個驗證是基于信任的建立的——看到的鏈的信任和證書頒發機構。此外,服務器還可以選擇驗證客戶端的身份——如。公司代理服務器可以驗證所有員工,每個人都可以有公司為自己簽署唯一的的證書。

最后,包含加密和認證的地方,TLS協議還提供自己的消息框架機制和信號每個消息與消息身份驗證代碼(MAC)。MAC算法是單向加密哈希函數(有效校驗和),談判的兩個連接的關鍵。每當TLS發送記錄,MAC值是生成和附加信息,然后接收者是能夠計算和驗證發送MAC值,以確保消息的完整性和真實性。

所有三個機制結合在一起,作為網絡安全通信的基礎。所有現代web瀏覽器提供支持多種密碼套件,可以對客戶端和服務器進行身份驗證,并透明地為每一個記錄執行消息完整性檢查。

代理,中介機構,TLS,web 上的新協議

HTTP的可擴展性和成功創造了一個充滿活力的網上代理和中介機構:緩存服務器,安全網關,網絡加速器,內容過濾器,和許多其它生態系統。在某些顯式的代理,我們可以意識到它們的存在,最終對于用戶是完全透明的。
在實踐中, 在80端口上常常會部署不可靠的服務,這些服務偏離的定義良好的HTTP / 1語義, 一些客戶沒有問題,一些客戶的不可預知。相同的客戶端在不同的網絡環境中可能會看到不同的結果,

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

HTTPS無處不在

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

HTTPS保護網站的完整性

加密可以防止入侵者篡改data-e.g交換。重寫內容、注入 廣告的和惡意的內容等等。

HTTPS保護用戶的隱私和安全

加密可以防止入侵者監聽傳輸的數據。每個未受保護的請求可以暴露用戶的敏感信息,當這些數據包含很多的 session 信息,可以用來推測用戶的身份和其他敏感信息。

HTTPS支持強大的功能

越來越多的新的網絡平臺特性,如訪問用戶地理位置,拍照,錄音錄像,支持離線應用經驗,,需要顯式的用戶選擇,反過來,需要HTTPS。HTTPS提供的安全性和完整性保證至關重要的一部分在一個安全的用戶權限工作環境中
進一步指出,因特網工程任務組(IETF)和互聯網架構委員會(IAB)發布了指導開發人員和強烈鼓勵采用HTTPS協議設計師:

IETF:無處不在的監控是攻擊

內勤局:互聯網保密聲明

當我們依賴互聯網的發展,所以對每個依賴它的人來說都有風險,它是我們的責任,作為應用程序開發人員和用戶,以確保我們保護自己通過啟用HTTPS無處不在。

Let’s Encrypt

對廣泛采用HTTPS常見的疑問和障礙的要求是 從一個可信證書頒發機構購買證書。

“Let’s Encrypt是一個免費的、自動化的、開放的證書頒發機構為您的網絡安全研究小組(ISRG)。讓我們加密和ACME協議的目的是能夠建立一個HTTPS服務器并讓它自動獲得browser-trusted證書,沒有任何人工干預。”

訪問項目網站學習如何設置它在你自己的站點上。沒有限制,現在任何人都可以獲得一個受信任的證書的網站,免費的。

TLS握手

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

圖片描述

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

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

56 ms
與TCP連接,客戶端發送一個純文本的規范,如TLS協議的版本運行,支持的密碼套件列表和其他可能想使用TLS選項。

84 ms
服務器選擇TLS協議版本進行進一步的溝通,決定從列表所提供的客戶端密碼套件,高度的證書,并將響應發送回客戶端。可選地,服務器也可以發送一個請求客戶機的證書和其他參數TLS擴展。

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

140 ms
服務器處理客戶端發送的密鑰交換參數,檢查消息完整性通過驗證MAC,并返回一個加密 Finished消息發送回客戶端。

168 ms
客戶端與談判對稱密鑰解密消息,驗證MAC,如果一切順利,那么建立了隧道和應用程序數據現在可以發送。

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

False Start 是TLS協議的擴展,它允許客戶端和服務器上開始傳輸加密應用程序數據只是部分complete-i.e握手時。,一旦 ChangeCipherSpec和 Finished消息被發送,但沒有等待另一側做同樣的事情。這種優化降低了新TLS握手開銷連接一個往返,明白了支持TLS FALSE Start.

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

上述優化的組合使我們能夠為首次訪問的和非首次訪問的訪客提供一個 1-RTT TLS握手,加上計算儲存先前的會話,可以恢復協商會話參數。確保在部署中利用這些優化點。

TLS 1.3的設計目標之一是減少建立安全連接的延遲開銷:新會話1-RTT,和恢復會話0-RTT!

RSA、diffie - hellman和保密

由于各種歷史和商業原因RSA握手一直大多數TLS實現中占主導地位的密鑰交換機制:客戶端生成一個對稱密鑰,與服務器的公鑰進行加密,并將它發送到服務器使用的對稱密鑰建立會話。反過來,服務器使用自己的私鑰解密對稱密鑰和密鑰交換完成發送。從這個角度提出了客戶端和服務器使用對稱密鑰來加密會話協商。

RSA的握手,但有一個重要缺點:使用相同的公私密鑰對服務器進行身份驗證和加密對稱會話密鑰發送到服務器。結果,如果一個攻擊者可以訪問服務器的私鑰和并監聽數據傳輸,他們可以就解密整個會話。更糟糕的是,即使攻擊者目前沒有訪問私鑰,他們仍然可以記錄加密的會話,之后一旦在獲得私鑰就可以解密它。

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

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

最重要的是,diffie - hellman密鑰交換可以用來減少傳遞 session 的風險:我們可以為每個對話生成一個新的“短暫”對稱密鑰,每一個密鑰交換后丟棄之前的鑰匙。因為 暫時的 key 是從來沒有溝通,新的會話會導致重新協商,最壞的情況是,攻擊者可以破解的客戶端或服務器,拿到的當前會話密鑰和未來的會話密鑰。然而,知道現在的私鑰,不能幫助攻擊者解密任何先前的會話!

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

結果,這個不應該感到驚訝,RSA握手在漸漸的被淘汰:所有流行的瀏覽器選跟先進的加密算法(即依靠diffie - hellman密鑰交換),作為額外的獎勵,可能使某些協議優化只有當保密是available-e.g向前發展。通過TLS的 False Start 實現1-RTT握手。

公共與對稱密鑰加密的性能

使用公開密匙加密只在初始設置的TLS隧道:證書認證和密鑰交換算法執行。

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

$> openssl speed ecdh

$> openssl speed aes

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

使用的具體性能數據建立在不同硬件、核心數量,TLS版本,服務器配置,和其他因素。不要愛上一個過時的基準!總是在自己的硬件上運行性能測試和參考降低計算成本額外的上下文。

應用程序層協議談判(ALPN)

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

為了使自定義協議容易部署,我們必須復用端口80或443,使用一個額外的機制應用協議進行協商。端口80是用于HTTP,HTTP規范提供了一個特殊的 Upgrade流這一目的。然而,使用 Upgrade可以添加一個額外的網絡往返延遲,在實踐中往往是不可靠的許多中介機構, 代理,中介機構,TLS,新協議在網絡上.

notice

HTTP操作示例的升級流程,提前翻轉升級到HTTP / 2.

解決方法是使用端口443,它是用于安全的HTTPS會話運行/ TLS。使用端到端加密通道, 一種快速而可靠的方法來部署新應用程序協議。然而,我們還需要另一種機制談判中的協議,它將使用于TLS會話。

應用程序層協議談判(ALPN)

顧名思義,是一個TLS擴展。它擴展了TLS握手(圖4 - 2),并允許在同行談判協議沒有額外的循環。具體來說,過程如下:

客戶端添加一個新的 ProtocolNameList領域,包含支持的應用程序協議列表,進入 ClientHello消息。

服務器檢查 ProtocolNameList場,并返回一個 ProtocolName字段顯示選中的協議的一部分 ServerHello消息。

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

歷史和NPN型和ALPN的關系

(NPN)是一個TLS擴展,谷歌開發它作為SPDY功能的一部分,使應用程序在TLS握手高效地協議談判。聽起來是不是很熟悉?最終的結果是功能上相當于ALPN。

ALPN修訂和IETF批準版的NPN型擴展。廣告在NPN型中,服務器所支持的協議,然后客戶端選擇和確認協議。在ALPN,這種交換是逆轉:現在客戶端指定它所支持的協議,然后,服務器選擇并確認協議。變化的基本原理是,這讓ALPN更為契合其他協議談判的標準。

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

服務器名稱指示(SNI)

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

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

TLS、HTTP和專用IPs

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

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

TLS會話恢復

額外的延遲和成本計算完整的TLS握手一個嚴重的性能損失強加給所有的應用程序都需要安全通信。為了降低延時上的成本,TLS提供一個機制來共享多個連接之間相同的協商密鑰數據。

會話標識符

第一個會話標識符(RFC 5246)恢復機制是在SSL 2.0中引入的,它允許服務器創建和發送32字節的會話標識符的一部分 在TLS協商之前發送ServerHello消息。與會話ID,客戶機和服務器可以存儲之前協商會話parameters-keyed會話ID和后續會話重用它們。

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

圖片描述

圖4 - 3。縮寫TLS握手協議

利用會話標識符允許我們減少一個完整的往返,以及公鑰密碼學的開銷,用于協商共享密鑰。這樣子在建立一個安全快速的連接同時, 也不會損失的安全性,因為我們是重用以前協商會話數據。

對于HTTP / 1會話恢復是一個重要的優化。HTTP / 2 x的應用可以消除了一個完整的往返延遲和顯著減少計算雙方的成本。

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

然而實際的限制要求服務器會話標識符機制來創建和維護一個會話緩存為每一個客戶。這導致服務器上的幾個問題,這可能會每一天看到成千上萬甚至上百萬獨特的連接:每打開TLS連接消耗內存,要求一個會話ID緩存和拆遷政策,對于擁有大量服務器的熱門網站是一個重要挑戰,在理想情況下,使用一個共享TLS會話緩存可以獲得最佳性能。

前面的問題都無法解決,但是許多高流量網站如今使用會話標識符依舊很成功。但對于任何多服務器部署、會話標識符需要仔細思考和系統架構,確保會話緩存的合理性。

Session Tickets

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

這次會話Ticket然后會被存儲在客戶端,可以包含在 Session Ticket內的擴展 ClientHello消息的后續會話。因此,所有會話數據只存儲在客戶端,但Ticket仍然是安全的,因為它是用一個只有服務器知道的密鑰加密。

會話標識符和會話票機制通常分別稱為會話緩存和無狀態恢復機制。無狀態恢復的主要改進是服務器端會話緩存,這簡化了部署,每個新連接服務端要求客戶端提供session ticket,直到ticket已經過期。

在實踐中,票在一組負載均衡服務器中部署session Tickets 也需要仔細思考和系統架構:所有服務器必須使用相同的初始化會話密鑰,和一個額外的安全機制需要定期和旋轉所有服務器的共享密鑰。

信任鏈和證書頒發機構

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

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

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

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

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

Bob使用愛麗絲的公鑰驗證提供消息簽名。

信任是一個關鍵組成部分前面的交換。具體來說,公鑰加密允許我們使用發送方的公鑰來驗證消息正確的私鑰簽署,但決定批準發送方仍是建立在信任的基礎之上的。在交換顯示,Alice和Bob可以交換他們的公鑰親自會面時,因為他們彼此很了解,他們確信他們的交流不被黑客impostor-perhaps他們甚至通過另一個驗證他們的身份,秘密(物理)握手他們早先建立了!

接下來,愛麗絲收到消息從查理,她從來沒有見過誰,而是誰聲稱是鮑勃的朋友。事實上,證明他的朋友鮑勃,查理問鮑勃簽署自己與鮑勃的公鑰私鑰,并與他的消息(這個簽名圖4 - 4)。在這種情況下,愛麗絲首先檢查鮑勃的簽名的查理的關鍵。她知道鮑勃的公鑰,因而能夠確認鮑勃確實簽查理的關鍵。因為她相信鮑勃決定驗證查理,她接受消息和對查理的消??執行類似的完整性檢查,以確保它是,事實上,從查理。

圖片描述

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

網絡身份驗證和在瀏覽器中遵循相同的過程如圖所示。這意味著在這一點上你應該問:你的瀏覽器信任誰,你信任誰,是你本人在使用瀏覽器嗎?至少有三種回答這個問題:

手動指定證書
所有瀏覽器和操作系統提供了一種機制讓你手動導入任何你信任的證書。你如何獲得證書并驗證其完整性是完全取決于你。

證書頒發機構
一個證書頒發機構(CA)是一個受信任的第三方信任的證書的主體(所有者)。

瀏覽器和操作系統
每一個操作系統和大多數瀏覽器附帶一個知名證書頒發機構列表。因此,您應該相信這個軟件的供應商提供和維護的信任方列表。

在實踐中,手動的去儲存每個網站證書是不切實際(盡管你可以)。因此,最常見的解決方案是使用證書頒發機構(ca)為我們做這個工作(圖4 - 5):瀏覽器指定ca信任(根ca), 中科院的作用就是用來驗證每個站點的sign,審計和驗證這些證書不被誤用或妥協。如果任何站點的安全與CA的證書被打破,那么它的責任,CA撤銷妥協證書。

圖片描述

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

圖片描述

StartCom類1主要中間服務器證書簽署的StartCom認證權威。

StartCom認證中心是公認的根證書頒發機構。

整個鏈的“信任錨”是根證書權威,這只是顯示,StartCom認證權威。所有瀏覽器附帶一個預表受信任的證書頒發機構(“根”),在這種情況下,瀏覽器信托和能夠驗證StartCom根證書。因此,通過傳遞信任鏈的瀏覽器,瀏覽器廠商和StartCom證書頒發機構,我們擴展信任我們的目的地網站。

證書的透明度

每一個操作系統供應商和每一個瀏覽器提供一個他們信任并且公開上市的默認證書頒發機構。可以搜索引擎來查找和調查這些列表。在實踐中,你會發現大多數系統依賴數以百計的受信任的證書頒發機構,這也是一個對系統常見的抱怨:大量的受信任的ca在您的瀏覽器中創建一個大型攻擊表面積的信任鏈。

好消息是,證書的透明度項目正在努力解決這些缺陷通過提供一個框架公開日志監控和審核發行的新證書。訪問項目網站,了解更多信息。

證書撤銷

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

圖片描述

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

證書撤銷列表(CRL)

證書撤銷列表(CRL)由RFC 5280定義和指定了一個簡單的機制來檢查每一個證書的狀態:每個證書頒發機構維護和定期發布撤銷證書編號的列表。任何一個試圖驗證證書的人就能下載撤銷列表,緩存,并檢查特定序列號的存在,如果它存在,那么它被撤銷。

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

越來越多的撤銷簽證意味著CRL列表只會變得更長,和每個客戶端必須獲取序列號的完整列表。

沒有即時通知證書機制revocation-if CRL證書被撤銷前由客戶端緩存,然后CRL認為撤銷證書有效,直到緩存到期。

需要獲取最新的CRL, CA可能會阻止證書驗證列表,這將顯著延長TLS握手時間。

CRL獲取可能會失敗,由于各種原因,在這種情況下,瀏覽器的行為是未定義的。大多數瀏覽器把這種情況下定義為“軟失敗”,允許驗證proceed-yes。

在線證書狀態協議(OCSP)

解決一些CRL機制的局限性,介紹了在線證書狀態協議(OCSP)由RFC 2560,這提供了一種機制來執行一個實時檢查證書的狀態。不像CRL文件,其中包含所有的撤銷序列號,OCSP允許客戶端直接查詢CA的證書數據庫序列號的問題,同時驗證證書鏈。

因此,消耗更少的帶寬和OCSP機制能夠提供實時驗證。然而,要求執行實時OCSP查詢創建自己的一組問題:

CA必須能夠處理負載的實時查詢。

CA必須確保服務和全局可用。

實時OCSP請求可能損害客戶的隱私因為CA知道哪些網站客戶端訪問。

客戶端必須阻止OCSP請求而驗證證書鏈。

瀏覽器行為,再一次,未定義,通常導致“軟失敗”如果OCSP獲取失敗由于網絡超時或其他錯誤。

作為一個現實世界的數據點,Firefox遙測表明OCSP請求時間高達15%的時間,并添加TLS握手當successful-see大約350毫秒hpbn.co / ocsp-performance.

OCSP裝訂

上面列出的原因,無論是CRL或OSCP撤銷機制提供了安全性和性能保證我們渴望我們的應用程序。但是,不要絕望,因為OCSP裝訂(RFC 6066,“證書狀態請求”擴展)解決了大部分的問題我們之前看到通過允許執行驗證的服務器和發送(“釘”)的TLS握手到客戶端:

而不是客戶OCSP請求,服務器,定期檢索簽署和時間戳OCSP CA的響應。

然后,服務器(即附加內容。“主食”)簽署了OCSP響應作為TLS握手的一部分,允許客戶端驗證證書和附加OCSP撤銷CA簽署的記錄。

這角色轉換是安全的,因為ping CA簽署的記錄,可以由客戶端驗證,并提供一些重要的好處:

客戶不會流失,其導航歷史。

客戶端沒有阻止和查詢OCSP服務器。

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

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

TLS協議記錄

不同的IP或TCP層下面,TLS會話中的所有數據交換框架使用一個定義良好的協議(圖4 - 8)。TLS協議記錄負責識別不同類型的消息(握手、警告或數據通過“內容類型”字段),以及保護和驗證每個消息的完整性。

圖片描述

圖4 - 8。TLS記錄結構
交付應用程序的典型工作流數據如下:

記錄協議接收應用程序數據。

接收的數據分為塊:最多214字節,或16 KB /記錄。

消息驗證碼(MAC)或HMAC被添加到每個記錄。

數據在每個記錄是使用協商加密密碼。

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

好消息是,所有的工作就顯示由TLS層本身,對于大多數應用程序是完全透明的。然而,記錄協議并介紹幾個重要的意義,我們需要注意的:

最大TLS記錄大小是16 KB

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

解密和驗證記錄,整個記錄必須是可用的。

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

優化TLS

部署您的應用程序在TLS需要一些額外的工作,在您的應用程序(如資源遷移到HTTPS以避免混合內容),以及基礎設施的配置負責交付應用程序數據在TLS。調整部署可以使一個巨大的不同凡響的觀測性能,用戶體驗,和整體運營成本。就讓我們一探究竟吧。

降低計算成本

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

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

2010年1月,Gmail將默認為所有使用HTTPS。之前它被引入作為一個選項,但現在我們所有的用戶使用HTTPS來保護他們的瀏覽器和谷歌之間他們的電子郵件,所有的時間。為了做到這一點我們還沒有部署額外的機器,沒有特殊硬件。在我們的前端生產環境服務器機,SSL / TLS占不到1%的CPU負載、每個連接不到10 KB的內存和不到2%的網絡開銷。許多人認為,SSL / TLS需要大量的CPU時間,我們希望前面的數字(公共)可以幫助大家打消那個誤解。

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

亞當·蘭利(谷歌)
我們在大規模部署TLS使用硬件和軟件負載平衡器。我們發現,現代的基于軟件的TLS實現產品, 高速cpu來處理大量HTTPS流量負載,而不需要采取專門的加密硬件。我們的服務所有的HTTPS都使用軟件來運行.

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

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

談到優化CPU周期,請一定要保持你的服務器更新與TLS庫的最新版本!除了安全改進,你也會經常看到性能優勢。安全性和性能是密不可分的。

啟用 1-RTT TLS握手

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

調優的TLS部署應該最多添加一個額外的往返談判TLS連接,不管它是新的或恢復,并避免其他延遲陷阱:配置會話恢復,并使向前保密支持TLS FALSE Start。

要獲得最佳的端到端性能,確保審計自己的和第三方服務和服務器所使用的應用程序,包括你的CDN提供商。快速,與流行的服務器和發布商的概述,請查看istlsfastyet.com.

優化連接重用

最好的方法減少計算開銷和延遲設置新的TCP + TLS連接優化連接重用。這樣平攤到了設置成本在請求和向用戶提供更快的體驗。

驗證您的服務器和代理配置設置允許keepalive連接,和審計連接超時設置。許多流行的服務器組積極的連接超時(例如Apache版本默認為5 s超時),迫使很多不必要的協議。為達到最佳效果,使用你的日志和分析來確定最優超時值。

利用提前終止

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

圖片描述

圖4 - 9日。客戶端連接的早期終止
一個簡單的方法來做到這一點是利用內容分發網絡(CDN)的服務,維護全球的邊緣服務器池,或者自己部署。通過允許用戶終止與附近的服務器,而不是穿越在海洋和大陸鏈接你的來源,客戶得到的好處與短循環“提前終止”。這種技術同樣是有用的和重要的靜態和動態內容:靜態內容也可以由邊緣服務器緩存,而動態請求可以在建立路由連接從邊緣到原點。

CDN獲取資源

使用CDN技術或代理服務器來獲取資源,這可能需要每個用戶定制的或包含其它私人數據,因此不是一個全球緩存資源的優勢,通常被稱為一個“未取回起源。”

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

事實上,作為一個額外的一層優化,附近一些CDN提供商使用服務器連接兩岸的!客戶端連接終止在附近的一個CDN節點,然后將請求到CDN節點接近原點,然后請求被路由到原點。跳在CDN網絡允許流量路由優化CDN骨干,這有助于進一步減少客戶端和起源服務器之間的延遲。

配置會話緩存和無狀態恢復

終止接近用戶的連接是一種優化,有助于降低延遲為用戶在所有情況下,但再一次,沒有一點比一點快sent-send更少的比特。支持TLS會話緩存和無狀態恢復允許我們消除整個往返重復訪客的延遲和減少計算開銷。

會話標識符,TLS會話緩存依賴,介紹了SSL寬2.0,大多數客戶端和服務器的支持。然而,如果你是在您的服務器上配置TLS,不要認為會話將在默認情況下支持。事實上,它是更常見的在大多數服務器的默認設置你知道更好!仔細檢查并驗證您的服務器、代理和CDN配置:

服務器有多個進程或員工應該使用一個共享會話緩存。

共享會話緩存的大小應該調整你的交通水平。

應提供會話超時時間。

在一個多服務器的設置中,客戶端IP路由一樣,或TLS會話ID相同,相同的服務器是一種提供良好的會話緩存利用率。

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

檢查和監控你的TLS會話緩存統計數據最佳性能。

在實踐中,為達到最佳效果,你應配置兩個會話緩存機制和會話ticket。這些機制共同努力,為新老客戶提供最好的報道。

支持TLS False Start

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

得到最好的兩個全世界一個往返握手為新和重復訪客,和計算節省重復visitors-we可以使用TLS FALSE Start,這是一個可選的擴展協議,允許發送方發送應用程序數據(圖4到10)握手時只有部分完成。

圖片描述

圖4到10。TLS握手與錯誤的開始
FALSE Start不修改TLS握手協議,相反,它只會影響協議的時機當應用程序可以發送數據。直觀地說,一旦客戶端發送 ClientKeyExchange記錄,它已經知道加密密鑰,就可以開始發送應用程序數據,剩下的握手是花握手確認沒有人篡改記錄,并且可以并行完成的。因此,錯誤的開始讓我們保持TLS握手一次往返不管我們是否執行一個完整的或縮寫握手。

部署TLS False Start

因為錯誤的開始只是握手協議的修改時間,它不需要任何更新TLS協議本身和可以unilaterally-i.e實現。,客戶端可以開始傳輸加密的應用程序數據。理論上是這樣的。

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

Chrome和Firefox需要ALPN協議聲明出現在服務器的握手,和選擇的密碼套件服務器使保密。

Safari要求密碼組合要求服務器支持向前保密。

Internet Explorer使用黑名單的網站的結合,打破啟用TLS False Start 時,和一個超時重復握手如果TLS FALSE Start握手失敗了。

所有瀏覽器支持TLS FALSE Start服務器應該做廣告支持的協議的列表通過ALPN extension-e.g。“h2,http / 1.1”——被配置為支持和更喜歡密碼套件,使保密。

優化TLS記錄大小

所有應用程序數據通過TLS內運輸記錄協議(圖4 - 8)。每個記錄是16 KB的最大大小,取決于所選的密碼,每個記錄將增加20到40字節的頭開銷,MAC和可選的填充。如果記錄符合一個TCP數據包,然后我們還必須添加TCP / IP開銷:IP 20-byte頭,20-byte頭不為TCP選項。因此,有可能為每一個記錄60到100字節的開銷。對于一個典型的最大傳輸單元(MTU)線大小為1500字節,這包結構轉化為最小幀開銷的6%。

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

圖片描述

圖4。WireShark捕獲的11211字節的TLS記錄分歧8 TCP段
小記錄產生開銷,大型記錄產生延遲,沒有一個“最優”記錄的值大小。相反,為web應用程序,使用瀏覽器,最好的策略是動態調整記錄大小基于TCP連接的狀態:

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

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

如果TCP連接一直閑置,即使慢啟動重啟服務器上禁用,最好的策略是減少數據的記錄大小在發送一個新的破裂:條件可能改變了自去年傳播,我們的目標是最小化的概率緩沖在應用程序層由于丟包,重新排序,重發。

使用一個動態交互式交通戰略提供最佳性能:小記錄大小可以消除不必要的緩沖延遲和提高time-to-first - { HTML字節,…,視頻幀},和一個更大的記錄大小優化吞吐量為長壽流TLS的開銷最小化。

確定最優記錄大小為每個狀態讓我們從最初的開始一個新的或閑置的TCP連接,我們希望避免TLS記錄跨越多個TCP數據包:

IPv4分配20字節幀開銷和40個字節為IPv6。

為TCP框架的開銷分配20字節。

分配40字節TCP選項開銷(時間戳,袋)。

假設一個常見的1500字節的MTU開始,這使得1420字節的TLS記錄交付在IPv4,并為IPv6 1400字節。不會過時的技術,使用IPv6大小,留下1400字節為每個TLS記錄,并根據需要調整如果你的MTU低。

接下來,決定當記錄大小應該增加和復位如果連接一直閑置,可以設置基于預配置的閾值:記錄大小增加到16 KB XKB的數據傳輸,重置后記錄大小 Y空閑時間的毫秒。

通常情況下,配置TLS記錄大小不是我們可以控制在應用程序層。相反,通常這是一個設置,有時TLS服務器的編譯時常量。檢查您的服務器的文檔有關如何配置這些值。

TLS在谷歌優化

2014年初,谷歌的服務器使用小TLS記錄,符合一個TCP段第一1 MB的數據,記錄大小增加到16 KB之后優化吞吐量,然后重置記錄大小回到一段inactivity-lather一秒鐘之后,沖洗,重復。

同樣,如果您的服務器處理大量的TLS連接,然后最小化優化內存使用每個連接可以是至關重要的。默認情況下,OpenSSL等流行的庫將50 KB的內存分配每個連接,但與記錄大小,它可能值得檢查文件或源代碼如何調整這個值。谷歌服務器減少OpenSSL緩沖區下降到5 KB。

優化證書鏈

驗證信任鏈遍歷鏈要求瀏覽器,從網站的證書,并遞歸地驗證證書的父母,直到達到一個可信的根。因此,它是至關重要的,提供鏈包括所有中級證書。如果有遺漏,瀏覽器將被迫暫停驗證過程和獲取丟失的證書,添加額外的DNS查找,TCP握手和HTTP請求到流程中。

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

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

在實踐中,證書鏈的大小和深度是一個更大的擔憂和問題在舊TCP堆棧初始化其初始4 TCP segments-see擁塞窗口慢啟動。對于更新的部署,最初的TCP擁塞窗口已經提高到10段,應該足夠大多數證書鏈。

也就是說,驗證您的服務器使用的是最新的TCP協議棧和設置,并優化,減少你的證書鏈的大小。少發送字節總是良好的和有價值的優化。

配置OCSP裝訂

每一個新的TLS連接要求,瀏覽器必須驗證發送的簽名證書鏈。然而,還有一個重要的步驟,我們不能忘記:瀏覽器也需要驗證證書沒有被撤銷。

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

OCSP響應可以改變從400年到4000字節大小。裝訂這個響應你的證書鏈將增加其size-pay密切關注證書鏈的總大小,這樣它不會溢出的初始擁塞窗口新的TCP連接。

當前OCSP裝訂實現只允許一個單一的OCSP響應包含,這意味著瀏覽器可能要回退到另一個如果它需要驗證其他證書撤銷機制的chain-reduce證書鏈的長度。在未來,OCSP Multi-Stapling應該解決這個問題。

最受歡迎的服務器支持OCSP裝訂。檢查相關文檔的支持和配置說明。同樣,如果使用或決定一個CDN,檢查他們的TLS堆棧支持和配置為使用OCSP裝訂。

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

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

所有請求的起源應該發送/ HTTPS。這包括導航和所有其他同源子資源requests-e.g。如果用戶類型沒有https URL前綴用戶代理應該自動將它轉換成一個https請求;如果一個頁面包含一個引用非http資源,用戶代理應該自動轉換成請求https版本。

如果不能建立一個安全連接,用戶不允許繞過HTTP version-i.e警告和請求。origin的協議是是https。

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

includeSubdomains表明當前的政策應該適用于所有子域。

hst origin 轉換為一個https目的地和幫助保護應用程序從各種各樣的被動和主動網絡的攻擊。還有一個額外的好處,它還提供了一個不錯的性能優化通過消除需要HTTP-to-HTTPS重定向:客戶端自動重寫所有請求安全起源之前派遣!

確保啟用hst之前徹底地測試您的TLS部署。一旦政策是由客戶端緩存,未能協商將導致hard-fail-i.e TLS連接。用戶將看到瀏覽器錯誤頁面,不會被允許繼續下去。這種行為是明確的和必要的設計選擇,以防止網絡攻擊者騙取客戶沒有HTTPS訪問你的網站。

hst預加載列表

hst機制留下第一個請求的來源不受保護的積極attacks-e.g。惡意方可以降低客戶的請求,并防止它注冊hst政策。為了解決這個問題,大多數瀏覽器提供一個單獨的“hst預加載列表”機制,該機制允許一個起源請求包含列表中的HSTS-enabled附帶瀏覽器的網站。

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

啟用 HTTP Public Key Pinning (HPKP)

的缺點之一,當前系統中討論鏈的信任和證書頒發機構是我們的依賴大量的受信任的證書頒發機構(CA)。一方面,這是方便的,因為它意味著我們可以獲得一個有效的證書從一個大池的實體。然而,這也意味著其中任何一個實體也能夠發出有效的證書給我們

DigiNotar認證權威的妥協的引人注目的例子之一是一個攻擊者能夠發行和使用虛假但有效證件與數以百計的高調的網站。

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

origin可以銷毀葉證書。這是最安全的策略,因為,實際上,硬編碼一個小的特定證書簽名應該接受瀏覽器。

父的起源可以銷一個證書的證書鏈。例如,原點可以銷中級證書的CA,告訴瀏覽器,這個特殊的起源,它應該只信任證書簽署的證書頒發機構。

銷哪個證書,選擇正確的戰略和多少備份提供,時間,和其他標準部署HPKP是重要的,微妙的,超出了我們的討論范圍。咨詢你的最喜歡的搜索引擎,或者你當地的安全專家,以獲取更多信息。

HPKP還公開一個“報告”模式,不執行提供銷但能夠檢測到故障報告。這是一個偉大的第一步驗證您的部署,和作為一種機制來檢測違規。

更新網站內容,HTTPS

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

將被瀏覽器混合的“活躍”內容(如HTTP上的腳本和樣式表傳遞)可能會破壞網站的功能。

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

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

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

性能檢查表

作為應用程序開發人員我們免受大多數TLS協議的復雜性客戶機和服務器代表我們做最困難的工作。然而,正如我們在本章中看到的,這并不意味著我們可以忽視在TLS交付我們的應用程序的性能方面。優化我們的服務器,使關鍵TLS優化和配置應用程序啟用客戶端利用這些特性支付高額股息:更快的握手,減少延遲,更好的安全保障,等等。

考慮到這一點,一個簡短的清單放在議事日程:

從TCP獲得最佳性能;請參閱優化TCP.

TLS庫升級到最新版本,和(重新)構建服務器。

啟用和配置會話緩存和無狀態的恢復。

監控你的會話緩存命中率,并相應地調整配置。

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

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

使用動態TLS記錄分級優化延遲和吞吐量。

審計和優化你的證書鏈的大小。

配置OCSP裝訂。

配置hst和HPKP。

配置CSP的政策。

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

測試和驗證

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

$ > openssl s_client狀態-CAfile startssl.ca。crt連接igvita.com:443

連接(00000003)
SSL_connect:前/連接初始化
SSL_connect:SSLv2的站點時/ v3寫客戶你好
SSL_connect:SSLv3讀服務器你好
深度= 2 / C = IL / O = StartCom有限公司/ OU =安全數字證書簽名
/ CN = StartCom認證權威
驗證返回:1
深度= 1 / C = IL / O = StartCom有限公司/ OU =安全數字證書簽名
/ CN = StartCom類1主要中間服務器
驗證返回:1
深度= 0 = ABjQuqt3nPv7ebEG /描述/ C =
/ CN =www.igvita.com/emailAddress=ilya@igvita.com
驗證返回:1
SSL_connect:SSLv3讀服務器證書
SSL_connect:SSLv3讀服務器做了
  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)
  ---

客戶端完成驗證收到的證書鏈。
收到證書鏈(兩個證書)。
收到了證書鏈的大小。
發布了有狀態的會話標識符TLS的簡歷。
在前面的例子中,我們連接igvita.com在默認的TLS端口(443),并執行TLS握手。因為 s_client沒有假設已知的根證書,我們手動指定路徑StartSSL證書的根證書Authority-this是很重要的。瀏覽器已經StartSSL的根證書,因此能夠驗證鏈,但是 s_client沒有這樣的假設。試著刪除根證書,你將看到一個驗證錯誤日志中。

檢查證書鏈顯示服務器發送兩個證書,加起來3571個字節。同時,我們可以看到協商會話variables-chosen TLS協議,密碼,鑰匙,我們還可以看到服務器發布當前會話的會話標識符。

outshineamaze: 時間匆忙, 如有錯誤, 多多包涵