Polling server connection fails on private collaborator instance
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?
Thanks for this report Floyd. Could you scale back to 2.0.13 and let us know if the issue persists?
Thanks Floyd. We’ve added this to our development backlog to investigate further.
Just updated to Burp v2.1 and the bug is still present. I really feel bad about polling over HTTP :(
We don’t have a ETA for this issue unfortunately.
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.
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.