Hi,
our MWG 7.5.2.8.0 cannot make a SSL-handshake to https://www.iif.com, while openssl with CLI on MWG and direkt browser connection work fine (with SSL tunnel). Every CLIENT HELLO receives an immediate Protocol Error as Whireshark shows. I don't unterstand this. This is with our standard setting using TLS1.2 with HIGH:!ADH:!MD5:!PSK:!KRB5:!CAMELLIA:@STRENGTH with works basically for all sites besides the ones we have to use weaker protocoll settings.
Can anybody confirm this? Does anybody know who to blame for this?
Thank you
Regards, Othmar
Hi Othmar,
I'm having similar issues on 7.6.1.3. I tested on 7.5.2.7 and it worked without issue.
In 7.5.2.8 openssl was updated to address the latest vulnerabilities. I know some older ciphers were removed, so perhaps this angers the server somehow?
It doesnt really make sense because when the handshake completes, it uses the highest available.
It does appear that others have trouble handshaking with this server: SSL Server Test: www.iif.com (Powered by Qualys SSL Labs) however they are random devices..
Best Regards,
Jon
Hi Jon,
From my experiments I get the impression it's not related to the cipher set:
My corporate browser has a very reduced cipher set and it works, while MWG offers a wide set of ciphers which is a superset compared to the browser. So it cannot be the case that the server rejects because it misses ciphers.
It also cannot be the case that the server is rejecting because of too many ciphers: I defined MWG with only one cipher which is proven by using openssl and the SSL handshake is still abortet.
I assume it's rejecting because of some other setting in the CLIENT HELLO but I still have no clue. And I'm afraid this cannot be configured. The server www.iif.com is the only one affected I heard of so far.
Regards, Othmar
I've been seeing similar behavior with 7.5.2.8.
SSL Labs tests against the specific sites show the same pattern of handshake failures. One of the sites that falls into this category is https://www.continuum.io.
The current workaround that I've identified is to make sure that in the alternative handshake settings TLS 1.1 is selected and TLS 1.2 is deselected. I haven't yet figured out why the initial TLS 1.2 handshake is failing, but if TLS 1.2 is selected in the alternative handshake settings, the handshake will fail. If only TLS 1.0 is selected, it also fails -- unsurprisingly because that site doesn't support TLS 1.0.
I spent a fair bit of time chasing ciphers because www.epson.com, which only supports TLS 1.2, was also failing. For that one, the immediate solution was to configure the primary ciphers as TLSv1.2:!DSS:!DH:!NULL:@STRENGTH
btlyric, interesting findings. Thank you.
I can confirm that handshake fails with TLS 1.2 but succeeds with TLS 1.1. This can also be shown when TLS 1.2 is deselected on first attempt for Certificate Verification. Of course this is only for testing but not for permanent configuration. I have configured TLS 1.2, 1.1, 1.0 on first attempt and TLS 1.0 on Alternative Handshake which makes most sense in my eyes, but does not help in this case.
I have a separate rule for a whitelist of servers with weak protocol settings using TLS 1.0, SSL 3.0 on first attempt and SSL 3.0 on Alternative Handshake together with support of weak cipers, because there are still a few business websites with bad SSL support.
so I'm thinking of adding another rule for a whitelist of servers dealing with only TLS 1.1 unless the reason for failing with TLS 1.2 can be found and resolved.
Regards, Othmar
If either of you have SRs open, please let me know. We can always ping development about these issues too.
Best Regards,
Jon
Jon,
The release notes for 7.5.2.9 say:
Web Gateway could not open a TLS connection to a particular web server, which required use of a legacy SHA signature algorithm that Web Gateway was not able to handle anymore. (1144894)
The single difference in the pcaps that I analyzed between the openssl client (successful handshake negotiations) and 7.5.2.8 proxy (failed handshakes) was that the openssl client offered 15 signature algorithms whereas the proxy was only offering 9.
The ones that the proxy wasn't offering were the ones represented by 0x201, 0x202, 0x203, 0x301, 0x302 and 0x303 in the list I have included below.
Does the 7.5.2.9 reference to legacy signature algorithms as a fixed item mean that the proxy will once again support the same algorithms supported by the openssl client?
openssl s_client signature algorithms:
Signature Hash Algorithms (15 algorithms)
Signature Hash Algorithm: 0x0601
Signature Hash Algorithm Hash: SHA512 (6)
Signature Hash Algorithm Signature: RSA (1)
Signature Hash Algorithm: 0x0602
Signature Hash Algorithm Hash: SHA512 (6)
Signature Hash Algorithm Signature: DSA (2)
Signature Hash Algorithm: 0x0603
Signature Hash Algorithm Hash: SHA512 (6)
Signature Hash Algorithm Signature: ECDSA (3)
Signature Hash Algorithm: 0x0501
Signature Hash Algorithm Hash: SHA384 (5)
Signature Hash Algorithm Signature: RSA (1)
Signature Hash Algorithm: 0x0502
Signature Hash Algorithm Hash: SHA384 (5)
Signature Hash Algorithm Signature: DSA (2)
Signature Hash Algorithm: 0x0503
Signature Hash Algorithm Hash: SHA384 (5)
Signature Hash Algorithm Signature: ECDSA (3)
Signature Hash Algorithm: 0x0401
Signature Hash Algorithm Hash: SHA256 (4)
Signature Hash Algorithm Signature: RSA (1)
Signature Hash Algorithm: 0x0402
Signature Hash Algorithm Hash: SHA256 (4)
Signature Hash Algorithm Signature: DSA (2)
Signature Hash Algorithm: 0x0403
Signature Hash Algorithm Hash: SHA256 (4)
Signature Hash Algorithm Signature: ECDSA (3)
Signature Hash Algorithm: 0x0301
Signature Hash Algorithm Hash: SHA224 (3)
Signature Hash Algorithm Signature: RSA (1)
Signature Hash Algorithm: 0x0302
Signature Hash Algorithm Hash: SHA224 (3)
Signature Hash Algorithm Signature: DSA (2)
Signature Hash Algorithm: 0x0303
Signature Hash Algorithm Hash: SHA224 (3)
Signature Hash Algorithm Signature: ECDSA (3)
Signature Hash Algorithm: 0x0201
Signature Hash Algorithm Hash: SHA1 (2)
Signature Hash Algorithm Signature: RSA (1)
Signature Hash Algorithm: 0x0202
Signature Hash Algorithm Hash: SHA1 (2)
Signature Hash Algorithm Signature: DSA (2)
Signature Hash Algorithm: 0x0203
Signature Hash Algorithm Hash: SHA1 (2)
Signature Hash Algorithm Signature: ECDSA (3)
Hi btlyric,
In 7.5.2.8 a patch was added to address one of the recent SSL vulnerabilities, as a result some ciphers we removed (as I mentioned above).
In 7.5.2.9, a checkbox "Allow legacy signatures in the handshake" was added to the SSL related settings which allow you to enable these ciphers.
After testing on 7.5.2.9 with this checkbox enabled, the site mentioned here loads as expected.
So to answer your question, MWG should use the additional ciphers you found, but only if you have that box checked (I believe).
Let me know if that helps.
Best Regards,
Jon
Thanks Jon,
I can confirm that enabling the legacy ciphers in release 7.5.2.9 allows accessing https://www.iif.com for us.
Now I only have to consider whether to generally support these legacy ciphers or to use a separate setting for certificate verification in a rule with a list of webservers.
Regards, Othmar
Curious, does https://www.iif.com/ any longer require legacy handshake? If I understand the issue fullly, I think the answer is now "no?"
Legacy handshakes are disabled in our environment (I came here with trouble on s3.amazonaws.com) but I can get to www.iif.com
I notice no mention of SHA1 today at least with https://www.iif.com/ - is that the reason legacy cipher support isn't needed on www.iif.com today (but perhaps was when this thread started?, peer signing digest is SHA256 as I look today).
SHA1 is the peer signing digest for https://s3.amazonaws.com or https://github-cloud.s3.amazonaws.com which I cannot connect to without legacy signature turned on.
# openssl s_client -debug -connect www.iif.com:443
...
subject=/OU=Domain Control Validated/CN=*.iif.com
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5231 bytes and written 415 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 6B50286B9CF8C0C7D6A641FD9775C199DAA2E113170749F5ADE1EB1BB0068A21
Session-ID-ctx:
Master-Key: F6476D01703DDED6DD168BD15C414D1D1FDA6CCCF09689749435656BD1ABFF9AEADBF9F0D9CB0521626C35319F1CF17E
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1475872954
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
q^C
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA