使用代理Nginx / Squid解決方案的Java 1.6 TLS1.2支持

Question

我有一個舊版Java Web應用程序，該應用程序調用了外部Web服務。 該服務的提供者正在關閉TLS1.0支持。 因此，我試圖查看應用程序如何繼續與服務一起使用。

我看到的選項是：a）使用BouncyCastle JCE代替Java JCE http://boredwookie.net/index.php/blog/how-to-use-bouncy-castle-lightweight-api-s-tlsclient/猜測需要代碼更改/重新編譯（我們沒有這樣做的奢侈）或2）使用代理服務器https://www.reddit.com/r/sysadmin/comments/48gzbi/proxy_solution_to_bump_tls_10_connection_to_tls_12/

我嘗試過nginx代理-它似乎無法處理最終服務器期望的TLS1.0傳入和TLS1.2之間的切換。

 server { listen 443 ssl; server_name proxy.mydomain.com;

ssl_certificate D：/apps/openssl/proxy.mydomain.com.cert； ssl_certificate_key D：/apps/openssl/proxy.mydomain.com.private; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH：SEED：！aNULL：！eNULL：！EXPORT：！DES：！RC4：！MD5：！PSK：！RSAPSK：！aDH：！aECDH：！EDH-DSS-DES-CBC3-SHA：！KRB5-DES -CBC3-SHA：！SRP; ssl_prefer_server_ciphers;

位置/ {proxy_pass https://fancyssl.hboeck.de/ ; }

由於https://fancyssl.hboeck.de僅支持TLS1.2，但可與支持TLS1.0的https://www.google.com一起使用 ，因此失敗並顯示502 /網關錯誤。

我正在Windows上執行此操作。

Answer 1

它不是TLSv1.2，而是缺少SNI導致重新協商。

首先，除了使用我自己的key＆cert和代理到我自己的測試服務器外，我使用與您一樣的配置來設置nginx（1.8.1 / Windows）。 它可以正常工作，從具有TLSv1.0的Java6請求者連接到具有TLSv1.2的服務器（甚至是“最佳”密碼套件之一的ECDHE-RSA-AES256GCM-SHA384），並且返回的頁面也很好。 我嘗試了fancyssl.hboek.de並得到了502的像你一樣的東西。

通過wireshark，我看到nginx不會發送SNI（默認情況下），並且至少使用服務器顯然托管多個域的IPv4地址46.4.40.249（我沒有IPv6），因為如果沒有SNI，它會提供不同的域（並且過期） ！）證書，用於*.schokokeks.org ，並在第一個應用程序數據（請求）之后發送加密的握手（重新協商請求，nginx不接受）。 使用openssl s_client測試，確認具有SNI的服務器立即發送該頁面，但沒有重新協商該頁面； 將nginx指向openssl s_server確認如果服務器請求重新協商，沒有收到響應，然后關閉nginx，則將其視為502。

我猜想Apache正在重新協商，因為它意識到所請求的主機未包含在證書中-只是再次使用了“錯誤的”證書。 我沒有試圖追蹤該部分。

當我連接時，Google 確實支持TLSv1.2（和ECDHE-RSA-AESGCM），但是即使沒有SNI也無法重新協商，大概是因為它的容量如此之大，因此www.google.com服務器上沒有其他軟件可以運行，也沒有歧義。 我的測試服務器沒有虛擬主機，因此不需要SNI。

nginx的文檔揭示了一個指令proxy_ssl_server_name可以設置on啟用SNI，然后代理到該服務器的作品。

僅供參考：該網頁上的一些陳述是錯誤的，盡管其結論（如果可能，將TLSv1.2與ECDHE或DHE和AES-GCM結合使用）是好的。 另外，您的大多數 ssl_ciphers字符串都是無用的，但是您沒有對此詢問。

---

ssl_ciphers HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP

HIGH是一個很好的開始。

SEED在Java / JSSE客戶端使用的服務器中（僅）沒有用，因為它不是在Java端實現的。 即使在Java之外，它也僅在韓國使用過，因為它是作為DES或IDEA的替代品而創建的，甚至在ARIA中，它也已成為AES的替代品而被廢棄-但不是由OpenSSL和因此，nginx。

可能不需要aNULL因為JSSE默認情況下禁用“匿名”套件，但是在此值得作為深度防御。

!eNULL什么都不做； 沒有eNULL套件位於HIGH ， DEFAULT或ALL 。 您只能顯式地獲取它們，也可以使用怪異的COMPLEMENTOFALL來獲取它們-不應這樣做。

!EXPORT !DES !RC4不執行任何操作； 他們都不是在HIGH 。 相反，如果您從舊版本的OpenSSL的DEFAULT或ALL ，那么它們會很好。

不需要!PSK Nginx似乎沒有為PSK配置，而JSSE仍然沒有實現它。

!RSAPSK被忽略，因為OpenSSL不會實現該密鑰交換，如果已經實現，則如上所述，這些套件已經涵蓋了。

!aDH !aECDH被覆蓋!aNULL ，因此什么也不做。

!EDH-DSS-DES-CBC3-SHA很傻; 當您保留其他DHE_DSS和3DES套件時，沒有理由排除此套件。

!KRB5-DES-CBC3-SHA被忽略，因為OpenSSL不實現Kerberos，並且如果不為其配置nginx，則再加上一次，則在保留相似性的同時排除一個套件是很愚蠢的。

不需要!SRP ; 像PSK nginx顯然沒有配置，而JSSE沒有實現。

所以： HIGH:!aNULL是您所需要的。