Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

SSL peer shut down incorrectly / WebSockets not upgrading

Scott | Last updated: Feb 11, 2016 12:19AM UTC

TL;DR - The default setting for 'Set "Connection close" on incoming requests', introduced in v1.6.32 should be disabled by default because it seems to break websockets. I had an issue that took me quite a while to figure out, so I thought I'd share here in hopes that this will save others time. I ran into two issues when using recent versions of Burp, specifically v1.6.36: 1) Attempting to intercept traffic against my application would result in an error "SSL peer shut down incorrectly". This would happen on every other request, maybe more often. I tried using the debugging options of Java ( java -Djavax.net.debug=ssl:handshake:verbose -jar burpsuite_pro_v1.6.36.jar) but its incredibly verbose and the only additional information that seemed relevant was: > pool-4-thread-377, SEND TLSv1.2 ALERT: fatal, description = unexpected_message Unfortunately, I didn't know what to do next. The only thing I knew was that I didn't get the error in v1.6.31, so after looking at various configuration differences such as the cipher suites, I finally looked at the release logs and found my solution (see below). 2) Independently, on a different application, I noticed that attempting to use websocket connections on new versions greater than v1.6.31 of Burp Suite seemed to break and I no longer saw the websocket messages in their tab. I did see something like them in the HTTP History tab, but I suspect this was a fall back to a non websocket version. SOLUTION These two issues are both caused by a change in v1.6.32, from http://releases.portswigger.net/2015/12/1632.html: > There is a new option in the Proxy to set the "Connection: close" header on incoming requests. Setting this header in requests can speed up the processing of the resulting responses from some target servers. The new option is on by default. So, if you are having similar problems, go to Proxy -> Options -> then at the bottom of the page under Miscelleneous disable 'Set "Connection close" on incoming requests'. I'm not totally sure why this fixes the first problem. I'm guessing that since the browser is sending requests with 'Connection: keep-alive' it assumes the connection is still open, but the server is getting the overwritten 'Connection: close' requests and this it kills the connection without the browser realizing? Regarding websockets, when a websocket connection is made, the header 'Connection: upgrade' is sent. If this is overwritten, I suspect apps can never upgrade to a websocket connection. Given this, I'd recommend the default setting for 'Set "Connection close" on incoming requests' should be disabled by default.

PortSwigger Agent | Last updated: Feb 11, 2016 09:57AM UTC

We actually fixed the "Connection: close" option in 1.6.36 so that it doesn't add the header on a WebSockets negotiation request. WIth the latest version of Burp you can leave the default option on and WebSockets should still work. Regarding the SSL negotiation problem, have a look at the options at Options / SSL / SSL Negotiation / SSL Negotiation Workarounds, and see if they help with the issue.

Burp User | Last updated: Feb 11, 2016 08:11PM UTC

Thanks Dafydd! Glad to hear the WebSockets issue was resolved in 1.6.36. I must have been using an earlier version when I saw that behavior. Regarding the SSL negotiation workarounds, I just tried going through all 16 permutations of the settings, including restarting Burp as needed, and nothing solved my problem. However, to be clear, disabling 'Set "Connection close" on incoming requests' did resolve my issue. So, I'll just stick with that. Also, I'd just like to say that I can't thank you enough for building such a fantastic tool! I've been a fan of Burp for many years. Cheers!

PortSwigger Agent | Last updated: Feb 12, 2016 09:11AM UTC

Thanks for the follow up. That's interesting that the "Connection: close" header is sometimes causing SSL failures. We hadn't anticipated that possible fall-out. If you're able to share with us (via private email) the domain name where this behavior was observed, we can investigate and look for a workaround.

Burp User | Last updated: Oct 18, 2016 12:48PM UTC

My WEB application uses LONG POLLING. While sending traff via burp my WEB UI app doen't work. I think issure related to handling headers Connection: Keep-alive sent from browser and Connection: close received from server. I tried to disable option "Set Connction close for incoming requests" but it didn't help. I checked in wireshark, looks like burp closing TCP connection after receiving HTTP response. (TCP connection is closed by server if burp is not used)

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