0x00 前言簡述
SSL/TLS 簡單說明
描述: 當下越來越多的網站管理員為企業站點或自己的站點進行了SSL/TLS配置, SSL/TLS 是一種簡單易懂的技術，它很容易部署及執行，但要對其進行安全部署的情況下通常是不容易。
如果想掌握如何配置一個安全的 web 伺服器或應用，往往需要系統管理員和開發者去了解 SSL 和 TLS 相關的技術, 這無疑會耗費很大的精力去看相關的技術文件，乏味且寬泛並加大了學習成本。
所以本篇文章主要是為了讓系統管理員或開發者用盡可能少的時間部署一個安全的 web 站點或應用，即 SSL 和 TLS 部署最佳實踐，但在學習實踐之前我們需要了解一下SSL/TLS 相關術語，避免在後續實踐中一頭霧水。
原文地址:
- 如何讓HTTPS站點評級達到A+? 還得看這篇HTTPS安全優化配置最佳實踐指南 【https://blog.weiyigeek.top/2022/4-6-11.html】
- 如何讓HTTPS站點更加安全?這篇HTTPS安全加固配置最佳實踐指南就夠了 【https://blog.weiyigeek.top/2022/4-6-11.html】
前置知識推薦瞭解
- HTTPS原理介紹以及證照籤名的申請配置(https://blog.weiyigeek.top/2019/10-21-10.html)
- SSL與TLS協議原理和證照籤名生成實踐指南 (https://blog.weiyigeek.top/2019/10-21-12.html)
SSL/TLS 相關術語一覽
EV : EV證照(Extended Validation Certificate)是一種根據一系列特定標準頒發的X.509電子證照，根據要求，在頒發證照之前，證照頒發機構(CA)必須驗證申請者的身份。不同機構根據證照標準發行的擴充套件驗證證照並無太大差異，但是有時候根據一些具體的要求，特定機構發行的證照可以被特定的軟體識別。
OV : OV證照(Organization Validation SSL)，指需要驗證網站所有單位的真實身份的標準型SSL證照，此類證照不僅能夠起到網站資訊加密的作用，而且能向使用者證明網站的真實身份。
DV : DV證照(Domain Validation SSL)，指需要驗證域名的有效性。該類證照只提供基本的加密保障，不能提供域名所有者的資訊。
CAA : DNS Certification Authority Authorization，使用DNS來指定該域名可以由哪些CA機構簽發證照，這不是為TLS層的安全提供保證，而是作為CA簽發證照程式中的一部分。使用CAA可以避免一些CA簽發錯誤證照的情況。
CSR : CSR(Certificate Signing Request)，在PKI系統中，CSR檔案必須在申請和購買SSL證照之前建立，也就是證照申請者在申請數字證照時由CSP(加密服務提供者)在生成私鑰的同時也生成證照請求檔案，證照申請者只要把CSR檔案提交給證照頒發機構後，證照頒發機構使用其根證照私鑰簽名就生成了證照公鑰檔案
CT : CT (Certificate Transparency) 證照透明，Certificate Transparency的目標是提供一個開放的審計和監控系統，可以讓任何域名所有者或者CA確定證照是否被錯誤簽發或者被惡意使用，從而提高HTTPS網站的安全性。
CRL : CRL(Certificate revocation list 證照吊銷列表)是一個已經被吊銷的數字證照的名單，這些在證照吊銷列表中的證照不再會受到信任，但目前OCSP(線上證照狀態協議)可以代替CRL實現證照狀態檢查。
OCSP : OCSP(Online Certificate Status Protocol)是一個用於獲取X.509數字證照撤銷狀態的網際協議，在RCF 6960中定義，作為證照吊銷列表的替代品解決公開金鑰基礎建設(PKI)中使用證照吊銷列表而帶來的多個問題。協議資料傳輸過程中使用ASN.1編碼，並通常建立在HTTP協議上
OCSP Stapling : OCSP裝訂，是TLS證照狀態查詢擴充套件，作為線上證照狀態協議的替代方法對X.509證照狀態進行查詢，伺服器在TLS握手時傳送事先快取的OCSP響應，使用者只要驗證該響應的時效性而不用再向數字證照認證機構(CA)傳送請求，可以加快握手速度。
RSA : RSA加密演算法是一種非對稱加密演算法。在公開金鑰加密和電子商業中RSA被廣泛使用。對極大整數做因數分解的難度決定了RSA演算法的可靠性，支援簽名和加密。
ECC : ECDSA（橢圓曲線簽名演算法）的常見叫法，和RSA同時具有簽名和加密不同，它只能做簽名，它的優勢是具有很好的效能、大小和安全性更高。
DH/DHE : Diffie-Hellman(DH)金鑰交換是一種金鑰交換的協議，DH的訣竅是使用了一種正向計算簡單、逆向計算困難的數學函式，即使交換中某些因子已被知曉，情況也是一樣。DH金鑰交換需要6個引數，其中兩個(dh_p和dh_g)稱為域引數，由伺服器選取，協商過程中，客戶端和伺服器各自生成另外兩個引數，相互傳送其中一個引數(dh_Ys和dh_Yc)到對端，在經過計算，最終得到共享金鑰。臨時Diffie-Hellman(ephemeral Diffie-Hellman,DHE)金鑰交換中沒有任何引數被重複利用。與之相對，在一些DH金鑰交換方式中，某些引數是靜態的，並被嵌入到伺服器和客戶端的證照中，這樣的話金鑰交換的結果是一直不變的共享金鑰，就無法具備前向保密的能力。
ECDH/ECHDE : 橢圓曲線Diffie-Hellman(elliptic curve Diffie-Hellman，ECDH)金鑰交換原理與DH相似，但是它的核心使用了不同的數學基礎，ECHD基於橢圓曲線加密，ECDH金鑰交換髮生在一條由伺服器定義的橢圓曲線上，這條曲線代替了DH中域引數的角色，理論上，ECDH支援靜態的金鑰交換。臨時橢圓曲線Diffie-Hellman金鑰交換，和DHE類似，使用臨時的引數，具有前向保密的能力。
RC4 : 是一種流加密演算法，對稱加密，金鑰長度可變。由於RC4演算法存在弱點，2015年2月所釋出的 RFC 7465 規定禁止在TLS中使用RC4加密演算法, Chrome 48版本開始會拒絕與「以 RC4 做為對稱加密演算法的 CipherSuite」建立 TLS 連線 。
3DES : 在加密套件中很多的密碼使用的是3DES_EDE_CBC這種型別的，在維基上3DES提供的bits數是192bits(168+24)，但由於Meet-in-the-middle attack攻擊的影響，只能提供112bits的安全。因此在等級評定上使用192bits，在套件的安全性上使用112bits.
PSK : PSK 是“Pre-Shared Key”的縮寫。就是 預先讓通訊雙方共享一些金鑰（通常是對稱加密金鑰）, 這種演算法用的不多它的好處是：不需要依賴公鑰體系，不需要部屬 CA 證照。不需要涉及非對稱加密，TLS 協議握手（初始化）時的效能好於 RSA 和 DH,金鑰交換時通訊雙方已經預先部署了若干個共享的金鑰為了標識多個金鑰，給每一個金鑰定義一個唯一的 ID客戶端通過ID 和服務端進行通訊。
SRP : TLS-SRP（ Secure Remote Password）密碼套件有兩類：第一類密碼套件僅使用SRP認證。第二類使用SRP認證和公共金鑰證照來增加安全性。
TLS GREASE : 為了保持可擴充套件性，伺服器必須忽略未知值，是Chrome 推出的一種探測機制。GREASE for TLS (https://tools.ietf.org/html/draft-davidben-tls-grease-01)
AEAD : 全稱是使用關聯資料的已驗證加密，Authenticated Encryption with Associated Data (AEAD) algorithms, 是用一個演算法在內部同時實現cipher+MAC，是TLS1.2、TLS1.3上採用的現代加密演算法,相關密碼套件(https://tools.ietf.org/html/rfc6655)：
TLS_RSA_WITH_AES_128_CCM = {0xC0,0x9C}
TLS_RSA_WITH_AES_256_CCM = {0xC0,0x9D)
TLS_DHE_RSA_WITH_AES_128_CCM = {0xC0,0x9E}
TLS_DHE_RSA_WITH_AES_256_CCM = {0xC0,0x9F}
TLS_RSA_WITH_AES_128_CCM_8 = {0xC0,0xA0}
TLS_RSA_WITH_AES_256_CCM_8 = {0xC0,0xA1)
TLS_DHE_RSA_WITH_AES_128_CCM_8 = {0xC0,0xA2}
TLS_DHE_RSA_WITH_AES_256_CCM_8 = {0xC0,0xA3}
AES-GCM : AES-GCM是一種AEAD，是目前TLS的主力演算法，網際網路上https流量的大部分依賴使用AES-GCM。
ChaCha20-poly1305 : ChaCha20-poly1305是一種AEAD，提出者是Daniel J. Bernstein教授，針對移動網際網路優化，目前Google對移動客戶端的所有流量都使用ChaCha20-Poly1305
AES-CBC : 關於AES-CBC，在AES-GCM流行之前，TLS主要依賴AES-CBC，而由於歷史原因，TLS在設計之初固定選擇了MAC-then-Encrypt結構，AES-CBC和MAC-then-encrypt結合，為選擇密文攻擊(CCA)創造了便利條件，TLS歷史上有多個漏洞都和CBC模式有關。
PFS : PFS(perfect forward secrecy)正向保密 ，在密碼學中也可以被稱為FS(forward secrecy)，是安全通訊協議的特性，要求一個金鑰只能訪問由它所保護的資料，用來產生金鑰的元素一次一換，不能再產生其他的金鑰，一個金鑰被破解，並不影響其他金鑰的安全性。
HPKP : 公鑰固定，這是一種https網站防止攻擊者使用CA錯誤頒發的證照進行中間人攻擊的一種安全機制，用於預防諸如攻擊者入侵CA偷發證照、瀏覽器信任CA簽發偽造證照等情況，採用該機制後伺服器會提供一個公鑰雜湊列表，客戶端在後續的通訊中只接受該列表上的一個或多個公鑰。
HPKP是一個響應頭
Public-Key-Pins:max-age=xxx;pin-sha256=xxxx;includeSubDomains;其中可以使用多個pin-sha256，pin-sha256的值是對證照公鑰sha256的值，includeSubDomains決定是否包含所有子域名，在max-age所指定的時間內(秒)，證照鏈中的證照至少一個公鑰須和固定公鑰相符，這樣客戶端才認為該證照鏈是有效的,
還有一種響應頭：Public-Key-Pins-Report-Only:max-age=xxx;pin-sha256=xxxx;includeSubDomains;report-uri=xxx,Public-Key-Pins-Report-Only 中的report-uri，決定是否回報違反HTTP公鑰固定策略的事件。客戶端進行HTTP公鑰固定驗證失敗後，將把此次錯誤詳情以JSON格式回報個report-uri引數中指定的伺服器。
H2 : HTTP/2 的協議名稱，口語叫法HTTP2和http/1.1 是一個概念，通過ALPN協商, HTTP/2 中只能使用 TLSv1.2+協議。
CSP : CSP，全稱是 Content Security Policy，它有非常多的指令，用來實現各種各樣與頁面內容安全相關的功能。 這裡只介紹兩個與 HTTPS 相關的指令，更多內容可以看我之前寫的《Content Security Policy Level 2 介紹》。
block-all-mixed-content ：前面說過，對於 HTTPS 中的圖片等 Optionally-blockable 類 HTTP 資源，現代瀏覽器預設會載入。圖片類資源被劫持，通常不會有太大的問題，但也有一些風險，例如很多網頁按鈕是用圖片實現的，中間人把這些圖片改掉，也會干擾使用者使用。通過 CSP 的 block-all-mixed-content 指令，可以讓頁面進入對混合內容的嚴格檢測（Strict Mixed Content Checking）模式。在這種模式下，所有非 HTTPS 資源都不允許載入。跟其它所有 CSP 規則一樣，可以通過以下兩種方式啟用這個指令。
HTTP 響應頭方式：Content-Security-Policy: block-all-mixed-content
標籤方式：upgrade-insecure-requests通過 CSP 指令，可以讓瀏覽器幫忙做這個轉換。啟用這個策略後，有兩個變化頁面所有 HTTP 資源，會被替換為 HTTPS 地址再發起請求, 頁面所有站內連結，點選後會被替換為 HTTPS 地址再跳轉；
跟其它所有 CSP 規則一樣，這個指令也有兩種方式來啟用，具體格式請參考上一節。需要注意的是upgrade-insecure-requests只替換協議部分，所以只適用於 HTTP/HTTPS 域名和路徑完全一致的場景。
HSTS: 在網站全站 HTTPS 後，如果使用者手動敲入網站的 HTTP 地址，或者從其它地方點選了網站的 HTTP 連結，依賴於服務端 301/302 跳轉才能使用 HTTPS 服務。而第一次的 HTTP 請求就有可能被劫持，導致請求無法到達伺服器，從而構成 HTTPS 降級劫持。該問題可以通過 HSTS（HTTP Strict Transport Security，RFC6797）來解決。
HSTS 是一個響應頭，格式如下：
Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [; preload]
- max-age，單位是秒，用來告訴瀏覽器在指定時間內，這個網站必須通過 HTTPS 協議來訪問。也就是對於這個網站的 HTTP 地址，瀏覽器需要先在本地替換為 HTTPS 之後再傳送請求。
- includeSubDomains，可選引數，如果指定這個引數，表明這個網站所有子域名也必須通過 HTTPS 協議來訪問。
- preload，可選引數，後面再介紹它的作用。
溫馨提示: HSTS 這個響應頭只能用於 HTTPS 響應；網站必須使用預設的 443 埠；必須使用域名且不能是 IP。而且啟用 HSTS 之後一旦網站證照錯誤，使用者無法選擇忽略。
HSTS Preload List: HSTS 可以很好的解決 HTTPS 降級攻擊，但是對於 HSTS 生效前的首次 HTTP 請求，依然無法避免被劫持。瀏覽器廠商們為了解決這個問題，提出了 HSTS Preload List 方案：內建一份可以定期更新的列表，對於列表中的域名，即使使用者之前沒有訪問過，也會使用 HTTPS 協議。目前這個 Preload List 由 Google Chrome 維護，Chrome、Firefox、Safari、IE 11 和 Microsoft Edge 都在使用。
如果要想把自己的域名加進這個列表，首先需要滿足以下條件,不過值得注意的是即便滿足了上述所有條件，也不一定能進入 HSTS Preload List，更多資訊可以看這裡。
- 擁有合法的證照（如果使用 SHA-1 證照，過期時間必須早於 2016 年）；
- 將所有 HTTP 流量重定向到 HTTPS；
- 確保所有子域名都啟用了 HTTPS；
- 輸出 HSTS 響應頭：
- max-age 不能低於 18 周（10886400 秒）；
- 必須指定 includeSubdomains 引數；
- 必須指定 preload 引數；
溫馨提示: 通過 Chrome 的chrome://net-internals/#hsts工具，可以查詢某個網站是否在 Preload List 之中，還可以手動把某個域名加到本機 Preload List。
SNI : SNI(伺服器名稱指示)，這個是一個擴充套件的TLS協議，在該協議中，在TLS握手過程中客戶端可以指定伺服器的主機名稱，這允許伺服器在相同的IP和埠上部署多個證照，並允許在相同的IP地址上提供多個HTTPS網站或者基於TLS的服務。
SRI : HTTPS 可以防止資料在傳輸中被篡改，合法的證照也可以起到驗證伺服器身份的作用，但是如果 CDN 伺服器被入侵，導致靜態檔案在伺服器上被篡改，HTTPS 也無能為力。W3C 的 SRI（Subresource Integrity）規範可以用來解決這個問題。SRI 通過在頁面引用資源時指定資源的摘要簽名，來實現讓瀏覽器驗證資源是否被篡改的目的。只要頁面不被篡改，SRI 策略就是可靠的, 有關 SRI 的更多說明請看Jerry Qu寫的《Subresource Integrity 介紹》。SRI 並不是 HTTPS 專用，但如果主頁面被劫持，攻擊者可以輕鬆去掉資源摘要，從而失去瀏覽器的 SRI 校驗機制。
ALPN : ALPN(應用層協議協商 Application-Layer Protocol Negotiation) 是一個進行應用層協議協商的傳輸層安全協議(TLS)擴充套件，ALPN允許應用層協商應該在安全連線上實行哪個協議，以避免額外且獨立於應用層協議的往返協商通訊, 它已被HTTP/2使用。
NPN : NPN(Next Protocol Negotiation) 下一協議協商，在TLS上允許應用層協商使用哪個協議，在2014年7月11日的RFC 7301中使用ALPN代替NPN。
STARTTLS : STARTTLS 是對純文字通訊協議(SMTP/POP3/IMAP)的擴充套件。它提供一種方式將純文字連線升級為加密連線（TLS或SSL），而不是另外使用一個埠作加密通訊。RFC 2595定義了IMAP和POP3的STARTTLS；RFC 3207定義了SMTP的；
Session ID : Session ID 完成SSL握手後會獲得一個編號（Session ID）。如果對話中斷，下次重連的時候，只要客戶端給出這個編號，且伺服器有這個編號的快取，雙方就可以重新使用已有的"對話金鑰"，而不必重新生成一把（握手的主要開銷）。 因為要快取每個連線的握手引數，服務端儲存開銷會比較大。
Session Ticket : Session ticket獲得方式和SessionID類似，但是使用時是在每次握手時由伺服器進行解密，獲得加密引數。服務端無需維持握手引數，可以減少記憶體開銷。
POODLE : POODLE(貴賓犬漏洞 CVE-2014-3566)，貴賓犬漏洞的根本原因是CBC模式在設計上的缺陷，具體來說就是CBC只對明文進行了身份驗證，但是沒有對填充位元組進行完整性校驗。這使得攻擊者可以對填充位元組修改並且利用填充預示來恢復加密內容，讓POODLE攻擊成為可能的原因是SSL3中過於鬆散的填充結構和校驗規則。
TLS POODLE ：TLS POODLE(TLS 貴賓犬漏洞 CVE-2014-8730) 該漏洞的原理和POODLE漏洞的原理一致，但不是SSL3協議，而是在TLS協議上，TLS協議本身沒有問題，但是在其實現上。一些開發人員在進行SSL3到TLS的轉換的時候，沒有遵守協議規定的填充要求，使得他們的實現容易受到POODLE攻擊的威脅
DROWN : 一句話概括就是“使用SSLv2對TLS進行交叉協議攻擊”，DROWN(CVE-2016-0800)表示僅支援SSL2是對現代伺服器和客戶端的威脅，它允許攻擊者通過講探測傳送到支援SSLv2的伺服器並使用相同的私鑰來解密最新客戶端和伺服器之間的TLS連線，如果如果伺服器容易受到DROWN的影響，有兩種原因：
- 伺服器允許SSL2連線
- 私鑰用於允許SSL2連線的其他伺服器，即使是另一個支援SSL/TLS的協議，例如，Web伺服器和郵件伺服器上使用相同的私鑰和證照，如果郵件伺服器支援SSL2，即使web伺服器不支援SSL2，攻擊者可以利用
- 郵件伺服器來破壞與web伺服器的TLS連線。
使用40bit的出口限制RSA加密套件，單臺PC能在一分鐘內完成工具，對於攻擊的一般變體（對任何SSL2服務起作用）也可以在8個小時內完成。
Logjam : Logjam(CVE-2015-4000) 使用 Diffie-Hellman 金鑰交換協議的 TLS 連線很容易受到攻擊，尤其是DH金鑰中的公鑰強度小於1024bits。中間人攻擊者可將有漏洞的 TLS 連線降級至使用 512 位元組匯出級加密。這種攻擊會影響支援 DHE_EXPORT 密碼的所有伺服器。這個攻擊可通過為兩組弱 Diffie-Hellman 引數預先計算 512 位元組質數完成，特別是 Apache 的 httpd 版本 2.1.5 到 2.4.7，以及 OpenSSL 的所有版本。
BEAST : BEAST(CVE-2011-3389) BEAST攻擊針對TLS1.0和更早版本的協議中的對稱加密演算法CBC模式，初始化向量IV可以預測，這就使得攻擊者可以有效的講CBC模式削弱為ECB模式，ECB模式是不安全的
Downgrade : Downgrade attack(降級攻擊) 是一種對計算機系統或者通訊協議的攻擊，在降級攻擊中，攻擊者故意使系統放棄新式、安全性高的工作方式，反而使用為向下相容而準備的老式、安全性差的工作方式，降級攻擊常被用於中間人攻擊，講加密的通訊協議安全性大幅削弱，得以進行原本不可能做到的攻擊。 在現代的回退防禦中，使用單獨的訊號套件來指示自願降級行為，需要理解該訊號並支援更高協議版本的伺服器來終止協商，該套件是TLS_FALLBACK_SCSV(0x5600)
MITM : MITM(Man-in-the-middle) 是指攻擊者與通訊的兩端分別建立獨立的聯絡，並交換其所有收到的資料，使通訊的兩端認為他們正在通過一個私密的連線與對方直接對話，但事實上整個對話都被攻擊者完全控制，在中間人攻擊中，攻擊者可以攔截通訊雙方的通話並插入新的內容。一箇中間人攻擊能成功的前提條件是攻擊者能夠將自己偽裝成每個參與會話的終端，並且不被其他終端識破。
Openssl Padding Oracle : Openssl Padding Oracle(CVE-2016-2107) openssl 1.0.1t到openssl 1.0.2h之前沒有考慮某些填充檢查期間的記憶體分配，這允許遠端攻擊者通過針對AES CBC會話的padding-oracle攻擊來獲取敏感的明文資訊。
CCS : CCS(openssl MITM CCS injection attack CVE-2014-0224) 0.9.8za之前的Openssl，1.0.0m之前的以及1.0.1h之前的openssl沒有適當的限制ChangeCipherSpec資訊的處理，這允許中間人攻擊者在通訊之間使用0長度的主金鑰。
FREAK : FREAK(CVE-2015-0204) 客戶端會在一個全安全強度的RSA握手過程中接受使用弱安全強度的出口RSA金鑰，其中關鍵在於客戶端並沒有允許協商任何出口級別的RSA密碼套件。
Export-cipher : 在1998年9月之前，美國曾經限制出口高強度的加密演算法。具體來說，限制對稱加密強度為最大40位，限制金鑰交換強度為最大512位。
CRIME : CRIME(Compression Ratio Info-leak Made Easy CVE-2012-4929)，這是一種可攻擊安全隱患，通過它可竊取啟用資料壓縮特性的HTTPS或SPDY協議傳輸的私密Web Cookie。在成功讀取身份驗證Cookie後，攻擊者可以實行會話劫持和發動進一步攻擊。
Heartbleed : Heartbleed(心血漏洞 CVE-2014-0160) 是Openssl的程式漏洞，如果使用帶缺陷的Openssl版本，無論是伺服器還是客戶端，都可能因此受到攻擊。此問題的原因是在實現TLS的心跳擴充套件時沒有對輸入進行適當的驗證（缺少邊界檢查），該程式錯誤屬於緩衝區過讀，即可以讀取的資料比應該允許讀取的還多。
0x01 HTTPS安全實踐指南
1.證照(certificate)與私鑰(Private key)
描述: 在TLS中所有的安全性都從伺服器的密碼標識開始，所以我們需要一個強大的私鑰以及有一個有效的和強大的證照來防止攻擊者進行模擬攻擊。
最佳安全實踐
1.1) 建議使用2048位的RSA私鑰或者128位的ECDSA私鑰, 注意如果使用RSA私鑰想要獲得128位的安全性,則需要3072位的RSA key, 但會對效能造成一定影響, 所以推薦使用ECDSA key它是一種提供更好安全性和更好效能的替代方法。
1.2) 建議保護好你的私鑰, 在可信計算機上用足夠的熵生成私有金鑰, 將金鑰進行加密儲存分配給指定人員管理, 可以訪問擁有私鑰的人越少越好, 除非保持相同的金鑰對於公鑰金鑰很重要，否則每當獲得新證照時，還應該生成新的私鑰。
1.3) 建議從可信 CA 頒發獲取證照, 選擇CA時重點考慮如果以下條件提供商是否發生過安全風險、業務側重點、是否提供對證照吊銷列表（CRL）和線上證照狀態協議（OCSP）撤銷方法的支援、是否提供便捷的證照管理無法。
1.4) 建議使用強簽名演算法,證照安全性取決於用於簽署證照的私鑰的強度、簽名中使用的雜湊函式的強度, 當前大多數的證照都依賴於SHA256雜湊函式,截止2022年。
1.5) 建議為指定站點名稱申請對應證照而非使用萬用字元(泛域名)證照，萬用字元證照能滿足更廣泛的需求但如果準備將金鑰暴露給更多的人員，特別是跨團隊或部門，則避免使用它們。
溫馨提示: 為了獲得最佳效果，請提前獲得證照，並在部署到生產業務環境之前至少一週，有助於避免在計算機上沒有正確時間的一些使用者的證照警告，以及避免與 CA 需要額外時間的 CA 失敗的撤銷檢查，以向 OCSP 響應者傳播有效的新證照
2.中介軟體SSL/TLS伺服器配置
描述: 使用正確的TLS伺服器配置，您可以確保將憑據正確呈現給站點的訪問者，僅使用安全的加密原語，並減輕所有已知的缺陷。
最佳安全實踐
2.1) 建議使用完整的證照鏈, 通過情況下僅伺服器證照不夠的,我們需要兩個或多個證照來建立完整的信任鏈，當部署具有有效證照但沒有所有必要的中間證照的伺服器時會發生常見的配置問題，這是因為無效的證照鏈有效地使伺服器證照無效並導致瀏覽器警告。
Let'sEncrypt快速頒發及自動續簽泛域名證照實踐指南(https://blog.weiyigeek.top/2022/3-11-589.html)
# 例如, 我採用Let'sEncrypt進簽發的證照，生成nginx響應的證照配置鏈。
acme.sh --installcert -d weiyigeek.top \
--key-file /etc/nginx/ssl/weiyigeek.top.key \
--fullchain-file /etc/nginx/ssl/fullchain.cer \
--reloadcmd "service nginx force-reload"
# Nginx 中證照鏈與證照金鑰配置
ssl_certificate /etc/nginx/ssl/fullchain.cer;
ssl_certificate_key /etc/nginx/ssl/weiyigeek.top.key;
2.2) 建議選擇使用安全的SSL/TLS協議, 避免使用 SSL v2，SSL v3, 當前推薦使用 TLS v1.0，TLS v1.1和TLS v1.2 以及 TLS 1.3 協議以消除所有過時和不安全的功能。
# Nginx
# intermediate configuration
ssl_protocols TLSv1.2 TLSv1.3;
2.3) 建議選擇使用安全的套件, 為了安全通訊您必須首先確定您正在與所需方（而不是通過將竊聽的其他人）直接溝通並安全地交換資料則需要至少128位加密的AEAD套件, 並且在配置中避免使用如下加密套件
NULL 密碼套件不提供加密
匿名 Diffie-Hellman（ADH）套件不提供身份驗證
弱密碼（通常為 40 和 56 位）的套件使用可以輕鬆破壞的加密
MD5 密碼套件是不安全的,容易被碰撞檢測
RC4 密碼套件是不安全的
DES/3DES 密碼套件緩慢而虛弱
例如, Nginx 中的ssl_ciphers配置項里加入不支援如下 !NULL:!aNULL:!eNULL:!EXPORT:!PSK:!ADH:!DES:!3DES:!MD5:!RC4; 密碼套件。
# 使用以RSA和ECDSA鍵為基礎的以下套件配置，作為起點（使用標準 TLS 套件名稱）：
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256
# 使用 openssl 命令檢視指定套件對應的標準 TLS 套件名稱以及支援的協議。
openssl ciphers -V 'ECDHE-RSA-AES128-GCM-SHA256:ECDH:AES:EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:HIGH:!NULL:!aNULL:!eNULL:!EXPORT:!PSK:!ADH:!DES:!MD5:!RC4;' | column -t
0x13,0x02 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac =AEAD
0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac =AEAD
0x13,0x01 - TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac =AEAD
0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac =AEAD
# Nginx
# 推薦安全配置（犧牲了相容性）生產環境中請根據業務需要配置。
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
2.4) 建議選擇合適的協議在SSLv3及更高版本的協議版本中, 將通用性安全較強的套件放在首位，使伺服器主動選擇最佳可用加密套件對於實現最佳安全性至關重要。
2.5) 建議使用FS前向保密, FS有時也稱為完全前向保密是一種協議功能，可實現不依賴伺服器私鑰的安全對話, 對於不提前向保密的密碼套件，如果有可以恢復伺服器的私鑰的人就可以解密所有較早記錄的加密對話（也就是可以先大量記錄密文，再解密，比如您的證照到期後沒有正確銷燬，它的私鑰就能用來解密非PFS的密文），所以我們應該使用 DHE 套件作為 ECDHE 後備並且避免 RSA 金鑰交換（除非必要）。
2.6) 建議使用強的金鑰交換演算法，前面我們說不建議選擇經典的短暫的 Diffie-Hellman金鑰交換（DHE）以及RSA 金鑰交換（不提供FS前向保密），通常推薦其橢圓曲線變體 ECDHE 金鑰交換，它更加安全和快速。
溫馨提示: 我們建議您始終首先在分段環境中測試TLS配置，僅在確定所有內容按預期工作時將更改應用到生產環境。請注意，以上是一個通用列表，並不是所有系統（特別是較舊的）支援所有套件。
3.SSL/TLS站點效能
描述: 本章節HTTPS安全是我們討論的重點,於此同時我們也需要關注配置了TLS站點的效能, 一個不符合效能標準的安全服務無疑將被丟棄。通過正確配置TLS伺服器訪問其站點時速度將會有很大提升, 例如使用現代協議（例如 HTTP/2），甚至可能比明文通訊更快。。
最佳安全實踐
3.1) 建議避免使用過度安全的金鑰長度, 使用超過 2048 位的 RSA 金鑰和強大於 256 位的 ECDSA 金鑰會浪費 CPU 功耗，並可能會損害使用者體驗。
3.2) 建議使用 session 恢復, 會話恢復是一種效能優化技術，可以節省昂貴的密碼操作的結果，並重復使用一段時間.
# Nginx
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m; # about 40000 sessions
ssl_session_tickets off;
3.3) 建議使用 WAN 優化和啟用 HTTP/2, 通常TLS 開銷不是來自CPU的加密操作，而是來自網路延遲, 只有在 TCP 握手完成後才能啟動TLS握手，需要進一步交換資料包，並且離開伺服器的距離更遠, 所以最小化延遲的最佳方法是避免建立新的連線，換句話說就是保持現有的連線長時間（keep-alives）。
# Nginx
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
}
......
3.4) 建議快取網站中公共的靜態資源, 通過TLS進行通訊時瀏覽器可能會認為所有流量都是敏感的, 預設的瀏覽器在使用中會快取某些靜態資源但是一旦關閉瀏覽器所有快取內容可能會丟失, 所以為了獲得效能提升我們需要長期快取一些靜態資源。
3.5) 建議使用 OCSP Stapling, OCSP 裝訂是 OCSP 協議的擴充套件，可以直接從伺服器提供撤銷資訊作為 TLS 握手的一部分。因此客戶端不需要聯絡 OCSP 伺服器進行帶外驗證，並且總體 TLS 連線時間顯著減少。
# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;
# verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
3.6) 建議使用 ECDSA 金鑰進行快速加密, 在選擇加密套件時除了保證其安全性還需要其良好的效能表現, 儘可能使用支援硬體加速 AES 的 CPU。
溫馨提示: 用於建立安全連線的密碼握手是一種操作，其費用受私鑰大小的高度影響,使用太短的金鑰是不安全的，但使用太長的金鑰將導致“太多”的安全性和緩慢的操作。
溫馨提示: 殘疾或非功能性會話恢復機制可能會引起顯著的效能損失。
溫馨提示: OCSP裝訂是一種重要的優化技術，但並不是所有的網路伺服器都提供了可靠的 OCSP 裝訂實現。
4.HTTP與應用安全
描述: HTTP 協議和 Web 應用交付的周邊平臺在 SSL 誕生後繼續快速發展, 所以在進行TLS伺服器配置時它們也是最重要的一環。
最佳安全實踐
4.1) 建議加密無處不在, https加密不能是可選項,可靠地保護網站通訊的唯一方法是無一例外地執行加密。
4.2) 建議消除混合內容, 請將任何地方的所有內容都 HTTPS 化（全站 HTTPS）, 通過 TLS 傳輸但是包含不通過 TLS 傳輸的資源（例如，JavaScript 檔案，images，CSS 檔案）的頁面, 可能會被一個活躍的中間人（MITM）攻擊者可以搭載一個單獨的未受保護的 JavaScript 資源，便有可能劫持使用者的會話。
4.3) 建議使用可信第三方js或者css並且第三方必須是警告https加密的從而避免MITM 攻擊, 於此同時使用子資源完整性（SRI）的新技術，可用於通過第三方資源來減少潛在的風險。
4.4) 建議配置安全cookie，要正確安全網站需要 TLS，而且所有的 Cookie 在建立時都被明確標記為安全的，為了獲得最佳效果，請考慮為您的 Cookie 新增加密完整性驗證或甚至加密。
4.5) 建議進行安全 HTTP 壓縮, TIME 和 BREACH 專注於使用 HTTP 壓縮壓縮的 HTTP 響應實體中的祕密，HTTP 壓縮是必需的不能關閉。
4.6) 建議部署配置 CSP ,內容安全策略（CSP）是網站可以用來限制瀏覽器操作的安全機制。儘管最初旨在解決跨站點指令碼（XSS），CSP 不斷髮展並支援對增強TLS安全性有用的功能, 部署CSP可以防止第三方混合內容，通常使用Strict-Transport-Security響應頭。
4.7) 建議不要快取敏感內容
4.8) 考慮其它威脅, TLS 旨在僅解決安全機密和您與使用者之間通訊的完整性的一個方面，但還有許多其他威脅需要處理,確保您的網站儘可能的減少攻擊面。
溫馨提示: 下述配置是不一定是部署 CSP 的最佳方法,為了提供不破壞混合內容以外的任何內容的示例，我不得不禁用某些預設安全功能。隨著時間的推移，當您瞭解 CSP 的更多資訊時，您應該更改您的策略以使其恢復。
Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval'; connect-src https: wss:
5.定期HTTPS檢查避免已知問題
描述: 近幾年來已經發生了幾次嚴重的 SSL 和 TLS 攻擊，但是如果您正在執行最新的openssl軟體以及使用上述指南中的協議和加密套件建議，那麼它們通常不會關心您。但是沒有什麼是完全安全的，所以為了保持對安全性的瞭解, 你應該排查和關注https相關漏洞, 以便於在第一時間保護或更新您的TLS伺服器配置。
所以通常情況下我建議定期使用全面的 SSL/TLS 評估工具來驗證您的配置，以確保您開始安全，對於公共網站建議您使用如下SSL實驗室伺服器進行站點https測試評估?。
最佳安全實踐
5.1) 建議定期使用如下SSL、TLS 評估工具對TLS配置進行檢查評估。
- 國外推薦:
ssllabs : 網站地址(https://www.ssllabs.com)，其檢測內容非常的詳細，包括證照、協議以及客戶端模擬和相容行。
cdn77 : 網站地址(https://www.cdn77.com/tls-test), 功能單一隻針對 TLS 、SSL協議版本進行評估。
- 國內推薦:
myssl : 網站地址(https://myssl.com),這個是國內的檢測站點與 ssllabs 相似，但個人感覺介面更清爽，證照檢測的功能更多，訪問速度也是快很多槓槓的，它還可以為您的https站點進行多方面綜合的評級，其中包括了證照、SSL協議、加密套件、漏洞、不安全的外鏈等等，便於網站管理人員排查驗證伺服器應用證照配置是否正確。
5.2) 建議排查驗證配置的TLS伺服器是否使用下述相關漏洞所關聯的openssl版本、加密套件以及脆弱的SSL、TLS協議。
DROWN 漏洞
OpenSSL Padding Oracle 攻擊
FREAK漏洞
Logjam漏洞
OpenSSL CCS 注入漏洞
心血漏洞(Heartbleed)
POODLE漏洞
CRIME漏洞
5.3) 瞭解或者使用 HPKP, 公共金鑰固定旨在使網站運營商有許可權制哪些 CA 可以為其網站頒發證照。Google 已經部署了這個功能了一段時間（硬編碼到他們的瀏覽器，Chrome），並且已被證明是非常有用的，以防止攻擊並使公眾瞭解它們, 但是需要一定的成本，部署需要大量精力和專業知識。
5.4) 建議配置使用 DNSSEC, 全稱是域名系統安全擴充套件（Domain Name System Security Extensions），它是一種增加域名系統完整性的技術，是由IETF提供的一系列DNS安全認證的機制（可參考RFC2535）它提供一種可以驗證應答資訊真實性和完整性的機制，利用密碼技術，使得域名解析伺服器可以驗證它所收到的應答(包括域名不存在的應答)是否來自於真實的伺服器，或者是否在傳輸過程中被篡改過。通過DNSSEC的部署，可以增強對DNS域名伺服器的身份認證，進而幫助防止DNS快取汙染等攻擊。（配置示例請參考下小節的實踐配置）
簡單的說，DNSSEC依靠數字簽名保證DNS應答報文的真實性和完整性。
5.5) 建議為電子郵件系統配置使用 DANE , DANE一種將X.509證照繫結到DNS中的機制, 可用於儲存自簽名證照或者從CA簽發的特定X.509證照, 其中, 證照作為DNS資源記錄通過DNSSEC來實現其來源驗證和完整性保護,根據證照用途的不同, 基於DANE的DNS資源記錄也有所不同, DANE協議的動機之一是解決現有的基於X.509的PKI的問題. 例如, DANE在應對欺詐證照、處理證照撤銷、建立可全球釋出和檢索證照的管理機制並允許自簽名證照授權等方面提供了很好的解決方式.
實踐配置
1.在騰訊雲DNSPod控制檯開啟DNSSEC流程操作。(PS: 收費版DNS套餐提供)
第一步：登陸 DNSPod 控制檯開啟 DNSSEC 服務。
[控制檯]- DNS 解析 - 我的域名 - 域名設定 - DNSSEC ，點選開啟，即可檢視該域名的 DS 記錄。
第二步：前往域名註冊商控制檯新增 DS 記錄。
前面拿到的 DS 記錄，還需在您域名註冊商的控制檯進行新增。(如果您的域名同樣註冊於騰訊雲(DNSPod)，則該步驟自動完成)
PS: 該域名註冊於騰訊雲且屬當前賬號，系統將自動為您新增 DS 記錄(https://docs.dnspod.cn/dns/dnssec-configuration/)
第三步: 檢視驗證DNSSEC是否配置成功, 此處仍然以騰訊云為例（我的域名在騰訊購買的沒辦法）。
[控制檯]- 域名註冊 - 我的域名 -> 管理 -> 域名安全 -> DNSSEC 設定（點選管理）
溫馨提示: 目前只有少數註冊商支援 DNSSEC ，如果您域名所在註冊商不支援，可先將域名轉入騰訊雲，轉入後方便一站管理，更可一鍵開啟(帶轉入連結)
總結說明
描述: HTTPS安全也是網路安全的一個重要點,想要部署 TLS 是非常容易的，但其難點在於如何使用安全的配置來保障站點的安全。尤其是 Protocol 版本和 Cipher 需要小心選擇和配置, 然後是一個門戶或者其它用途的站點需要根據業務情況、針對使用者群體、實際情況制定相應的TLS配置，最大限度的保證在安全的同時下對業務或者使用者訪問造成的影響越小越好，其次是針對某些嚴重危害應用或資料安全的應該及時修補,避免造成更大的影響。
本文章來源 我的Blog站點 或者 WeiyiGeek 公眾賬號 (
技術交流、友鏈交換請郵我喲)
歡迎各位志同道合的朋友一起學習交流，如文章有誤請留下您寶貴的知識建議，通過郵箱【master#weiyigeek.top】聯絡我喲！