CODEWITHSUNDEEP
c#sslhandshakehandshaking
user10641370
user10641370

Reputation:

Possible Long Handshake Intolerance Issue with AuthenticateAsClient?

I believe SslStream.AuthenticateAsClient suffers from the Long Handshake Intolerance issue documented by ssllabs here on GitHub.

I have tried for almost 2 years to figure out the problem and by chance I was debugging with Fiddler and read its log tab and saw it was listing

Warning: ClientHello record was X bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance

I believe AuthenticateAsClient (perhaps even AuthenticateAsServer) is prone to this bug/issue as it's simply the only possible reason I have of why im constantly getting exceptions almost randomly, even when using the same IP's, Proxy, Proxy Type and destination request.

try {
  sslStream.AuthenticateAsClient(Host, null, false);
  authenticated = sslStream.IsAuthenticated;
} catch (Exception ex) {
  if ((Marshal.GetHRForException(ex) & 0xFFFF) == 5664) {
    //Authentication failed because the remote party has closed the transport stream.
  }
  //As well as "The handshake failed due to an unexpected packet format."
}

There are 2 common errors I receive, The one with Marshal of 5664 and "The handshake failed due to an unexpected packet format." which is the one I believe to be related to this 255 bytes issue.

Im not fully sure on ways to debug this so im asking here for guidence.

Update:

Just got a confirmed reproducable instance, it seems to always or atleast most of the time happen when you have a SOCKS4 Proxy but try make the request by sending SOCKS5 negotiation, perhaps theres a way to test if the proxy is SOCKS4 or 5?

Update 2:

So im testing a SOCKS4 by correctly using SOCKS4 negotiation and I see that its often returning a status byte of 0x5A (Success) but maybe 20% of the time it returns a 4 byte array of just full 0x00's (nulls), for the first, third and fourth byte it would essentially be ignored but the fact that the 2nd byte (status byte) is returning 0x00 even though thats not even documented according to wikipedia is a bit weird.

Update 3:

Just to clarify im testing via publicly available free proxies. Coincidentally all 3 of the proxies that seem to be having issues are mostly port 4145 and with a bit of research it seems to be a common proxy port on Microtik routers, shockinly if I go to port :80 one one of these proxies, it presents me a routers default gateway login presented with a Microtik logo. All 3 of these proxies when requested via a browser to port 4145 say Returned no data, so im assuming all 3 of these are Microtik as all evidence points to it.

Upvotes: 0

Views: 612

Answers (0)

Related Questions