Question

我相信SslStream.AuthenticateAsClient受到ssllabs here在GitHub上记录的Long Handshake Intolerance问题的困扰。

我已经尝试了将近两年的时间来解决问题，并且偶然地我正在Fiddler进行调试，并阅读了其日志标签并看到了它的清单

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

我相信AuthenticateAsClient（也许甚至AuthenticateAsServer）也容易出现此错误/问题，因为这只是我一直不断地随机获取异常的唯一可能原因，即使使用相同的IP，Proxy，Proxy类型和目的地请求。

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."
}

我收到2个常见错误，一个是5664的元帅，另一个是“由于意外的数据包格式，握手失败。”我认为这与这255个字节的问题有关。

我不确定如何调试此方法，因此请在这里寻求指导。

更新：

只有一个已确认的可重现实例，当您拥有SOCKS4代理但通过发送SOCKS5协商尝试发出请求时，似乎大多数时候或总是至少发生一次，也许有一种方法可以测试代理是SOCKS4还是5 ？

更新2：

因此，我通过正确地使用SOCKS4协商来测试SOCKS4，我发现它通常返回状态字节0x5A（成功），但可能有20％的时间返回仅充满0x00（空）的4字节数组。第一个，第三个和第四个字节实际上将被忽略，但是第二个字节（状态字节）返回0x00的事实，即使根据维基百科甚至都没有记录，这有点奇怪。

更新3：

仅通过公开提供的免费代理来澄清即时测试。巧合的是，似乎有问题的所有3个代理都大多是端口4145，并且经过一点研究，它似乎是Microtik路由器上的通用代理端口，令人震惊的是，如果我转至端口：80，则代表其中之一我是带有Microtik徽标的路由器默认网关登录名。当通过浏览器请求到端口4145时，所有这三个代理均未返回任何数据，因此，我假设所有这三个代理均是Microtik，因为所有证据均指向该代理。

AuthenticateAsClient是否可能出现长时间握手不兼容问题？

更新：

更新2：

更新3：

0 个答案: