Қате “қате нұсқа” дейді, сондықтан TLS нұсқаларын ауыстыра бастау азғырады. Проксимен болса, бұрынғы мүмкіндікті тексеріңіз: клиент қарапайым HTTP күтіп тұрған портқа TLS қол алысуды жіберді ме?

https://example.com/ сияқты мақсат пен http://proxy.example:8080 сияқты прокси қарапайым жұп. Екінші URL-ді HTTPS-ке өзгерту клиентке өз әңгімесін проксидің өзімен шифрлауды айтады. Бұл HTTPS сайттарына рұқсат беру нұсқауы емес.

Алғашқы TLS әңгімесін табыңыз

HTTP проксиде клиент алдымен CONNECT жіберіп, HTTP жауабын ала алады. Содан кейін ғана туннельдің ішінде мақсаттың TLS-ін бастайды. HTTPS проксиде алдымен проксиге жеке TLS қосылымы келеді.

HTTP қате бетін немесе басқа ашық мәтінді алған TLS талдағышы протокол қатесін хабарлауы мүмкін. Бұл тұжырым сайттың қандай TLS нұсқаларын қолдайтынын, тіпті сайтпен байланыс болғанын да дәлелдемейді.

  1. Проксидің URL-ін схемасымен бірге және соңғы нүктенің құжатталған протоколын жазып алыңыз.
  2. Сәтсіздік CONNECT жауабына дейін, мақсаттың TLS-і кезінде немесе проксидің өз сертификатын тексеру кезінде болғанын анықтаңыз.
  3. Ескі айналып өту шешімін салыстырғанда клиент пен тәуелділіктердің нақты нұсқаларын тексеріңіз. Бұрынғы прокси іске асырулары схеманы кейде басқаша қарастырды.

Бірнеше түзету әртүрлі себептермен қате болуы мүмкін. HTTP проксилер тізімі осындай бағыт арқылы рұқсат етілген жария сұраныстар үшін қарапайым HTTP соңғы нүкте үміткерлерін ұсынады. Қарапайым HTTP соңғы нүктеге HTTP прокси схемасы қажет; шынымен TLS қосылған соңғы нүкте HTTPS пен сертификат тексеруін сақтауы керек. CONNECT-ті қабылдамайтын проксиге қолдау көрсетілген қызмет немесе саясат қажет, кітапхананы қалауынша төмендету емес.

Алғашқы байқалатын сәтсіздікті ұстап тұрыңыз. Сертификат тексеруін өшіру тек HTTP сөйлейтін тыңдаушыны TLS сөйлете алмайды, ал ескі шифр саясатын таңдау сайттың қол алысуына дейін жіберілген HTTP бас тартуын түсіндіре алмайды.

Қатысты мақалалар