MWG cannot make SSL-Handshake with www.iif.com

[otruniger]

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

[jscholte]

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

[otruniger]

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

[btlyric]

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

[otruniger]

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

[jscholte]

If either of you have SRs open, please let me know. We can always ping development about these issues too.

Best Regards,

Jon

[btlyric]

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)

[jscholte]

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

[otruniger]

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

[Regis]

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