TLS/SSL 高級進階

時間 2019-11-07

標籤 tls ssl 高級進階欄目 SSL 简体版

原文原文鏈接

TLS/SLL 是如今網絡安全通訊比較重要的一環，經過一些列的 key 交換和 key 生成，最終確立加密通道的整個流程。衆所周知，TLS/SSL 耗費的時間也是挺可觀的，相對於 TCP 的3次 RTT 來講，若是加上 TLS/SSL, 則總的 RTT 時間至少爲 4 次。雖然看起來不少，但若是相對於如今的網絡環境來講，大概也就每次 20~30ms，這樣算下來，估計也就 100ms 左右。這樣的時間差仍是能夠忍受的，不過，這裏還沒算入 DNS 解析，這個暫時不考慮。並且，TLS/SSL 生成的 sessionkey 若是在有效期內的話，那麼這個時間就能夠徹底忽略掉了。很少說了，咱們直接來看下 TLS/SSL 的基本內容。linux

TLS 算法

TLS/SSL 其實就是經過非對稱加密，生成對稱加密的 sessionkey 的過程。對稱加密的算法無外乎就 AES，或者使用 Cipher/Decipher 模塊。而非對稱加密經常使用的就是 RSA，不過也有使用 Diffie-Hellman (迪菲)。但，較安全性來講，DH 要高一些。由於，RSA 在生成 sessionkey 時，最後是由 browser 生成，而後經過 public key 加密後傳給 server 的，這樣存在必定的問題是，若是 hacker 獲得了 private key，那麼，他能夠全程監控流量，而後使用 private key 進行解密，那麼可想而知，sessionkey 也就暴露了。
但對於 DH 來講，它機制的不一樣點在於，sessionkey 不會經過網絡傳輸，而是在兩端獨立生成的。ok~ 這就涉及到兩個 key 的一致性問題。DH 還有一個機制，即，前向安全性(perfect forward secrecy--PFS)：server 端的 private key，不能用來代替之前任何一把的 sessionkey，因此，也沒法破解之前任何一次的 session 內容。每次鏈接，DH 都會從新生成一個 key，而且當該次 session 結束時，丟棄它。不過，這並非很大的問題，由於 DH 能很快的生成 key。由於它耗費在網絡上的時間相比於 RSA 來講少了一半。能夠從下圖簡單瞭解 DH 的加密算法：nginx

簡單來講，兩邊經過一次的信息交換，完成了密鑰生成。由於 sessionkey 是獨立放在兩端的，爲了達到一致性，每次鏈接時，DH 都須要從新協商生成 sessionkey。如今有個問題是：爲何必定要有 session key，他存在的意義是什麼？git

sessionkey 用途

TLS/SSL 其實就是經過非對稱加密，生成對稱加密的 session key 的過程程序員

那 session key 主要又幹了什麼呢？
首先，咱們要先明確，session key 是用來進行對稱加密的，這種加密方式主要使用到的是 AES 加密算法。這不一樣於 Elliptic Curve Diffie-Hellman (ECDH) 這種非對稱加密算法。二者其實均可以用來對信息進行加密，但因爲算法內部的實現機理不一樣，他們所用的時間也是不同的。基本上是，ECDH 所用的時間是 AES 的 3 倍。github

你能夠自行測試一下：算法

openssl speed ecdh
openssl speed aes

ok,上面大概簡述了 TLS/SSL 所用到的算法。接下來，咱們來了解一下，具體 TLS/SSL 密鑰交換的過程。瀏覽器

TLS/SLL 過程

在詳述過程以前，咱們須要瞭解一下，在過程當中會出現的內容。緩存

session key: 這是 TLS/SSL 最後協商的結果，用來進行對稱加密。安全
client random: 是一個 32B 的序列值，每次鏈接來時，都會動態生成，即，每次鏈接生成的值都不會同樣。由於，他包含了 4B 的時間戳和 28B 的隨機數。
server random: 和 client random 同樣，只是是由 server 端生成。
premaster secret: 這是 48B 的 blob 數據。它能和 client & server random 經過 pseudorandom (PRF) 一塊兒生成 session key。
cipher suite: 用來定義 TLS 鏈接用到的算法。一般有 4 部分：
- 非對稱加密 (ECDH 或 RSA)
- 證書驗證 (證書的類型)
- 保密性 (對稱加密算法)
- 數據完整性 (產生 hash 的函數)
  好比 AES128-SHA 表明着：
  - RSA 算法進行非對稱加密
  - RSA 進行證書驗證
  - 128bit AES 對稱加密
  - 160bit SHA 數據加密算法
- 好比 ECDHE-ECDSA-AES256-GCM-SHA384 表明着
  - ECDHE 算法進行非對稱加密
  - ECDSA 進行證書驗證
  - 265bit AES 對稱加密
  - 384bit SHA 數據加密算法

相信你們對這張圖已經很熟悉了：

不過，上面不是說了有兩種不一樣的非對稱加密方式嗎？ RSA & DH？那爲何圖只是一個嘞？
ok，實際上這圖沒錯，他並無把傳輸的內容是什麼寫出來，這很關鍵。而兩種算法也是在傳輸內容上區分開的，基本的過程是徹底同樣的。根據 wiki 的解釋，咱們大概能知道整個傳輸過程須要的內容。

客戶端發送 clientHello 信息，包含了客戶端支持的最高 TLS 協議版本，random num (上文提到過)，cipher suite。若是，客戶端使用 resumed handshake，那麼這裏發送的就是 sessionID。若是，客戶端還支持 ALPN，那麼它應該還須要發送它所支持的其餘協議，好比 HTTP/2.
在 server 端進行 serverhello 階段，這裏 server 根據 client 發送過來的相關信息，採起不一樣的策略，一樣會發送和 client 端匹配的 TLS 最高版本信息，cipher suite 和本身產生的 random num. 而且，這裏會產生該次鏈接獨一無二的 sessionID。
經過 certificate 階段，會在信息流中加入 public key certification。ServerKeyExchange 該階段，主要是針對於 ECDH 加密方式，這裏就不贅述，後面再進行講解。
serverHelloDone 標識這 server 階段處理結束，將該階段產生的信息發送給 client。
在 clientKeyExchange 階段時，client 會隨機生成一串 pre-master secret 序列，而且會經由 public key 加密,而後發送給 server。在 ChangeCipherSpec 階段，主要是 client 本身，經過 pre-master secret + server random-num + client random-num 生成 sessionKey。這就標識着，此時在 client 端，TLS/SSL 過程已經接近尾聲。
後面在 server 端進行的 ChangeCipherSpec 和 client 進行的差很少，經過使用 private key 解密 client 傳過來的 pre-master secret ,而後生成 sessionkey。後面再經過一次驗證，使用 session Key 加密 server finshed，發送給 client，觀察可以成功解密，來表示最終的 TLS/SSL 完成。

上面主要是根據 RSA 加密方式來說解的。由於 RSA 纔會在 TLS/SSL 過程當中，將 pre-master secret 顯示的進行傳輸，這樣的結果有可能形成，hacker 拿到了 private key 那麼他也能夠生成如出一轍的 sessionKey。即，該次鏈接的安全性就沒了。

接下來，咱們主要講解一下另一種加密方式 DH。它和 RSA 的主要區別就是，到底傳不傳 pre-master secret。RSA 傳而 DH 不傳。

根據 cloudflare 的講解能夠清楚的瞭解到二者的區別：

這是 RSA 的傳輸方式，基本過程如上述。

而 DH 具體區別在下圖：

這裏先補充一下 DH 算法的知識。由於，pre-master secret 就是根據這個生成的。DH 基本過程也不算太難，詳情能夠參考 wiki。它主要運用到的公式就是:

爲了防止在 DH 參數交換時，數據過大，DH 使用的是取模數的方式，這樣就能限制傳輸的值永遠在 [1,p-1]。這裏，先說明一下 DH 算法的基本條件：

公共條件： p 和 g 都是已知，而且公開。即，第三方也能夠隨便獲取到。
私有條件： a 和 b 是兩端本身生成的，第三方獲取不到。

基本流程就是：

咱們只要把上圖的 DH parameter 替換爲相對應的 X/Y 便可。而最後的 Z 就是咱們想要的 Premaster secret。以後，就和 RSA 加密算法一致，加上兩邊的 random-num 生成 sessionKey。經過，咱們經常稱 DH 也叫做 Ephemeral Diffie-Hellman handshake。由於，他每次一的 sessionKey 都是不一樣的。

而 RSA 和 DH 二者之間的具體的區別就在於：RSA 會將 premaster secret 顯示的傳輸，這樣有可能會形成私鑰泄露引發的安全問題。而 DH 不會將 premaster secret 顯示的傳輸。

TLS/SSL 中的基本概念

上面內容大概講清楚了基本的 TLS/SSL 的加密過程。不過，其中，還有不少其餘的小細節，好比 SNI，ALPN，Forward Secrey。接下來，咱們主要將這些細節將一下，由於他們其實也很重要。

Forward Secrey

FS(Forward Secrey) 主要是針對 private key 進行描述了。若是你的 private key 可以用來破解之前通訊的 session 內容，好比，經過 private key 破解你的 premaster secret ，獲得了 sessionKey，就能夠解密傳輸內容了。這種狀況就是 non-forward-secrey。那如何作到 FS 呢？很簡單，上文也已經提到過了，使用 DH 加密方式便可。由於，最後生成的 sessionKey 和 private key 並無直接關係，premaster secret 是經過 g(ab) mod P 獲得的。

簡單的說就是，若是你想要啓用 FS，那麼你應該使用的是 DH 加密方式，而放棄 RSA。不過，因爲歷史緣由（TLS 版本問題），RSA 如今還算是主流的加密方式。但，DH 也憑藉他 5S 的安全性，份額也在增長。

ALPN

ALPN 全稱是 Application Layer Protocol Negotiation（應用層協議協商機制）。看到應用層，程序員們應該都能反應出 OSI 7層網絡協議。在應用層中，HTTP 協議應該是重點。不過，因爲 HTTP 版本的問題，以及如今 HTTP2 的流行，爲了讓 client-server 使用相同的協議而出現了 ALPN。ALPN 其實是從 SPDY 中的 NPN 協議衍生出來的。不過，它們倆的機制正好相反。

NPN：由 server 端告訴 client，它支持什麼協議，而後 client 確認支持的協議後，開始進行鏈接。
ALPN：在 TLS 階段，由 client 告訴 server，它所支持的全部協議，而後開始進行鏈接。

總的來講，NPN 已經退出歷史的舞臺了。。。ALPN 如今是 IETF 指定的標準協議。ALPN 在 TLS 具體的過程是：

在 clientHello 階段，client 會在 message 中，添加一個 ProtocolNameList 字段。用來表示它所支持的協議列表
server 端在 serverHello 階段，處理 client 提供的 ProtocolNameList。而且選擇最高版本的協議，執行。將選擇信息添加到 serverhello 內。

SNI

SNI 的全稱爲：Server Name Indication。該機制的提出的意義是，當有一個 server 同時處理了不少個 host 時。至關於，一個 IP 映射多個域名，但，因爲證書只能對一個 3 級域名有效，因此，針對於多個 host 來講，server 爲了能同時兼顧這些域名。一種簡單的辦法就是重定向到指定域名，若是都想支持的話，也行，掏錢本身多買幾個證書（真土豪）。若是，你很土豪的話，如今就有這樣的狀況，一個 IP 服務器下，搭載了支持多個域名的 server，而且每一個域名都有合法的 CA 證書。那麼，server 怎麼判斷，哪個域名用哪個證書呢？這時候，就須要用到 SNI。至關於在 TLS 階段，將 host 一併發送過去，而後 server 就知道在 serverhello 階段該返回啥證書了。
如今，有個問題，爲何必定要用 SNI 呢？
咱們回想一下，這裏咱們僅僅只是創建 TCP + TLS 鏈接，客戶端的一些內容，好比 hostname，咱們並不能在 TCP 中得到。而，想要得到的話，就須要等到 HTTP 階段，得到 client 傳過來的 host 或 origin 字段。因此，爲了解決這個比較尷尬的點，就提出了 SNI。

Session Resumption

感受能看到這裏的人，應該都是閒的蛋疼的人。。。若是讓我來看這篇文章，估計看幾張圖，我基本上就直接關網站了。由於，這實在是複雜。而且，上面說的只是協議上的複雜性，對於計算機來講，只須要記下每一次該發什麼東西而已，但真正讓 Computer 感到蛋疼的是，key 的計算。特別是 random key 和 premaster secret 動不動就是 32B，48B 的數據量。因此，爲了真正減小計算機的工做量（其實是 server），提出了 Session ID 和 Session Tickets，來將成功進行鏈接的 session 內容緩存起來。

Session ID

Session ID 是 server 將上一次成功鏈接的 session 內容存在本身的硬盤裏面。這裏，就不涉及對 session data 的二次加密。基本的過程是：

client 端在 clientHello 階段，將 random num，TLS protocol 和經過 hostname 匹配到的最新一次的 session ID 發送給 server 端。（也就是說，client 一樣須要存儲一份 session data）
server 接收到 session ID 後，在緩存中查找，若是找到，則直接進行 ChangeCipher 階段，開始生成sessionKey。而後，返回相同的 sessionID 便可。

那麼相對於徹底的 TLS/SSL 鏈接來講，這裏只用到了一次 RTT。那麼協議過程就變爲了：

Session Ticket

既然 Session ID 是爲了解決網絡時延和計算機性能問題，那麼 Session Ticket 又幹了什麼呢？
Session Ticket 和 Session ID 作的也是一樣的事情，server 將最新一次的 sesion data 經過二次加密，在上一次握手結束時傳遞過去，而後 client 將傳遞過來的信息保存。
這樣，利不利用緩存的 session data 這時，就取決於 client。若是該次的 session data 沒有過時，那麼 client 就會在 clientHello 階段將該數據發送過去，server 接受到以後，便開始進行解密而後，雙方生成 sessionKey，握手結束。
那 Session Ticket 和 Session ID 到底用哪個呢？
這估計得看你的業務狀況了，Session ID 注重的是節省性能，而損耗部分空間。Session Ticket 注重的是節省空間，而損耗部分性能。它們二者都能節省一次 RTT 時間，用誰，仍是得看你的服務器的具體狀況。

CA 證書詳情

前面大體說了 TLS/SSL 是怎樣運做的，以及有哪些鏈接方法。至關於，學畫一條線同樣，咱們如今只知道這條線該畫多長，但還不知道，這條線從哪裏畫。因此，接下來，咱們就須要來探討一下，兩端發生了什麼。其實也不難，主要仍是關於 CA 證書的存放和驗證。server 端的很簡單，就是把本身的 CA 證書發過來就 ok。但，client 驗證這個證書是否可信，會有點複雜。
首先，證書頒發機構就那麼一些，換句話理解就是，每一個證書頒發機構，就表明着一張 CA 證書。但，如今市面上的 HTTPS 網站，辣麼辣麼多，難道他們都用同一張證書？難道他們都有同樣的 pu/pr key? 那麼 HTTPS 安全還有用嗎？
因此，按照上面的推理，咱們的網站上的 HTTPS 證書，確定都是各不同的。通常來講，有 3 種類型的證書： DV（Domain Validation），OV（Organization Validation），EV（Extended Validation）。均價按照順序上升，因此，最便宜的就是 DV，這應該是咱們勤勞的貧苦大衆用得起的。它們之間具體的區別在於域名的支持上：

DV：就是我的證書嘛，基本支持的就是單域名和多域名，不支持泛域名（*.villainhr.com）。不過，看價格，好比我這個就是騰訊雲給的一個免費的 DV 證書，因此，就支持一個 3 級域名（https://www.villainhr.com）。若是是收費的，單/多域名應該都支持。
OV：就比較牛逼，面向企業的，多域名/泛域名都支持。
EV：屬於貴族用的，通常人也搞不到，主要它還須要去買個保險。。。

那咱們的證書在芸芸證書中，是處於哪個層級呢？
通常是三級。怎麼體現的呢？

那這麼多證書，咱們用的是哪個呢？固然是，最下面那個。由於每一個證書並非都被信任，因此客戶端首先就要了解一下，你這個證書可否用來進行驗證。若是不行的話，那麼你此次鏈接就是不被信任的，就沒有綠色的小鎖。這就須要瞭解一下，客戶端的驗證過程。

CA 鏈式驗證

首先，什麼叫作可信的證書呢？
咱們先要明白一個道理，HTTPS 是先創建在人與人之間的相互信任上，而後才創建在機器與機器的相互信任上。假如，根證書 A 機構，惡意的將一個之前頒發過的證書，又給了另一個不要臉攔截站點（好比，用來插廣告的）。這樣，我拿到了這個證書後，就能夠本身搭一個服務器，用來進行攔截瀏覽，監管裏你網站，並強行插廣告。這就被稱爲不可信的機構/證書。
而驗證的可行性，一般又跟機構的權威性有着極大的關係。它基本的驗證過程簡述就是（按照上面的層級）：

www.villainhr.com 問 TrustAsia DV SSL，個人證書可不可信？
可信！ok，繼續。TrustAsia DV SSL 問 VeriSign Class 3，個人證書可不可信
可信！ok，而後便開始 TLS/SSL 鏈接。

若是上述任一步驟出現問題，那麼該次 TLS/SSL 就不會進行，會回退。那麼它們在詢問的時候，會不會發送網絡請求呢？
不會~ 由於，電腦在初始化時，會自帶不少可信任的證書機構（即，Root CA），也就是咱們剛剛提到的 VeriSign Class 3 的證書機構。以及，可以簽發證書的二級機構（比較少）。到時候，瀏覽器會自動的根據數字簽名來進行證書的驗證。

CA 合法驗證

上面已經闡述了，CA 證書的合法性是自下而上的驗證方式。那麼它們具體驗證協議是怎樣的呢？
在說以前，咱們先說幾個概念：

數字簽名：它是用頒發機構的私鑰，對下級證書的公鑰進行加密生成的值。digital_sign = CA_pr_key + sub_Cer_ppu_key。
解密：用頒發機構的公鑰對數字簽名進行解密，對比下級證書的公鑰和解密後的值是否一致。

CA 驗證首先須要說一下它的頒發過程：

頒發機構 A，用本身的私鑰將須要生成的下級證書 B 的公鑰進行加密，生成數字簽名，而後再帶上相關信息：公鑰，公鑰的指紋，數字簽名，證書名，簽發機構等。

而後，驗證過程就是根據這個來的：

瀏覽器解析下級證書 B 的相關信息，找到簽發機構和數字簽名。
而後，找到簽發機構 A，使用 A 的公鑰去解密數字簽名，而後對比下級證書 B 的公鑰。若是成功則合法，反之，不合法。

而上面的三級證書層級，也是一樣的道理，自上而下的找就 ok。固然，有時候爲了驗證的速度，會作一些緩存，這樣就沒必要再進行驗證了。因此，根據上面的描述，有童鞋可能會想到，能不能自簽證書呢？反正，瀏覽器也是從本地找的。
固然能夠，openssl 就能夠生成你本身的 CA。不過須要注意的是，你生成的 CA 只是在你本身的電腦上使用，若是你想保證你的 CA 在其餘電腦上也能使用的話（這是不可能的），那就用錢砸就 ok。
具體的過程能夠參考：生成本身的 CA 證書。
之前，在使用 Charles 和 Fiddler 的時候，一直在想，它們是怎麼作到，將本身的證書，變成簽發機構證書。

後來發現，它是把證書中的相關字段該成它的證書內容。不過，對於某些高級證書，仍是會有一些問題，好比，wx.qq.com（微信的）

另外，爲了證書的可靠性，提出了 Certificate Transparency 項目，實際上，就是讓證書機構公開它的簽發流水。防止出現重複簽發。

證書的吊銷

如今有個問題，爲何證書有過時時間呢？
這一樣是爲了安全性，前面說過，若是你的證書發生了泄漏（實際上就是私鑰）。那麼，其餘服務器就能夠做爲一個代理去攔截你的流量。這時候，因爲過時的緣由，可能一段時間後，中間惡意的服務器就沒用了，另外，若是你發現了你遺失了證書，能夠向頒發機構去掛失。
另外，還有一個緣由是證書吊銷的 CRL 機制。簡單來講，就是有一個列表來記錄當前時間，該頒發機構被吊銷的證書 list。若是，沒有過時時間的話，那麼這個 list，會隨時間程指數增加，引入過時機制的話，該 list 只要記錄當前沒過時但吊銷的證書信息便可。
證書的吊銷有兩種機制：CRL，OCSP

CRL

CRL（Certificate Revocation List），即，證書吊銷列表。CA 機構會生成一個列表，列表裏面是當前週期被吊銷證書的序列號，當進行證書驗證時，一樣也會進行驗證該項。若是，已是吊銷證書的話，那麼該次 TLS/SSL 鏈接也會失敗。
咱們能夠從證書信息中找到 CRL URI:

該協議雖然簡單，但，缺陷仍是比較多的。

下載時間。由於該 list 不是自帶的，須要從頒發機構下載，這就形成了網絡時延。
緩存時間。若是存在緩存，就存在了信息不一樣步的問題，若是一個證書已通過期，但緩存中顯示的是未過時，那麼也是一個安全問題。

OCSP

OCSP（Online Certificate Status Protocol），即，在線證書狀態協議。它經過在線請求的方式來進行驗證，不須要下載整個 list，只須要將該證書的序列號發送給 CA 進行驗證。固然，驗證經過也會有必定的緩存期。不過，因爲驗證也會存在時延。另外，部署 OCSP 對 CA 也有必定的要求，CA 要搭建的一個服務器來接受驗證，而且，該服務器的性能要好（負載很大）。

OCSP stapling

OCSP stapling 常稱爲： TLS Certificate Status Request extension。是 OCSP 的另一種實現方式，由於前兩個（OCSP,CRL）都是由客戶端去驗證證書是否吊銷，而且都會發送請求。而 OCSPs（OCSP stapling）則是直接在 server 端，進行證書的有效性驗證。server 會週期性的向 CA 機構發送請求，驗證有效性，並在 certificate 階段，發送相應的簽名信息。不過，該協議是創建在，咱們徹底信任 serve 的狀況下，這裏就排除了一些惡意的中間服務器。詳情能夠參考：OCSP stapling。

TLS/SSL 優化

TLS/SSL 主要的性能調優簡單包括：啓用 False Start, OSCP Stapling, 選擇合適 cipher suite, resumption 等。另外，若是你追求 fashion, 那麼 HTTP/2 應該是個不錯的選擇。
想要作 TLS/SSL 優化，那麼你必須瞭解，TLS/SSL 握手的整個過程是什麼。固然，你能夠買個證書，從頭本身搭建一個服務器，可是，這樣只能證實 你頗有錢 外，其它也證實不了什麼。由於，這徹底能夠本身內網搭一個呀~ 能夠參考：10s 自建證書. 這裏，咱們結合 nginx 來具體對 TLS/SSL handshake 優化，作個總體的闡述。

設置 session 緩存

session 緩存設置可讓兩次的 RTT，變爲一次，這至關於快了一倍（不包括，密鑰計算等）。不一樣的 server 設置 session 的辦法有不少，這裏以 nginx 爲例。在 nginx 中，支持的是 Session ID 的形式，即在 server 中緩存之前 session 的加密內容。涉及的字段有兩個，ssl_session_cache 和 ssl_session_timeout。

ssl_session_cache：用來設置 session cache 上限值，以及是否在多個 worker 之間共享
ssl_session_timeout：用來設置 session cache 存儲的時間

看個 demo 吧：

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 20m;

表示的意思是：session cahce 會在不一樣的 worker 之間分享，假設 1MB 只能存儲 8000 次握手的信息。那麼， 10 MB 一共能夠存儲 80000 次握手信息。若是超出，則不會存儲。緩存信息存在時長爲 20分鐘。
另外，你也能夠開啓 session ticket。ST(session ticket) 須要一個sign 參數，使用 openssl 建立便可。

$ openssl rand 48 > ticket.key
# 在 nginx 中開啓
ssl_session_tickets on; 
ssl_session_ticket_key ticket.key;

選擇合適的 cipher suite

這裏先聲明一下，你的證書的內容和你的加密套件實際沒有半毛錢關係，這主要仍是取決於你的服務器的支持程度以及客戶端的支持度。另外，若是你想啓用 False Start，這也可套件的選擇有很大的關係。咱們來看一下若是設置吧。在 nginx 中，主要用到兩個指令：

ssl_prefer_server_ciphers on;
ssl_ciphers xxx;

ssl_prefer_server_ciphers: 用來告訴客戶端，要按照我提供的加密套件選擇。
ssl_ciphers: 具體設置的加密套件內容，使用 : 分隔。

支持性最高的就是使用：

// 讓瀏覽器來決定使用哪個套件(額。。。最後的手段)
ssl_ciphers  HIGH:!aNULL:!MD5;

通常狀況，仍是應該本身來決定使用哪個套件，這樣安不安全由本身說了算。具體能夠參考 mozilla 的套件配置。這裏簡單放一個，比較安全的，下面全部的套件都必須支持 Forwar Secrecy

ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5

不過，如下的加密套件，最好不要使用，由於基本上都不安全：

aNULL: 是一種非標準的 DH 密鑰交換套件。容易被中間人攻擊。
eNULL: 沒有加密方式，明文交換
EXPORT: 一種弱加密方式，老美那邊早期使用的
RC4: 使用已經廢棄的 ARCFOUR 算法
DES: 使用已經廢棄的 Data Encryption 標準
SSLv2: 老版本 SSL2.0 的加密套件（最少，你也寫 SSLv3 嘛）
MD5: 直接使用 MD5 加密方式

上面那些只能給一些遠古瀏覽器使用，基本上在選擇中是做爲墊底的選擇。

False Start

另外，怎麼在 nginx 中開啓 False Start 呢？這其實和服務器並無多大的關係，關鍵仍是你選擇的套件和 NPN/ALPN 協議的做用。

首先，你的加密套件必須具備 Forward Secrecy，不然開不了。
瀏覽器須要使用 NPN 或者 ALPN 告訴服務器，該所需的協議版本，而後再決定開不開啓。

那麼，在 nginx 中，咱們只要選擇好合適的加密套件便可。這裏就放一份現成的吧

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256::DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5';

使用 DH 密鑰交換

DH 的加密過程，上面已經說過了。DH 自帶兩個公共的參數，因此，這必須手動進行建立(實際上就是將參數 sign 一遍)。

// 建立一個 DH param
openssl dhparam 2048 -out dhparam.pem

而後，調用該文件

ssl_dhparam dhparam.pem;

這樣，你就正式的開啓的 DH 加密模式。若是你使用抓包工具觀察一下，此時 DH 應該會在 Server Hello 裏：

不過，因爲歷史緣由，DH param 已經使用的長度是 1024，好比: 採用 Oakley group 2 版本。如今，比較流行的 DH 加密方式是 ECDHE，它和之前的加密方式（DHE）比起來，在密鑰生成這塊會快不少。一樣，因爲歷史緣由，它的基本條件比較高：（其實也還好）

Android > 3.0.0
Java > 7
OpenSSL > 1.0.0

開啓 OCSP Stapling

OCSP Stapling 是驗證證書權威性的一種手段，前面還有兩種 CRL 和 OCSP。不過，它們都是讓 client 本身去驗證。而 OCSP Stapling 則把驗證這塊放到了 server 裏，經過按期檢查，來減小網絡時間中的消耗。要開啓 OCSP Stapling 首先是須要你證書的 chain 文件，該是用來詳細說明，從根證書到你的證書中間所要經歷的全部驗證（和其餘兩種驗證手段同樣）。那如何獲得 chain 文件呢？直接去問你的證書頒發機構，這個又不是啥祕密文件。若是是自發證書（本身測試用的），那就本身生成。將全部的中間證書按照 bottom to up 放到一個文件裏：

cat intermediate/certs/intermediate.cert.pem \
      certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem;

那麼 ca-chain.cert.pem 就是 OSCP stapling 驗證文件。而後在 nginx 開啓便可。

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate ca-chain.cert.pem;
resolver 8.8.8.8 8.8.4.4; // 默認使用 Google 的

關於 DNS 解析，一樣你也須要問一下證書提供商，固然，該值能夠不用管。下面也一樣適用

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate ca-chain.cert.pem;

開啓事後，你可使用 openssl s_client -connect www.yourDomainName.com:443 來測試一下，檢測是否開啓成功。

開啓 HSTS

HSTS（HTTP Strict Transport Security）實際上就是一個響應頭，沒啥很特別的，具體內容就是，你全部對外部的請求都是 https，因此這有一個問題，若是你的圖片地址是 http 的，那麼最終的結果，會變爲 https://xxx，有可能會形成資源丟失的狀況，因此，開不開啓還須要慎用。

Strict-Transport-Security: max-age=15768000 # 設定 6 個月的強制期

在有效時間內，客戶端都會嘗試使用 https 訪問你的站點，若是在這期限裏你的證書過時了，開不了 https。那麼，呵呵。

使用 SNI

SNI 就是針對一個 IP 手握不少張證書時，用到的協議機制，這主要是用來區分，不一樣的 host，使用不一樣的證書。SNI 詳情上面已經說過了，這裏就不贅述了。主要使用格式就是不一樣的 server_name 搭配不一樣的 certificate

server{
    server_name www.abc.com;
    ssl_certificate abc.crt;
    ssl_certificate_key abc.crt.key;
}
server{
    server_name www.def.com;
    ssl_certificate def.crt;
    ssl_certificate_key def.crt.key;
}

如何開啓呢？換個高版本的 nginx 就好了。你可使用 nginx -V 檢查你的 nginx 是否帶有

TLS SNI support enabled

完整示例

最後，放一份完整的吧：

server {
        listen 443 ssl http2; # 默認打開 http2
        listen [::]:443 ssl http2;

        ssl_certificate /etc/nginx/cert/bjornjohansen.no.certchain.crt;
        ssl_certificate_key /etc/nginx/cert/bjornjohansen.no.key;

        ssl_session_cache shared:SSL:10m;
        ssl_session_timeout 20m;

        ssl_prefer_server_ciphers on;

        ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;

        ssl_dhparam /etc/nginx/cert/dhparam.pem;

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

        ssl_stapling on;
        ssl_stapling_verify on;
        ssl_trusted_certificate /etc/nginx/cert/trustchain.crt;
        resolver 8.8.8.8 8.8.4.4; # 看狀況選擇 DNS IP

        #add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
        # 我通常不開 HSTS
        # add_header Strict-Transport-Security "max-age=31536000" always;
}