Burp Suite User Forum

Login to post

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

Tom | Last updated: 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.

PortSwigger Agent | Last updated: Feb 20, 2017 04:42PM UTC

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

Burp User | Last updated: May 16, 2017 01:29PM UTC

Any update, when this issue will be fixed?

PortSwigger Agent | Last updated: May 16, 2017 01:57PM UTC

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.

Burp User | Last updated: 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>

PortSwigger Agent | Last updated: May 30, 2017 03:27PM UTC

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.

Burp User | Last updated: 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. Thanks

PortSwigger Agent | Last updated: Jun 23, 2017 10:40AM UTC

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

Burp User | Last updated: Jul 13, 2017 12:21PM UTC

Can you determine when the next release is available? Thx Michael

Burp User | Last updated: 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...]

PortSwigger Agent | Last updated: Aug 10, 2017 07:19AM UTC

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.

Burp User | Last updated: 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

PortSwigger Agent | Last updated: Sep 04, 2017 10:49AM UTC

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.

Burp User | Last updated: Nov 26, 2019 10:50AM UTC

Hi, I having this issue. There is an update or workaround? Thanks

Ben, PortSwigger Agent | Last updated: Nov 26, 2019 01:06PM UTC

Hi Yakir, Unfortunately, this is still in our development backlog and has not yet been implemented. Have you tried to use the socat workaround mentioned earlier in the thread?

You need to Log in to post a reply. Or register here, for free.