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

Burp Browser automatically upgrades http:// requests to https://

Ryan | Last updated: Jun 02, 2023 01:59PM UTC

I have an application running on http://localhost:3000. It does not use https, and I've set a hostname in my /etc/hosts file so that I can access it via http://myapp:3000 Any time I attempt to load http://myapp:3000 in burp browser, it gets immediately switched to https://myapp:3000, which fails with `Unsupported or unrecognized SSL message`. Proxy history just shows the initial request with no response, so it's not like the server is asking for the upgrade, it seems like it's the browser just changing it before ever sending the request. I've cleared out the browser cache and all private browsing data, I've reset my user and project settings to defaults. Not sure what else to try. I'm using the most recent version of burp pro on MacOS Monteray. Thanks!

Ryan | Last updated: Jun 04, 2023 05:27PM UTC

I've also attempted to clear the HSTS cache for the domain and for `localhost` but that also hasn't helped. A full system restart seems to fix the problem temporarily. This just started happening after the most recent update.

Michelle, PortSwigger Agent | Last updated: Jun 05, 2023 08:52AM UTC

Can you send an email to support@portswigger.net with a few more details, as we've not been able to replicate this here yet? What do you see in the Proxy History and Logger tags? Do you see the same issue if you browse to http://example.com? Do you have any extensions installed? Can you also please send us the output from Help > Diagnostics?

Tim | Last updated: Jun 05, 2023 08:21PM UTC

I'm experiencing identical behavior. Requests within the embedded Chromium browser seem to automatically upgrade HTTP requests to HTTPS. The requests aren't being _redirected_ to HTTPS, but rather the initial request which Burp receives is for HTTPS. I have double-checked HSTS settings, and I do not have any HSTS entries. I get this behavior even when browsing http://example.com . When I do that, Burp Proxy History tab receives a request for https://example.com, even when http://example.com is typed in the browser. (Again, I'm not seeing http:// get _redirected_ to https://. I'm only seeing a single request come in for https://). I can load http://example.com directly in e.g. Burp Repeater tab just fine. This smells like an issue with the embedded Chromium browser config, rather than Burp itself. Burp seems to be doing what it should. I have tried with the "Burp Suite" extension both enabled, and disabled. I have no other extensions installed, and can reproduce this even after clearing all browsing and site history in Chromium. Excerpt from diagnostics page: ``` --------------------------------------------------------------------------------------------------------- SYSTEM PROPERTIES --------------------------------------------------------------------------------------------------------- com.sun.net.ssl.requireCloseNotify false exe4j.moduleName /home/XXX/apps/burp/BurpSuitePro/BurpSuitePro file.encoding UTF-8 file.separator / flatlaf.uiScale.enabled false install4j.appDir /home/XXX/apps/burp/BurpSuitePro/ install4j.exeDir /home/XXX/apps/burp/BurpSuitePro/ install4j.jvmDir /home/XXX/apps/burp/BurpSuitePro/jre install4j.launcherId 70 install4j.swt false java.class.path /home/XXX/apps/burp/BurpSuitePro/.install4j/i4jruntime.jar:/home/XXX/apps/burp/BurpSuitePro/.install4j/launcherccf7dac9.jar:/home/XXX/apps/burp/BurpSuitePro/burpsuite_pro.jar java.class.version 63.0 java.home /home/XXX/apps/burp/BurpSuitePro/jre java.io.tmpdir /tmp java.library.path /usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib java.net.useSystemProxies true java.runtime.name OpenJDK Runtime Environment java.runtime.version 19.0.2+7-44 java.specification.name Java Platform API Specification java.specification.vendor Oracle Corporation java.specification.version 19 java.vendor Oracle Corporation java.vendor.url https://java.oracle.com/ java.vendor.url.bug https://bugreport.java.com/bugreport/ java.version 19.0.2 java.version.date 2023-01-17 java.vm.compressedOopsMode Zero based java.vm.info mixed mode java.vm.name OpenJDK 64-Bit Server VM java.vm.specification.name Java Virtual Machine Specification java.vm.specification.vendor Oracle Corporation java.vm.specification.version 19 java.vm.vendor Oracle Corporation java.vm.version 19.0.2+7-44 jdk.debug release jdk.tls.allowUnsafeServerCertChange true jdk.tls.maxCertificateChainLength 30 native.encoding UTF-8 org.bouncycastle.jsse.client.dh.minimumPrimeBits 1024 org.bouncycastle.jsse.client.dh.unrestrictedGroups true os.arch amd64 os.name Linux os.version 5.10.0-23-amd64 path.separator : python.cachedir.skip true python.console.encoding UTF-8 stderr.encoding UTF-8 stdout.encoding UTF-8 sun.arch.data.model 64 sun.awt.enableExtraMouseButtons true sun.boot.library.path /home/XXX/apps/burp/BurpSuitePro/jre/lib sun.cpu.endian little sun.io.unicode.encoding UnicodeLittle sun.java.command install4j.burp.StartBurp sun.java.launcher SUN_STANDARD sun.jnu.encoding UTF-8 sun.management.compiler HotSpot 64-Bit Tiered Compilers user.country US user.dir /home/XXX/apps/burp/BurpSuitePro user.home /home/XXX user.language en user.name XXX user.timezone America/XXX --------------------------------------------------------------------------------------------------------- SYSTEM RESOURCES --------------------------------------------------------------------------------------------------------- Number of processors 12 Total JVM memory 696 MiB Max JVM memory 15.55 GiB Free JVM memory 156.8 MiB Total physical memory 31.08 GiB Free physical memory 12.6 GiB Total swap 976 MiB Free swap 844.75 MiB --------------------------------------------------------------------------------------------------------- BURP PROPERTIES --------------------------------------------------------------------------------------------------------- Burp Version 2023.5.2 Build Number 20972 Product Name Burp Suite Professional Update Channel Stable Burp Browser version 114.0.5735.90 Burp Browser binaries /home/XXX/apps/burp/BurpSuitePro/burpbrowser/114.0.5735.90 Code source /home/XXX/apps/burp/BurpSuitePro/burpsuite_pro.jar Debug ID xxx:xxx JAR type Installer currenttimemillis 1685995839623 nanotime 422242223603332 superuser false --------------------------------------------------------------------------------------------------------- PROJECT PROPERTIES --------------------------------------------------------------------------------------------------------- Project type disk Project file size 32 MiB Project file location /home/XXX/YYY/burp/2023-06-05-ZZZ.burp ```

Michelle, PortSwigger Agent | Last updated: Jun 06, 2023 09:58AM UTC

Hi Thanks for getting in touch. We're currently trying to replicate the issue here. At this stage, it does seem to be related to the Chromium version. When I browse to http://example.com, I see a request being sent to https://example.com, but this was followed by the HTTP requests, and the browser displayed the HTTP version of the page. The behavior you're seeing sounds like it might be slightly different. Does the HTTP version of the page display at all for you? If you clear the browser cache (Settings > Tools > Burp's browser > Clear all browser data from the browser data folder), does that change the behavior at all?

Ryan | Last updated: Jun 06, 2023 01:20PM UTC

The behaviour Tim is seeing sounds identical to what i'm seeing. The HTTP version is never even requested according to the burp proxy history. I type http://myapp:3000 into the burp browsers address bar, press enter, and it immediately upgrades to https://. In the proxy history tab I only see one request to https://myapp:3000. This behaviour persists after "clear all browser data from the browser data folder"

Jaggar | Last updated: Jun 06, 2023 02:03PM UTC

I am experiencing this behavior as well. What fixed it for me was replacing the Chromium binary located at ~/BurpSuitePro/burpbrowser/114.0.5735.90/chrome with one I downloaded from Chromium. Not sure what adverse effects this will have long term, but traffic is proxied correctly and the extension is loaded fine. This works until we can find an official workaround.

Tim | Last updated: Jun 06, 2023 02:58PM UTC

I tried the "Clear all browser data" option in Burp's settings, and the behavior persisted. (Also, I did not know about that settings page, so thanks for showing it to me! :-) )

Michelle, PortSwigger Agent | Last updated: Jun 07, 2023 02:29PM UTC

Hi If you go to the Proxy > Intercept tab and turn on Intercept as you first visit the site, then choose to drop the initial HTTPS request, do you then see the HTTP request being sent and are you able to access the site?

Ryan | Last updated: Jun 07, 2023 08:54PM UTC

I don't really understand what's happening yet, but this worked for me.

Michelle, PortSwigger Agent | Last updated: Jun 08, 2023 10:10AM UTC

Hi We're currently investigating this and checking the behavior of some of the flags in Chromium. In the meantime, the workarounds we've found are to either use the embedded browser and drop the first HTTPS request or to use an external browser such as Firefox (you may need to check the HTTPS-Only mode settings).

X0RW3LL | Last updated: Jun 13, 2023 11:44PM UTC

Hi @Michelle, This thread caught my attention since someone asked the same question on Discord, so I went deep into the rabbit hole. Here's what I know so far: - Burp itself does not perform HTTPS upgrades—that would be Chromium's doing - This change is not exactly new; HTTPS-only mode was first introduced most probably in Chromium version 93.0.4558.0 and upwards (Q2-Q3 2021), with more commits that handle HTTPS upgrades landing in later revisions (93.0.4564.0 and up) - What happens is Chromium will first attempt to upgrade non-unique hostnames to HTTPS, fast-falling back to HTTP when certain conditions are not met (lack of HTTPS support, some cert errors, and so on) - The reason why dropping the initial HTTPS request(s) (usually 2) works without another prompt for the same non-unique hostname is because the security level for the requested site will be remembered for 7 days - I've experimented with toggling various flags off, specifically #https-first-mode-v2 and #https-upgrades. However, that didn't seem to have any effect - I've also experimented with grabbing an older Kali release (2021.2) when Burp Suite had Chromium 88.0.4324.150, and sure enough, initial request was not upgraded to HTTPS - To confirm said behavior, I've also experimented with a slightly dated release (2023.1, Chromium 110.0.5481.77). As one would expect, initial requests were HTTPS upgraded, followed by fast-fallback to HTTP I'm not an expert on browsers (or C) by any means. Luckily, however, the Chromium browser source code is thoroughly documented, and more or less pointed me in what I believe was the right direction. I will include relevant links for anyone interested in further investigations, and I hope it helps! - First appearance of HTTPS-only mode: https://github.com/chromium/chromium/tree/93.0.4558.0/chrome/browser/ssl - Further expansion to HTTPS-only mode: https://github.com/chromium/chromium/tree/93.0.4564.0/chrome/browser/ssl - [HTTPS-Upgrades] diff that sparked this entire trip: https://chromium.googlesource.com/chromium/src/+/19719792bbd02433d8aeb7fda7fb00fc8ab7f0a6%5E%21/#F0 - https_upgrades_browsertest.cc source code that explains all the different HTTPS-related tests: https://chromium.googlesource.com/chromium/src/+/19719792bbd02433d8aeb7fda7fb00fc8ab7f0a6/chrome/browser/ssl/https_upgrades_browsertest.cc - https_upgrades_interceptor.cc: https://chromium.googlesource.com/chromium/src/+/19719792bbd02433d8aeb7fda7fb00fc8ab7f0a6/chrome/browser/ssl/https_upgrades_interceptor.cc

Matt | Last updated: Jun 14, 2023 01:05PM UTC

FF is what I use for general browsing and research and having to switch the proxy on and off depending on what I'm doing gets old really quickly. I can definitely say this issue is Chromium, not Burp Suite. Also I did confirm that "Always use secure connections" is NOT turned on in chromium settings. Something else is broken here. I don't believe it's related, but with the latest burp update the burp browser address bar has gotten really small, almost too small to read. Other Chrome and Chromium installs on this same workstation don't have that issue.

Matt | Last updated: Jun 14, 2023 01:08PM UTC

My above post didn't explain that I'm using Firefox as a work around since using FF proxied through burp works as expected, no http requests are upgraded to https.

Ben, PortSwigger Agent | Last updated: Jun 14, 2023 01:14PM UTC

Thanks both. We have now raised a bug report so that our developers can investigate why this might be happening. If and when we find out more we will update this forum thread.

X0RW3LL | Last updated: Jun 14, 2023 11:15PM UTC

Thanks, Ben Looking forward to finding out more about this behavior!

Ryan | Last updated: Jul 02, 2023 02:09PM UTC

Hey team, just wanted to check in and see if there are any updates on this issue. I use burp pro at work and this bug has made it near unusable. A lot of the flows I'm testing get bounced around between various domains in a local dev environment that doesn't use SSL. Each time a redirect throws burp toward new domain it bumps up against this bug, for flows that use 2 or 3 domains this is a huge barrier. Thanks!

Michelle, PortSwigger Agent | Last updated: Jul 03, 2023 07:31AM UTC

Hi We've been working on a fix that should be included in the next EA release, which will hopefully be this week.

Matt | Last updated: Jul 13, 2023 02:49AM UTC

I've upgraded my Mac and Linux versions of Burp Suite Professional. The MacOS version looks to be fixed, awesome! The Linux version however, still automatically upgrades http requests to https.

Michelle, PortSwigger Agent | Last updated: Jul 13, 2023 08:36AM UTC

Hi Thanks for getting in touch. I've just run some tests here on macOS and Linux, and both behaved the same for me and just sent the HTTP requests straight away. Could you email support@portswigger.net with more details of the test you're running and the output from Help > Diagnostics from both installations so we can take a closer look, please?

Matt | Last updated: Jul 13, 2023 01:30PM UTC

Michelle, thank you, I've sent the diagnostic reports.

Michelle, PortSwigger Agent | Last updated: Jul 13, 2023 02:12PM UTC

Thanks, we'll take a look and be in touch soon :)

Ben, PortSwigger Agent | Last updated: Jul 25, 2023 10:11AM UTC

Hi, We just wanted to let you know that the recent 'early adopter' 2023.7 release contains the fix for the issue that you were experiencing with the embedded browser upgrading the HTTP connection.

X0RW3LL | Last updated: Jul 26, 2023 12:57AM UTC

Thanks for the updates! I'll be on the lookout for that release once it makes its way into the repos, and leave an update as soon as I can.

X0RW3LL | Last updated: Aug 07, 2023 12:16PM UTC

Thank you, everyone, for the sharp work; reporters, agents, and dev team alike. I can finally confirm this issue's been fixed in 2023.7.2 (2023.7.2-0kali1).

Jason | Last updated: Nov 04, 2023 05:43PM UTC

Hi, I'm using v2023.10.2.4 but still got such problem No HTTPS redirect when using generic Chrome browser Version or Edge. But the Burp built-in browser (Version 118.0.5993.90) enforce to redirect HTTP to HTTPS. Please advise

Hannah, PortSwigger Agent | Last updated: Nov 06, 2023 04:36PM UTC

Hi Could you try performing the following actions, and let me know if these help? 1. In Burp: "Settings > Tools > Browser data > Clear all" 2. If that hasn't helped, open the browser: "Settings > Privacy and security > Security > Advanced > Always use secure connections > Disable" Please let me know how you get on with this.

Jason | Last updated: Nov 15, 2023 06:19PM UTC

after clear all Browser data, fine then thanks

Hannah, PortSwigger Agent | Last updated: Nov 16, 2023 10:01AM UTC

Glad to hear it! Please let us know if you need any further assistance.

zetsu | Last updated: Nov 26, 2023 11:16AM UTC