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

TLS - Windows TLS connection handshake through Burp is slow when using non-loopback interface

Illya | Last updated: Sep 23, 2020 09:59AM UTC

Basically on Windows, when proxying traffic on any other interface other than loopback, Burp takes easily over 5 seconds to respond to the client's TLS "Client Hello" message. This is reproduceable all the way back to even v1.7.35 (did not test any further). Highly suspect something is wrong as the Linux version does not have this issue at all.

Michelle, PortSwigger Agent | Last updated: Sep 23, 2020 12:21PM UTC

Thanks for getting in touch. If you don't mind, I'd like to check a few more details about your setup, please. Can I confirm that you were using 2020.9.1 when you first noticed this issue? Are you using the installed version or the JAR file? If you are using the JAR file to launch Burp, which version of Java do you use? Which version of Windows are you using when you see this behavior? Do you see this behavior with all HTTPS sites? Are you just proxying via Burp or do you also use an upstream proxy? If you have a screen recording you'd be happy to share to help us replicate this issue, please feel free to email it over to support@portswigger.net

Andrew | Last updated: Nov 05, 2020 02:04PM UTC

Same issue here. When using Burp running on a Windows 10 host, and a browser in a virtual machine, there is a gap of around 5 seconds between the client HELLO and server HELLO on most or all TLS connections. With most sites having tens of resources, this slows down the loading a lot. This is with v2019.9.2 using the installer. There is no upstream proxy.

Michelle, PortSwigger Agent | Last updated: Nov 06, 2020 01:58PM UTC

Thanks for sending the information over. To help us understand your setup which might help us to replicate the issue can I check a couple more details with you, please? Is the virtual machine where your browser is also on Windows? Have you experienced this with any earlier versions of Burp or have you only noticed it with the latest version?

Andrew | Last updated: Nov 10, 2020 03:20PM UTC

The situation occurs with both Windows 10 and Ubuntu 18.04 virtual machines. I've used this setup for a while, and it's only become apparent in the last few months. I suspect the same thing is happening when proxying mobile applications but have not had a chance to check this yet.

Michelle, PortSwigger Agent | Last updated: Nov 11, 2020 02:50PM UTC

Thanks for the information. We'll do some tests and see if we can replicate the issue here.

Michelle, PortSwigger Agent | Last updated: Nov 13, 2020 04:22PM UTC

We're still looking into this issue, out of interest, do you see the same issue/delay if you use two VMs, with Burp installed in one and the browser being proxied via Burp in the other?

Michelle, PortSwigger Agent | Last updated: Nov 20, 2020 10:11AM UTC

Thanks for your patience. We've been running some tests and were able to replicate an issue where we had the browser in a virtual machine and Burp running on a Windows 10 machine and from a packet capture on the virtual machine there was a small delay between the Client Hello and the Server Hello. We ran some debugs on the Burp installation whilst this was happening and these showed no gap between the Client and Server hello. So this seems to be an environmental issue, have you tried using different modes for the Virtual machine, e,g, maybe try swapping between bridged and NAT modes to see if there is a difference?

CHANG | Last updated: Dec 13, 2020 05:23AM UTC

I encountered a similar problem. But this only happens on Windows. I used Burp Suite Community 2020.12 (bundled with OpenJDK 14.0.2) on two different laptops (not VM), macOS Catalina 11.0.1 and Windows 10 20H2 (19042.685). Both systems have correctly installed the CA certificate. When visiting a TLS site, the Windows host has a response delay, but macOS does not. Especially when proxying mobile traffic on Windows. The delay time is very long.

Uthman, PortSwigger Agent | Last updated: Dec 14, 2020 11:08AM UTC