Грешка каже “погрешна верзија”, па је примамљиво почети мењати TLS верзије. Уз прокси проверите ранију могућност: је ли клијент послао TLS руковање на порт који је чекао обичан HTTP?

Одредиште попут https://example.com/ и прокси попут http://proxy.example:8080 обичан су пар. Промена другог URL-а у HTTPS говори клијенту да шифрује разговор са самим проксијем. То није упутство да се дозволе HTTPS странице.

Пронађите први TLS разговор

Код HTTP проксија клијент најпре може послати CONNECT и примити HTTP одговор. Тек тада започиње TLS одредишта унутар тунела. Код HTTPS проксија прво долази засебна TLS веза према проксију.

TLS рашчлањивач који прими HTTP страницу грешке или други обичан текст може пријавити грешку протокола. Формулација не утврђује које TLS верзије страница подржава, нити да је страница уопште контактирана.

  1. Забележите URL проксија, укључујући његову шему, и документовани протокол завршне тачке.
  2. Утврдите да ли је до квара дошло пре CONNECT одговора, током TLS-а одредишта или током провере властитог сертификата проксија.
  3. Проверите стварне верзије клијента и зависности кад упоређујете старо заобилазно решење. Раније имплементације проксија понекад су другачије третирале шему.

Неколико исправки може бити погрешно из различитих разлога. Списак HTTP проксија нуди обичне кандидате завршне тачке HTTP за јавне захтеве дозвољене тим путем. Обична HTTP завршна тачка треба шему HTTP проксија; истински TLS-омогућена завршна тачка треба да задржи HTTPS и проверу сертификата. Прокси који одбија CONNECT треба подржану услугу или правило, а не произвољно снижавање библиотеке.

Задржите први уочљиви квар. Искључивање провере сертификата не може натерати сервер који говори само HTTP да говори TLS, а избор старе шифарске политике не може објаснити HTTP одбијање послато пре руковања са страницом.

Повезани чланци