Forum Discussion

Babak_AA_246963's avatar
Babak_AA_246963
Icon for Altostratus rankAltostratus
Jul 05, 2016

BIG-IP Proxy SSL 12.1 Handshake Failure

I set up SSL Proxy in order to do client certificate authentication on my IIS web server on LTM 12.1 firmware. The setup is working fine on Firefox version 43, IE 10 and OpenSSL but it fails on Chrom...
clien certificate authentication
devops
LTM
proxy ssl
security
  • Babak_AA_246963's avatar
    Babak_AA_246963
    Sep 23, 2016

    I figured out the issue I was facing. It had to do with TLS Extended Master Secret and the BIG-IP was failing to decrypt the handshake. The extended master secret changes the way pre-master secret is generated for TLS sessions and I suspect BIG-IP fails to detect its presence and calculates the pre-master secret as if extended master secret is not in place, anyways I've written my experience in a couple of blog posts in case someones willing to get into the details: TLS Extended Master Secret Breaking SSL Proxies.

     

    Solution

     

    As for the solution, until BIG-IP adds this feature (decrypting sessions where extended master secret is used) I disabled it on my web server (The threat it was mitigating was minimal in my case when the choice is between having a WAF or having extended master secret enabled, it basically prevents rogue CAs to create bogus certificates and use them to MITM live TLS sessions, more details in the blog post).

     

    Disabling TLS Extended Master Secret in Windows Server/IIS:

     

    For IIS you'd have to go into registry and under SCHANNEL configurations add the following key:

     

    Under HKLM\System\CurrentControlSet\Control\SecurityProviders\Schannel:

     

    Add DisableServerExtendedMasterSecret as REG_DWORD with the value of 1 (anything other than 0 works)

     

    The setting applies immediately and you don't need to restart the server.

     

Hannes_Rapp_162's avatar
Hannes_Rapp_162
Icon for Nacreous rankNacreous
Jul 06, 2016

Check if your client-auth certificate, client-ssl certificate and all certificates in CA intermediary certificate bundle are signed with modern SHA algorithms, or if there are any certs signed by the deprecated SHA1. Note that the very root certificate of your CA may still remain SHA1-signed, but any intermediary certificates above it must be SHA256-signed (or stronger). Any of this does not apply to SSL handshakes and SHA in a cipher suite is still OK.

Newer browsers are becoming more and more restrictive with SHA1 certificates and this could be one potential cause to your issue. This OpenSSL command can help you get started:

openssl x509 -text -in '/Path/To/Cert.crt' | grep "Signature Algorithm"

Signature Algorithm: sha256WithRSAEncryption
  • Babak_AA_246963's avatar
    Babak_AA_246963
    Icon for Altostratus rankAltostratus
    Jul 07, 2016
    Apart from the root certificate which was SHA1, the rest of the certificates where using SHA256. but the fact that the BIG-IP sends a handshake failure and resets the connection has to do something with an issue on BIG-IP side rather than clients browser being unhappy, correct me if this assumption is incorrent.
  • Hannes_Rapp_162's avatar
    Hannes_Rapp_162
    Icon for Nacreous rankNacreous
    Jul 07, 2016
    You may be right, but we cannot really tell, as in your own words, there are browsers with which the whole solution works. To further isolate the issue, and eliminate variables, perhaps disabling Client-Auth for a test would be worth it. If the SSL handshake then completes successfully, it can at least be confirmed that it's a SSL-MA problem, and maybe tweaking some settings will do the trick. After all, it's also possible you're looking to solve a problem caused by a bug, so I recommend to open a support case with F5.