[TOC]

0x00 前言簡(jiǎn)述

SSL/TLS 簡(jiǎn)單說(shuō)明

描述: 當(dāng)下越來(lái)越多的網(wǎng)站管理員為企業(yè)站點(diǎn)或自己的站點(diǎn)進(jìn)行了SSL/TLS配置, SSL/TLS 是一種簡(jiǎn)單易懂的技術(shù)情屹，它很容易部署及運(yùn)行，但要對(duì)其進(jìn)行安全部署的情況下通常是不容易迁霎。

如果想掌握如何配置一個(gè)安全的 web 服務(wù)器或應(yīng)用，往往需要系統(tǒng)管理員和開發(fā)者去了解 SSL 和 TLS 相關(guān)的技術(shù), 這無(wú)疑會(huì)耗費(fèi)很大的精力去看相關(guān)的技術(shù)文檔，乏味且寬泛并加大了學(xué)習(xí)成本乳讥。

所以本篇文章主要是為了讓系統(tǒng)管理員或開發(fā)者用盡可能少的時(shí)間部署一個(gè)安全的 web 站點(diǎn)或應(yīng)用考蕾，即 SSL 和 TLS 部署最佳實(shí)踐掖肋，但在學(xué)習(xí)實(shí)踐之前我們需要了解一下SSL/TLS 相關(guān)術(shù)語(yǔ)甩苛，避免在后續(xù)實(shí)踐中一頭霧水蹂楣。

原文地址:

• 如何讓HTTPS站點(diǎn)評(píng)級(jí)達(dá)到A+? 還得看這篇HTTPS安全優(yōu)化配置最佳實(shí)踐指南 【https://blog.weiyigeek.top/2022/4-6-11.html】
• 如何讓HTTPS站點(diǎn)更加安全?這篇HTTPS安全加固配置最佳實(shí)踐指南就夠了 【https://blog.weiyigeek.top/2022/4-6-11.html】

前置知識(shí)推薦了解

• HTTPS原理介紹以及證書簽名的申請(qǐng)配置(https://blog.weiyigeek.top/2019/10-21-10.html)
• SSL與TLS協(xié)議原理和證書簽名生成實(shí)踐指南 (https://blog.weiyigeek.top/2019/10-21-12.html)

SSL/TLS 相關(guān)術(shù)語(yǔ)一覽

EV : EV證書(Extended Validation Certificate)是一種根據(jù)一系列特定標(biāo)準(zhǔn)頒發(fā)的X.509電子證書，根據(jù)要求浪藻，在頒發(fā)證書之前捐迫，證書頒發(fā)機(jī)構(gòu)(CA)必須驗(yàn)證申請(qǐng)者的身份乾翔。不同機(jī)構(gòu)根據(jù)證書標(biāo)準(zhǔn)發(fā)行的擴(kuò)展驗(yàn)證證書并無(wú)太大差異爱葵，但是有時(shí)候根據(jù)一些具體的要求，特定機(jī)構(gòu)發(fā)行的證書可以被特定的軟件識(shí)別反浓。
OV : OV證書(Organization Validation SSL)萌丈，指需要驗(yàn)證網(wǎng)站所有單位的真實(shí)身份的標(biāo)準(zhǔn)型SSL證書，此類證書不僅能夠起到網(wǎng)站信息加密的作用雷则，而且能向用戶證明網(wǎng)站的真實(shí)身份辆雾。
DV : DV證書(Domain Validation SSL)，指需要驗(yàn)證域名的有效性月劈。該類證書只提供基本的加密保障度迂，不能提供域名所有者的信息。

CAA : DNS Certification Authority Authorization猜揪，使用DNS來(lái)指定該域名可以由哪些CA機(jī)構(gòu)簽發(fā)證書惭墓，這不是為TLS層的安全提供保證，而是作為CA簽發(fā)證書程序中的一部分而姐。使用CAA可以避免一些CA簽發(fā)錯(cuò)誤證書的情況腊凶。
CSR : CSR(Certificate Signing Request)，在PKI系統(tǒng)中拴念，CSR文件必須在申請(qǐng)和購(gòu)買SSL證書之前創(chuàng)建钧萍，也就是證書申請(qǐng)者在申請(qǐng)數(shù)字證書時(shí)由CSP(加密服務(wù)提供者)在生成私鑰的同時(shí)也生成證書請(qǐng)求文件，證書申請(qǐng)者只要把CSR文件提交給證書頒發(fā)機(jī)構(gòu)后政鼠，證書頒發(fā)機(jī)構(gòu)使用其根證書私鑰簽名就生成了證書公鑰文件
CT : CT (Certificate Transparency) 證書透明风瘦，Certificate Transparency的目標(biāo)是提供一個(gè)開放的審計(jì)和監(jiān)控系統(tǒng)，可以讓任何域名所有者或者CA確定證書是否被錯(cuò)誤簽發(fā)或者被惡意使用公般，從而提高HTTPS網(wǎng)站的安全性万搔。
CRL : CRL(Certificate revocation list 證書吊銷列表)是一個(gè)已經(jīng)被吊銷的數(shù)字證書的名單器躏，這些在證書吊銷列表中的證書不再會(huì)受到信任，但目前OCSP(在線證書狀態(tài)協(xié)議)可以代替CRL實(shí)現(xiàn)證書狀態(tài)檢查蟹略。
OCSP : OCSP(Online Certificate Status Protocol)是一個(gè)用于獲取X.509數(shù)字證書撤銷狀態(tài)的網(wǎng)際協(xié)議登失，在RCF 6960中定義，作為證書吊銷列表的替代品解決公開密鑰基礎(chǔ)建設(shè)(PKI)中使用證書吊銷列表而帶來(lái)的多個(gè)問(wèn)題挖炬。協(xié)議數(shù)據(jù)傳輸過(guò)程中使用ASN.1編碼揽浙，并通常創(chuàng)建在HTTP協(xié)議上
OCSP Stapling : OCSP裝訂，是TLS證書狀態(tài)查詢擴(kuò)展意敛，作為在線證書狀態(tài)協(xié)議的替代方法對(duì)X.509證書狀態(tài)進(jìn)行查詢馅巷，服務(wù)器在TLS握手時(shí)發(fā)送事先緩存的OCSP響應(yīng)，用戶只要驗(yàn)證該響應(yīng)的時(shí)效性而不用再向數(shù)字證書認(rèn)證機(jī)構(gòu)(CA)發(fā)送請(qǐng)求草姻，可以加快握手速度钓猬。

RSA : RSA加密算法是一種非對(duì)稱加密算法。在公開密鑰加密和電子商業(yè)中RSA被廣泛使用撩独。對(duì)極大整數(shù)做因數(shù)分解的難度決定了RSA算法的可靠性敞曹，支持簽名和加密。
ECC : ECDSA（橢圓曲線簽名算法）的常見叫法综膀，和RSA同時(shí)具有簽名和加密不同澳迫，它只能做簽名，它的優(yōu)勢(shì)是具有很好的性能剧劝、大小和安全性更高橄登。
DH/DHE : Diffie-Hellman(DH)密鑰交換是一種密鑰交換的協(xié)議，DH的訣竅是使用了一種正向計(jì)算簡(jiǎn)單讥此、逆向計(jì)算困難的數(shù)學(xué)函數(shù)拢锹，即使交換中某些因子已被知曉，情況也是一樣萄喳。DH密鑰交換需要6個(gè)參數(shù)卒稳，其中兩個(gè)(dh_p和dh_g)稱為域參數(shù)，由服務(wù)器選取取胎，協(xié)商過(guò)程中展哭，客戶端和服務(wù)器各自生成另外兩個(gè)參數(shù)，相互發(fā)送其中一個(gè)參數(shù)(dh_Ys和dh_Yc)到對(duì)端闻蛀，在經(jīng)過(guò)計(jì)算匪傍，最終得到共享密鑰。臨時(shí)Diffie-Hellman(ephemeral Diffie-Hellman,DHE)密鑰交換中沒(méi)有任何參數(shù)被重復(fù)利用觉痛。與之相對(duì)役衡，在一些DH密鑰交換方式中，某些參數(shù)是靜態(tài)的薪棒，并被嵌入到服務(wù)器和客戶端的證書中手蝎，這樣的話密鑰交換的結(jié)果是一直不變的共享密鑰榕莺，就無(wú)法具備前向保密的能力。
ECDH/ECHDE : 橢圓曲線Diffie-Hellman(elliptic curve Diffie-Hellman棵介，ECDH)密鑰交換原理與DH相似钉鸯，但是它的核心使用了不同的數(shù)學(xué)基礎(chǔ)，ECHD基于橢圓曲線加密邮辽，ECDH密鑰交換發(fā)生在一條由服務(wù)器定義的橢圓曲線上唠雕，這條曲線代替了DH中域參數(shù)的角色，理論上吨述，ECDH支持靜態(tài)的密鑰交換岩睁。臨時(shí)橢圓曲線Diffie-Hellman密鑰交換，和DHE類似揣云，使用臨時(shí)的參數(shù)捕儒，具有前向保密的能力。
RC4 : 是一種流加密算法邓夕，對(duì)稱加密刘莹，密鑰長(zhǎng)度可變。由于RC4算法存在弱點(diǎn)翎迁，2015年2月所發(fā)布的 RFC 7465 規(guī)定禁止在TLS中使用RC4加密算法, Chrome 48版本開始會(huì)拒絕與「以 RC4 做為對(duì)稱加密算法的 CipherSuite」建立 TLS 連接 栋猖。
3DES : 在加密套件中很多的密碼使用的是3DES_EDE_CBC這種類型的，在維基上3DES提供的bits數(shù)是192bits(168+24)汪榔，但由于Meet-in-the-middle attack攻擊的影響，只能提供112bits的安全肃拜。因此在等級(jí)評(píng)定上使用192bits痴腌，在套件的安全性上使用112bits.
PSK : PSK 是“Pre-Shared Key”的縮寫。就是 預(yù)先讓通訊雙方共享一些密鑰（通常是對(duì)稱加密密鑰）, 這種算法用的不多它的好處是：不需要依賴公鑰體系燃领，不需要部屬 CA 證書士聪。不需要涉及非對(duì)稱加密，TLS 協(xié)議握手（初始化）時(shí)的性能好于 RSA 和 DH,密鑰交換時(shí)通訊雙方已經(jīng)預(yù)先部署了若干個(gè)共享的密鑰為了標(biāo)識(shí)多個(gè)密鑰猛蔽，給每一個(gè)密鑰定義一個(gè)唯一的 ID客戶端通過(guò)ID 和服務(wù)端進(jìn)行通訊剥悟。
SRP : TLS-SRP（ Secure Remote Password）密碼套件有兩類：第一類密碼套件僅使用SRP認(rèn)證。第二類使用SRP認(rèn)證和公共密鑰證書來(lái)增加安全性曼库。
TLS GREASE : 為了保持可擴(kuò)展性区岗，服務(wù)器必須忽略未知值，是Chrome 推出的一種探測(cè)機(jī)制毁枯。GREASE for TLS (https://tools.ietf.org/html/draft-davidben-tls-grease-01)
AEAD : 全稱是使用關(guān)聯(lián)數(shù)據(jù)的已驗(yàn)證加密慈缔，Authenticated Encryption with Associated Data (AEAD) algorithms, 是用一個(gè)算法在內(nèi)部同時(shí)實(shí)現(xiàn)cipher+MAC，是TLS1.2种玛、TLS1.3上采用的現(xiàn)代加密算法,相關(guān)密碼套件(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的主力算法瓤檐，互聯(lián)網(wǎng)上https流量的大部分依賴使用AES-GCM。
ChaCha20-poly1305 : ChaCha20-poly1305是一種AEAD娱节，提出者是Daniel J. Bernstein教授挠蛉，針對(duì)移動(dòng)互聯(lián)網(wǎng)優(yōu)化，目前Google對(duì)移動(dòng)客戶端的所有流量都使用ChaCha20-Poly1305
AES-CBC : 關(guān)于AES-CBC肄满，在AES-GCM流行之前碌秸，TLS主要依賴AES-CBC，而由于歷史原因悄窃，TLS在設(shè)計(jì)之初固定選擇了MAC-then-Encrypt結(jié)構(gòu)讥电，AES-CBC和MAC-then-encrypt結(jié)合，為選擇密文攻擊(CCA)創(chuàng)造了便利條件轧抗，TLS歷史上有多個(gè)漏洞都和CBC模式有關(guān)恩敌。

PFS : PFS(perfect forward secrecy)正向保密 ，在密碼學(xué)中也可以被稱為FS(forward secrecy)横媚，是安全通信協(xié)議的特性纠炮，要求一個(gè)密鑰只能訪問(wèn)由它所保護(hù)的數(shù)據(jù)，用來(lái)產(chǎn)生密鑰的元素一次一換灯蝴，不能再產(chǎn)生其他的密鑰恢口，一個(gè)密鑰被破解，并不影響其他密鑰的安全性穷躁。
HPKP : 公鑰固定耕肩，這是一種https網(wǎng)站防止攻擊者使用CA錯(cuò)誤頒發(fā)的證書進(jìn)行中間人攻擊的一種安全機(jī)制，用于預(yù)防諸如攻擊者入侵CA偷發(fā)證書问潭、瀏覽器信任CA簽發(fā)偽造證書等情況猿诸，采用該機(jī)制后服務(wù)器會(huì)提供一個(gè)公鑰哈希列表，客戶端在后續(xù)的通信中只接受該列表上的一個(gè)或多個(gè)公鑰狡忙。

HPKP是一個(gè)響應(yīng)頭 Public-Key-Pins:max-age=xxx;pin-sha256=xxxx;includeSubDomains; 其中可以使用多個(gè)pin-sha256梳虽，pin-sha256的值是對(duì)證書公鑰sha256的值，includeSubDomains決定是否包含所有子域名灾茁，在max-age所指定的時(shí)間內(nèi)(秒)窜觉，證書鏈中的證書至少一個(gè)公鑰須和固定公鑰相符，這樣客戶端才認(rèn)為該證書鏈?zhǔn)怯行У?
還有一種響應(yīng)頭：Public-Key-Pins-Report-Only:max-age=xxx;pin-sha256=xxxx;includeSubDomains;report-uri=xxx,Public-Key-Pins-Report-Only 中的report-uri北专，決定是否回報(bào)違反HTTP公鑰固定策略的事件禀挫。客戶端進(jìn)行HTTP公鑰固定驗(yàn)證失敗后逗余，將把此次錯(cuò)誤詳情以JSON格式回報(bào)個(gè)report-uri參數(shù)中指定的服務(wù)器特咆。

H2 : HTTP/2 的協(xié)議名稱，口語(yǔ)叫法HTTP2和http/1.1 是一個(gè)概念，通過(guò)ALPN協(xié)商, HTTP/2 中只能使用 TLSv1.2+協(xié)議腻格。

CSP : CSP画拾，全稱是 Content Security Policy，它有非常多的指令菜职，用來(lái)實(shí)現(xiàn)各種各樣與頁(yè)面內(nèi)容安全相關(guān)的功能青抛。 這里只介紹兩個(gè)與 HTTPS 相關(guān)的指令，更多內(nèi)容可以看我之前寫的《Content Security Policy Level 2 介紹》酬核。

block-all-mixed-content ：前面說(shuō)過(guò)蜜另，對(duì)于 HTTPS 中的圖片等 Optionally-blockable 類 HTTP 資源，現(xiàn)代瀏覽器默認(rèn)會(huì)加載嫡意。圖片類資源被劫持举瑰，通常不會(huì)有太大的問(wèn)題，但也有一些風(fēng)險(xiǎn)蔬螟，例如很多網(wǎng)頁(yè)按鈕是用圖片實(shí)現(xiàn)的此迅，中間人把這些圖片改掉，也會(huì)干擾用戶使用旧巾。通過(guò) CSP 的 block-all-mixed-content 指令耸序，可以讓頁(yè)面進(jìn)入對(duì)混合內(nèi)容的嚴(yán)格檢測(cè)（Strict Mixed Content Checking）模式。在這種模式下鲁猩，所有非 HTTPS 資源都不允許加載坎怪。跟其它所有 CSP 規(guī)則一樣，可以通過(guò)以下兩種方式啟用這個(gè)指令廓握。
HTTP 響應(yīng)頭方式：Content-Security-Policy: block-all-mixed-content
標(biāo)簽方式：upgrade-insecure-requests 通過(guò) CSP 指令竹捉，可以讓瀏覽器幫忙做這個(gè)轉(zhuǎn)換偿枕。啟用這個(gè)策略后适贸，有兩個(gè)變化頁(yè)面所有 HTTP 資源馆蠕，會(huì)被替換為 HTTPS 地址再發(fā)起請(qǐng)求, 頁(yè)面所有站內(nèi)鏈接，點(diǎn)擊后會(huì)被替換為 HTTPS 地址再跳轉(zhuǎn)是尔；
跟其它所有 CSP 規(guī)則一樣，這個(gè)指令也有兩種方式來(lái)啟用开仰，具體格式請(qǐng)參考上一節(jié)拟枚。需要注意的是 upgrade-insecure-requests 只替換協(xié)議部分，所以只適用于 HTTP/HTTPS 域名和路徑完全一致的場(chǎng)景众弓。

HSTS: 在網(wǎng)站全站 HTTPS 后恩溅，如果用戶手動(dòng)敲入網(wǎng)站的 HTTP 地址，或者從其它地方點(diǎn)擊了網(wǎng)站的 HTTP 鏈接谓娃，依賴于服務(wù)端 301/302 跳轉(zhuǎn)才能使用 HTTPS 服務(wù)脚乡。而第一次的 HTTP 請(qǐng)求就有可能被劫持，導(dǎo)致請(qǐng)求無(wú)法到達(dá)服務(wù)器，從而構(gòu)成 HTTPS 降級(jí)劫持奶稠。該問(wèn)題可以通過(guò) HSTS（HTTP Strict Transport Security俯艰，RFC6797）來(lái)解決。

HSTS 是一個(gè)響應(yīng)頭锌订，格式如下：Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [; preload]

• max-age竹握，單位是秒，用來(lái)告訴瀏覽器在指定時(shí)間內(nèi)辆飘，這個(gè)網(wǎng)站必須通過(guò) HTTPS 協(xié)議來(lái)訪問(wèn)啦辐。也就是對(duì)于這個(gè)網(wǎng)站的 HTTP 地址，瀏覽器需要先在本地替換為 HTTPS 之后再發(fā)送請(qǐng)求蜈项。
• includeSubDomains芹关，可選參數(shù)，如果指定這個(gè)參數(shù)紧卒，表明這個(gè)網(wǎng)站所有子域名也必須通過(guò) HTTPS 協(xié)議來(lái)訪問(wèn)侥衬。
• preload，可選參數(shù)常侦，后面再介紹它的作用浇冰。
  溫馨提示: HSTS 這個(gè)響應(yīng)頭只能用于 HTTPS 響應(yīng)；網(wǎng)站必須使用默認(rèn)的 443 端口聋亡；必須使用域名且不能是 IP肘习。而且啟用 HSTS 之后一旦網(wǎng)站證書錯(cuò)誤，用戶無(wú)法選擇忽略坡倔。

HSTS Preload List: HSTS 可以很好的解決 HTTPS 降級(jí)攻擊漂佩，但是對(duì)于 HSTS 生效前的首次 HTTP 請(qǐng)求，依然無(wú)法避免被劫持罪塔。瀏覽器廠商們?yōu)榱私鉀Q這個(gè)問(wèn)題投蝉，提出了 HSTS Preload List 方案：內(nèi)置一份可以定期更新的列表，對(duì)于列表中的域名征堪，即使用戶之前沒(méi)有訪問(wèn)過(guò)瘩缆，也會(huì)使用 HTTPS 協(xié)議。目前這個(gè) Preload List 由 Google Chrome 維護(hù)佃蚜，Chrome庸娱、Firefox、Safari谐算、IE 11 和 Microsoft Edge 都在使用熟尉。

如果要想把自己的域名加進(jìn)這個(gè)列表，首先需要滿足以下條件,不過(guò)值得注意的是即便滿足了上述所有條件洲脂，也不一定能進(jìn)入 HSTS Preload List斤儿，更多信息可以看這里。

• 擁有合法的證書（如果使用 SHA-1 證書，過(guò)期時(shí)間必須早于 2016 年）往果；
• 將所有 HTTP 流量重定向到 HTTPS疆液；
• 確保所有子域名都啟用了 HTTPS；
• 輸出 HSTS 響應(yīng)頭：
• max-age 不能低于 18 周（10886400 秒）棚放；
• 必須指定 includeSubdomains 參數(shù)枚粘；
• 必須指定 preload 參數(shù)；
  溫馨提示: 通過(guò) Chrome 的 chrome://net-internals/#hsts 工具飘蚯，可以查詢某個(gè)網(wǎng)站是否在 Preload List 之中馍迄，還可以手動(dòng)把某個(gè)域名加到本機(jī) Preload List。

SNI : SNI(服務(wù)器名稱指示)局骤，這個(gè)是一個(gè)擴(kuò)展的TLS協(xié)議攀圈，在該協(xié)議中，在TLS握手過(guò)程中客戶端可以指定服務(wù)器的主機(jī)名稱峦甩，這允許服務(wù)器在相同的IP和端口上部署多個(gè)證書赘来，并允許在相同的IP地址上提供多個(gè)HTTPS網(wǎng)站或者基于TLS的服務(wù)。
SRI : HTTPS 可以防止數(shù)據(jù)在傳輸中被篡改凯傲，合法的證書也可以起到驗(yàn)證服務(wù)器身份的作用犬辰，但是如果 CDN 服務(wù)器被入侵，導(dǎo)致靜態(tài)文件在服務(wù)器上被篡改冰单，HTTPS 也無(wú)能為力幌缝。W3C 的 SRI（Subresource Integrity）規(guī)范可以用來(lái)解決這個(gè)問(wèn)題。SRI 通過(guò)在頁(yè)面引用資源時(shí)指定資源的摘要簽名诫欠，來(lái)實(shí)現(xiàn)讓瀏覽器驗(yàn)證資源是否被篡改的目的涵卵。只要頁(yè)面不被篡改，SRI 策略就是可靠的, 有關(guān) SRI 的更多說(shuō)明請(qǐng)看Jerry Qu寫的《Subresource Integrity 介紹》荒叼。SRI 并不是 HTTPS 專用轿偎，但如果主頁(yè)面被劫持，攻擊者可以輕松去掉資源摘要被廓，從而失去瀏覽器的 SRI 校驗(yàn)機(jī)制坏晦。
ALPN : ALPN(應(yīng)用層協(xié)議協(xié)商 Application-Layer Protocol Negotiation) 是一個(gè)進(jìn)行應(yīng)用層協(xié)議協(xié)商的傳輸層安全協(xié)議(TLS)擴(kuò)展，ALPN允許應(yīng)用層協(xié)商應(yīng)該在安全連接上實(shí)行哪個(gè)協(xié)議嫁乘，以避免額外且獨(dú)立于應(yīng)用層協(xié)議的往返協(xié)商通信, 它已被HTTP/2使用英遭。
NPN : NPN(Next Protocol Negotiation) 下一協(xié)議協(xié)商，在TLS上允許應(yīng)用層協(xié)商使用哪個(gè)協(xié)議亦渗，在2014年7月11日的RFC 7301中使用ALPN代替NPN。
STARTTLS : STARTTLS 是對(duì)純文本通信協(xié)議(SMTP/POP3/IMAP)的擴(kuò)展汁尺。它提供一種方式將純文本連接升級(jí)為加密連接（TLS或SSL）法精，而不是另外使用一個(gè)端口作加密通信。RFC 2595定義了IMAP和POP3的STARTTLS；RFC 3207定義了SMTP的搂蜓；

Session ID : Session ID 完成SSL握手后會(huì)獲得一個(gè)編號(hào)（Session ID）狼荞。如果對(duì)話中斷，下次重連的時(shí)候帮碰，只要客戶端給出這個(gè)編號(hào)相味，且服務(wù)器有這個(gè)編號(hào)的緩存，雙方就可以重新使用已有的"對(duì)話密鑰"殉挽，而不必重新生成一把（握手的主要開銷）丰涉。 因?yàn)橐彺婷總€(gè)連接的握手參數(shù)，服務(wù)端存儲(chǔ)開銷會(huì)比較大斯碌。
Session Ticket : Session ticket獲得方式和SessionID類似一死，但是使用時(shí)是在每次握手時(shí)由服務(wù)器進(jìn)行解密，獲得加密參數(shù)傻唾。服務(wù)端無(wú)需維持握手參數(shù)投慈，可以減少內(nèi)存開銷。

POODLE : POODLE(貴賓犬漏洞 CVE-2014-3566)冠骄，貴賓犬漏洞的根本原因是CBC模式在設(shè)計(jì)上的缺陷伪煤，具體來(lái)說(shuō)就是CBC只對(duì)明文進(jìn)行了身份驗(yàn)證，但是沒(méi)有對(duì)填充字節(jié)進(jìn)行完整性校驗(yàn)凛辣。這使得攻擊者可以對(duì)填充字節(jié)修改并且利用填充預(yù)示來(lái)恢復(fù)加密內(nèi)容抱既，讓POODLE攻擊成為可能的原因是SSL3中過(guò)于松散的填充結(jié)構(gòu)和校驗(yàn)規(guī)則。
TLS POODLE ：TLS POODLE(TLS 貴賓犬漏洞 CVE-2014-8730) 該漏洞的原理和POODLE漏洞的原理一致蟀给，但不是SSL3協(xié)議蝙砌，而是在TLS協(xié)議上，TLS協(xié)議本身沒(méi)有問(wèn)題跋理，但是在其實(shí)現(xiàn)上择克。一些開發(fā)人員在進(jìn)行SSL3到TLS的轉(zhuǎn)換的時(shí)候，沒(méi)有遵守協(xié)議規(guī)定的填充要求前普，使得他們的實(shí)現(xiàn)容易受到POODLE攻擊的威脅

DROWN : 一句話概括就是“使用SSLv2對(duì)TLS進(jìn)行交叉協(xié)議攻擊”肚邢，DROWN(CVE-2016-0800)表示僅支持SSL2是對(duì)現(xiàn)代服務(wù)器和客戶端的威脅，它允許攻擊者通過(guò)講探測(cè)發(fā)送到支持SSLv2的服務(wù)器并使用相同的私鑰來(lái)解密最新客戶端和服務(wù)器之間的TLS連接拭卿，如果如果服務(wù)器容易受到DROWN的影響骡湖，有兩種原因：

• 服務(wù)器允許SSL2連接
• 私鑰用于允許SSL2連接的其他服務(wù)器，即使是另一個(gè)支持SSL/TLS的協(xié)議峻厚，例如响蕴，Web服務(wù)器和郵件服務(wù)器上使用相同的私鑰和證書，如果郵件服務(wù)器支持SSL2惠桃，即使web服務(wù)器不支持SSL2浦夷，攻擊者可以利用
• 郵件服務(wù)器來(lái)破壞與web服務(wù)器的TLS連接辖试。
  使用40bit的出口限制RSA加密套件，單臺(tái)PC能在一分鐘內(nèi)完成工具劈狐，對(duì)于攻擊的一般變體（對(duì)任何SSL2服務(wù)起作用）也可以在8個(gè)小時(shí)內(nèi)完成罐孝。

Logjam : Logjam(CVE-2015-4000) 使用 Diffie-Hellman 密鑰交換協(xié)議的 TLS 連接很容易受到攻擊，尤其是DH密鑰中的公鑰強(qiáng)度小于1024bits肥缔。中間人攻擊者可將有漏洞的 TLS 連接降級(jí)至使用 512 字節(jié)導(dǎo)出級(jí)加密莲兢。這種攻擊會(huì)影響支持 DHE_EXPORT 密碼的所有服務(wù)器。這個(gè)攻擊可通過(guò)為兩組弱 Diffie-Hellman 參數(shù)預(yù)先計(jì)算 512 字節(jié)質(zhì)數(shù)完成续膳，特別是 Apache 的 httpd 版本 2.1.5 到 2.4.7改艇，以及 OpenSSL 的所有版本。

BEAST : BEAST(CVE-2011-3389) BEAST攻擊針對(duì)TLS1.0和更早版本的協(xié)議中的對(duì)稱加密算法CBC模式姑宽，初始化向量IV可以預(yù)測(cè)遣耍，這就使得攻擊者可以有效的講CBC模式削弱為ECB模式，ECB模式是不安全的
Downgrade : Downgrade attack(降級(jí)攻擊) 是一種對(duì)計(jì)算機(jī)系統(tǒng)或者通信協(xié)議的攻擊炮车，在降級(jí)攻擊中舵变，攻擊者故意使系統(tǒng)放棄新式、安全性高的工作方式瘦穆，反而使用為向下兼容而準(zhǔn)備的老式纪隙、安全性差的工作方式，降級(jí)攻擊常被用于中間人攻擊扛或，講加密的通信協(xié)議安全性大幅削弱绵咱，得以進(jìn)行原本不可能做到的攻擊。 在現(xiàn)代的回退防御中熙兔，使用單獨(dú)的信號(hào)套件來(lái)指示自愿降級(jí)行為悲伶，需要理解該信號(hào)并支持更高協(xié)議版本的服務(wù)器來(lái)終止協(xié)商，該套件是TLS_FALLBACK_SCSV(0x5600)

MITM : MITM(Man-in-the-middle) 是指攻擊者與通訊的兩端分別創(chuàng)建獨(dú)立的聯(lián)系住涉，并交換其所有收到的數(shù)據(jù)麸锉，使通訊的兩端認(rèn)為他們正在通過(guò)一個(gè)私密的連接與對(duì)方直接對(duì)話，但事實(shí)上整個(gè)對(duì)話都被攻擊者完全控制舆声，在中間人攻擊中花沉，攻擊者可以攔截通訊雙方的通話并插入新的內(nèi)容。一個(gè)中間人攻擊能成功的前提條件是攻擊者能夠?qū)⒆约簜窝b成每個(gè)參與會(huì)話的終端媳握，并且不被其他終端識(shí)破碱屁。

Openssl Padding Oracle : Openssl Padding Oracle(CVE-2016-2107) openssl 1.0.1t到openssl 1.0.2h之前沒(méi)有考慮某些填充檢查期間的內(nèi)存分配，這允許遠(yuǎn)程攻擊者通過(guò)針對(duì)AES CBC會(huì)話的padding-oracle攻擊來(lái)獲取敏感的明文信息蛾找。

CCS : CCS(openssl MITM CCS injection attack CVE-2014-0224) 0.9.8za之前的Openssl娩脾，1.0.0m之前的以及1.0.1h之前的openssl沒(méi)有適當(dāng)?shù)南拗艭hangeCipherSpec信息的處理，這允許中間人攻擊者在通信之間使用0長(zhǎng)度的主密鑰打毛。

FREAK : FREAK(CVE-2015-0204) 客戶端會(huì)在一個(gè)全安全強(qiáng)度的RSA握手過(guò)程中接受使用弱安全強(qiáng)度的出口RSA密鑰晦雨，其中關(guān)鍵在于客戶端并沒(méi)有允許協(xié)商任何出口級(jí)別的RSA密碼套件架曹。

Export-cipher : 在1998年9月之前，美國(guó)曾經(jīng)限制出口高強(qiáng)度的加密算法闹瞧。具體來(lái)說(shuō)，限制對(duì)稱加密強(qiáng)度為最大40位展辞，限制密鑰交換強(qiáng)度為最大512位奥邮。

CRIME : CRIME(Compression Ratio Info-leak Made Easy CVE-2012-4929)，這是一種可攻擊安全隱患罗珍，通過(guò)它可竊取啟用數(shù)據(jù)壓縮特性的HTTPS或SPDY協(xié)議傳輸?shù)乃矫躓eb Cookie洽腺。在成功讀取身份驗(yàn)證Cookie后，攻擊者可以實(shí)行會(huì)話劫持和發(fā)動(dòng)進(jìn)一步攻擊覆旱。
Heartbleed : Heartbleed(心血漏洞 CVE-2014-0160) 是Openssl的程序漏洞蘸朋，如果使用帶缺陷的Openssl版本，無(wú)論是服務(wù)器還是客戶端扣唱，都可能因此受到攻擊藕坯。此問(wèn)題的原因是在實(shí)現(xiàn)TLS的心跳擴(kuò)展時(shí)沒(méi)有對(duì)輸入進(jìn)行適當(dāng)?shù)尿?yàn)證（缺少邊界檢查），該程序錯(cuò)誤屬于緩沖區(qū)過(guò)讀噪沙，即可以讀取的數(shù)據(jù)比應(yīng)該允許讀取的還多炼彪。

0x01 HTTPS安全實(shí)踐指南

1.證書(certificate)與私鑰(Private key)

描述: 在TLS中所有的安全性都從服務(wù)器的密碼標(biāo)識(shí)開始，所以我們需要一個(gè)強(qiáng)大的私鑰以及有一個(gè)有效的和強(qiáng)大的證書來(lái)防止攻擊者進(jìn)行模擬攻擊正歼。

最佳安全實(shí)踐
1.1) 建議使用2048位的RSA私鑰或者128位的ECDSA私鑰, 注意如果使用RSA私鑰想要獲得128位的安全性,則需要3072位的RSA key, 但會(huì)對(duì)性能造成一定影響, 所以推薦使用ECDSA key它是一種提供更好安全性和更好性能的替代方法辐马。

1.2) 建議保護(hù)好你的私鑰, 在可信計(jì)算機(jī)上用足夠的熵生成私有密鑰, 將密鑰進(jìn)行加密存儲(chǔ)分配給指定人員管理, 可以訪問(wèn)擁有私鑰的人越少越好, 除非保持相同的密鑰對(duì)于公鑰密鑰很重要，否則每當(dāng)獲得新證書時(shí)局义，還應(yīng)該生成新的私鑰喜爷。

1.3) 建議從可信 CA 頒發(fā)獲取證書, 選擇CA時(shí)重點(diǎn)考慮如果以下條件提供商是否發(fā)生過(guò)安全風(fēng)險(xiǎn)、業(yè)務(wù)側(cè)重點(diǎn)萄唇、是否提供對(duì)證書吊銷列表（CRL）和在線證書狀態(tài)協(xié)議（OCSP）撤銷方法的支持檩帐、是否提供便捷的證書管理無(wú)法。

1.4) 建議使用強(qiáng)簽名算法,證書安全性取決于用于簽署證書的私鑰的強(qiáng)度穷绵、簽名中使用的散列函數(shù)的強(qiáng)度, 當(dāng)前大多數(shù)的證書都依賴于SHA256散列函數(shù),截止2022年轿塔。

1.5) 建議為指定站點(diǎn)名稱申請(qǐng)對(duì)應(yīng)證書而非使用通配符(泛域名)證書，通配符證書能滿足更廣泛的需求但如果準(zhǔn)備將密鑰暴露給更多的人員仲墨，特別是跨團(tuán)隊(duì)或部門勾缭，則避免使用它們。

溫馨提示: 為了獲得最佳效果目养，請(qǐng)?zhí)崆矮@得證書俩由，并在部署到生產(chǎn)業(yè)務(wù)環(huán)境之前至少一周，有助于避免在計(jì)算機(jī)上沒(méi)有正確時(shí)間的一些用戶的證書警告癌蚁，以及避免與 CA 需要額外時(shí)間的 CA 失敗的撤銷檢查幻梯，以向 OCSP 響應(yīng)者傳播有效的新證書

2.中間件SSL/TLS服務(wù)器配置

描述: 使用正確的TLS服務(wù)器配置兜畸，您可以確保將憑據(jù)正確呈現(xiàn)給站點(diǎn)的訪問(wèn)者，僅使用安全的加密原語(yǔ)碘梢，并減輕所有已知的缺陷咬摇。

最佳安全實(shí)踐

2.1) 建議使用完整的證書鏈, 通過(guò)情況下僅服務(wù)器證書不夠的,我們需要兩個(gè)或多個(gè)證書來(lái)建立完整的信任鏈，當(dāng)部署具有有效證書但沒(méi)有所有必要的中間證書的服務(wù)器時(shí)會(huì)發(fā)生常見的配置問(wèn)題煞躬，這是因?yàn)闊o(wú)效的證書鏈有效地使服務(wù)器證書無(wú)效并導(dǎo)致瀏覽器警告肛鹏。

Let'sEncrypt快速頒發(fā)及自動(dòng)續(xù)簽泛域名證書實(shí)踐指南(https://blog.weiyigeek.top/2022/3-11-589.html)

# 例如, 我采用Let'sEncrypt進(jìn)簽發(fā)的證書，生成nginx響應(yīng)的證書配置鏈恩沛。
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協(xié)議, 避免使用 SSL v2在扰，SSL v3, 當(dāng)前推薦使用 TLS v1.0，TLS v1.1和TLS v1.2 以及 TLS 1.3 協(xié)議以消除所有過(guò)時(shí)和不安全的功能雷客。

# Nginx
# intermediate configuration
ssl_protocols TLSv1.2 TLSv1.3;

2.3) 建議選擇使用安全的套件, 為了安全通信您必須首先確定您正在與所需方（而不是通過(guò)將竊聽的其他人）直接溝通并安全地交換數(shù)據(jù)則需要至少128位加密的AEAD套件, 并且在配置中避免使用如下加密套件

NULL 密碼套件不提供加密
匿名 Diffie-Hellman（ADH）套件不提供身份驗(yàn)證
弱密碼（通常為 40 和 56 位）的套件使用可以輕松破壞的加密
MD5 密碼套件是不安全的,容易被碰撞檢測(cè)
RC4 密碼套件是不安全的
DES/3DES 密碼套件緩慢而虛弱

例如, Nginx 中的ssl_ciphers配置項(xiàng)里加入不支持如下 !NULL:!aNULL:!eNULL:!EXPORT:!PSK:!ADH:!DES:!3DES:!MD5:!RC4; 密碼套件芒珠。
# 使用以RSA和ECDSA鍵為基礎(chǔ)的以下套件配置，作為起點(diǎn)（使用標(biāo)準(zhǔn) 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 命令查看指定套件對(duì)應(yīng)的標(biāo)準(zhǔn) TLS 套件名稱以及支持的協(xié)議搅裙。
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
# 推薦安全配置（犧牲了兼容性）生產(chǎn)環(huán)境中請(qǐng)根據(jù)業(yè)務(wù)需要配置皱卓。
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) 建議選擇合適的協(xié)議在SSLv3及更高版本的協(xié)議版本中, 將通用性安全較強(qiáng)的套件放在首位，使服務(wù)器主動(dòng)選擇最佳可用加密套件對(duì)于實(shí)現(xiàn)最佳安全性至關(guān)重要呈宇。

2.5) 建議使用FS前向保密, FS有時(shí)也稱為完全前向保密是一種協(xié)議功能好爬，可實(shí)現(xiàn)不依賴服務(wù)器私鑰的安全對(duì)話, 對(duì)于不提前向保密的密碼套件，如果有可以恢復(fù)服務(wù)器的私鑰的人就可以解密所有較早記錄的加密對(duì)話（也就是可以先大量記錄密文甥啄，再解密存炮，比如您的證書到期后沒(méi)有正確銷毀，它的私鑰就能用來(lái)解密非PFS的密文）蜈漓，所以我們應(yīng)該使用 DHE 套件作為 ECDHE 后備并且避免 RSA 密鑰交換（除非必要）穆桂。

2.6) 建議使用強(qiáng)的密鑰交換算法，前面我們說(shuō)不建議選擇經(jīng)典的短暫的 Diffie-Hellman密鑰交換（DHE）以及RSA 密鑰交換（不提供FS前向保密）融虽，通常推薦其橢圓曲線變體 ECDHE 密鑰交換享完，它更加安全和快速。

溫馨提示: 我們建議您始終首先在分段環(huán)境中測(cè)試TLS配置有额，僅在確定所有內(nèi)容按預(yù)期工作時(shí)將更改應(yīng)用到生產(chǎn)環(huán)境般又。請(qǐng)注意，以上是一個(gè)通用列表巍佑，并不是所有系統(tǒng)（特別是較舊的）支持所有套件茴迁。

3.SSL/TLS站點(diǎn)性能

描述: 本章節(jié)HTTPS安全是我們討論的重點(diǎn),于此同時(shí)我們也需要關(guān)注配置了TLS站點(diǎn)的性能, 一個(gè)不符合性能標(biāo)準(zhǔn)的安全服務(wù)無(wú)疑將被丟棄。通過(guò)正確配置TLS服務(wù)器訪問(wèn)其站點(diǎn)時(shí)速度將會(huì)有很大提升, 例如使用現(xiàn)代協(xié)議（例如 HTTP/2）萤衰，甚至可能比明文通信更快堕义。。

最佳安全實(shí)踐
3.1) 建議避免使用過(guò)度安全的密鑰長(zhǎng)度, 使用超過(guò) 2048 位的 RSA 密鑰和強(qiáng)大于 256 位的 ECDSA 密鑰會(huì)浪費(fèi) CPU 功耗脆栋，并可能會(huì)損害用戶體驗(yàn)倦卖。

3.2) 建議使用 session 恢復(fù), 會(huì)話恢復(fù)是一種性能優(yōu)化技術(shù)洒擦，可以節(jié)省昂貴的密碼操作的結(jié)果，并重復(fù)使用一段時(shí)間.

# Nginx 
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m;  # about 40000 sessions
ssl_session_tickets off;

3.3) 建議使用 WAN 優(yōu)化和啟用 HTTP/2, 通常TLS 開銷不是來(lái)自CPU的加密操作怕膛，而是來(lái)自網(wǎng)絡(luò)延遲, 只有在 TCP 握手完成后才能啟動(dòng)TLS握手熟嫩，需要進(jìn)一步交換數(shù)據(jù)包，并且離開服務(wù)器的距離更遠(yuǎn), 所以最小化延遲的最佳方法是避免創(chuàng)建新的連接嘉竟，換句話說(shuō)就是保持現(xiàn)有的連接長(zhǎng)時(shí)間（keep-alives）邦危。

# Nginx
server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
}
......

3.4) 建議緩存網(wǎng)站中公共的靜態(tài)資源, 通過(guò)TLS進(jìn)行通信時(shí)瀏覽器可能會(huì)認(rèn)為所有流量都是敏感的, 默認(rèn)的瀏覽器在使用中會(huì)緩存某些靜態(tài)資源但是一旦關(guān)閉瀏覽器所有緩存內(nèi)容可能會(huì)丟失, 所以為了獲得性能提升我們需要長(zhǎng)期緩存一些靜態(tài)資源。

3.5) 建議使用 OCSP Stapling, OCSP 裝訂是 OCSP 協(xié)議的擴(kuò)展舍扰，可以直接從服務(wù)器提供撤銷信息作為 TLS 握手的一部分。因此客戶端不需要聯(lián)系 OCSP 服務(wù)器進(jìn)行帶外驗(yàn)證希坚，并且總體 TLS 連接時(shí)間顯著減少边苹。

# 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 密鑰進(jìn)行快速加密, 在選擇加密套件時(shí)除了保證其安全性還需要其良好的性能表現(xiàn), 盡可能使用支持硬件加速 AES 的 CPU。

溫馨提示: 用于建立安全連接的密碼握手是一種操作裁僧，其費(fèi)用受私鑰大小的高度影響,使用太短的密鑰是不安全的个束，但使用太長(zhǎng)的密鑰將導(dǎo)致“太多”的安全性和緩慢的操作。
溫馨提示: 殘疾或非功能性會(huì)話恢復(fù)機(jī)制可能會(huì)引起顯著的性能損失聊疲。
溫馨提示: OCSP裝訂是一種重要的優(yōu)化技術(shù)茬底，但并不是所有的網(wǎng)絡(luò)服務(wù)器都提供了可靠的 OCSP 裝訂實(shí)現(xiàn)。

4.HTTP與應(yīng)用安全

描述: HTTP 協(xié)議和 Web 應(yīng)用交付的周邊平臺(tái)在 SSL 誕生后繼續(xù)快速發(fā)展, 所以在進(jìn)行TLS服務(wù)器配置時(shí)它們也是最重要的一環(huán)获洲。

最佳安全實(shí)踐
4.1) 建議加密無(wú)處不在, https加密不能是可選項(xiàng),可靠地保護(hù)網(wǎng)站通信的唯一方法是無(wú)一例外地執(zhí)行加密阱表。

4.2) 建議消除混合內(nèi)容, 請(qǐng)將任何地方的所有內(nèi)容都 HTTPS 化（全站 HTTPS）, 通過(guò) TLS 傳輸?shù)前煌ㄟ^(guò) TLS 傳輸?shù)馁Y源（例如，JavaScript 文件贡珊，images最爬，CSS 文件）的頁(yè)面, 可能會(huì)被一個(gè)活躍的中間人（MITM）攻擊者可以搭載一個(gè)單獨(dú)的未受保護(hù)的 JavaScript 資源，便有可能劫持用戶的會(huì)話门岔。

4.3) 建議使用可信第三方j(luò)s或者css并且第三方必須是警告https加密的從而避免MITM 攻擊, 于此同時(shí)使用子資源完整性（SRI）的新技術(shù)爱致，可用于通過(guò)第三方資源來(lái)減少潛在的風(fēng)險(xiǎn)。

4.4) 建議配置安全cookie寒随，要正確安全網(wǎng)站需要 TLS糠悯，而且所有的 Cookie 在創(chuàng)建時(shí)都被明確標(biāo)記為安全的，為了獲得最佳效果妻往，請(qǐng)考慮為您的 Cookie 添加加密完整性驗(yàn)證或甚至加密互艾。

4.5) 建議進(jìn)行安全 HTTP 壓縮, TIME 和 BREACH 專注于使用 HTTP 壓縮壓縮的 HTTP 響應(yīng)實(shí)體中的秘密，HTTP 壓縮是必需的不能關(guān)閉蒲讯。

4.6) 建議部署配置 CSP ,內(nèi)容安全策略（CSP）是網(wǎng)站可以用來(lái)限制瀏覽器操作的安全機(jī)制忘朝。盡管最初旨在解決跨站點(diǎn)腳本（XSS），CSP 不斷發(fā)展并支持對(duì)增強(qiáng)TLS安全性有用的功能, 部署CSP可以防止第三方混合內(nèi)容判帮，通常使用Strict-Transport-Security響應(yīng)頭局嘁。

4.7) 建議不要緩存敏感內(nèi)容

4.8) 考慮其它威脅, TLS 旨在僅解決安全機(jī)密和您與用戶之間通信的完整性的一個(gè)方面溉箕，但還有許多其他威脅需要處理,確保您的網(wǎng)站盡可能的減少攻擊面。

溫馨提示: 下述配置是不一定是部署 CSP 的最佳方法,為了提供不破壞混合內(nèi)容以外的任何內(nèi)容的示例悦昵，我不得不禁用某些默認(rèn)安全功能肴茄。隨著時(shí)間的推移，當(dāng)您了解 CSP 的更多信息時(shí)但指，您應(yīng)該更改您的策略以使其恢復(fù)寡痰。

Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval'; connect-src https: wss:

5.定期HTTPS檢查避免已知問(wèn)題

描述: 近幾年來(lái)已經(jīng)發(fā)生了幾次嚴(yán)重的 SSL 和 TLS 攻擊，但是如果您正在運(yùn)行最新的openssl軟件以及使用上述指南中的協(xié)議和加密套件建議棋凳，那么它們通常不會(huì)關(guān)心您拦坠。但是沒(méi)有什么是完全安全的，所以為了保持對(duì)安全性的了解, 你應(yīng)該排查和關(guān)注https相關(guān)漏洞, 以便于在第一時(shí)間保護(hù)或更新您的TLS服務(wù)器配置剩岳。

所以通常情況下我建議定期使用全面的 SSL/TLS 評(píng)估工具來(lái)驗(yàn)證您的配置贞滨，以確保您開始安全，對(duì)于公共網(wǎng)站建議您使用如下SSL實(shí)驗(yàn)室服務(wù)器進(jìn)行站點(diǎn)https測(cè)試評(píng)估??拍棕。

最佳安全實(shí)踐
5.1) 建議定期使用如下SSL晓铆、TLS 評(píng)估工具對(duì)TLS配置進(jìn)行檢查評(píng)估。

• 國(guó)外推薦:
  ssllabs : 網(wǎng)站地址(https://www.ssllabs.com)绰播，其檢測(cè)內(nèi)容非常的詳細(xì)骄噪，包括證書、協(xié)議以及客戶端模擬和兼容行蠢箩。
  cdn77 : 網(wǎng)站地址(https://www.cdn77.com/tls-test), 功能單一只針對(duì) TLS 链蕊、SSL協(xié)議版本進(jìn)行評(píng)估。

WeiyiGeek.ssllabs證書配置檢測(cè)

• 國(guó)內(nèi)推薦:
  myssl : 網(wǎng)站地址(https://myssl.com),這個(gè)是國(guó)內(nèi)的檢測(cè)站點(diǎn)與 ssllabs 相似忙芒，但個(gè)人感覺(jué)界面更清爽示弓，證書檢測(cè)的功能更多，訪問(wèn)速度也是快很多杠杠的呵萨，它還可以為您的https站點(diǎn)進(jìn)行多方面綜合的評(píng)級(jí)奏属，其中包括了證書、SSL協(xié)議潮峦、加密套件囱皿、漏洞、不安全的外鏈等等忱嘹，便于網(wǎng)站管理人員排查驗(yàn)證服務(wù)器應(yīng)用證書配置是否正確嘱腥。

WeiyiGeek.檢測(cè)部署SSL/TLS的服務(wù)是否符合行業(yè)最佳實(shí)踐

5.2) 建議排查驗(yàn)證配置的TLS服務(wù)器是否使用下述相關(guān)漏洞所關(guān)聯(lián)的openssl版本、加密套件以及脆弱的SSL拘悦、TLS協(xié)議齿兔。

DROWN 漏洞
OpenSSL Padding Oracle 攻擊
FREAK漏洞
Logjam漏洞
OpenSSL CCS 注入漏洞
心血漏洞(Heartbleed)
POODLE漏洞
CRIME漏洞

5.3) 了解或者使用 HPKP, 公共密鑰固定旨在使網(wǎng)站運(yùn)營(yíng)商有權(quán)限制哪些 CA 可以為其網(wǎng)站頒發(fā)證書。Google 已經(jīng)部署了這個(gè)功能了一段時(shí)間（硬編碼到他們的瀏覽器，Chrome）分苇，并且已被證明是非常有用的添诉，以防止攻擊并使公眾了解它們, 但是需要一定的成本，部署需要大量精力和專業(yè)知識(shí)医寿。

5.4) 建議配置使用 DNSSEC, 全稱是域名系統(tǒng)安全擴(kuò)展（Domain Name System Security Extensions）栏赴，它是一種增加域名系統(tǒng)完整性的技術(shù)，是由IETF提供的一系列DNS安全認(rèn)證的機(jī)制（可參考RFC2535）它提供一種可以驗(yàn)證應(yīng)答信息真實(shí)性和完整性的機(jī)制靖秩，利用密碼技術(shù)须眷，使得域名解析服務(wù)器可以驗(yàn)證它所收到的應(yīng)答(包括域名不存在的應(yīng)答)是否來(lái)自于真實(shí)的服務(wù)器，或者是否在傳輸過(guò)程中被篡改過(guò)沟突。通過(guò)DNSSEC的部署花颗，可以增強(qiáng)對(duì)DNS域名服務(wù)器的身份認(rèn)證，進(jìn)而幫助防止DNS緩存污染等攻擊惠拭。（配置示例請(qǐng)參考下小節(jié)的實(shí)踐配置）

簡(jiǎn)單的說(shuō)捎稚，DNSSEC依靠數(shù)字簽名保證DNS應(yīng)答報(bào)文的真實(shí)性和完整性。

WeiyiGeek.DNSSEC運(yùn)作方式

5.5) 建議為電子郵件系統(tǒng)配置使用 DANE , DANE一種將X.509證書綁定到DNS中的機(jī)制, 可用于存儲(chǔ)自簽名證書或者從CA簽發(fā)的特定X.509證書, 其中, 證書作為DNS資源記錄通過(guò)DNSSEC來(lái)實(shí)現(xiàn)其來(lái)源驗(yàn)證和完整性保護(hù),根據(jù)證書用途的不同, 基于DANE的DNS資源記錄也有所不同, DANE協(xié)議的動(dòng)機(jī)之一是解決現(xiàn)有的基于X.509的PKI的問(wèn)題. 例如, DANE在應(yīng)對(duì)欺詐證書求橄、處理證書撤銷、創(chuàng)建可全球發(fā)布和檢索證書的管理機(jī)制并允許自簽名證書授權(quán)等方面提供了很好的解決方式.

實(shí)踐配置
1.在騰訊云DNSPod控制臺(tái)開啟DNSSEC流程操作葡公。(PS: 收費(fèi)版DNS套餐提供)
第一步：登陸 DNSPod 控制臺(tái)開啟 DNSSEC 服務(wù)罐农。

[控制臺(tái)]- DNS 解析 - 我的域名 - 域名設(shè)置 - DNSSEC ，點(diǎn)擊開啟催什，即可查看該域名的 DS 記錄涵亏。

第二步：前往域名注冊(cè)商控制臺(tái)添加 DS 記錄。

前面拿到的 DS 記錄蒲凶，還需在您域名注冊(cè)商的控制臺(tái)進(jìn)行添加气筋。(如果您的域名同樣注冊(cè)于騰訊云(DNSPod)，則該步驟自動(dòng)完成)
PS: 該域名注冊(cè)于騰訊云且屬當(dāng)前賬號(hào)旋圆，系統(tǒng)將自動(dòng)為您添加 DS 記錄(https://docs.dnspod.cn/dns/dnssec-configuration/)

WeiyiGeek.騰訊云中開啟DNSSEC服務(wù)

第三步: 查看驗(yàn)證DNSSEC是否配置成功, 此處仍然以騰訊云為例（我的域名在騰訊購(gòu)買的沒(méi)辦法）宠默。

[控制臺(tái)]- 域名注冊(cè) - 我的域名 -> 管理 -> 域名安全 -> DNSSEC 設(shè)置（點(diǎn)擊管理）

WeiyiGeek.騰訊云中查看DNSSEC配置

溫馨提示: 目前只有少數(shù)注冊(cè)商支持 DNSSEC ，如果您域名所在注冊(cè)商不支持灵巧，可先將域名轉(zhuǎn)入騰訊云搀矫，轉(zhuǎn)入后方便一站管理，更可一鍵開啟(帶轉(zhuǎn)入鏈接)

總結(jié)說(shuō)明
描述: HTTPS安全也是網(wǎng)絡(luò)安全的一個(gè)重要點(diǎn),想要部署 TLS 是非常容易的刻肄，但其難點(diǎn)在于如何使用安全的配置來(lái)保障站點(diǎn)的安全瓤球。尤其是 Protocol 版本和 Cipher 需要小心選擇和配置, 然后是一個(gè)門戶或者其它用途的站點(diǎn)需要根據(jù)業(yè)務(wù)情況、針對(duì)用戶群體敏弃、實(shí)際情況制定相應(yīng)的TLS配置卦羡，最大限度的保證在安全的同時(shí)下對(duì)業(yè)務(wù)或者用戶訪問(wèn)造成的影響越小越好，其次是針對(duì)某些嚴(yán)重危害應(yīng)用或數(shù)據(jù)安全的應(yīng)該及時(shí)修補(bǔ),避免造成更大的影響。

本文章來(lái)源 我的Blog站點(diǎn) 或者 WeiyiGeek 公眾賬號(hào) (技術(shù)交流绿饵、友鏈交換請(qǐng)郵我喲)
歡迎各位志同道合的朋友一起學(xué)習(xí)交流欠肾，如文章有誤請(qǐng)留下您寶貴的知識(shí)建議，通過(guò)郵箱【master#weiyigeek.top】聯(lián)系我喲蝴罪！