如何決定使用 nginx 設置哪些 ssl_protocols 和 ssl_ciphers？
我最近在我的域中添加了 TLS（使用 certbot 加密）。它帶有一個基本配置
options-ssl-nginx.conf，其中包括ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS";這部分與Mozilla 推薦的相同。
然後我使用https://ssldecoder.org和 . 他們抱怨我的伺服器不支持 TLSv1.3
**問題一：為什麼 ssl_protocols 中沒有 TLSv1.3？**有什麼理由不加嗎？
使用https://www.ssllabs.com/ssltest檢查我的網站顯示了一些關於支持的 SSL 密碼的投訴：
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_CBC_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA256
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA
問題 2：我應該如何決定支持哪些密碼？
如果支持的密碼越少，則能夠訪問該站點的設備就越少。但是有沒有辦法讓我判斷會有多少（比如caniuse.com 用於 css，但用於密碼）？而且，由於這是優先順序，客戶仍然可以選擇他們喜歡的任何人：為什麼我不應該支持所有？
對此沒有唯一的正確答案，因為選擇密碼套件必須是安全性和兼容性之間的適當折衷。連結在配置生成器上的Mozilla 的伺服器端 TLS 指南解釋了不同配置文件的用途：
- **現代兼容性。**對於不需要向後兼容的服務，以下參數提供了更高級別的安全性。此配置與 Firefox 27、Chrome 30、Windows 7 上的 IE 11、Edge、Opera 17、Safari 9、Android 5.0 和 Java 8 兼容。
- 中間兼容性（預設）。對於不需要兼容舊版客戶端（主要是 WinXP）但仍需要支持多種客戶端的服務，建議使用此配置。它與 Firefox 1、Chrome 1、IE 7、Opera 5 和 Safari 兼容
- 舊的向後兼容性。這是舊密碼套件，適用於所有回到 Windows XP/IE6 的客戶端。它應該僅作為最後的手段使用。
已在討論將 TLS 1.3 添加到這些建議中，但尚未添加。這個推理是從 2016 年開始的，在 TLS 1.3 被提議作為RFC 8446中的標準之前：
jvehent 於 2016 年 12 月 27 日
我認為我們不應該在這裡推薦實驗版本。在將 CHACHA20 添加到指南之前，我們等待其標準化，這同樣適用於 TLS1.3。
同樣，Qualys SSL Labs 發布了SSL 和 TLS 部署最佳實踐。由於它（截至 2019 年 6 月）最後一次更新是在 2017 年 5 月，它還提到 TLS 1.3 僅作為未來協議，但它解釋了 TLS 1.2 之前的舊版本的問題：
TLS v1.2 應該是您的主要協議，因為它是唯一提供現代認證加密（也稱為 AEAD）的版本。如果您今天不支持 TLS v1.2，那麼您的安全性就會不足。
為了支持舊客戶端，您現在可能需要繼續支持 TLS v1.0 和 TLS v1.1。但是，您應該計劃在不久的將來停用 TLS v1.0。例如，PCI DSS 標準將要求所有接受信用卡付款的網站在 2018 年 6 月之前取消對 TLS v1.0 的支持。
目前正在進行設計 TLS v1.3 的工作，旨在刪除所有過時和不安全的功能，並進行改進，以確保我們在接下來的幾十年中的通信安全。
SSL Labs 伺服器測試會更定期更新，並指出其他可能的弱點：
- 所有
TLS_RSA密碼套件都被標記為弱，因為它們不提供前向保密：如果私鑰在未來被洩露，所有記錄的流量都可以使用它來解密。- 所有使用密碼塊連結
CBC的密碼套件都不會自動變弱，但是有太多的實現容易受到填充預言機攻擊，他們決定將它們都標記為弱。從 2015 年 5 月開始，我們還有一個最佳實踐 RFC 7525；安全使用傳輸層安全 (TLS) 和數據報傳輸層安全 (DTLS) 的建議。它的第 4.2 節給出了類似於 Mozilla 的現代兼容性和 SSL 實驗室伺服器測試的建議：
鑑於上述考慮，建議實施和部署以下密碼套件：
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
這些密碼套件僅在 TLS 1.2 中受支持，因為它們是經過身份驗證的加密 (AEAD) 算法
$$ RFC5116 $$.
基於所有這些，通過例如“調整您的需求”現代配置文件可能會很好
- 從現代兼容性配置文件中刪除基於 CBC 的密碼套件，即刪除
ECDHE-ECDSA-AES256-SHA384、、、、ECDHE-RSA-AES256-SHA384``ECDHE-ECDSA-AES128-SHA256``ECDHE-RSA-AES128-SHA256- 添加 DHE 密碼套件，只要它們的密鑰長度至少為 2048 位並使用 GCM 模式：
DHE-RSA-AES256-GCM-SHA384,DHE-RSA-AES128-GCM-SHA256.SSL Labs Server Test 中的握手模擬部分有助於指出配置不支持的瀏覽器。由您決定支持它們是否重要，並添加該瀏覽器上可用的最強密碼套件。
是否等待 Mozilla 關於實施 TLS 1.3 的建議也是基於意見的。對您來說好消息是 TLS 1.3 已完全刪除對所有舊算法的支持，這使得挑選壞密碼套件變得更加困難。來自RFC 8446, 1.2。 與 TLS 1.2 的主要區別：
支持的對稱加密算法列表已刪除所有被視為遺留的算法。剩下的都是帶有關聯數據的認證加密 (AEAD) 算法。密碼套件概念已更改為將身份驗證和密鑰交換機制與記錄保護算法（包括密鑰長度）和與密鑰派生函式和握手消息身份驗證程式碼 (MAC) 一起使用的散列分開。