Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

handshake_failure with cloudfront domains

Miskov Aug 06, 2019 01:45PM UTC

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)


Liam Tai-Hogan Aug 06, 2019 02:31PM UTC Support Center agent

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?

- https://portswigger.net/burp/documentation/desktop/options/connections#hostname-resolution

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.


Miskov Aug 06, 2019 04:23PM UTC
Hi Liam,

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?

Miskov Aug 06, 2019 04:58PM UTC
The issue is resolved. I have asked the owners of the application to remove the underscores in the subdomain, now the handshake error is gone.

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

Rose Krawczuk Aug 07, 2019 01:53PM UTC Support Center agent

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!


Post Your public answer

Your name
Your email address
Answer