TLS協商失敗是否存在連接存在的錯誤證明？

Question

我們正在嘗試允許客戶訪問我們的QA環境之一。他們看到下面的錯誤在IE中：不能顯示

本頁面在高級設置上TLS 1.0，TLS 1.1和TLS 1.2 打開並嘗試連接到https://oursite.com一次。如果此錯誤仍然存​​在，則該站點有可能使用不受支持的協議或密碼套件，如RC4（詳細信息請參見鏈接），這是不安全的。 Pelase聯繫您的網站管理員。

我不是要求stackoverflow用戶來解決這個問題。

我問下面的非常具體的問題：

因爲我們看到了這個錯誤，這是否證明了存在的連接，也就是我們的防火牆是通過讓他們？我想如果他們在防火牆被阻止，他們只會得到一個超時或可能是一個403或500錯誤。因爲他們能夠看到Web服務器支持哪些TLS協議，所以我推斷他們必須能夠在OSI級別1-4上與它進行通信。我對麼？ （我需要知道是否參與運行防火牆的網絡團隊，或者參與設置TLS配置的應用程序支持團隊）。

請注意，SSL終止於我們的IIS Web服務器（我們沒有SSL卸載）。

不幸的是，我們有80端口阻塞，所以我們只能測試443;否則我會建議使用http訪問來幫助隔離問題。

Answer 1

......如果他們在防火牆被阻止，他們只會得到超時或403或500錯誤。

爲了發回403或500錯誤，防火牆必須已成功完成與客戶端的SSL握手，因爲HTTP響應（包括狀態碼，即403,500 ......）只會發送在加密連接中。已經無法在SSL握手中返回403或500。

防火牆之間的典型行爲是超時（防火牆丟棄數據包）或更可能是連接重置或關閉（防火牆重置或關閉連接）。使用簡單的數據包過濾器防火牆，它通常會阻塞TCP連接，導致連接被拒絕。但是，使用DPI的防火牆實際上可能會讓TCP連接建立，並且只有在基於此有效內容的內容（即應用程序檢測）獲取實際數據後纔會阻止。

最後一種情況可能會導致您看到的錯誤。但是，如果服務器端在服務器端關閉或重置連接時出現問題，則可以看到完全相同的行爲。某些TLS堆棧在找不到共享協議版本或密碼時顯示此類行爲（而不是發回TLS警報）。只要你不能從這個錯誤消息得出結論，防火牆阻止了連接，你也不能斷定服務器導致錯誤。