有很多大問題，它們問什麼是用於網站的最佳證書？但是，一旦購買了證書，就有可能選擇或編輯密碼列表。
儘管每個供應商可能將此設置稱為稍有不同，但我的理解是密碼列表用於協商加密客戶端和服務器之間的協議。
為我的網站選擇密碼列表的基礎是什麼？如果需要更改默認值，“初學者”應該從哪裡獲得可靠的建議？
自2011年9月的BEAST攻擊或2012年的CRIME攻擊以來，任何傳統建議都發生了變化嗎？
有人維護列表嗎？ OS /供應商/版本支持的密碼集？說這樣的話會有用嗎？
某些證書與某些密碼不兼容或不受歡迎嗎？
- ol>
在哪裡可以了解更多信息？具體來說，如何獲得粗略的密碼比較能力，而不必重新參加一些中學後的數學課程？
在 SSL / TLS中，密碼套件為一系列任務選擇一組算法：密鑰協商，對稱加密，完整性檢查。
證書類型影響關鍵協議的選擇。必須考慮兩個參數：密鑰類型和密鑰用法：
大多數SSL服務器證書都具有不受密鑰用法擴展限制的RSA密鑰，因此您可以同時使用“ RSA”和“ DHE_RSA”密鑰類型。
“ DHE”代表“ Diffie-Hellman Ephemeral”。這樣可以實現完美的前向保密性。 PFS意味著，如果攻擊者竊取了服務器私鑰（存儲在文件中的私鑰，因此很可能容易被盜竊），他將仍然無法解密過去記錄的交易。這是一個理想的屬性，尤其是當您希望系統在審核過程中保持良好狀態時。
對於完整性檢查，您不應使用MD5，並且如果可能，請避免使用MD5。 SHA-1也是如此。 MD5和SHA-1的當前已知弱點均不影響TLS的安全性（可能在證書中使用時除外，但這是由CA選擇的，而不是您選擇的）。但是，使用MD5（或在較小程度上使用SHA-1）對公共關係不利。 MD5被“破壞”。如果使用MD5，則可能必須證明自己是正確的。沒有人會質疑SHA-256的選擇。普遍的共識是，SHA-1出於遺留原因是“可容忍的”。
對於對稱加密，您可以在RC4、3DES和AES之間選擇（主要是RC4、3DES和AES）（對於後者，256位版本是過大的； AES-128已經可以了）。可以提出以下幾點：
RC4和3DES到處都受支持。最老的客戶端可能不支持AES（例如，Internet Explorer 6.0似乎無法協商基於AES的密碼套件）。
RC4中存在已知的弱點。沒有什麼是致命的。這種情況與SHA-1的情況有點相似：從學術上講“已損壞”，但現在不是問題。如果可以避免的話，這仍然是不使用RC4的一個很好的理由。
3DES是64位分組密碼。當您在單個會話中加密多個千兆字節時，這意味著一些（學術上的）弱點。
3DES在您的CPU上可能很繁重。在2.7 GHz Intel i7上， OpenSSL使用AES-128達到180 MB / s的加密速度（如果使用 AES-NI指令則可以做得更好），但僅使用3DES時為25 MB / s。 25 MB / s仍然不錯（這是100 Mbit / s鏈路可以處理的2.5倍，並使用單個內核），但可能無法忽略，具體取決於您的情況。
BEAST攻擊是一個古老的學術弱點，最近被證明可以在實踐中應用。它要求攻擊者在鏈接上進行間諜，並且在客戶端上運行惡意代碼（並且該代碼必須與外部間諜系統進行通信）；當惡意的內部代碼使用Java或Javascript時，BEAST的作者設法運行了它。通用解決方案是切換到不受干擾的TLS 1.1或1.2。同樣，這僅涉及CBC模式下的分組密碼。 RC4是免疫的。
在SSL / TLS握手中，客戶端宣布其支持的密碼套件（優先出現的優先套件），然後服務器選擇將要使用的套件。服務器會遵守客戶的偏好設置，這是傳統的，即選擇客戶端發送的列表中服務器可以處理的第一套套件。但是服務器可以強制執行其自己的首選項順序。
沒有使用RC4的DHE密碼套件。
摘要：，這使我想到了以下首選的密碼套件列表。如果BEAST攻擊可能適用於您（即客戶端是Web瀏覽器），請使用以下命令：
TLS_RSA_WITH_RC4_128_SHA 。 TLS_RSA_WITH_RC4_128_SHA ，或者您認為PFS對您而言比BEAST更為重要主動攻擊（例如，您最關心的是長期保密性，而不是立即違反），然後使用 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 （如果客戶端不支持SHA-256，則退回到 TLS_DHE_RSA_WITH_AES_128_CBC_SHA ） TLS_RSA_WITH_3DES_EDE_CBC_SHA ，該密碼在任何地方都可以使用。 請注意，以上選擇假定您可以根據協商的協議版本更改套件選擇，這對於您來說可能是可用的選項，也可能不是
如果BEAST不適用於您（客戶端不會運行惡意代碼），則完全放棄RC4支持；專注於AES-128和SHA-256;後退分別在3DES和SHA-1上；如果可用，請使用DHE。
修復程序在哪裡，它們看起來像什麼？僅修復程序是所有相關平台上的所有瀏覽器都實現TLS 1.1或1.2。但是，我不相信這種情況會在傳統平台上發生。
因此，由於大多數軟件開發人員過去錯過了實施最新的TLS標準的機會，因此目前我僅將RC4視為解決方法。現在我們陷入了困境。
我喜歡Mozilla提出的密碼套件（2014年1月）：
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：DHE-RSA-AES128-SHA：DHE-DSS-AES128-SHA256：DHE-RSA-AES256-SHA256：DHE-DSS-AES256-SHA：DHE-RSA- AES256-SHA：AES128-GCM-SHA256：AES256-GCM-SHA384：ECDHE-RSA-RC4-SHA：ECDHE-ECDSA-RC4-SHA：AES128：AES256：RC4-SHA：HIGH：！aNULL：！eNULL：！EXPORT ：！DES：！3DES：！MD5：！PSK 按照我推薦的微軟，我會遠離RC4
通過SSL實驗室更新2016：
您應該主要依靠AEAD套件，該套件可提供強大的身份驗證和密鑰交換，前向保密性以及至少128位的加密。如果僅與不支持更好功能的老客戶端進行協商，則仍然可以支持其他一些較弱的套件。
必須避免使用一些過時的加密原語：
匿名Diffie-Hellman（ADH）套件不提供身份驗證。
使用以下針對RSA和ECDSA密鑰設計的套件配置作為起點：
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AESDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA 256
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
EDH-RSA-DES-CBC3-SHA
Note此示例配置使用OpenSSL所需的非標準套件名稱。要在其他環境（例如IIS）中進行部署，則需要使用標準的TLS套件名稱。
參考： https://github.com/ssllabs/research/wiki/SSL和TLS部署最佳實踐＃23-使用安全密碼套件
我們先來看一下無視BEAST攻擊的密碼。
我建議僅使用帶有強密鑰的“當前”密碼，而不支持任何人都不會使用的歷史密碼。因此，例如沒有RC4。另外，我建議您不要使用出口級密碼，因為這些密碼的密鑰非常薄弱，因此美國政府可能會破解它們。儘管我認為導出高級加密不再是非法的，但該概念仍存在於您的服務器配置中。最後，避免使用諸如MD5之類的具有較大問題的哈希算法。為此，mail.google.com為此進行了辯護，迅速將其切換為128位RC4。如果您非常擔心接下來2週內的這種攻擊（例如Google），則可以應用相同的解決方法。在其他情況下，我只需要等待修復，然後配置您的密碼即可，而無需考慮這種攻擊。
您可能會在此處找到有關apache2 &強大的SSL算法選擇的一些有趣配置：
Mozilla SSL配置生成器 https://mozilla.github.io/server-side-tls/ssl- config-generator /
現代瀏覽器的2019.02建議是：
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384：ECDHE-RSA-AES256-GCM-SHA384 ：ECDHE-ECDSA-CHACHA20-POLY1305：ECDHE-RSA-CHACHA20-POLY1305：ECDHE-ECDSA-AES128-GCM-SHA256：ECDHE-RSA-AES128-GCM-SHA256：ECDHE-ECDSA-AES256-SHA384：ECDHE-RSA-AES256 -SHA384：ECDHE-ECDSA-AES128-SHA256：ECDHE-RSA-AES128-SHA256
可讀：
ECDHE-ECDSA-AES256-GCM-SHA384ECDHE-RSA-AES256 -GCM-SHA384ECDHE-ECDSA-CHACHA20-POLY1305ECDHE-RSA-CHACHA20-POLY1305ECDHE-ECDSA-AES128-GCM-SHA256ECDHE-RSA-AES128-GCM-SHA256ECDHE-ECDSA-AES256-SHA384ECDHE-RSA-AES256-SHA384ECDHE- -RSA-AES128-SHA256