Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

handshake_failure with cloudfront domains

Miskov | Last updated: 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, PortSwigger Agent | Last updated: Aug 06, 2019 02:05PM UTC

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.

Burp User | Last updated: 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?

Burp User | Last updated: 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, PortSwigger Agent | Last updated: Aug 07, 2019 11:05AM UTC

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!

Jejomar | Last updated: Apr 21, 2021 02:58PM UTC

Hi Support Team! I have encountered this issue as well, just recently, the difference is the sub-domain of the application has no underscores in it. Do you have any work arounds for this one, for it to be able to not block the traffic when accessing the application while doing the burp scan? Thanks!

Hannah, PortSwigger Agent | Last updated: Apr 22, 2021 10:44AM UTC

Hi

Could you provide us with some further details?
  • Your Burp version
  • Whether you are using the standalone JAR or installer version of Burp
Are you just seeing this failure when running a scan against the application, or is it also happening if you are using the Burp proxy to access the application, or when sending a request to the application in Repeater?

Graves, | Last updated: Apr 23, 2021 02:24AM UTC

I'm getting the same error. I'm using 2021.3.3 installer version on Linux. The issue arises with Burp proxy as well as repeater.

Hannah, PortSwigger Agent | Last updated: Apr 23, 2021 07:48AM UTC

Thank you for that info! Is the site publicly accessible? If so, would it be possible for you to disclose the site to us (or any similar site that has the same issue) so we can take a look? You can email us at support@portswigger.net with any information.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.