TLS/SLL 是如今網絡安全通訊比較重要的一環,經過一些列的 key 交換和 key 生成,最終確立加密通道的整個流程。衆所周知,TLS/SSL 耗費的時間也是挺可觀的,相對於 TCP 的3次 RTT 來講,若是加上 TLS/SSL, 則總的 RTT 時間至少爲 4 次。雖然看起來不少,但若是相對於如今的網絡環境來講,大概也就每次 20~30ms,這樣算下來,估計也就 100ms 左右。這樣的時間差仍是能夠忍受的,不過,這裏還沒算入 DNS 解析,這個暫時不考慮。並且,TLS/SSL 生成的 sessionkey 若是在有效期內的話,那麼這個時間就能夠徹底忽略掉了。很少說了,咱們直接來看下 TLS/SSL 的基本內容。html
文章摘自: please call me HRlinux
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
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 密鑰交換的過程。瀏覽器
在詳述過程以前,咱們須要瞭解一下,在過程當中會出現的內容。緩存
pseudorandom
(PRF) 一塊兒生成 session key。AES128-SHA
表明着:
ECDHE-ECDSA-AES256-GCM-SHA384
表明着
相信你們對這張圖已經很熟悉了:安全
不過,上面不是說了有兩種不一樣的非對稱加密方式嗎? RSA & DH? 那爲何圖只是一個嘞? ok,實際上這圖沒錯,他並無把傳輸的內容是什麼寫出來,這很關鍵。而兩種算法也是在傳輸內容上區分開的,基本的過程是徹底同樣的。根據 wiki 的解釋,咱們大概能知道整個傳輸過程須要的內容。
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 算法的基本條件:
基本流程就是:
咱們只要把上圖的 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 的加密過程。不過,其中,還有不少其餘的小細節,好比 SNI,ALPN,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 全稱是 Application Layer Protocol Negotiation(應用層協議協商機制)。看到應用層,程序員們應該都能反應出 OSI 7層網絡協議。在應用層中,HTTP 協議應該是重點。不過,因爲 HTTP 版本的問題,以及如今 HTTP2 的流行,爲了讓 client-server 使用相同的協議而出現了 ALPN。ALPN 其實是從 SPDY 中的 NPN 協議衍生出來的。不過,它們倆的機制正好相反。
總的來講,NPN 已經退出歷史的舞臺了。。。ALPN 如今是 IETF 指定的標準協議。ALPN 在 TLS 具體的過程是:
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。
感受能看到這裏的人,應該都是閒的蛋疼的人。。。若是讓我來看這篇文章,估計看幾張圖,我基本上就直接關網站了。由於,這實在是複雜。而且,上面說的只是協議上的複雜性,對於計算機來講,只須要記下每一次該發什麼東西而已,但真正讓 Computer 感到蛋疼的是,key 的計算。特別是 random key 和 premaster secret 動不動就是 32B,48B 的數據量。因此,爲了真正減小計算機的工做量(其實是 server),提出了 Session ID 和 Session Tickets,來將成功進行鏈接的 session 內容緩存起來。
Session ID 是 server 將上一次成功鏈接的 session 內容存在本身的硬盤裏面。這裏,就不涉及對 session data 的二次加密。基本的過程是:
那麼相對於徹底的 TLS/SSL 鏈接來講,這裏只用到了一次 RTT。那麼協議過程就變爲了:
既然 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 時間,用誰,仍是得看你的服務器的具體狀況。
前面大體說了 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,這應該是咱們勤勞的貧苦大衆用得起的。它們之間具體的區別在於域名的支持上:
那咱們的證書在芸芸證書中,是處於哪個層級呢? 通常是三級。怎麼體現的呢?
那這麼多證書,咱們用的是哪個呢?固然是,最下面那個。由於每一個證書並非都被信任,因此客戶端首先就要了解一下,你這個證書可否用來進行驗證。若是不行的話,那麼你此次鏈接就是不被信任的,就沒有綠色的小鎖
。這就須要瞭解一下,客戶端的驗證過程。
首先,什麼叫作可信的證書呢? 咱們先要明白一個道理,HTTPS 是先創建在人與人之間的相互信任上,而後才創建在機器與機器的相互信任上。假如,根證書 A 機構,惡意的將一個之前頒發過的證書,又給了另一個不要臉
攔截站點(好比,用來插廣告的)。這樣,我拿到了這個證書後,就能夠本身搭一個服務器,用來進行攔截瀏覽,監管裏你網站,並強行插廣告。這就被稱爲不可信的機構/證書。 而驗證的可行性,一般又跟機構的權威性有着極大的關係。它基本的驗證過程簡述就是(按照上面的層級):
若是上述任一步驟出現問題,那麼該次 TLS/SSL 就不會進行,會回退。那麼它們在詢問的時候,會不會發送網絡請求呢? 不會~ 由於,電腦在初始化時,會自帶不少可信任的證書機構(即,Root CA),也就是咱們剛剛提到的 VeriSign Class 3 的證書機構。以及,可以簽發證書的二級機構(比較少)。到時候,瀏覽器會自動的根據數字簽名來進行證書的驗證。
上面已經闡述了,CA 證書的合法性是自下而上的驗證方式。那麼它們具體驗證協議是怎樣的呢? 在說以前,咱們先說幾個概念:
CA 驗證首先須要說一下它的頒發過程:
而後,驗證過程就是根據這個來的:
而上面的三級證書層級,也是一樣的道理,自上而下的找就 ok。固然,有時候爲了驗證的速度,會作一些緩存,這樣就沒必要再進行驗證了。因此,根據上面的描述,有童鞋可能會想到,能不能自簽證書呢?反正,瀏覽器也是從本地找的。 固然能夠,openssl
就能夠生成你本身的 CA。不過須要注意的是,你生成的 CA 只是在你本身的電腦上使用,若是你想保證你的 CA 在其餘電腦上也能使用的話(這是不可能的),那就用錢砸就 ok。 具體的過程能夠參考:生成本身的 CA 證書。 之前,在使用 Charles 和 Fiddler 的時候,一直在想,它們是怎麼作到,將本身的證書,變成簽發機構證書。
後來發現,它是把證書中的相關字段該成它的證書內容。不過,對於某些高級證書,仍是會有一些問題,好比,wx.qq.com(微信的)
另外,爲了證書的可靠性,提出了 Certificate Transparency
項目,實際上,就是讓證書機構公開它的簽發流水。防止出現重複簽發。
如今有個問題,爲何證書有過時時間呢? 這一樣是爲了安全性,前面說過,若是你的證書發生了泄漏(實際上就是私鑰)。那麼,其餘服務器就能夠做爲一個代理去攔截你的流量。這時候,因爲過時的緣由,可能一段時間後,中間惡意的服務器就沒用了,另外,若是你發現了你遺失了證書,能夠向頒發機構去掛失。 另外,還有一個緣由是證書吊銷的 CRL
機制。簡單來講,就是有一個列表來記錄當前時間,該頒發機構被吊銷的證書 list。若是,沒有過時時間的話,那麼這個 list,會隨時間程指數增加,引入過時機制的話,該 list 只要記錄當前沒過時但吊銷的證書信息便可。 證書的吊銷有兩種機制:CRL,OCSP
CRL(Certificate Revocation List),即,證書吊銷列表。CA 機構會生成一個列表,列表裏面是當前週期被吊銷證書的序列號,當進行證書驗證時,一樣也會進行驗證該項。若是,已是吊銷證書的話,那麼該次 TLS/SSL 鏈接也會失敗。 咱們能夠從證書信息中找到 CRL URI:
該協議雖然簡單,但,缺陷仍是比較多的。
OCSP(Online Certificate Status Protocol),即,在線證書狀態協議。它經過在線請求的方式來進行驗證,不須要下載整個 list,只須要將該證書的序列號發送給 CA 進行驗證。固然,驗證經過也會有必定的緩存期。不過,因爲驗證也會存在時延。另外,部署 OCSP 對 CA 也有必定的要求,CA 要搭建的一個服務器來接受驗證,而且,該服務器的性能要好(負載很大)。
OCSP stapling 常稱爲: TLS Certificate Status Request extension。是 OCSP 的另一種實現方式,由於前兩個(OCSP,CRL)都是由客戶端去驗證證書是否吊銷,而且都會發送請求。而 OCSPs(OCSP stapling)則是直接在 server 端,進行證書的有效性驗證。server 會週期性的向 CA 機構發送請求,驗證有效性,並在 certificate
階段,發送相應的簽名信息。不過,該協議是創建在,咱們徹底信任 serve 的狀況下,這裏就排除了一些惡意的中間服務器。詳情能夠參考:OCSP stapling。
TLS/SSL 主要的性能調優簡單包括:啓用 False Start, OSCP Stapling, 選擇合適 cipher suite, resumption 等。另外,若是你追求 fashion
, 那麼 HTTP/2 應該是個不錯的選擇。 想要作 TLS/SSL 優化,那麼你必須瞭解,TLS/SSL 握手的整個過程是什麼。固然,你能夠買個證書,從頭本身搭建一個服務器,可是,這樣只能證實 你頗有錢
外,其它也證實不了什麼。由於,這徹底能夠本身內網搭一個呀~ 能夠參考:10s 自建證書. 這裏,咱們結合 nginx 來具體對 TLS/SSL handshake 優化,作個總體的闡述。
session 緩存設置可讓兩次的 RTT,變爲一次,這至關於快了一倍(不包括,密鑰計算等)。不一樣的 server 設置 session 的辦法有不少,這裏以 nginx 爲例。在 nginx 中,支持的是 Session ID 的形式,即在 server 中緩存之前 session 的加密內容。涉及的字段有兩個,ssl_session_cache
和 ssl_session_timeout
。
看個 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;
複製代碼
這裏先聲明一下,你的證書的內容和你的加密套件實際沒有半毛錢關係,這主要仍是取決於你的服務器的支持程度以及客戶端的支持度。另外,若是你想啓用 False Start
,這也可套件的選擇有很大的關係。咱們來看一下若是設置吧。在 nginx 中,主要用到兩個指令:
ssl_prefer_server_ciphers on;
ssl_ciphers xxx;
複製代碼
:
分隔。支持性最高的就是使用:
// 讓瀏覽器來決定使用哪個套件(額。。。最後的手段)
ssl_ciphers HIGH:!aNULL:!MD5;
複製代碼
通常狀況,仍是應該本身來決定使用哪個套件,這樣安不安全由本身說了算。具體能夠參考 mozilla 的套件配置。這裏簡單放一個,比較安全的,下面全部的套件都必須支持 Forwar Secrecy
ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5
複製代碼
不過,如下的加密套件,最好不要使用,由於基本上都不安全:
中間人
攻擊。上面那些只能給一些遠古瀏覽器使用,基本上在選擇中是做爲墊底的選擇。
另外,怎麼在 nginx 中開啓 False Start 呢? 這其實和服務器並無多大的關係,關鍵仍是你選擇的套件和 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 自帶兩個公共的參數,因此,這必須手動進行建立(實際上就是將參數 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
)比起來,在密鑰生成這塊會快不少。一樣,因爲歷史緣由,它的基本條件比較高:(其實也還好)
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(HTTP Strict Transport Security) 實際上就是一個響應頭,沒啥很特別的,具體內容就是,你全部對外部的請求都是 https
,因此這有一個問題,若是你的圖片地址是 http 的,那麼最終的結果,會變爲 https://xxx
,有可能會形成資源丟失的狀況,因此,開不開啓還須要慎用。
Strict-Transport-Security: max-age=15768000 # 設定 6 個月的強制期
複製代碼
在有效時間內,客戶端都會嘗試使用 https 訪問你的站點,若是在這期限裏你的證書過時了,開不了 https
。那麼,呵呵。
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: