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.

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.

John Jun 05, 2017 10:28PM UTC
I just want to echo that I am also experiencing this condition. I have a host that requires SNI (CloudFront domain), but the handshake fails in Burp under certain conditions.

The handshake fails when I have an upstream proxy configured. I confirmed the handshake will succeed through the same upstream proxy with proxytunnel+openssl (with SNI). But the same connection fails under Burp.

The connection succeeds with Burp when an upstream proxy is not configured.

Things I've tried:

- Multiple versions of Burp (including latest 1.7.21)
- Multiple versions of Java (including the packaged JRE)
- Forcing -Djsse.enableSNIExtension=true

Dafydd Stuttard Jun 06, 2017 07:55AM UTC Support Center agent

There is a known issue with SNI not working correctly with some upstream proxies, which we intend to fix at some point. In the meantime, it might be possible to use a different intercepting proxy upstream from Burp, before your normal upstream proxy, to see if that can workaround the issue.

CC Jun 13, 2017 03:40PM UTC
Tested Version: 1.7.23 Free
Tested Platform: Windows 7 SP1

What is holding up this fix???

The issue of Burp not sending SNI in SSL handshake can be consistently reproduced by configuring Burp to access a SNI enabled site through an upstream proxy. While it is true that Java 7+ will automatically add SNI hostnames to the handshake, there are situations where the destination hostname is not known to the SSLSocket, and hence, can't be automatically added.

The following steps describe how to repro the issue of Burp not sending SNI when an upstream proxy is used.

Repro Steps:
1. First, you need a NON-MITM upstream proxy. In this example, we'll use adamfisk/LittleProxy that is available from GitHub.

2. Download LittleProxy from GitHub and run it on port 9999 using the command below.
IMPORTANT NOTE: Please do this within a trusted network or others will be able to proxy through your machine.

java -jar littleproxy-1.1.2-littleproxy-shade.jar --port 9999

3. Configure your browser to proxy through port 9999.
4. Navigate to SSLLab's browser test site at the following URL.

5. After the page has loaded, scroll down to somewhere in the middle of the page and you should see "Server Name Indication (SNI) Yes"
6. This confirms that the browser can correctly access a SNI-enabled site through the LittleProxy upstream proxy.

7. DISABLE ALL upstream proxy configured in Burp, so Burp will connect directly to all sites.
8. Configure the browser to proxy through Burp.
9. Load the SSLLab's browser test page again.
10. After the page has loaded, scroll down to somewhere in the middle of the page, and you should see "Server Name Indication (SNI) Yes"
11. This confirms that Burp will send the SNI when it is configured not to use any upstream proxy.

12. Next, configure Burp to use LittleProxy as the upstream proxy for all sites.
13. Load the SSLLab's browser test page again.
14. After the page has loaded, scroll down to somewhere in the middle of the page, and you should see "Server Name Indication (SNI) No"
15. This confirms that Burp will NOT send the SNI if it is using an upstream proxy.

Possible Cause:
Below is a possible cause of the issue. Please double-check that Burp's code is not sending an empty string "" or some invalid values in the "destHostname" parameter mentioned below.

Typically, when an upstream proxy is used, a HTTPS connection is established to the destination host via the following steps.
1. A Normal non-SSL socket is used to connect to the upstream proxy.
2. A CONNECT command is then issued through this socket to request the upstream proxy to connect to the destination host.
3. After the proxy has acknowledged a successful connection, a new SSLSocket will be created to overlay over the non-SSL socket that is currently connecting to the upstream proxy.
4. This overlay is typically done using a call like the one below, where nonSSLsocket is the socket that is currently connected to the upstream proxy. Note that "destHostname" MUST be set to the hostname of the destination host. Otherwise, the SSLSocket will have NO way of knowing the hostname of the destination host, and hence, will not be sending the SNI.

localSSLSocketFactory.createsocket(nonSSLsocket, destHostname, destPort, true)

Paul Johnston Jun 14, 2017 12:56PM UTC Support Center agent

Hi Zach,

Thanks for providing such detailed information.

We have confirmed the problem and it appears we can do a change just like you suggest. This still needs to go through our QA process, but barring any unexpected side-effects, it should be in the next release.

Please let us know if you need any further assistance.

Dafydd Stuttard Jul 19, 2017 08:10AM UTC Support Center agent

Just to let you know that the latest release (1.7.24) fixes the SNI problem with upstream proxies.

Thanks again for your feedback, and let us know if you run into any other issues.

Post Your public answer

Your name
Your email address