Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

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

Zach | Last updated: 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

PortSwigger Agent | Last updated: Feb 23, 2017 12:07PM UTC

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?

Burp User | Last updated: 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.

PortSwigger Agent | Last updated: Feb 23, 2017 12:15PM UTC

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.

Burp User | Last updated: 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.

PortSwigger Agent | Last updated: Mar 28, 2017 10:14AM UTC

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?

Burp User | Last updated: 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'

Burp User | Last updated: 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.

PortSwigger Agent | Last updated: Apr 26, 2017 01:24PM UTC

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.

Burp User | Last updated: 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

Burp User | Last updated: 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. https://www.ssllabs.com/ssltest/viewMyClient.html 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)

PortSwigger Agent | Last updated: Jun 14, 2017 07:08AM UTC

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.

PortSwigger Agent | Last updated: Jul 19, 2017 08:07AM UTC

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.

Burp User | Last updated: Sep 14, 2017 04:05PM UTC

Hello, I am also experiencing some problems with this issue. I just tested Burp 1.7.27 version. -Djsse.enableSNIExtension=false passed to java and Disable SNI unchecked and burp rebooted. I get the same: connection reset.

PortSwigger Agent | Last updated: Sep 15, 2017 08:36AM UTC

Hi Gregory, Thanks for your message. Can you please tell us: 1) Are you using an upstream proxy? If you are, try using Burp without the upstream proxy - does the issue still occur? 2) What options have you got in Project options > SSL ? 3) Does this happen with all sites you try to connect to, or just some? 4) If some - what are they? If they're Internet-based, the URL is helpful. Otherwise, is it an IIS webserver? F5 SSL accelerator? etc. 5) What OS and Java versions are you using? This should give us enough information to diagnose your issue.

Burp User | Last updated: Nov 15, 2017 03:17PM UTC

Just curious if the latest release fixed this issue or if folks are still having problems? I have an app test coming up that uses SNI.

PortSwigger Agent | Last updated: Nov 16, 2017 10:47AM UTC

Hi Kelley, We're not aware of any SNI issues in the latest version. The fix in 1.7.28 was for an extremely rare corner case. If you do encounter any issues, let us know.

Burp User | Last updated: Nov 17, 2017 06:33AM UTC

Still doesn't send server_name for the short domain names (without dot).

PortSwigger Agent | Last updated: Nov 17, 2017 09:29AM UTC

Hi Serkan, What version of Java are you using? Only Oracle Java 8 and newer has the API to send SNI in this scenario. If you are on Oracle Java 8, we'd be interested to know more about your setup, as it should be sending SNI.

Burp User | Last updated: Nov 20, 2017 07:53AM UTC

Hi Paul, Only installed Oracla Java is 8 and last version used. I tested both with 32 bit and 64 bit java version. Additionally we also running the setup version of Windows, so it should use its own Java in the package shouldn't it? All scenarios, i have traced the network traffic with wireshark and no SNI is sent to the server.

PortSwigger Agent | Last updated: Nov 20, 2017 10:04AM UTC

Hi Serkan, Thanks for reporting this. I've investigated some more and you are correct - SNI is not being sent. After we did our initial version, we put in sanity checks for illegal characters. Turns out these were not quite right. This will be corrected in the next version of Burp.

Burp User | Last updated: Nov 30, 2017 07:03AM UTC

Hi Paul, Thank you for the update. We are waiting for the next version.

PortSwigger Agent | Last updated: Nov 30, 2017 08:31AM UTC

Hi Martijn, We're not aware of anyone having difficulty since we implemented the fix for this. Can you please tell us: 1) Version of your OS, Java and Burp 2) Does the hostname contain a dot? 3) Are you using an upstream proxy? 4) Can you capture the SSL handshake in Wireshark and identify the server name extension?

Burp User | Last updated: Jul 03, 2018 01:11PM UTC

Hi, I'm having the same issue. SSL options: [x] enable algorithms.. [ ] disable Java SNI extension I'm also the only one at the office that has encountered this issue, any work around for this?

Burp User | Last updated: Mar 05, 2019 01:34PM UTC

Hi, we have a problem regarding SNI. We tested on the server with latest version of Burp (v2) and the SNI is not added by Burp. It's working using mitmproxy. We did not use an upstream proxy. I can provide screenshot if needed.

PortSwigger Agent | Last updated: Mar 05, 2019 03:04PM UTC

Please check in User options > SSL - there's an option to "Disable Java SNI extension". You must make sure this is NOT selected. Does you host name contain a dot? Java doesn't like adding a SNI without a dot, although we have some code in Burp to workaround this.

Burp User | Last updated: Mar 05, 2019 03:32PM UTC

Yes I never check this option of course. Yes my name contain multiple dot like: api.mysub.mydomain.com

PortSwigger Agent | Last updated: Mar 05, 2019 03:43PM UTC

Ok, there must be something in you environment which is affecting Burp as this works correctly for us. Can you confirm your OS, Java and Burp versions. Also, how are you determining that SNI is not being sent?

Burp User | Last updated: Mar 05, 2019 04:31PM UTC

OS: Arch linux up to date Java, bundled with burp, burp version: latest downloaded today, tested with beta 2.0 and 1.0. I see inside wireshark that SNI is not send, that's all.

Burp User | Last updated: Mar 05, 2019 04:39PM UTC

here is the screen: https://imgur.com/a/wXaEXCY

PortSwigger Agent | Last updated: Mar 06, 2019 08:41AM UTC

Hi Zack, I don't have Arch Linux handy but I tried this just now on Kali with OpenJDK 11 and Burp 2.0.18 - and SNI was sent correctly. I have no idea why it's not sending on yours. Perhaps Arch Linux is not compatible.

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