Support Center

Burp Community

See what our users are saying about Burp Suite:

How do I?

New Post View All

Feature Requests

New Post View All

Burp Extensions

New Post View All

Bug Reports

New Post View All

Burp Suite Documentation

Take a look at our Documentation section for full details about every Burp Suite tool, function and configuration option.

Full Documentation Contents Burp Projects
Suite Functions Burp Tools
Options Using Burp Suite

Burp Extender

Burp Extender lets you extend the functionality of Burp Suite in numerous ways.

Extensions can be written in Java, Python or Ruby.

API documentation Writing your first Burp Suite extension
Sample extensions View community discussions about Extensibility
Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

'SSL Pass Through' traffic is incorrectly forwarded through an upstream proxy

Tom Tervoort Jan 30, 2017 12:09PM UTC

When the SSL Pass Through function is used in combination with an upstream proxy server proxy, the proxy is used incorrectly, causing the proxy to deny TLS connections that are passed through.

Expected behaviour would be that Burp performs a CONNECT request to the proxy server, providing it with the target host; after receiving a 200 response, it can proceed forwarding the TLS messages to the proxy.

However, what I see is that the CONNECT phase is skipped entirely for SSL Pass Through connections. Instead, the TLS data is forwarded immediately to the proxy server. When this server receives a TLS ClientHello rather than a CONNECT request, it will abort the connection.

A CONNECT request is performed correctly when intercepted HTTP(S) traffic is forwarded. The problem only occurs for SSL Pass Through connections.

I encountered this problem while configuring the upstream proxy server within the Project options. I confirmed that it occurs regardless of using no or Basic authentication. By the way, there were no problems with the selection of the correct proxy based on the destination host of SSL Pass Through connections.

I use Burp Suite Professional v1.7.16.

Dafydd Stuttard Feb 20, 2017 04:45PM UTC Support Center agent

Thanks for this report. We’ve created a ticket for this and will update this thread when we have a fix available.

Kraemer May 16, 2017 01:29PM UTC
Any update, when this issue will be fixed?

Dafydd Stuttard May 16, 2017 01:58PM UTC Support Center agent

We don’t have any update on this, sorry. The fix depends on some other more involved work that we plan in the coming months, so we’re unlikely to deliver a fix in the near term.

Tom Tervoort May 26, 2017 02:57PM UTC
For people who are also affected by this issue, a workaround is to configure an upstream proxy for the Pass Through traffic that is actually a local TCP server that forwards the connection to the proxy you want. You can, for example, achieve this with the following socat command:

socat tcp-listen:<local-port>,fork proxy:<proxy-host>:<target-host>:<target-port>

Michael K. Jun 23, 2017 07:04AM UTC
Thanks for the feedback.

Can you tell me, if the bug is also included in the older version 1.6.30?
We have had tested this older versions and everything seems to be fine.
Our customer now uses 1.7.16 and he has the problem.


Dafydd Stuttard Jun 23, 2017 08:29AM UTC Support Center agent

As far as we’re aware, Burp has always had this bug. We are currently working on a fix and we are aiming to have this ready for the next release.

Michael K. Jul 13, 2017 12:21PM UTC
Can you determine when the next release is available?

Thx Michael

Dafydd Stuttard Jul 14, 2017 08:14AM UTC Support Center agent

We are expecting to release an update within the next 1-2 weeks.

Michael K. Aug 09, 2017 04:25PM UTC
We have installed Version 1.7.26 assuming the issue is solved.

But we still get trouble, when using an upstream proxy.
We are sure that Burp is closing the connection with "CLIENT HELLO" in wireshark trace.
Any hints or tipps for trouble shooting?

Do you need any other information for understanding the root-cause? [wireshark traces...]

Paul Johnston Aug 11, 2017 07:32AM UTC Support Center agent

Hi Michael,

Unfortunately the fix didn’t make it to the recent release. I will have a word with the development team to see if this can be bumped up the list.

In the interim, your best option is to either run Burp on a network without an upstream proxy, or to use the socat workaround described above.

Michael Aug 30, 2017 04:48PM UTC
Hello Paul,

thanks for your feedback.
We have checked the workaround with socat. We are running Burp on Windows with JRE.
So it's not clear for us to rebuild the socat command on Win.
Can you emphasize this fixing for the next build?

Thanks Michael

Paul Johnston Sep 07, 2017 08:10AM UTC Support Center agent

Hi Michael,

We’ve had a look at this in more detail now, and produced a prototype that works in simple scenarios (specifically, no proxy authentication). However, the changes are more intrusive than we’d hoped; it may be too risky to apply at this stage. We’ll discuss this internally over the coming weeks.

To get you going now, I have compiled socat on Windows for you. I will email you with this shortly.

Post Your public answer

Your name
Your email address