Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Polling server connection fails on private collaborator instance

floyd | Last updated: Jun 04, 2019 08:07AM UTC

Hi there, I have setup a private collaborator server with let's encrypt wildcard certificates. It works fine, except that I can only pull over unencrypted HTTP. This is very strange, as I do not have a "polling" section in the configuration file. This means that Burp Collaborator server will use the same wildcard certificate for interactions and polling. I get the following when I try to poll over an encrypted connection: Initiating health check Server address resolution Success Server HTTP connection Success Server HTTPS connection (trust enforced) Success Server HTTPS connection (trust not enforced) Success Server SMTP connection on port 25 Success Server SMTP connection on port 587 Success Server SMTPS connection (trust enforced) Success Server SMTPS connection (trust not enforced) Success Polling server address resolution Success Polling server connection Error And all checks successful if I poll over unencrypted HTTP. From my point of view this does not make sense. Isn't it the same HTTPS endpoint used for the "Server HTTPS connection (trust not enforced)" and "Polling server connection" checks when I don't have a polling section in my configuration? cheers, floyd

Burp User | Last updated: Jun 04, 2019 08:08AM UTC

James says he can replicate it :)

Liam, PortSwigger Agent | Last updated: Jun 04, 2019 09:49AM UTC

Thanks for this report Floyd. Could you scale back to 2.0.13 and let us know if the issue persists?

Liam, PortSwigger Agent | Last updated: Jun 04, 2019 10:40AM UTC

Thanks Floyd. We've added this to our development backlog to investigate further.

Burp User | Last updated: Jun 04, 2019 11:26AM UTC

Yes, running 2.0.13 works fine and there are no connection errors.

Burp User | Last updated: Jun 28, 2019 11:47AM UTC

Do you have an ETA on this one? Just updated to Burp v2.1 and the bug is still present. I really feel bad about polling over HTTP :(

Liam, PortSwigger Agent | Last updated: Jun 28, 2019 01:33PM UTC

We don't have a ETA for this issue unfortunately.

Burp User | Last updated: Aug 23, 2019 06:50AM UTC

Burp 2.1.03 still broken. I wonder how many pentest companies haven't noticed yet and are either running without Burp Collaborator or are doing insecure requests via HTTP...

Burp User | Last updated: Aug 23, 2019 11:18AM UTC

I got the same issue.

Liam, PortSwigger Agent | Last updated: Aug 27, 2019 12:01PM UTC

Hi Floyd Thanks for following up with such a detailed response. I've passed your message to the development team. We'll update you when this issue has been investigated.

Burp User | Last updated: Sep 16, 2019 01:45PM UTC

My server supports IPv6, but that does not seem to be it. However, client and server talk TLS version 1.3 to each other (according to Wireshark), which might be something new that could explain why it breaks (maybe the Burp Suite client made some assumptions that do not hold for TLS 1.3). For example, are multiple clients allowed to connect to the same polling instance at the same time? Because if not, I could image that might be the problem. If TLS sessions are not removed identically, that could be one reason. But this is rather unlikely. I wonder if "Polling server address resolution" really only does a DNS lookup? I doubt it for some reason, but I might be wrong. Or I just didn't see it because it was answered from the OS cache, this is the most likely explanation. If "Polling server address resolution" would do a full connection to the polling server, this could support the "only one client allowed" theory where this would occupy the connection. But this is again unlikely to be the issue. So here comes the most likely theory: Maybe this problem only occurs on new servers that support TLS 1.3? That obviously depends on the Java version. But as Burp Collaborator doesn't have a built-in Java version yet (see https://portswigger.net/burp/documentation/collaborator/deploying#installation-and-execution where it just says "sudo java -Xms10m -Xmx200m -XX:GCTimeRatio=19 -jar burp.jar --collaborator-server"), people use different Java versions. I have "openjdk 11.0.4 2019-07-16" here, that supports TLS 1.3. Now in my case they will choose Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301) and will choose secp256r1 as the "key share" algorithm (how they provide the authentication, which is failing in our case). Now I would guess that there is some Burp Suite code that checks the server's "certificate", however, that works a little different in TLS 1.3. Hint: If you are looking at TLS 1.3 for the first time in Wireshark as I do, better have a look at https://networkengineering.stackexchange.com/questions/55752/why-does-wireshark-show-version-tls-1-2-here-instead-of-tls-1-3 first. There is also no cleartext certificate name visible in the server hello, instead there is a "key share" extension. So do you check the server certificate in your code "manually" or additionally? Are you sure that works for TLS 1.3? If somebody could have a look I would appreciate it.

Burp User | Last updated: Sep 24, 2019 02:11PM UTC

We're currently working on this, but for now as a workaround you can probably fix it by using 'Project options -> SSL -> Use custom protocols and ciphers' to disable TLSv1.3 in Burp Suite.

Burp User | Last updated: Sep 24, 2019 03:02PM UTC

The root problem appears to be a bug with Java 11's handling of TLS 1.3 so the best solution is to ensure you're running Burp Suite with Java 12. We will update the Burp Suite installer to bundle Java 12 shortly.

Burp User | Last updated: Oct 01, 2019 07:54AM UTC

I can confirm: 'Project options -> SSL -> Use custom protocols and ciphers' disable TLSv1.3 works! Thank you for investigating.

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