完全吃透 TLS/SSL

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

文章摘自: please call me HR

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 的加密演算法：

簡單來說，兩邊通過一次的資訊交換，完成了金鑰生成。因為 sessionkey 是獨立放在兩端的，為了達到一致性，每次連線時，DH 都需要重新協商生成 sessionkey。現在有個問題是： 為什麼一定要有 session key，他存在的意義是什麼？

sessionkey 用途

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

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

你可以自行測試一下：

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 的解釋，我們大概能知道整個傳輸過程需要的內容。

1. 客戶端傳送 clientHello 資訊，包含了客戶端支援的最高 TLS 協議版本，random num (上文提到過)，cipher suite。如果，客戶端使用 resumed handshake，那麼這裡傳送的就是 sessionID。如果，客戶端還支援 ALPN，那麼它應該還需要傳送它所支援的其他協議，比如 HTTP/2.
2. 在 server 端進行 serverhello 階段，這裡 server 根據 client 傳送過來的相關資訊，採取不同的策略，同樣會傳送和 client 端匹配的 TLS 最高版本資訊，cipher suite 和 自己產生的 random num. 並且，這裡會產生該次連線獨一無二的 sessionID。
3. 通過 certificate 階段，會在資訊流中加入 public key certification。ServerKeyExchange 該階段，主要是針對於 ECDH 加密方式，這裡就不贅述，後面再進行講解。
4. serverHelloDone 標識這 server 階段處理結束，將該階段產生的資訊傳送給 client。
5. 在 clientKeyExchange 階段時，client 會隨機生成一串 pre-master secret 序列，並且會經由 public key 加密,然後傳送給 server。在 ChangeCipherSpec 階段，主要是 client 自己，通過 pre-master secret + server random-num + client random-num 生成 sessionKey。這就標識著，此時在 client 端，TLS/SSL 過程已經接近尾聲。
6. 後面在 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 的二次加密。基本的過程是：

1. client 端在 clientHello 階段，將 random num，TLS protocol 和通過 hostname 匹配到的最新一次的 session ID 傳送給 server 端。（也就是說，client 同樣需要儲存一份 session data）
2. 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;
}
複製程式碼

參考列表

這個，配置也很簡單，你可以從 Mozilla 裡獲得更豐富的內容。詳情可以參考：

• wiki.mozilla.org/Security/TL…
• wiki.mozilla.org/Security/Se…
• hpbn.co/transport-l…

另外，還有一些測試工具和生成工具,這裡也提供一份 list:

• 摸直了 官方測試工具
• 摸直了 官方 tls/ssl 配置生成工具
• SSL lab tls/ssl 測試工具