Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Intercept TLSv1.2 traffic no server_name Burp Proxy

Mary | Last updated: Dec 10, 2018 09:29PM UTC

I am using Burp as an invisible proxy to intercept all the traffic from a remote box, I have root privileges on the remote box and I have installed the correct certificate in it. Connecting the remote box to an Access Point where Burp is running and redirecting the traffic with iptables (or with configurations of the /hosts file) to the IP/Port Burp is listening. Problem: The remote box contacts multiple domains, TLSv1 communications is successfully decrypted, but there is one connection with TLSv1.2 that Burp proxy fails to handle. After a lot of testing I found the root of the problem. There is no server_name extension on the CLient Hello message, and after the handshake is done, Burp asks Hello Request again and I see two encrypted alert messages back-to-back starting from the remote box, and two FIN packets terminating the handshake. This behaviour indicates an SNI error, and it is to be expected, since Burp cannot forward a request since it has no knowledge of the destination host name. *The certificate presented by Burp is the right one, since I can get the host name from the original certificate of the handshake without using the proxy. *Redirecting the requests to that Host name stated above will not solve the problem since I don't see (wireshark on interface with connection to the internet) any packets leaving burp in order to redirect them. *I get no alerts on Burp, my only indication is the loss of connectivity on the remote box, and the wireshark capture.

Liam, PortSwigger Agent | Last updated: Dec 11, 2018 12:11PM UTC

We're going to try to replicate your set up. In the meantime, have you configured the "Redirect to host:" settings in the Edit proxy listener window? Additionally, have you tried enabling the "Disable Java SNI extension" option via User options > SSL > Java SSL Options?

Burp User | Last updated: Dec 12, 2018 06:44PM UTC

Thank you for your fast reply! I am surprised! I have configured the Redirect to host settings, but as I mention on the post, Nothing happens. Again the connection terminates at the handshake the same way. I have also enabled the "Disable Java SNI extension" with no positive results as well. I plan to take a closer look at the log files in the remote box.. I understand that there are a lot of parameters that might interfere. So I attach some more info: *When I use Burp as proxy the cipher suite changes (but still I guess this is something that I should not care since both client and server consent) *The client Hello on the handshake that "fails" includes a SessionTickets TLS extension to make the future communication more direct. This is something that I am not sure of, if it has to do with my problem.. Thank you!

PortSwigger Agent | Last updated: Dec 13, 2018 10:20AM UTC

I just checked this setup here and Burp is sending SNI with an invisible proxy connection. I was using Windows 10 and the Burp Platform Installer. Just to be clear, you must NOT enable "Disable Java SNI extension" - we were highlighting this to understand if you'd tried it. Can you please try your setup with a regular non-invisible proxy, and tweak until Burp is sending SNI. This could be related to the Java version you're using - we recommend using the Platform Installer as it has an embedded JRE that we know works well.

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