Соединение Websocket - клиент пытается получить подтверждение TLS для одного адреса, но не для другого - PullRequest
Новая
       14

Соединение Websocket - клиент пытается получить подтверждение TLS для одного адреса, но не для другого

0 голосов
/ 01 апреля 2020

У меня есть настройка, которая включает устройства, подключающиеся к серверу через веб-сокеты. Я испытываю странную проблему, когда они могут без проблем подключиться к одному тестовому серверу, но не могут подключиться к другому серверу (расположенному на Azure).

Я установил Wireshark на них обоих, и можно наблюдать как успешное соединение, так и неудачное соединение. Похоже, что неудачный пытается инициировать SSL-рукопожатие.

Вот успешное соединение:

enter image description here

Вот неудачное соединение:

enter image description here

Похоже, что клиент при успешном соединении просто устанавливает веб-сокет HTTP, но при неудачной установке он пытается установить до безопасного соединения. Почему клиент устанавливает различные соединения в зависимости от адреса сервера?

Код клиента для создания веб-сокета - просто javascript, вызывая new Websocket(address), и в обоих случаях адрес начинается с 'ws префикс.

Я провел дополнительное расследование и обнаружил еще одно странное поведение. Так получилось, что два доменных имени указывают на один и тот же сервер.

Если я использовал доменное имя с доменом верхнего уровня "com" (XXXX.australiaeast.cloudapp. azure .com), то соединение работает.

Если я использовал доменное имя с доменом верхнего уровня "dev" (comutername.mydomainname.dev), то соединение завершится неудачно со странным пакетом TLSV1.

Оба работают хорошо, если я запускаю тот же код клиента в браузере Microsoft Edge.

Это, кажется, дефект в реализации Chrome API WebScoket

Я опубликовал здесь дефект, давайте посмотрим, как это происходит. https://bugs.chromium.org/p/chromium/issues/detail?id=1067076

1 Ответ

0 голосов
/ 03 апреля 2020

Проблема в игре: HTTP Strict Transport Security (HSTS)

Браузер может быть настроен так, чтобы к некоторым доменам была присоединена политика HSTS, то есть любая небезопасная ссылка будет автоматически преобразуется в защищенную ссылку.

Эта политика будет применяться, если запрос возвращает заголовок Strict-Transport-Security. Но, что важно, браузеры Chrome и Firefox автоматически применяют политику ко всем dev доменам.

Похоже, что до недавнего времени Chrome браузер и Chrome ОС не соблюдает политику в отношении соединений WebSocket. Это изменилось, и теперь WebSockets будет соблюдать политику HSTS.

В результате, если у вас есть веб-сокет, использующий протокол ws, а не протокол wss, и он находится в домене .dev, Ваш браузер Chrome и Firefox не сможет подключиться к нему.

...