Support Center

Burp Community

See what our users are saying about Burp Suite:

How do I?

New Post View All

Feature Requests

New Post View All

Burp Extensions

New Post View All

Bug Reports

New Post View All
Documentation

Burp Suite Documentation

Take a look at our Documentation section for full details about every Burp Suite tool, function and configuration option.

Full Documentation Contents Burp Projects
Suite Functions Burp Tools
Options Using Burp Suite
Extensibility

Burp Extender

Burp Extender lets you extend the functionality of Burp Suite in numerous ways.

Extensions can be written in Java, Python or Ruby.

API documentation Writing your first Burp Suite extension
Sample extensions View community discussions about Extensibility
Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

Burp does not set SNI on the outgoing connection to an SSL enabled web server

Zach Pigadas Feb 23, 2017 12:03PM UTC

Hi there,

We run into the following situation the other day:

We were testing an SSL enabled application and kept getting connection resets when accessing it via intercepting Burp and correct connections and interactions when accessing it outside a proxy.

Some trial error and troubleshooting later it was identified that the server was expecting an SNI to be set. This was validated by using OpenSSL:

openssl s_client -host ipaddress -port portnum was getting us connection reset again while openssl s_client -host ipaddress -port portnum -servername webservername established the connection OK and allowed us to interact with the application, well you can hardly call "GET / HTTP/1.1" interaction but it did the trick.

So now off to Burp. We restarted it with -Djavax.net.debug=all and watched the messages go by:

This was what got generated in the incoming connection to Burp (browser to Burp):
pool-5-thread-41, READ: TLSv1 Handshake, length = 219
*** ClientHello, TLSv1.2
RandomCookie: GMT: -883550241 bytes = { 127, 5, 35, 183, 229, 255, 215, 186, 4, 30, 203, 127, 136, 157, 80, 137, 108, 121, 187, 141, 80, 250, 139, 109, 133, 235, 127, 190 }
Session ID: {88, 173, 111, 129, 195, 169, 111, 184, 197, 235, 138, 144, 134, 120, 151, 186, 129, 179, 29, 66, 73, 18, 137, 234, 141, 101, 88, 13, 165, 215, 174, 179}
Cipher Suites: [...]
Compression Methods: { 0 }
Extension server_name, server_name: [host_name: webservername]
Unsupported extension type_23, data:
Extension renegotiation_info, renegotiated_connection: <empty>
Extension elliptic_curves, curve names: {secp256r1, secp384r1, secp521r1}
Extension ec_point_formats, formats: [uncompressed]
Unsupported extension type_35, data:
Unsupported extension type_13172, data:
Unsupported extension type_16, data: 00:15:02:68:32:08:73:70:64:79:2f:33:2e:31:08:68:74:74:70:2f:31:2e:31
Unsupported extension status_request, data: 01:00:00:00:00
Extension signature_algorithms, signature_algorithms: SHA256withRSA, SHA384withRSA, SHA512withRSA, SHA1withRSA, SHA256withECDSA, SHA384withECDSA, SHA512withECDSA, SHA1withECDSA, Unknown (hash:0x4, signature:0x2), SHA1withDSA
***
...

and this is what went out the other way (Burp to web site)
RandomCookie: GMT: 1470984080 bytes = { 115, 245, 215, 127, 203, 179, 2, 149, 152, 29, 47, 90, 211, 122, 100, 60, 121, 188, 157, 125, 204, 224, 38, 81, 89, 65, 124, 223 }
Session ID: {}
Cipher Suites: [...]
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, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA, MD5withRSA
***

which led to

pool-5-thread-42, handling exception: java.net.SocketException: Connection reset
pool-5-thread-42, SEND TLSv1 ALERT: fatal, description = unexpected_message
pool-5-thread-42, WRITE: TLSv1 Alert, length = 2
pool-5-thread-42, Exception sending alert: java.net.SocketException: Connection reset by peer: socket write error
pool-5-thread-42, called closeSocket()

The issue was resolved by hardsetting dns names in hosts file, using Burp in invisible proxy mode and sending it to stunnel upstream with a specific sni = webservername which again confirmed the issue.

The issue exists with SNI support at User options / SSL set both off and on and also set from the commandline since it is the server that appears to be imposing it.

I am running Windows 7 SP1
java version "1.7.0_13"
Java(TM) SE Runtime Environment (build 1.7.0_13-b20)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
Burp 1.7.17

Cheers,
Zach


Dafydd Stuttard Feb 23, 2017 12:07PM UTC Support Center agent

Java ought to handle SNI automatically provided this is not disabled. Have you changed the option at User options / SSL / Java SSL options / Disable Java SNI extension?


Zach Pigadas Feb 23, 2017 12:12PM UTC
Yes, The issue exists with SNI support at User options / SSL set both off and on and also set from the commandline (-Djsse.enableSNIExtension=false) since it is the server that appears to be imposing it.

Dafydd Stuttard Feb 23, 2017 01:25PM UTC Support Center agent

It’s not clear why Burp/Java isn’t sending the SNI in the client hello if you haven’t disabled it. If other people run into this happening, we’ll investigate further. It sounds like the stunnel workaround will be good enough for this occasion.


HT Mar 24, 2017 05:32PM UTC
I'm also having this same issue.... The website has SNI enabled and there seems to be an error using burpsuite on it to conduct security testing.

cdhdt Apr 14, 2017 08:14AM UTC
Yeah, I am having the same issue when trying to chain proxy that need SNI information, burp is not sending the SNI information with the 'Client Hello'

Dafydd Stuttard Apr 18, 2017 08:01AM UTC Support Center agent

Burp relies on Java to deal with SNI, unless you have disabled this at User options / SSL / Java SSL options.

Perhaps this is due to an issue with a particular version of Java. Please can you try using the plain JAR file version of Burp with different versions of Java, and see if this makes any difference for you?


Steve Apr 26, 2017 11:31AM UTC
I'm also having the same issue with burp pro 1.7.21. The website has SNI enabled and there seems to be an error using burp-suite pro on it to conduct a web security testing.

Post Your public answer

Your name
Your email address
Answer