Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

Polling server connection fails on private collaborator instance

floyd 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


floyd Jun 04, 2019 08:08AM UTC
James says he can replicate it :)

Liam Tai-Hogan Jun 04, 2019 10:12AM UTC Support Center agent

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


floyd Jun 04, 2019 11:26AM UTC
Yes, running 2.0.13 works fine and there are no connection errors.

Liam Tai-Hogan Jun 05, 2019 12:49PM UTC Support Center agent

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


floyd 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 Tai-Hogan Jun 28, 2019 01:34PM UTC Support Center agent

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


floyd 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...

fenceposterror Aug 23, 2019 11:18AM UTC
I got the same issue.

floyd 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.

Liam Tai-Hogan Sep 18, 2019 10:23AM UTC Support Center agent

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.


Post Your public answer

Your name
Your email address
Answer