使用與 Google 相同的 HTTPS 密碼套件是個好主意嗎？
我正在為我的 HTTPS 網站搜尋一個密碼套件，該套件在 Apache 2 Web 伺服器上執行，它可以在與使用者的兼容性和安全性之間提供良好的折衷。我的一個想法是簡單地使用Google使用的相同密碼套件，即：
Accepted TLSv1 256 bits ECDHE-RSA-AES256-SHA Accepted TLSv1 256 bits AES256-SHA Accepted TLSv1 128 bits ECDHE-RSA-AES128-SHA Accepted TLSv1 128 bits AES128-SHA Accepted TLSv1 112 bits DES-CBC3-SHA Accepted TLS11 256 bits ECDHE-RSA-AES256-SHA Accepted TLS11 256 bits AES256-SHA Accepted TLS11 128 bits ECDHE-RSA-AES128-SHA Accepted TLS11 128 bits AES128-SHA Accepted TLS11 112 bits DES-CBC3-SHA Accepted TLS12 256 bits ECDHE-RSA-AES256-GCM-SHA384 Accepted TLS12 256 bits ECDHE-RSA-AES256-SHA384 Accepted TLS12 256 bits ECDHE-RSA-AES256-SHA Accepted TLS12 256 bits AES256-GCM-SHA384 Accepted TLS12 256 bits AES256-SHA256 Accepted TLS12 256 bits AES256-SHA Accepted TLS12 128 bits ECDHE-RSA-AES128-GCM-SHA256 Accepted TLS12 128 bits ECDHE-RSA-AES128-SHA256 Accepted TLS12 128 bits ECDHE-RSA-AES128-SHA Accepted TLS12 128 bits AES128-GCM-SHA256 Accepted TLS12 128 bits AES128-SHA256 Accepted TLS12 128 bits AES128-SHA Accepted TLS12 112 bits DES-CBC3-SHA據推測，Google選擇他們的密碼套件是為了與大多數人的瀏覽器兼容，同時也非常安全，所以看起來這對於一般的密碼套件來說應該是一個不錯的選擇。但由於我只經營一個小型網站，我並不完全相信對 Google 有益的東西也對我有益。所以我的問題是：
- 上面的套件中是否有我不應該使用的密碼？如果是這樣，為什麼？
- 即使Google不允許，我真的應該允許其他任何密碼嗎？
但由於我只經營一個小型網站，我並不完全相信對 Google 有益的東西也對我有益。
你對這個評估是正確的。Google在這方面的資源比你可能擁有的要多得多，這就是為什麼他們可以在標準化之前推出 ChaCha20-Poly1305或他們正在使用的新的後量子密鑰交換等事情，特別是因為他們在很大程度上控制了 Chrome 的開發它擁有龐大的使用者群。
即使Google不允許，我真的應該允許其他任何密碼嗎？
是的。
出於某種原因，Google僅提供ECDHE 和（靜態）RSA 密碼套件。雖然他們接觸到的人最多，但您可能不需要接觸那些既不了解 DHE 也不了解 ECDHE 的古老瀏覽器（現在是 2016 年，加油！）。所以這裡的建議是添加密碼套件的 DHE 變體（儘管優先級低於 ECDHE 對應部分）。
此外，如果您的 TLS 實現支持，您應該考慮將（現在標準化的）ChaCha20-Poly1305 密碼套件添加到該列表中，因為移動平台上的高性能。
但請注意：如果可以，請禁用參數（如在私鑰中）與 (EC)DHE 密碼套件一起重複使用並生成您自己的 DH 參數（並使用它們）一次（使用 OpenSSL 或類似的東西）。
上面的套件中是否有我不應該使用的密碼？如果是這樣，為什麼？
是的。
所有名稱中缺少“ECDHE”或“DHE”的密碼套件都應該消失。這些 a) 無論如何都從TLS v1.3中刪除，b) 如果您的伺服器密鑰被洩露（讓任何人心血來潮？）攻擊者可以解密在使用此密鑰和這些密碼套件時記錄的所有流量。(EC)DHE 套件不會發生這種情況，它們的屬性稱為“前向保密”。
此外，您可以（並且應該）放棄 3DES 密碼套件，因為您不需要它們（可能）提供的向後兼容性，並且因為它們的塊大小非常小，因此容易受到Sweet32 之類的攻擊。