Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

handshake failure using strong cipher suites

Daniel | Last updated: Nov 21, 2016 10:19AM UTC

Description: Clients requesting (exclusively) strong cipher suites are unable to connect to Burp proxy. Burp always causes handshake failure. Software used: oracle jdk1.8.0_122, burp suite 1.7.06 How to reproduce: remove restrictions for strong cipher suites in java setup burp proxy to listen transparently on e.g. 127.0.0.1:9999 run openssl s_client -cipher 'ECDHE-RSA-AES256-SHA384' -servername host.domain.tld -connect 127.0.0.1:9999 Notes: further debugging burpsuite found this ... found key for : portswigger chain [0] = [ [ Version: V3 Subject: EMAILADDRESS=mail@portswigger.net, CN=PortSwigger, OU=PortSwigger, O=PortSwigger, L=London, ST=London, C=GB Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5 Key: Sun RSA public key, 1024 bits modulus: 142917230766032334595075833882492863259267794465425046100685121546501480083103580172309525941238553536456474333176322342383265133766918392286631671000336225700969472382299856180840919340915442938076224674993067161138641355600365277646886166545688782687618116370955117255945837906750176773493048514923456923251 public exponent: 65537 Validity: [From: Mon Nov 13 13:15:58 CET 2006, To: Sun Nov 08 13:15:58 CET 2026] Issuer: EMAILADDRESS=mail@portswigger.net, CN=PortSwigger, OU=PortSwigger, O=PortSwigger, L=London, ST=London, C=GB SerialNumber: [ 00] Certificate Extensions: 3 [1]: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ 0000: B8 C9 39 06 13 4B 4D 97 60 3A BB 97 40 91 4A 44 ..9..KM.`:..@.JD 0010: 0B B0 5C 25 ..\% ] [EMAILADDRESS=mail@portswigger.net, CN=PortSwigger, OU=PortSwigger, O=PortSwigger, L=London, ST=London, C=GB] SerialNumber: [ 00] ] [2]: ObjectId: 2.5.29.19 Criticality=false BasicConstraints:[ CA:true PathLen:2147483647 ] [3]: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: B8 C9 39 06 13 4B 4D 97 60 3A BB 97 40 91 4A 44 ..9..KM.`:..@.JD 0010: 0B B0 5C 25 ..\% ] ] ] Algorithm: [SHA1withRSA] Signature: 0000: 9D 10 19 CC 8E 4B FF 73 B1 D8 43 BA FC 9F 70 53 .....K.s..C...pS 0010: F5 FE 64 F0 4C 67 FE 28 D5 78 AE 49 36 92 4E 37 ..d.Lg.(.x.I6.N7 0020: E1 9C C6 B1 16 47 AD E7 3C 86 23 17 5F 22 B1 1A .....G..<.#._".. 0030: 07 35 91 78 C9 99 9E 21 49 7E 45 9E B9 EC 25 71 .5.x...!I.E...%q 0040: 08 14 96 07 25 37 83 3D E5 EA 43 18 FC 1A CD 57 ....%7.=..C....W 0050: 1B 99 DF 01 58 5D 6B 75 EA 44 D4 3F 0F 3D E3 F2 ....X]ku.D.?.=.. 0060: 48 D2 26 AD DA 4C F3 C0 C5 93 04 74 6C 25 03 3B H.&..L.....tl%.; 0070: B3 2D 86 7A C6 7E E2 4E B9 13 66 2D CD C2 A3 AF .-.z...N..f-.... ] *** Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_GCM_SHA256 Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384 Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 trustStore is: /usr/lib/jvm/jdk1.8.0_122/jre/lib/security/cacerts ... All strong hashing algorithms disabled despite lifting restrictions in java itself Please fix. I'm expecting that more and more applications will start using strong cipher suites - rendering burp useless.

PortSwigger Agent | Last updated: Nov 21, 2016 04:55PM UTC

Please can you go to Proxy Options / SSL / SSL Negotiation, and select the option "Use custom protocols and ciphers". Here you will see the list of protocols and ciphers that your platform is making available for Burp to use. You can turn on the ones you need. If something isn't shown there, it's because your Java installation doesn't have it or isn't configured to allow its use.

Burp User | Last updated: Nov 22, 2016 07:20AM UTC

Is this option available in the free edition? I can't find it. However, Burp does connections to perfdata.portswigger.net using TLS_RSA_WITH_AES_256_CBC_SHA256 ... Allow unsafe renegotiation: false Allow legacy hello messages: true Is initial handshake: true Is secure renegotiation: false Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for SSLv3 . . . Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1 %% No cached client session *** ClientHello, TLSv1.2 RandomCookie: GMT: 1479732276 bytes = { 168, 232, 201, 89, 116, 79, 126, 208, 66, 132, 55, 152, 199, 248, 19, 129, 221, 211, 132, 119, 23, 94, 65, 33, 169, 33, 197, 65 } Session ID: {} Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV] Compression Methods: { 0 } Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1} Extension ec_point_formats, formats: [uncompressed] Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA, MD5withRSA Extension server_name, server_name: [type=host_name (0), value=perfdata.portswigger.net] *** pool-2-thread-1, WRITE: TLSv1.2 Handshake, length = 274 pool-2-thread-1, READ: TLSv1.2 Handshake, length = 5526 *** ServerHello, TLSv1.2 RandomCookie: GMT: 1479731903 bytes = { 225, 179, 247, 114, 99, 87, 67, 85, 179, 87, 11, 90, 232, 170, 75, 206, 84, 183, 142, 2, 108, 126, 99, 154, 150, 94, 185, 189 } Session ID: {88, 51, 235, 191, 211, 188, 112, 203, 149, 133, 150, 143, 177, 213, 0, 53, 59, 140, 234, 169, 45, 187, 164, 56, 16, 5, 96, 135, 133, 47, 28, 217} Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 Compression Method: 0 Extension renegotiation_info, renegotiated_connection: <empty> *** %% Initialized: [Session-3, TLS_RSA_WITH_AES_256_CBC_SHA256] ** TLS_RSA_WITH_AES_256_CBC_SHA256 ... So burp client (my java installation) supports strong cipher suites with strong SHA This is a guess: The certificate on perfdata.portswigger.net utilizes 2048 bit RSA key and "Algorithm: [SHA256withRSA]" while the randomly generated certificate for the proxy is at 1024 bit RSA with "Algorithm: [SHAwithRSA]" I strongly suspect that that is the problem. Importing my own strong certificate does not help either as the weak "built in" certificate is not replaced with it. (Which is another bug)

PortSwigger Agent | Last updated: Nov 22, 2016 08:54AM UTC

Yes, the SSL options are the same in the free edition of Burp. Just make sure you're using the latest version. We changed Burp a while ago to use SHA256 in its generated certificates. You'll need to regenerate your Burp CA certificate and install it in your browser. Go to Proxy / Options / Proxy listeners / Regenerate CA certificate to do this.

PortSwigger Agent | Last updated: Nov 22, 2016 09:52AM UTC

Sorry, I mean project options, not proxy options, for those settings. If you use the option to regenerate CA certificate (use this option explicitly rather than deleting prefs files), then Burp should use SHA256 except where this isn't supported by your underlying Java platform. It's not clear why this doesn't appear to be happening since say you are using a current version of Java. Is it possible you have more than one JRE installed and the wrong one is being used?

Burp User | Last updated: Nov 22, 2016 10:15AM UTC

no avail :( delete prefs.xml, ran java -Djavax.net.debug=ssl:handshake:verbose -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -jar /path/to/burpsuite_free_v1.7.10.jar the generated cert is still SHA1withRSA: found key for : portswigger chain [0] = [ [ Version: V3 Subject: EMAILADDRESS=mail@portswigger.net, CN=PortSwigger, OU=PortSwigger, O=PortSwigger, L=London, ST=London, C=GB Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5 Key: Sun RSA public key, 1024 bits modulus: 142917230766032334595075833882492863259267794465425046100685121546501480083103580172309525941238553536456474333176322342383265133766918392286631671000336225700969472382299856180840919340915442938076224674993067161138641355600365277646886166545688782687618116370955117255945837906750176773493048514923456923251 public exponent: 65537 Validity: [From: Mon Nov 13 13:15:58 CET 2006, To: Sun Nov 08 13:15:58 CET 2026] Issuer: EMAILADDRESS=mail@portswigger.net, CN=PortSwigger, OU=PortSwigger, O=PortSwigger, L=London, ST=London, C=GB SerialNumber: [ 00] So I compiled a simple Java HTTPS Server for testing, created a cert for it with keytool (1024bit RSA AND SHA1with RSA) and guess what - hand shake with that server runs smoothly: *** ClientHello, TLSv1.2 RandomCookie: GMT: 1883716619 bytes = { 200, 13, 147, 243, 106, 46, 100, 23, 232, 152, 53, 202, 222, 126, 59, 136, 123, 90, 15, 114, 140, 126, 204, 52, 113, 167, 92, 28 } Session ID: {} Cipher Suites: [TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_EMPTY_RENEGOTIATION_INFO_SCSV] Compression Methods: { 1, 0 } Extension server_name, server_name: [type=host_name (0), value=host.domain.tld] Extension ec_point_formats, formats: [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2] Extension elliptic_curves, curve names: {secp256r1, secp521r1, unknown curve 28, unknown curve 27, secp384r1, unknown curve 26, secp256k1, sect571r1, sect571k1, sect409k1, sect409r1, sect283k1, sect283r1} Unsupported extension type_35, data: Extension signature_algorithms, signature_algorithms: SHA512withRSA, Unknown (hash:0x6, signature:0x2), SHA512withECDSA, SHA384withRSA, Unknown (hash:0x5, signature:0x2), SHA384withECDSA, SHA256withRSA, SHA256withDSA, SHA256withECDSA, SHA224withRSA, SHA224withDSA, SHA224withECDSA, SHA1withRSA, SHA1withDSA, SHA1withECDSA Unsupported extension type_15, data: 01 *** %% Initialized: [Session-1, SSL_NULL_WITH_NULL_NULL] matching alias: selfsigned Standard ciphersuite chosen: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 %% Negotiating: [Session-1, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384] whereas burp proxy produces: *** ClientHello, TLSv1.2 RandomCookie: GMT: 64239955 bytes = { 181, 135, 58, 158, 124, 58, 111, 166, 133, 49, 255, 78, 91, 163, 109, 234, 222, 18, 150, 10, 112, 160, 7, 47, 139, 37, 237, 41 } Session ID: {} Cipher Suites: [TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_EMPTY_RENEGOTIATION_INFO_SCSV] Compression Methods: { 1, 0 } Extension server_name, server_name: [type=host_name (0), value=host.domain.tld] Extension ec_point_formats, formats: [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2] Extension elliptic_curves, curve names: {secp256r1, secp521r1, unknown curve 28, unknown curve 27, secp384r1, unknown curve 26, secp256k1, sect571r1, sect571k1, sect409k1, sect409r1, sect283k1, sect283r1} Unsupported extension type_35, data: Extension signature_algorithms, signature_algorithms: SHA512withRSA, Unknown (hash:0x6, signature:0x2), SHA512withECDSA, SHA384withRSA, Unknown (hash:0x5, signature:0x2), SHA384withECDSA, SHA256withRSA, SHA256withDSA, SHA256withECDSA, SHA224withRSA, SHA224withDSA, SHA224withECDSA, SHA1withRSA, SHA1withDSA, SHA1withECDSA Unsupported extension type_15, data: 01 *** %% Initialized: [Session-4, SSL_NULL_WITH_NULL_NULL] %% Invalidated: [Session-4, SSL_NULL_WITH_NULL_NULL] I still don't see Proxy / Options / SSL / SSL Negotiation btw.

Burp User | Last updated: Nov 23, 2016 06:56AM UTC

Found the options . But: "These settings control the SSL protocols and ciphers that Burp will use when performing SSL negotiation with upstream servers. ..." My problem is not with upstream servers! It's the hand shake of the downstream clients which fails when using e.g. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. All strong ciphers are listed in the options page. So they are available. Regenerated the CA certificate as you suggested. Still get handshake failures. My JRE is not the problem. As I told you a simple Java SSL server handles hand shakes quite smoothly, Burp proxy does not.

Burp User | Last updated: Nov 23, 2016 09:47AM UTC

N.B. I even went to the trouble of setting up a clean Windows VM, install Java, lift export restrictions etc. With the same result: hand shake failure even with a weak TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (which was listed as available in the options as well) Please debug and fix.

PortSwigger Agent | Last updated: Nov 23, 2016 09:55AM UTC

Thanks for the further information. We'll investigate this issue and see how we can get it resolved.

Burp User | Last updated: Nov 23, 2016 10:17AM UTC

One more time.. I did some debugging for your and found that you do SSLContext yoursslcontext = SSLContext.getInstance("SSLv3"); instead of SSLContext yoursslcontext = SSLContext.getInstance("TLS"); furthermore you init yoursslcontext without TrustManager whereas my working server app does... hope this helps

PortSwigger Agent | Last updated: Nov 23, 2016 10:23AM UTC

Thanks for all the feedback. We will investigate this and get a fix in place.

Burp User | Last updated: Nov 23, 2016 10:30PM UTC

You need an edit function ;-) I changed my server to use SSLv3 and no trustmanager and I still can perform hand shakes using strong cipher suites. So the assumptions in my last post are on the wrong track entirely...

Burp User | Last updated: Nov 24, 2016 08:53AM UTC

I tweaked Java's HandShaker.class to print what cipher suites are actually added. For Burp proxy the output is: Added cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA Added cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA ..and so forth while for the simple https server it is: Added cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 Added cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ... Added cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA Added cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA ... and many more I leave it up to your programmers to figure out why burp proxy does not add any suite with strong signature algorithms as I have spent too much time on this already. Looking forward to seeing this problem fixed.

Burp User | Last updated: Nov 24, 2016 10:56AM UTC

SOLVED! I couldn't let this rest.... So I patched s5d.class to set sslcontext to "TLS" instead of the (obfuscated) "SSLv3" Handshake now works -Hooray :-D Please update Burpsuite asap- Thanks

PortSwigger Agent | Last updated: Nov 24, 2016 11:15AM UTC

Yes, the change to use TLS instead of SSLv3 was made in Burp 1.7.14.

Burp User | Last updated: Jan 13, 2017 11:57AM UTC

Has this fix been implemented yet? I am testing an API using strong auth and I am experiencing the same problem.

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