SSL/TLS 是一種看似簡單的技術。它易於部署，正常部署後就可以執行了。但想要部署地安全可靠卻並非易事。這就使得系統管理員和開發者不得不花費額外時間和精力瞭解相關技術，以便能配置一個高安全的伺服器或應用。

為了讓系統管理員輕鬆部署安全站點或應用，本篇將講解SSL/TLS部署最佳實踐。

一、私鑰和證照

在SSL/TLS中，所有安全都始於伺服器的密碼標識。因此需要一個強大的私鑰來防止攻擊。另外，擁有一張有效且強大的證照也是至關重要的，它能授予私鑰代表特定主機名的權利。沒有這兩個基本構建塊，任何東西都無法得到安全保障。

1.1 使用2048位私鑰

對於大多數網站來說，2048位RSA金鑰足以保障其安全性了。RSA加密演算法的普遍應用使得這種型別的金鑰成為預設的安全選擇。如果是2048位，這類金鑰提供了相當於112位的安全性。如果您想要比這更高的安全性，如128位的安全性，您需要3072位的RSA金鑰，但是RSA加密演算法的擴充套件性不太好，3072位的RSA金鑰將會影響效能。金鑰提供了一種替代方案，可以給予更高的安全性和更好的效能。ECDSA金鑰為256位，提供128位的安全性。少數老舊的客戶端不支援ECDSA，但現代客戶端能支援。如果您不介意管理此類設定的開銷，則可以同時部署支援RSA和ECDSA加密演算法的SSL證照。

1.2 保護私鑰

私鑰是非常重要的資產之一，需限制訪問私鑰人數，同時建議您採取以下策略保護私鑰：

ü 在可信的計算機上生成私鑰，建議拒絕CA為您生成私鑰。

ü 從一開始就對金鑰進行安全保護，防止金鑰儲存在備份系統中時遭到破壞。

ü 證照被破壞後，撤銷舊證照並生成新的私鑰。

ü 每年更新SSL證照。如果您採用自動化管理證照，更新頻率應更高。有效期較短的證照在實踐中更安全。

ü 保持證照的公鑰與私鑰相匹配，否則每當您獲得新證照時，還應該生成新的私鑰。

1.3 確保覆蓋所有域名

確保您的SSL證照覆蓋您希望用於所有站點域名，否則無效證照警告會降低使用者對該站點的信任度。經驗法則是，安全的Web伺服器應該具備這樣一個證照，該證照對於指向它的每個DNS名稱都有效。

萬用字元證照有其用途而且能滿足更廣泛的需求，但在跨團隊或部門情況下，使用萬用字元證照時容易將金鑰暴露給很多人。為控制訪問私鑰人數防止私鑰被濫用，這種情況下請避免使用萬用字元證照。

請確保將所有必要的域名新增到使用者可選名稱(SAN)，因為所有最新的瀏覽器都不會透過檢查通用名稱進行驗證。

1.4 從可信CA獲取證照

選擇認真對待其證照業務和安全性的可信證照頒發機構，即CA。選擇 CA 時，請參考以下標準：

ü 對待安全的態度 。所有 CA 都會接受定期審計，但有些CA比其他CA更重視安全。找出在這方面哪個CA做的更好並不容易，但您可以做的一項是檢查他們的安全歷史記錄，檢視CA面對漏洞的反應是怎樣，是否從錯誤中吸取了教訓。

ü 提供的服務 。您選擇的CA應支援證照吊銷列表 (CRL) 和線上證照狀態協議 (OCSP) 吊銷方法，並具有穩定的網路可用性和高效能。許多站點喜歡使用域名驗證型DV證照，但您還應該考站點是否需要擴充套件驗證型EV證照。但無論哪種情況，您都應該選擇公鑰演算法。目前大多數網站都使用RSA演算法，但ECDSA可能會因為其效能優勢在未來變得重要。

ü 證照管理 。如果您需要大量SSL證照並在複雜的環境中執行，請選擇一個可以為您提供良好的管理工具的CA。

注意：為獲得最佳效果，請提前至少一週獲取證照，以便部署並正常執行。這樣做有助於避免因計算機時間不準確而導致出現證照不安全警告。另外，由於CA需要額外的時間才能有效的將新證照傳送給OCSP響應，所以最好先提前獲取證照避免證照撤銷檢查的失敗。因此，千萬不要等到您的證照到期時才替換它們。

1.5 使用強簽名演算法

證照安全性取決於私鑰的強度和簽名中使用的雜湊函式強度。如今SHA1雜湊函式的證照被普遍認為是不安全的，所以最好安裝使用SHA256雜湊函式的證照。

1.6 使用DNS CAA

DNS CAA 是一項防止HTTPS證照錯誤頒發的安全措施，CAA標準可以允許域名所有者限制能為其域名頒發證照的CA。如果沒有CAA記錄，那麼任何人都能為該域名生成CSR並獲取任何CA簽發的證照。使用DNS CAA記錄，可以減少欺詐證照的出現，從而使站點更加安全。如果CA啟用自動簽發證照的流程，那麼就應該檢查DNS CAA記錄，這樣可以減少錯誤頒發證照的風險。

建議透過為您的證照新增CAA記錄將CA列入白名單。新增您信任的CA為您頒發證照。

二、配置

正確的SSL伺服器配置可以讓您的網站身份能正常向使用者展示以增強信任，並能使用安全的加密原語以緩解所有已知的缺陷。

2.1 使用完整的證照鏈

在部署SSL證照時，僅靠伺服器證照是不夠的，這就需要兩個或多個證照來建立完整的信任鏈。如果您部署了一個有效證照，但卻缺少必要的中間證照，那麼就會出現常見的配置問題。為避免這種情況的發生，您需要按相應順序部署CA提供給您的所有證照。

2.2 使用安全的協議

SSL/TLS 系列中有六種協議：SSL 2.0、SSL 3.0、TLS1.0、TLS 1.1、TLS 1.2 和 TLS 1.3：

l SSL 2.0 不安全，不能使用。

l SSL 3.0 與HTTP一起使用時不安全。它也已過時，建議不使用。

l TLS 1.0 和TLS 1.1已於2020年1月棄用。

1.2 和TLS 1.3都沒有已知的安全問題。TLS 1.2或TLS 1.3是目前主要使用的安全協議，因為這些版本提供現代認證加密（也稱為AEAD）。如果您的伺服器不支援 TLS 1.2或TLS 1.3，那您的網站可能缺乏安全性。

l TLS 1.3 相對來說更加安全，效能更強大。

2.3 使用安全的密碼套件

要確保安全通訊，必須首先確定您是直接與所需方通訊（而不是透過竊聽的其他人）並安全地交換資料。在 SSL 和 TLS 中，密碼套件定義了安全通訊的發生方式。它們由不同的構建塊組成，其理念是透過多樣性實現安全。如果發現其中一個構建塊薄弱或不安全，您應該能夠切換到另一個構建塊。

目前主要依賴提供強身份驗證和金鑰交換、前向保密和至少128位加密的AEAD套件。可能仍然有支援其他一些較弱的套件，前提是它們僅與不支援任何更好的舊客戶端協商。下面是一些過時的密碼原語，建議不要使用：

l ADH 套件不提供身份驗證。

l NULL 密碼套件不提供加密。

l 匯出密碼套件在連線中協商時不安全，但也可以針對更喜歡更強大的套件（FREAK攻擊）的伺服器使用。

l 弱密碼（112 位或更少位數）的套件很容易被破解，是不安全的。

l RC4 不安全。

l 64 位分組密碼（3DES / DES / RC2 / IDEA）很弱。

l RSA 金鑰交換密碼套件較弱。

建議 使用AEAD或PFS密碼套件：

l AEAD 密碼套件-包括CHACHA20_POLY1305, GCM and CCM。

密碼套件-包括ECDHE_RSA, ECDHE_ECDSA, DHE_RSA, DHE_DSS, CECPQ1和所有的TLS 1.3密碼。

以下是專為：

注意：建議先在臨時環境中測試TLS配置，只有在確定一切按預期工作時才轉移到生成環境。請注意，以上是一個通用列表，並非所有系統（尤其是舊系統）都支援所有套件，所以建議參考《SSL伺服器配置評級指南》進行檢測。

以上示例配置使用標準的TLS套件名稱。一些平臺使用非標準名稱；有關更多詳細資訊，請參閱您平臺的文件。例如，以下套件名稱將與OpenSSL一起使用：

2.4 選擇最佳密碼套件

在 SSL 3.0 及更高版本的協議中，客戶端需提交他們支援的密碼套件列表，伺服器從列表中選擇一個用於連線的套件。然而，並非所有伺服器都能做出最佳選擇。有些伺服器會從客戶端列表中選擇第一個支援的套件。因此，讓伺服器主動選擇最佳可用密碼套件才能使SSL部署安全達到最佳化。

2.5 使用前向保密

前向保密（也稱完美前向保密，簡稱PFS），它是一種協議功能，可不依賴於伺服器私鑰實現安全對話。如果不使用前向保密的密碼套件，他人就能恢復伺服器私鑰，進而解密所有先前記錄下來加密對話。使用ECDHE套件就能在Web瀏覽器中啟用前向保密。為了支援更廣泛的客戶端，您還應該使用 DHE套件作為ECDHE後備。除非絕對必要，請避免RSA金鑰交換。

2.6 使用強金鑰交換

對於金鑰交換，公共站點通常可以選擇常用的Diffie-Hellman金鑰交換(DHE)或橢圓曲線變體ECDHE。RSA金鑰交換應用非常廣泛，但它不提供前向保密。當然還有其他金鑰交換演算法，但它們通常不安全。

2015 年，一組研究人員發表了針對DHE的新攻擊，他們的工作被稱為Logjam攻擊。研究人員發現，較低強度的DH金鑰交換（例如768位）很容易被破解。為了安全起見，如果部署 DHE，請至少配置2048位。一些老版本的客戶端（例如Java 6）可能不支援這種強度級別。ECDHE相比之下效能更高、更快速。secp256r1命名曲線（也稱為P-256）是一個不錯的選擇。

小結

近年來發生了幾次針對SSL和TLS的嚴重攻擊，但如果您執行的是最新軟體並遵循本指南中的SSL部署最佳實踐建議，那就不必太過擔心這些問題。但是，沒有什麼是絕對安全的，最好的做法是密切關注網路安全，及時解決安全漏洞問題。

本文來源於銳成資訊，轉載請註明地址： https://www.racent.com/blog/ssl-deployment-best-practices

SSL證書部署最佳實踐