傳輸層安全性(Transport Layer Security,TLS)-譯

原文: 高性能網絡瀏覽器-第四章傳輸層安全性(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。

圖4 - 6。信任的證書鏈爲igvita.com(Google Chrome,25節)
igvita.com證書籤署StartCom類1主要中間服務器。

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...
告訴瀏覽器升級全部(本身的和第三方)請求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: 時間匆忙, 若有錯誤, 多多包涵