Сокетное соединение с расширением Chrome блокируется прокси/брандмауэром

У меня есть веб-приложение в javascript, которое подключается к сокету с помощью socket.io и расширения Chrome, которое подключается таким же образом и к тому же серверу. Все работает нормально на большинстве компьютеров и подключений к Интернету, но на одном из компьютеров моего клиента не удается подключить расширение Chrome (веб-приложение успешно подключается).

Проверяя консоль расширения на наличие background.js (скрипт внутри расширения, создающий соединение сокета), я вижу, что он не пытается подключиться к правильному URL-адресу (моему серверу сокетов), а к неизвестному URL-адресу, который кажется прокси: https://gateway.zscloud.net/auT?origurl=http%3A%2F%2Fmy_socket_server_domain...

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

Опять же, это происходит только в контексте расширения Chrome. Тот же самый компьютер, использующий то же подключение к Интернету, успешно подключается с веб-страницы в том же браузере (Google Chrome).

Кто-нибудь знает, в чем может быть проблема? Клиент не знает о наличии защитного программного обеспечения (брандмауэра, антивируса и т. д.), которое может быть причиной этого, но это компьютер, управляемый его компанией, поэтому администратор мог сделать это за него. Однако, если это так, не должно ли быть также захвачено соединение с веб-страницы? Есть ли что-то особенное в подключениях к сокетам в расширениях Chrome, которые отличаются от обычных веб-приложений?

Спасибо!


person protozoo    schedule 17.08.2017    source источник


Ответы (1)


Соединения WebSocket отличаются от обычных HTTP-запросов; они требуют обновления протокола после установления того, что (некоторые!) прокси-серверы могут не поддерживать.

Я был в какой-то момент за одним таким (прозрачным) прокси на работе; однако он не пытается перехватить HTTPS, что означает, что я могу использовать wss: WebSockets, но не ws: WebSockets.

..который вы должны использовать в любом случае! С появлением на рынке Let's Encrypt порог входа для HTTPS очень низок. Если какие-либо конфиденциальные данные отправляются через это соединение, это в ваших же интересах.

К сведению, этот конкретный прокси-сервер является частью ZScaler, который является решением для обеспечения безопасности. К сожалению, он включает HTTPS MITM, поэтому описанное выше вряд ли решит проблему (но все равно должно быть реализовано!). Он настроен как прокси-сервер на уровне ОС — если этот параметр можно изменить или переопределить с помощью настроек прокси-сервера Chrome, это исправит его. Однако это разозлит сетевую безопасность!

Если вы не можете этого сделать, то ваш клиент является SOL и должен жаловаться по цепочке на то, что решение безопасности нарушает законные приложения.

Изменить: я огляделся и нашел это, который, кажется, утверждает, что использования SSL (то есть wss:) достаточно. Но это с 2012 года — возможно, до того, как ZScaler смог MITM весь HTTPS-трафик.

Должна быть возможность проверить, будет ли работать переключатель wss:, используя https://www.websocket.org/echo.html - если он сможет подключиться, то все будет работать через wss:

person Xan    schedule 17.08.2017
comment
Извините, забыл ответить на ваш ответ. Очень помогло, спасибо! - person protozoo; 14.09.2017