SSL證書加密套件常見弱密鑰以及修復建議

服務器使用了anonymous套件

匿名加密套件檢測（CVE-2007-1858），支持對SSL3.0、TLS1.0、TLS1.1、TLS1.2多種協議，19個ANON類加密套件，包含DES、AES、CAMELLIA和ARIA等算法。

TLS_DH_ANON_WITH_AES_256_GCM_SHA384

TLS_DH_ANON_WITH_AES_128_GCM_SHA256

TLS_DH_ANON_WITH_AES_256_CBC_SHA256

TLS_DH_ANON_WITH_AES_256_CBC_SHA

TLS_DH_ANON_WITH_AES_128_CBC_SHA256

TLS_DH_ANON_WITH_AES_128_CBC_SHA

TLS_DH_ANON_WITH_3DES_EDE_CBC_SHA

TLS_DH_ANON_WITH_RC4_128_MD5

TLS_DH_ANON_EXPORT_WITH_RC4_40_MD5

TLS_DH_ANON_WITH_DES_CBC_SHA

TLS_DH_ANON_WITH_CAMELLIA_128_CBC_SHA256

TLS_DH_ANON_WITH_CAMELLIA_128_GCM_SHA256

TLS_DH_ANON_WITH_CAMELLIA_256_GCM_SHA384

TLS_DH_ANON_WITH_CAMELLIA_128_CBC_SHA

TLS_DH_ANON_WITH_CAMELLIA_256_CBC_SHA

TLS_DH_ANON_WITH_ARIA_128_CBC_SHA256

TLS_DH_ANON_WITH_ARIA_256_CBC_SHA384

TLS_DH_ANON_WITH_ARIA_128_GCM_SHA256

TLS_DH_ANON_WITH_ARIA_256_GCM_SHA384

以上都是不安全套件，存在嚴重安全風險。

如何解決使用了anonymous套件？

SSL 配置生成器 https://ssl-config.mozilla.org/

服務器支持不安全的加密套件

不安全的加密套件，容易被攻擊者破解，從而解密兩端加密信息，影響網站安全。

如何設置安全的加密套件？

SSL 配置生成器 https://ssl-config.mozilla.org/

不建議加密協議上使用64bits塊加密套件（3DES/DES/RC2/IDEA）

怎么解決使用了64bits塊加密套件?

SSL 配置生成器 https://ssl-config.mozilla.org/

RC4密碼套件

2015年3月26日，國外數據安全公司Imperva的研究員Itsik Mantin在BLACK HAT ASIA 2015發表論文《Attacking SSL when using RC4》闡述了利用存在了13年之久的RC4漏洞——不變性弱密鑰（《Weakness in the Key Scheduling Algorithm of RC4》,FMS 發表于2001年）進行的攻擊，并命名為“受戒禮”攻擊（Bar Mitzvah Attack）。

根據《Attacking SSL when using RC4》中的闡述，漏洞的成因主要在于不變性弱密鑰是RC4密鑰中的一個L型的圖形，它一旦存在于RC4的密鑰中，在整個初始化的過程之中保持狀態轉換的完整性。這個完整的部分包括置換過程中的最低有效位，在由RPGA算法處理的時候，決定偽隨機輸出流的最低有效位。這些偏差的流字節和明文進行過異或，導致密文中會泄露重要明文信息。

怎么解決使用了RC4密碼套件?

如果您的服務器需要支持IE6這種古董級別的瀏覽器，那么可以支持SSLv3版本協議，如果說對兼容性沒有太大的需求，只要主流的瀏覽器能夠訪問那么就不要支持3DES系列的加密套件，如果說想要在保證安全性的同時，也要有最好的兼容性，那么就可以采取TLS1.x協議+FS加密套件配置方式進行配置。

服務采用了TLSv1.0+TLSv1.1+TLSv1.2的SSL協議，安全加密套件使用了不帶RC4的加密套件，并且設置了優先使用FS系列加密套件。

服務器不支持安全的密鑰交換參數

如何設置安全的密鑰交換參數？

SSL 配置生成器 https://ssl-config.mozilla.org/

服務器支持弱Diffie-Hellman(DH)密鑰交換參數

Diffie-Hellman:一種確保共享KEY安全穿越不安全網絡的方法，它是OAKLEY的一個組成部分。Whitefield與Martin Hellman在1976年提出了一個奇妙的密鑰交換協議，稱為Diffie-Hellman密鑰交換協議/算法(Diffie-Hellman Key Exchange/Agreement Algorithm).這個機制的巧妙在于需要安全通信的雙方可以用這個方法確定對稱密鑰。然后可以用這個密鑰進行加密和解密。但是注意，這個密鑰交換協議/算法只能用于密鑰的交換，而不能進行消息的加密和解密。雙方確定要用的密鑰后，要使用其他對稱密鑰操作加密算法實現加密和解密消息。

怎么解決弱Diffie-Hellman(DH)密鑰交換參數?

服務采用了TLSv1.0+TLSv1.1+TLSv1.2的SSL協議，安全加密套件使用了不帶RC4的加密套件，并且設置了優先使用FS系列加密套件。

沒有使用AEAD系列加密套件

AEAD的全稱是Authenticated encryption (AE) and authenticated encryption with associated data (AEAD, variant of AE)。也就是帶附加數據的加密和驗證算法。

常見的 AEAD 算法如下：

AES-128-GCM

AES-192-GCM

AES-256-GCM

ChaCha20-IETF-Poly1305

XChaCha20-IETF-Poly1305

怎么解決加密套件問題?

使用以RSA和ECDSA鍵為對象的以下套件配置作為起點：

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

TLS_DHE_RSA_WITH_AES_128_CBC_SHA

TLS_DHE_RSA_WITH_AES_256_CBC_SHA

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

沒有優先使用FS系列加密套件

怎么解決加密套件問題?

需要配置符合PFS規范的加密套件，推薦配置：

ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4:!DH:!DHE

需要在服務端TLS協議中啟用TLS1.2，推薦配置：TLSv1 TLSv1.1 TLSv1.2;

服務器只使用SSL3作為最好的協議

ssl3 存在POODLE漏洞，并且最新瀏覽器的兼容性較差，不支持最新的安全特性。

如何設置服務器協議？

推薦配置：TLSv1 TLSv1.1 TLSv1.2; SSL 配置生成器

服務器僅支持老的協議，沒有啟用安全性與兼容性最佳的TLSv1.2協議

怎么支持TLSv1.2協議？

SSL 配置生成器 https://ssl-config.mozilla.org/

啟用了SSLv3協議

POODLE（在降級的傳統加密上填充Oracle）是2014年10月14日發現的一個漏洞，它使攻擊者可以通過執行中間人攻擊來使用SSLv3協議讀取任何加密信息。盡管許多程序使用SSLv3作為后備，但它已經到了應禁用的地步-因為許多客戶端可能被迫使用SSLv3。強制客戶端進入SSLv3會增加發生攻擊的機會。本文將向您展示如何在當今常用的某些軟件應用程序中禁用SSLv3。

怎么關閉SSLv3協議?

推薦配置：TLSv1 TLSv1.1 TLSv1.2; SSL 配置生成器

主頁面引用了不安全的HTTP資源

HTTP 協議在傳輸過程中是明文數據，很容易被第三方劫持和修改。

怎么解決不安全HTTP資源?

引用的資源都是用 Https 請求進行替換。

使用HSTS，但是使用的max-age屬性小于180天(15768000秒)

HTTP嚴格傳輸安全（英語：HTTP Strict Transport Security，縮寫：HSTS）是一套由互聯網工程任務組發布的互聯網安全策略機制。網站可以選擇使用HSTS策略，來讓瀏覽器強制使用HTTPS與網站進行通信，以減少會話劫持風險。

HSTS可以用來抵御SSL剝離攻擊。SSL剝離攻擊是中間人攻擊的一種，由Moxie Marlinspike于2009年發明。他在當年的黑帽大會上發表的題為“New Tricks For Defeating SSL In Practice”的演講中將這種攻擊方式公開。SSL剝離的實施方法是阻止瀏覽器與服務器創建HTTPS連接。它的前提是用戶很少直接在地址欄輸入https://，用戶總是通過點擊鏈接或3xx重定向，從HTTP頁面進入HTTPS頁面。所以攻擊者可以在用戶訪問HTTP頁面時替換所有https://開頭的鏈接為http://，達到阻止HTTPS的目的。

HSTS可以很大程度上解決SSL剝離攻擊，因為只要瀏覽器曾經與服務器創建過一次安全連接，之后瀏覽器會強制使用HTTPS，即使鏈接被換成了HTTP。

另外，如果中間人使用自己的自簽名證書來進行攻擊，瀏覽器會給出警告，但是許多用戶會忽略警告。HSTS解決了這一問題，一旦服務器發送了HSTS字段，將不再允許用戶忽略警告。

怎么設置HSTS?

HSTS的作用是強制客戶端（如瀏覽器）使用HTTPS與服務器創建連接。服務器開啟HSTS的方法是，當客戶端通過HTTPS發出請求時，在服務器返回的超文本傳輸協議（HTTP）響應頭中包含Strict-Transport-Security字段。非加密傳輸時設置的HSTS字段無效。

比如，https://example.com/ 的響應頭含有Strict-Transport-Security: max-age=31536000; includeSubDomains。這意味著兩點：

1、在接下來的31536000秒（即一年）中，瀏覽器向example.com或其子域名發送HTTP請求時，必須采用HTTPS來發起連接。比如，用戶點擊超鏈接或在地址欄輸入 http://www.example.com/ ，瀏覽器應當自動將 http 轉寫成 https，然后直接向 https://www.example.com/ 發送請求。

2、在接下來的一年中，如果 example.com 服務器發送的TLS證書無效，用戶不能忽略瀏覽器警告繼續訪問網站。

參考網址：

SSL 配置生成器 https://ssl-config.mozilla.org/

https SSL證書管理 通用安全

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。