Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

SSL SNI not used with upstream proxy

Ron | Last updated: Sep 21, 2016 07:08PM UTC

Hello, SSL SNI works properly on regular connections but not on connections through upstream http proxy. After getting Handshake_Failure alerts when using an upstream http proxy I've confirmed that the "Server_Name" extension is missing for SSL handshakes when an upstream proxy is enabled. Could you please confirm if it is a bug or should I check anything else? Details: Windows 10 Burp Pro v1.7.06 using the BurpSuitePro.exe executable JRE 8 Universal JCE installed

PortSwigger Agent | Last updated: Sep 22, 2016 09:43AM UTC

We have this issue captured in our backlog of work, and will update this thread when we have some progress to report, thanks.

Burp User | Last updated: Apr 03, 2017 04:09PM UTC

Hello, I am afraid I am having the same issue with Burp Suite Pro 1.7.19... The SNI is correctly sent if I disable the upstream proxy, but it is missing from the Client Hello when I enable the upstream proxy (squid). Toggling the setting "disable java SNI extension" (and restarting) do not fix this. Could you please investigate? Windows 7 x64 With Burp installer or .jar Java : 1.8.0_121-b13 JCE installed

Burp User | Last updated: Apr 07, 2017 12:41AM UTC

I need this too, damn...

PortSwigger Agent | Last updated: Apr 07, 2017 08:01AM 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: May 26, 2017 12:53PM UTC

Tested Version: 1.7.23 Free Tested Platform: Windows 7 SP1 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)

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