Я считаю, что SslStream.AuthenticateAsClient страдает от проблемы Long Handshake Intolerance, задокументированной ssllabs здесь на GitHub.
Я пытался выяснить проблему в течение почти 2 лет, и случайно отладил 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 Type и запрос назначения.
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% случаев он возвращает массив из 4 байтов только полных 0x00 (нулей), для первый, третий и четвертый байт, по сути, будут игнорироваться, но тот факт, что 2-й байт (байт состояния) возвращает 0x00, хотя это даже не задокументировано в соответствии с википедией, немного странно.
Обновление 3:
Просто чтобы уточнить, что я тестирую через общедоступные бесплатные прокси. По совпадению все 3 прокси, которые, кажется, имеют проблемы, являются главным образом портом 4145, и с небольшим исследованием это, кажется, является общим портом прокси на маршрутизаторах Microtik, шокирует, если я иду в порт: 80 один из этих прокси, он представляет мне имя входа шлюза по умолчанию маршрутизаторов представлено с логотипом Microtik.
Все 3 из этих прокси-серверов при запросе через браузер к порту 4145 говорят, что не возвращали никаких данных, поэтому я предполагаю, что все 3 из них являются Microtik, поскольку все доказательства указывают на это.