Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Fatal alert: handshake_failure for TLS1.2 enabled site

Andreas | Last updated: Oct 18, 2016 05:12PM UTC

Hey forum, I've got a problem where Burp is not able to proxy traffic to a certain domain due to SSL/TLS handshake failure. The site is configured to use TLS1.2 with a strong key exchange and key. This is from Chrome's Dev Tools: "The connection to this site is encrypted and authenticated using a strong protocol (TLS 1.2), a strong key exchange (ECDHE_RSA), and a strong cipher (AES_128_GCM)." I did some searching online and have 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 http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html for Java 8). I have tried running Burp with Java 7 & 8, both OpenJDK and Oracle, and also by running Burp the intended way, i.e. the Burp Suite Pro file, but no difference at all. I could also mention that sslscan against the site returns no available cipher suites, but SSLLabs gives it an A. As Burp ships with it's own JRE now, it would be really awesome if this could be fixed centrally. :) Oh, and I'm running Linux (Ubuntu 14.04). Any help with this would be much appreciated.

PortSwigger Agent | Last updated: Oct 21, 2016 03:09PM UTC

In the latest update (1.7.14) we have modified the SSL configuration of the Proxy listener, and this should now support clients with this configuration.

Burp User | Last updated: Nov 24, 2016 11:02AM UTC

If the cipher suite is using a strong MAC algorithm burp proxy fails the handshake because it is started with the wrong SSL context. I.e. it's setup as a SSLv3 server. But SHA256 and SHA384 require it to be TLSv1.2. I hope they fix it soon ;-)

Burp User | Last updated: Jan 05, 2017 09:18PM UTC

I have a similar problem. From Chrome I see: "The connection to this site is encrypted and authenticated using a strong protocol (TLS 1.2), a strong key exchange (ECDHE_RSA with P-256), and a strong cipher (AES_128_GCM)." I'm using the latest Burp Suite Professional v.1.7.15 for Mac. It comes with its own Java JRE so I updated: /Applications/Burp Suite Professional.app/Contents/PlugIns/jre.bundle/Contents/Home/jre/lib/security/local_policy.jar and US_export_policy.jar with UnlimitedJCEPolicyJDK8. Using custom protocols and ciphers: TLSv1.2 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 checked. Regenerated the Burp Certificate and installed on client to ensure 256 signature Still seeing: javax.net.ssl.SSLException: Received fatal alert: handshake_failure Received fatal alert: handshake_failure Several different applications in AWS have the same problem. Help is appreciated! NOT seeing

Burp User | Last updated: Jan 05, 2017 09:28PM UTC

Sorry - Missed this. NOT seeing: You have limited key lengths available to use stronger keys install JCE unlimited strength Jurisdiction Policy Files. This was fixed by placing UnlimiteJCEPolicy in the correct Burp JRE directory.

Burp User | Last updated: Jan 06, 2017 12:10AM UTC

We are using CloudFront CDN in front of the ALB load balancers. Burp works when hitting origin load balancers, but has the handshake failure when hitting the externally exposed Cloudfront Domain Name. Cloudfront requires SNI: Server Name Indication (SNI) Custom SSL. SNI is supported by most modern browsers, and provides an efficient way to deliver content over HTTPS using your own domain and SSL certificate. SNI Custom SSL relies on the SNI extension of the Transport Layer Security protocol, which allows multiple domains to serve SSL traffic over the same IP address by including the hostname viewers are trying to connect to. Java 8 should have SNI enabled by default. The version of Java with the current Burp Mac distribution is: Java(TM) SE Runtime Environment (build 1.8.0_112-b16) This looks fully patched. Is SNI somehow dissabled? Thanks again.

PortSwigger Agent | Last updated: Jan 06, 2017 08:55AM UTC

SNI is enabled by default. You can turn this off via a command line switch (which you presumably aren't doing), or at User options / SSL / Java SSLoptions / Disable Java SNI extension. Please can you verify that you haven't disabled SNI through either of these methods?

Burp User | Last updated: Jan 06, 2017 06:31PM UTC

From Wireshark: Successful Client Hello from firefox browser without Burp proxy: (notice Server Name Indication extension) Secure Sockets Layer TLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 204 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 200 Version: TLS 1.2 (0x0303) Random GMT Unix Time: Feb 9, 2023 21:00:12.000000000 PST Random Bytes: 34d1f79fe5e3f4836eb02b2fa86e1ec09dce5690f1c2b0ad... Session ID Length: 0 Cipher Suites Length: 36 Cipher Suites (18 suites) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 123 Extension: Unknown 51914 Extension: renegotiation_info Extension: server_name Type: server_name (0x0000) Length: 20 Server Name Indication extension Server Name list length: 18 Server Name Type: host_name (0) Server Name length: 15 Server Name: target.server.com Extension: Extended Master Secret Extension: SessionTicket TLS Extension: signature_algorithms Extension: status_request Extension: signed_certificate_timestamp Extension: Application Layer Protocol Negotiation Extension: channel_id Extension: ec_point_formats Extension: elliptic_curves Extension: Unknown 23130 Unsuccessfule Hello from Burp ( no SNI extension) 312 bytes TLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 241 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 237 Version: TLS 1.2 (0x0303) Random GMT Unix Time: Jan 6, 2017 09:59:09.000000000 PST Random Bytes: 06ca061624dcb4d9c6129c048d2269e53b8b349684cc3ff6... Session ID Length: 0 Cipher Suites Length: 100 Cipher Suites (50 suites) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 96 Extension: elliptic_curves Extension: ec_point_formats Extension: signature_algorithms Thanks for you help.

Burp User | Last updated: Jan 06, 2017 07:32PM UTC

Also tried: /Applications/Burp Suite Professional.app/Contents/PlugIns/jre.bundle/Contents/Home/jre/bin/java -Djsse.enableSNIExtension=true -jar "/Applications/Burp Suite Professional.app/Contents/java/app/burpsuite_pro.jar" Does not work either.

Burp User | Last updated: Jan 06, 2017 09:44PM UTC

Yes I verified that Disable Java SNI extension is unchecked with v1.7.15 mac version. It doesn't work. So I got it to work with on older version of Burp! This is where you first added this option SNI extension option - V1.6.10. Running the older version on my local copy of Java(TM) SE Runtime Environment (build 1.8.0_65-b17) Looks like Java(TM) SE Runtime Environment (build 1.8.0_112-b16) with your distribution may be the problem. Thanks!

Burp User | Last updated: Jan 06, 2017 10:13PM UTC

Strange, now both versions are working. Sorry for the goose chase. No idea what the problem was.

PortSwigger Agent | Last updated: Jan 09, 2017 09:04AM UTC

If you're using the platform installer version of Burp, then the embedded Java version is often rolled up to the latest version, which might have caused a change in SSL handling. We'd suggest trying the plain JAR file with different versions of Java, and see if that fares any better.

Burp User | Last updated: Mar 24, 2017 04:35PM UTC

Looks like I am also having the same issue.. wondering if this is with the newest update?

Burp User | Last updated: Apr 03, 2017 05:11PM UTC

I've tried that and had the same issues. I do know this website being tested on makes use of high strength ciphers. And, it seems like it's an issue with it and possibly how JAVA is working in relation to the appropriate ciphers.

PortSwigger Agent | Last updated: Apr 04, 2017 08:14AM UTC

Do you see any errors in the alerts tab relating to cipher key lengths? If so, follow the advice there. Otherwise, we would suggest connecting directly with your browser, identify the SSL protocol and cipher that is chosen, and configure in your Burp options only to use those specific ones.

Burp User | Last updated: May 09, 2017 11:28AM UTC

GUYS! I've tried everything, but nothing helped me... And... I've removed every Java on my OS and fresh installed NetBeans with JDK 8 and problem was fixed! IM HAPPY AF! P.S. I have Windows x64.

PortSwigger Agent | Last updated: May 09, 2017 11:31AM UTC

Have you tried connecting directly with your browser, identifying the SSL protocol and cipher that is chosen, and configuring in your Burp options only to use those specific ones?

Burp User | Last updated: May 09, 2017 03:10PM UTC

I'm also facing similar issue when I'm trying to scan one ALB fronted instance and getting handshake_failure error. I'm using the latest available jar and have already upgraded the cipher suite as asked for java 8 version.

Burp User | Last updated: Jun 14, 2017 07:58PM UTC

I am also battling this issue. VERY frustrating. Seems like Portswigger could fix this?? Yes, I have "tried connecting directly with your browser, identifying the SSL protocol and cipher that is chosen, and configuring in your Burp options only to use those specific ones?" That didn't help. How do I "remove every Java on my OS"? I followed instructions to remove JRE and JDK at https://www.java.com/en/download/help/mac_uninstall_java.xml But immediately after the uninstall I am still able to run Burp, so there must be some Java still in my OS somewhere? I was trying to get all java uninstalled so I can try it with a fresh install of "NetBeans with JDK 8" as that seems to have worked for Eobard Thawne.

Burp User | Last updated: Jun 14, 2017 09:36PM UTC

Ok, I figured it out. I think the full installer for Burp installs some JRE it uses, so even if you uninstall the JDK it still works. I did what Eobard Thawne did, uninstalled/removed all JDK and JRE, then installed JDK8. I then ran v1.7.4 of Burp (just the jar) and I can now continue with testing, so yay.

Liam, PortSwigger Agent | Last updated: Jun 15, 2017 07:06AM UTC

Are you using the latest version of Burp Suite? Burp Suite 2.1.07 considerably improves Burp's SSL/TLS coverage - http://releases.portswigger.net/2019/12/professional-community-2107.html. If you are using the latest version and your problem persists, could you please provide us with additional details?

Burp User | Last updated: Aug 20, 2018 11:04AM UTC

I was getting "javax.net.ssl.SSLException: Received fatal alert: handshake_failure" error. Then after disabling User options / SSL / Java SSLoptions / Disable "Java SNI extension" issue got resolved. Thanks Dafydd..

Burp User | Last updated: Oct 02, 2018 03:03AM UTC

I spent about 4 hours trying to figure this out on Mac OS. Basically, Burp is unusable on OS X now, as TLS 1.2 is too common. Installed and uninstalled all of the JDKs to no avail. Ran the burp launcher stub that the installer drops, and also ran the jar file under specific JDKs. No luck. Eventually installed a bloody Windows VM and installed Burp and it worked flawlessly. Please fix the OS X version, Portswigger!

Burp User | Last updated: Jan 06, 2020 06:20PM UTC