Изобретают ли WebSockets колесо?

#networking #html #websocket

#сеть #HTML #websocket

Вопрос:

Поправьте меня, если я ошибаюсь…

  1. Мы внедрили брандмауэры, чтобы ограничить доступ в Интернет для своих корпоративных сотрудников (и косвенно «защитить» домашних пользователей)
  2. Теперь WebSockets позволяет приложениям туннелировать любую связь через порт 80.

В чем смысл? Брандмауэры вообще не должны были быть изобретены? Если, как я ожидаю, брандмауэры начнут блокировать все коммуникации Websockets, какой смысл вводить их в первую очередь?

ОБНОВЛЕНИЕ: моя ошибка. У меня создалось ложное впечатление, что WebSockets допускает туннелирование с произвольной переадресацией портов через порт 80. Это не так. Веб-сокеты имеют дело исключительно с открытием полнодуплексной связи через порт 80.

Ответ №1:

Веб-сокеты не предназначены для удобства администраторов корпоративной безопасности, они предназначены для обеспечения быстрой связи с браузером <-> сервером; таким образом, точка зрения, с которой вы задаете этот вопрос, неверна; Веб-сокеты отлично подходят для своего назначения, и большая часть Интернета не находится за корпоративным брандмауэром.

Многие корпорации в настоящее время разрешают зашифрованное туннелирование произвольных данных в Интернет в любом случае, так что в этом нет ничего нового. Риск утечки данных через WebSockets и необходимые контрмеры по-прежнему будут зависеть от суждений отдельных администраторов безопасности, основанных на уровне доверия, которое они испытывают к своим сотрудникам, и чувствительности корпоративных данных, к которым у них есть доступ.

Комментарии:

1. 1, с незначительным недостатком: WebSockets обеспечит быстрые соединения в смысле задержки. Веб-сокеты не будут иметь значительного преимущества перед HTTP в пропускной способности (меньшие накладные расходы незначительны при больших передачах).

2. Разве веб-сокеты не позволяют вам туннелировать связь с произвольными портами через порт 80? То есть, не перенаправляют ли WebSockets обмен данными на локальные порты, которые обычно блокируются брандмауэром?

3. @Gill. Не больше, чем AJAX уже делает. В этом и заключается цель рукопожатия WebSockets — обеспечить соблюдение ограничений безопасности из разных источников. Javascript на странице может запрашивать соединение с произвольным хостом (точно так же, как запрос AJAX), но Javascript не может подделать исходный заголовок (это устанавливает только браузер). Веб-серверы внутри сети (где запущен браузер) могут отказываться от нелокальных источников. Другие службы внутри сети откажутся от периода подключения из-за HTTP-подобного подтверждения связи (точно так же, как при запросе AJAX).

Ответ №2:

Мы внедрили брандмауэры, чтобы ограничить доступ в Интернет для своих корпоративных сотрудников (и косвенно «защитить» домашних пользователей)

Брандмауэры не были введены для ограничения активности внутренней части сети (хотя их можно использовать таким образом). Брандмауэры были созданы для предотвращения вторжений извне сети.

Теперь WebSockets позволяет приложениям туннелировать любую связь через порт 80.

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

Наверное, я действительно не понимаю, почему вы думаете, что корпоративные сети будут блокировать трафик WebSocket. Все, что делает WebSocket, — это обеспечивает эффективное полнодуплексное соединение между веб-браузером и сервером.

Комментарии:

1. Разве веб-сокеты не позволяют вам туннелировать связь с произвольными портами через порт 80? То есть, не перенаправляют ли WebSockets обмен данными на локальные порты, которые обычно блокируются брандмауэром?

2. @Gili: Насколько я знаю, не предусмотрена произвольная переадресация портов. Я совершенно уверен, что это просто позволяет устанавливать соединение между сервером и браузером в полнодуплексном режиме.

3. Моя ошибка. Спасибо за разъяснение по поводу переадресации портов.

Ответ №3:

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

Итак, да. Брандмауэры никогда не должны были изобретаться, и изобретатели должны были предвидеть изобретение websockets или чего-либо, что использует надежный транспорт, который в этом примере имеет порт 80.

Отвечая на ваш актуальный вопрос, websockets — это просто еще один уровень абстракции другого типа в вашей сети. Скорее всего, они не заменяют обычные сокеты в зависимости от соответствующего программного обеспечения.

Изобретение колеса — любимое времяпрепровождение разработчиков, особенно тех, кто не является разработчиками, ставшими веб-разработчиками. Я предполагаю, что это облегчает боль от необоснованного комплекса неполноценности, вызванного осознанием того, что базовая компьютерная грамотность — это не то же самое, что умение программировать.

Комментарии:

1. -1 За предположение, что брандмауэры вообще не следовало изобретать.

2. -1 за предположение, что WebSockets являются низшей реализацией чего-то, что уже существует, без ссылки на предыдущее эквивалентное решение и без предоставления доказательств в его пользу. И если вы подразумеваете, что сокеты являются превосходным предыдущим изобретением, вы когда-нибудь пробовали создавать необработанные сокеты из браузера? Вы не можете. Даже с Flash вам все равно нужно иметь сервер политики, работающий на целевом сервере для обеспечения безопасности origin (websockets делает это встроенным с рукопожатием). И самая похожая из доступных вещей, Comet, отличается более высокими накладными расходами, более высокой задержкой и более сложной в использовании.

3. @kanaka, я полагаю, artificialidiot говорит, что WebSockets — это переосмысление обычных сокетов, и нет очевидного преимущества внедрения WebSockets по сравнению с простым предоставлением нам доступа к обычным сокетам вместо этого.

4. @Gill, необработанные подключения к сокетам из браузера без проверки перекрестного происхождения (CORS) и без защитного рукопожатия полностью запрещены. Представьте сценарий, в котором Javascript может инициировать необработанные соединения с сокетами: кто-то внедряет вредоносную рекламу Javascript в cnn.com , yahoo.com (или где бы то ни было). Javascript подключается к частной интрасети вашей компании, файловому серверу, выберите свой частный сервис. Больше никаких секретов. WebSockets предоставляет браузерам почти все преимущества необработанных сокетов (низкая задержка, двунаправленность), не создавая дыру размером с Техас в доменах интернет-безопасности.

5. @artificialidiot: Я увидел это, подумал, не сарказм ли это, затем понадеялся, что кто-то, кто размещает ответы на сайте вопросов и ответ, где люди, задающие вопросы, хотят получить реальный и правдивый ответ, не будет использовать сарказм, не заявив об этом явно.