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

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

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 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: 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: 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


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.

Post Your public answer

Your name
Your email address