WRONG_VERSION_NUMBER із проксі: перевірте HTTP і HTTPS

Помилка каже “неправильна версія”, тож хочеться почати перебирати версії 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, надіслану до рукостискання сайту.