TLS/SSL 高級進階

kamran 8年前發布 | 93K 次閱讀 SSL協議 加密解密 加密/解密軟件包

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

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 級域名。如果是收費的，單/多域名應該都支持。

  • 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。

以前，在使用 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 的情況下，這里就排除了一些惡意的中間服務器。

TLS/SSL 優化

TLS/SSL 主要的性能調優簡單包括：啟用 False Start, OSCP Stapling, 選擇合適 cipher suite, resumption 等。另外，如果你追求 fashion , 那么 HTTP/2 應該是個不錯的選擇。

想要做 TLS/SSL 優化，那么你必須了解，TLS/SSL 握手的整個過程是什么。當然，你可以買個證書，從頭自己搭建一個服務器，但是，這樣只能證明 你很有錢 外，其它也證明不了什么。因為，這完全可以自己內網搭一個呀。這里，我們結合 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 里獲得更豐富的內容。詳情可以參考：

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

 

來自：https://segmentfault.com/a/1190000007283514

 

 本文由用戶 kamran 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
 轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！