One reason you can tell your friends like you: They will share packets with you :) . One such friend sent me an interesting packet capture this weekend: And SSH "Protocol Mismatch Error" in response to an SSL Client Hello. That's right: Somehow, SSH and SSL streams got mixed.

Here is the Wireshark TCP stream:

Odd... To protect the innocent, I removed the host name of the website that created the error. Interestingly, this issue only showed up with Edge on Windows 10, not with Safari on macOS. Both browsers eventually connected to the site, but there was a noticeable delay in the response for Edge/Win10.

Windows 10 just sent a second client hello after the first one failed:

The different: The first client hello only allowed for TLS 1.2, while the second client hello was version tolerant and allowed for TLS 1.0-1.2. Safari on the other hand only sent the "version tolerant" client hello. I wasn't quite able to use openssl to recreate the client hello as "tight" as Windows 10 does. But this was the only significant difference between the two Client Hellos. APNS, SNI and other option didn't seem to matter.

So what is happening here?

This is not malicious behavior in this case. instead, the server is running behind a multiplexer like sslh [1] or haproxy [2]. In this case, after contacting the owner of the site, it turned out to be haproxy. It profiles incoming requests and then sends them to one out of various servers. By default, if it doesn't recognize the request, it forwards it to an ssh server. The goal of this tool is to allow someone to run multiple servers on port 443 to be able to connect to them from behind corporate firewalls that only allow outbound port 443 traffic.

The version of haproxy apparently doesn't support TLS 1.2 yet, and as a result redirects the rather strict Windows 10 requests to SSH, the default option. Windows 10 on the other hand realizes that TLS 1.2 isn't universally supported yet, and downgrades if the initial client hello fails.

Could a configuration like this be malicious? Sure. A setup like this could be used to exfiltrate data "stealthy" over port 443. But like my friend, many networks watch for things like ssh banners on odd ports.

Got any other explanations? Please let me know. For a packet capture of this activity, see https://isc.sans.edu/diaryimages/haproxy_capture.pcap (haproxy is listening on port 8443 in this case)

[1] http://www.rutschle.net/tech/sslh.shtml
[2] http://www.haproxy.org

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn