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

can load HTTPS. but not intercept ?

sakarias | Last updated: Oct 10, 2015 01:18PM UTC

Hello, today i tried to test Burp suite on my website, which is HTTPS. i've configured the proxy and downloaded the CA. i can load the HTTPS website but i get 0 data from it. HTTP websites works great. but not HTTPS. as i said, i can load them and surf around but i get 0 information from them. what to do ? (mac - safari)

PortSwigger Agent | Last updated: Oct 12, 2015 08:11AM UTC

Please can you give some more detail about what you mean by "I can load them and surf around but i get 0 information from them"? Also, have a look at our troubleshooting tips, which might help you resolve the issue: https://portswigger.net/burp/help/suite_troubleshooting.html

Burp User | Last updated: Oct 12, 2015 11:02AM UTC

before i downloaded the CA i couldn't load a HTTPS website (safari can't make a connection to the server) but when i downloaded the CA i could refresh the page and everything would display as usual, but burp won't intercept any data from my website.

PortSwigger Agent | Last updated: Oct 12, 2015 12:10PM UTC

Are you seeing requests appear in the Proxy history tab when you browse using HTTPS via Burp? If so, then the traffic is passing through Burp and you should be able to intercept it. Try restoring defaults for all Burp options, via the Burp menu.

Burp User | Last updated: Oct 12, 2015 01:09PM UTC

okey, i reseted all my setting,s can't load the website anymore, getting ''The client failed to negotiate an SSL Connection to www.xxxx.se:443 no cipher suits in common''

Burp User | Last updated: Oct 12, 2015 02:57PM UTC

Managed to get burp to intercept the website when i removed the HTTPS:/// and just typed www.xxx.se but i get 0 information now.

PortSwigger Agent | Last updated: Oct 12, 2015 03:37PM UTC

Regarding the "no cipher suits in common" error message, what browser are you using? Does switching to a different browser help at all?

Burp User | Last updated: Oct 20, 2015 09:08AM UTC

I have the same problem, burp works with HTTP but not HTTPS. I have the certificate installed, and I use java8. The requests doesn't appear in the Proxy history lab, and the burp error is "'The client failed to negotiate an SSL Connection to www.xxxx.xx:443 no cipher suits in common''. Can you help us? Thanks!

Burp User | Last updated: Oct 20, 2015 10:48AM UTC

I tried with Firefox, Chrome, Iceweasel and IE, but it doesn't work. I test in and old virtual machine with java6 and it works (iceweasel), could be a problem with java?

PortSwigger Agent | Last updated: Oct 21, 2015 08:16AM UTC

Is this affecting all HTTPS targets, or just some? If you switch to Java 7 or 6 on your current machine, does that help?

Burp User | Last updated: Oct 21, 2015 01:40PM UTC

It affects al HTTPS targets. With Java 8 and Java 7 it doesn't work, With java 6 works. How can it work with java 8? Previously it works. Thanks.

PortSwigger Agent | Last updated: Oct 21, 2015 03:41PM UTC

It's possible that there is no overlap in available SSL ciphers between your installation of Java and your browsers. We'll look into how Burp is initializing SSL on proxy listener connections and see if we can improve coverage. In the meantime, it sounds like using Java 6 when running Burp would be an effective workaround.

PortSwigger Agent | Last updated: Oct 27, 2015 02:04PM UTC

Do you see the supported ciphers in the list available in Burp at Options / SSL / SSL negotiation? If not then your installation of Java doesn't support the ciphers needed? If so, try disabling everything but the supported ciphers and see if that helps.

Burp User | Last updated: Jan 12, 2016 02:51PM UTC

Hi, today i had facing the same issue with Burp 1.6.32 on Kali 2.0 and two servers providing only the following cipher suites: Server 1 Accepted TLSv1 256 bits ECDHE-RSA-AES256-SHA Accepted TLSv1 256 bits AES256-SHA Accepted TLSv1 168 bits DES-CBC3-SHA Accepted TLSv1 128 bits ECDHE-RSA-AES128-SHA Accepted TLSv1 128 bits AES128-SHA Server 2 Accepted TLSv1 256 bits AES256-SHA Accepted TLSv1 168 bits DES-CBC3-SHA Accepted TLSv1 128 bits ECDHE-RSA-AES128-SHA Accepted TLSv1 128 bits AES128-SHA Using the known workarounds by either downgrading to Java 6 or by installing Java 8 from Oracle including the JCE 8 files (http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html) and enabling all SSL ciphers in Burp isn't helping here. Is there anything else what can be done from user-side?

Burp User | Last updated: Mar 01, 2016 12:08PM UTC

I've hit this same "no cipher suites in common" error message when trying to connect a Java thick client to a server via Burp. Twiddling with the Burp options got also "unknown certificate" error once in a while. Taking a closer and harder look, it turned out this error was somewhat misleading, the root cause was not wrong ciphers. This got solved by installing the correct certificates to the client side Java cacerts keystore. I had thought I had already done it, but the workstation had two different Java installations. Adding certs to the right keystore solved this.

Burp User | Last updated: Dec 22, 2018 03:03PM UTC

hey !, i was also facing the same problem .. i was able to load the HTTPS website but i was unable to Intercept the requests ! (I already installed CA certificate) i was finding the solutions online but none of them worked but after some time i was just looking into my network settings of my browser (Firefox) and i got the solution for this problem .!!!!!! just a silly mistake was happed there .. "Use this proxy server for all protocols " option was disabled ans :- open your network settings and enable the option "Use this proxy server for all protocols" (if enabled then no need to do anything) after doing this you will be able to intercept the requests ! i hope that will solve your issue ! thanks

Burp User | Last updated: Mar 25, 2019 06:56AM UTC