在沒有中間人的情況下觀察密碼套件和證書算法
我管理代理伺服器。在技術上是否可以觀察和確定在端點（客戶端和伺服器）之間選擇了哪個密碼套件，而無需更改其 SSL 證書，也無需通過代理模擬伺服器證書？
我的主要目標是獲得各方同意的弱算法。
例如，如果客戶端和伺服器使用 MD5 或 SHA1、DES 或 CAST 包含的密碼套件或 SSLv3，或者，如果伺服器向我的客戶端發送使用 SHA1 簽名的證書或過期證書等，我想檢測此流量.
注意：我已經在這裡問過一個關於特定伺服器技術的問題：Server Fault Question
沒有使用 CAST 的 TLS 密碼套件，因此您無需查看來自任何連接的任何類型的任何實際數據即可確定它。
是的，您總是可以被動地（僅通過查看）在 TLS 握手時告訴所選的密碼套件。請注意，包含“SHA”（意思是 SHA1）的密碼套件僅將其用於密鑰派生（通過 1.2 稱為 PRF），通過 1.1（始終）或在 1.2 中用於任何 CBC 模式密碼或 RC4 的 HMAC——但 RC4 被削弱了根據 2015 年的 rfc7465，根本不應該使用。在密鑰推導或 HMAC 中使用 SHA1 甚至 MD5 都不是弱點；他們的碰撞破損只會危及證書。（實際上並非全部證書，但足以讓共識完全禁止它們。）您絕對應該擔心任何使用單 DES 以及帶有 DES-40 或 RC4-40 的“導出”套件（如上所述，甚至是全強度RC4-128 現在被正式禁止）。有些人擔心 Triple-DES（在 RFC 名稱中寫為 3DES_EDE_CBC，在 OpenSSL 的方案中寫為 3DES-CBC3），因為 64 位塊的通用生日綁定 - 請參閱https://www.sweet32.org - 但對於許多應用程序，例如訪問 StackExchange，這不是問題。IDEA 原則上也有 64 位塊的問題，但它很少使用，主要是因為它的專利狀態導致很多人過去避免使用它，現在沒有理由、利益或激勵回到它而不是更新，更好的選擇。
通過 1.2，您還可以查看伺服器證書鏈（幾乎總是兩個，有時更多，而不是您要求的“一個”證書）並檢查簽名算法和更重要的密鑰大小。如上所述，因衝突而損壞的 MD5 和 SHA1 確實會危及證書，因此在 2008 年左右之後公共 CA 頒發的證書都沒有使用 MD5，而 2015 年或最多 2016 年之後沒有證書使用 SHA1 進行簽名——在此之前頒發的證書是所有過期和無效（簽名算法根本不重要的根除外）。在 1.3 中，證書現在是加密的，但是如果您在路徑上，您可以主動與具有相同參數的同一伺服器建立測試連接，並且您幾乎可以保證獲得相同的證書，您可以查看。來自公共 CA 的證書現在位於公共透明度日誌中，您可以在那裡查看 - 儘管如果伺服器/域在日誌中有多個目前公共證書，您不知道實際使用了哪些證書。
那些說，關於你的其他 QI 不知道 squid 是否可以做任何或所有這些，或者可以合理地修改這樣做。
最後，需要明確的是，雖然這會檢測到某些連接不安全的情況，但連接中缺少已辨識的弱原語並不意味著它是安全的。除了故意破壞的導出套件和長期過時的單 DES，以及一些使用 MD5 簽名的證書案例之外，我還沒有聽到任何可信的指控，即由於原語較弱（甚至 RC4 ）。相反，中斷是由於錯誤的參數或密鑰（有時明顯如此，即太小，有時不是）或協議或實現缺陷，或者根本不是連接而是端點。此外，即使在同一對端點之間，也並非所有連接都是相同的，並且某些明顯良好的連接的存在並不能阻止過去、現在或將來發生壞的連接。