handshake_failure with cloudfront domains
Hi support team,
For a particular web application that is running on CloudFront domains we continuously are getting Fatal error: Handshake_Failure when trying to intercept traffic with Burp.
I have tried to resolve this issue on several OS's (Windows 10, OSX, Kali Linux), also replaced the default local_policy.jar and US_export_policy.jar files with the ones in the Java Cryptography Extension (JCE) Unlimited Strength download (for example for Java 8). I have tried running Burp with Java 7 & 8, both OpenJDK and Oracle, both the pro and the community version.
In addition, I have tried porting the web application traffic through Fiddler first (which worked, Fiddler can intercept the traffic), but as soon as I attach Burp to it afterwards, it gives me the same handshake error again. Also I have made sure the Java SNI extension is switched on, also have tried it with the extension switched off just in case.
The application is using an AES_128_GCM cipher (gets an A+ in ssl labs) and I have tried setting that specific cipher in Burp via the SSL options, this also did not make a difference.
I am seeing some posts related to SNI and CloudFront domains (https://support.portswigger.net/customer/portal/questions/16714402-fatal-alert-handshake-failure-for-tls1-2-enabled-site) but cannot find a working solution.
Can you help me out please? Below I will post some errors I am seeing when debugging Burp:
pool-project-thread-4, READ: TLSv1.2 Application Data, length = 466
pool-project-thread-4, setSoTimeout(10) called
pool-project-thread-4, handling exception: java.net.SocketTimeoutException: Read timed out
pool-project-thread-4, setSoTimeout(120000) called
pool-project-thread-4, "omitted.domain.name.com" is not a legal HostName for server name indication
pool-project-thread-4, WRITE: TLSv1.2 Handshake, length = 215
pool-project-thread-4, READ: TLSv1.2 Alert, length = 2
pool-project-thread-4, RECV TLSv1.2 ALERT: fatal, handshake_failure
pool-project-thread-4, called closeSocket()
pool-project-thread-4, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
pool-project-thread-4, WRITE: TLSv1.2 Application Data, length = 1460
pool-project-thread-4, WRITE: TLSv1.2 Application Data, length = 106
pool-project-thread-4, WRITE: TLSv1.2 Application Data, length = 65
pool-project-thread-4, called close()
pool-project-thread-4, called closeInternal(true)
pool-project-thread-4, SEND TLSv1.2 ALERT: warning, description = close_notify
pool-project-thread-4, WRITE: TLSv1.2 Alert, length = 26
pool-project-thread-4, called closeSocket(true)
Miskov, it sounds like you’ve tried most of our usual remediation steps. We have two additional suggestions:
1. Could you obtain the IPs of the hosts behind CloudFront, and put a DNS entry in Burp for those hosts so that CloudFront is bypassed?
2. Keep trying different combinations of protocols and ciphers. While doing this, disable “Automatically select compatible SLL parameters on negotiation failure”. At first, leave the ciphers as default, and try only enabling TLSv1.2 then TLSv1.1 and work your way through the protocols. Try each one with “Disable SSL session resume” both on and off. After that you could try enabling some ciphers.
Let us know if this helps.
Unfortunately both suggestions do not seem to work. I did notice something interesting.
We have a second subdomain with the exact same application with almost identical webserver configuration, both using CloudFront. One subdomain does not get the handshake error, but the other does. The difference is in the subdomain 'format'.
test.mydomain.com > works perfectly well
a_test_domain.mydomain.com > gives the handshake error
perhaps this is a bug with underscores in a domain name that is not being handled properly?
It appears Java cannot handle underscores in subdomains, as this issue also exists within OWASP ZAP. I hope this post helps someone as I just lost a day in my life figuring this out :)
Thanks for helping @Liam
Miskov, thanks for letting us know, the manifestation of that error was a little cryptic given its apparent cause. Glad you managed to fix it!