Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

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