Burp Suite User Forum

Create new post

Responses to HTTPS requests are very/too slow when listening on non-loopback interface on Windows

Pieter | Last updated: Apr 29, 2020 07:47PM UTC

I have reinstalled the latest version from scratch, and still face the following issue. * I start a listener on all interfaces (*), or a specific non-loopback interface; * I use the default Burp configuration with e a clean temporary project without extensions; * From a second device, I run `curl http://www.google.com/ -x <burp>:8080` which returns the page instantly and shows up nicely in Burp; * When I run `curl https://www.google.com/ -k -x <burp>:8080` (note the HTTPS), the request takes 10 seconds to load. This issue is most prominent when executing mobile application tests, and configuring burp as a proxy on a mobile device. I do not encounter the same problem when running v2020.1 from a Linux VM on the same network. System information: Microsoft Windows 10 Home Version 10.0.18363 Build 18363 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz, 2801 MHz, 4 cores, 8 logical processors

Pieter | Last updated: Apr 30, 2020 08:59AM UTC

I have continued to look into this, and bumping into more issues (which are hopefully related): * When the PortSwigger ca has not been installed, I get an expected SSL error: "self signed certificate in certificate chain" when sending a curl through Burp * After having installed the PortSwigger ca, the SSL error switches to: "curl: (35) error:0900006e:PEM routines:OPENSSL_internal:NO_START_LINE" When running the same commands, from the same device (as well as tested from a second mobile device), through a different instance of Burp (on a Linux VM), this error persists. Although the error message has a 10 second delay from the Windows Burp and is instant on the Linux Burp.

Pieter | Last updated: Apr 30, 2020 09:27AM UTC

Upon further investigation, it turns out the OPENSSL error is linked to my Android devices, because I can run `curl https://google.com -x <burp>:8080 -cacert cacert.crt` from a linux VM without issues. The time difference persists, however.

Huite | Last updated: Apr 30, 2020 09:30AM UTC

I'm facing a similar issue with the proxy. 2020.1 was adding a noticable delay but not a problem for applications. 2020.2 seemed to have added a bigger delay (5 seconds or more)O and didn't create a problem for my applications. 2020.4 seems to have add a delay over 10 seconds per HTTPS requests, which breaks functionalitity in app's I'm working on. java.runtime.name OpenJDK Runtime Environment java.runtime.version 13.0.2+8 os.name Windows 10 Intel I7-8700K and 32GB of RAM

Uthman, PortSwigger Agent | Last updated: May 01, 2020 08:37AM UTC

Have you tried setting up an invisible proxy to see if it improves the speed? https://portswigger.net/burp/documentation/desktop/tools/proxy/options/invisible

Pieter | Last updated: May 07, 2020 08:32AM UTC

Hello - I have tried setting up an invisible proxy with the same results. This is what I did: * mounted /etc/hosts on my mobile device and added record 192.168.0.10 www.example.com * set up a Proxy Listener in Burp on interface 192.168.0.10 on port 443 * issued a "direct" request to https://www.example.com/ The request still took over 9 seconds to finish. I also tried running the JAR file (java -jar .\burpsuite_pro_v2020.4.jar) with an updated version of Java on my system: java version "13.0.2" 2020-01-14 Java(TM) SE Runtime Environment (build 13.0.2+8) Java HotSpot(TM) 64-Bit Server VM (build 13.0.2+8, mixed mode, sharing) Is there a way to get a verbose output from running Burp, to start troubleshooting? Thanks, Pieter

Uthman, PortSwigger Agent | Last updated: May 07, 2020 09:10AM UTC

Thanks for that information. Can you share a screen recording via email, please? Are all the sites you are connecting to using a specific version of TLS? Do you notice any improvements when disabling TLSv1.3?

Pieter | Last updated: May 08, 2020 07:28AM UTC

Hello Uthman, I have recorded a screencap and sent the video to support@portswigger.net I did not notice a difference when disabling TLSv1.3.

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