WSS протокол

Библиотека STOMP.js поддерживает работу поверх WebSocket и Secure WebSocket. В обычной конфигурации соединение устанавливается через ws://, а при использовании TLS-шифрования применяется wss://.

Пример адреса подключения:

const client = new Client({
    brokerURL: 'wss://broker.example.com/ws'
});

Протокол WSS представляет собой WebSocket поверх TLS. По аналогии с HTTPS он обеспечивает:

  • шифрование трафика;
  • защиту от перехвата данных;
  • проверку подлинности сервера;
  • защиту от MITM-атак;
  • безопасную передачу токенов и cookie.

Для STOMP.js использование WSS особенно важно при работе:

  • с авторизацией;
  • с JWT-токенами;
  • с пользовательскими сообщениями;
  • с финансовыми системами;
  • с административными панелями;
  • с приватными очередями;
  • с браузерными приложениями в production-среде.

Различия между WS и WSS

WS

Обычный WebSocket без шифрования.

ws://example.com/socket

Особенности:

  • данные передаются открыто;
  • трафик может быть перехвачен;
  • браузеры ограничивают использование на HTTPS-сайтах;
  • не подходит для production.

WSS

Защищённый WebSocket.

wss://example.com/socket

Особенности:

  • используется TLS;
  • весь трафик зашифрован;
  • браузеры считают соединение безопасным;
  • поддерживается современными инфраструктурами;
  • обязателен для HTTPS-приложений.

Почему HTTPS требует WSS

Современные браузеры блокируют небезопасные WebSocket-соединения на HTTPS-страницах.

Например:

https://app.example.com

не сможет открыть:

ws://broker.example.com/ws

Браузер выдаст ошибку Mixed Content.

Корректный вариант:

wss://broker.example.com/ws

Это правило безопасности действует в:

  • Chrome;
  • Firefox;
  • Safari;
  • Edge;
  • мобильных браузерах.

Подключение STOMP.js через WSS

Базовая конфигурация

import { Client } from '@stomp/stompjs';

const client = new Client({
    brokerURL: 'wss://broker.example.com/ws',

    reconnectDelay: 5000,

    heartbeatIncoming: 4000,
    heartbeatOutgoing: 4000
});

client.activate();

Использование connectHeaders

При WSS часто используются токены авторизации.

const client = new Client({
    brokerURL: 'wss://broker.example.com/ws',

    connectHeaders: {
        Authorization: 'Bearer TOKEN_VALUE'
    }
});

Часто применяются:

Заголовок Назначение
Authorization JWT или Bearer Token
login Имя пользователя
passcode Пароль
tenant-id Идентификатор арендатора
x-api-key API-ключ

Работа TLS в WSS

При установке WSS-соединения выполняется TLS Handshake.

Этапы:

  1. Клиент подключается к серверу.
  2. Сервер отправляет сертификат.
  3. Браузер проверяет сертификат.
  4. Формируется общий ключ шифрования.
  5. Создаётся безопасный канал.
  6. Начинается WebSocket-коммуникация.
  7. STOMP.js запускает STOMP-фреймы.

Что шифруется при WSS

Шифруется весь WebSocket-трафик:

  • STOMP-команды;
  • заголовки;
  • body сообщений;
  • heartbeat-пакеты;
  • подписки;
  • ACK/NACK;
  • токены;
  • cookie;
  • session-id.

Например, такой пакет:

SEND
destination:/topic/chat

Hello

в сети передаётся в зашифрованном виде.

Использование SockJS с WSS

SockJS также поддерживает защищённые соединения.

import SockJS from 'sockjs-client';
import { Client } from '@stomp/stompjs';

const socket = new SockJS('https://broker.example.com/stomp');

const client = new Client({
    webSocketFactory: () => socket
});

SockJS самостоятельно использует HTTPS и безопасные транспорты.

Автоматический выбор транспорта

SockJS может переключаться между:

  • WebSocket;
  • XHR-streaming;
  • XHR-polling;
  • EventSource.

Если основной транспорт работает через HTTPS, соединение также остаётся защищённым.

Сертификаты TLS

Для работы WSS сервер должен иметь TLS-сертификат.

Наиболее распространённые варианты:

Тип Описание
Let’s Encrypt Бесплатный сертификат
Wildcard Для поддоменов
EV SSL Расширенная проверка
Self-Signed Самоподписанный сертификат

Проблемы self-signed сертификатов

Браузеры обычно блокируют self-signed сертификаты.

Типичная ошибка:

WebSocket connection failed

или:

NET::ERR_CERT_AUTHORITY_INVALID

В production self-signed сертификаты использовать не рекомендуется.

Проверка соединения

Проверка в DevTools

Вкладка:

Network → WS

позволяет увидеть:

  • успешное подключение;
  • статус 101 Switching Protocols;
  • STOMP-фреймы;
  • heartbeat;
  • ошибки соединения.

Проверка TLS

В браузере можно проверить:

  • валидность сертификата;
  • цепочку доверия;
  • дату истечения;
  • используемый TLS;
  • cipher suite.

Использование reverse proxy

Часто WSS завершается на reverse proxy:

  • Nginx;
  • HAProxy;
  • Traefik;
  • Apache;
  • Envoy.

После этого трафик передаётся брокеру.

Схема:

Browser
   ↓
WSS
   ↓
Nginx
   ↓
WS
   ↓
RabbitMQ / ActiveMQ

Конфигурация Nginx для WSS

Пример proxy-конфигурации:

server {
    listen 443 ssl;
    server_name broker.example.com;

    ssl_certificate /etc/ssl/fullchain.pem;
    ssl_certificate_key /etc/ssl/private.key;

    location /ws {
        proxy_pass http://localhost:15674/ws;

        proxy_http_version 1.1;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";

        proxy_set_header Host $host;
    }
}

Upgrade-заголовки

Для WebSocket необходим HTTP Upgrade.

Ключевые заголовки:

Upgrade: websocket
Connection: Upgrade

Без них WebSocket не установится.

Порты WSS

Стандартный порт:

443

Также могут использоваться:

Порт Назначение
443 HTTPS/WSS
8443 Альтернативный TLS
15671 RabbitMQ TLS
61614 ActiveMQ SSL

Heartbeat через WSS

Heartbeat работает поверх защищённого канала.

const client = new Client({
    brokerURL: 'wss://broker.example.com/ws',

    heartbeatIncoming: 10000,
    heartbeatOutgoing: 10000
});

Heartbeat-пакеты также шифруются TLS.

Переподключение при WSS

Автоматический reconnect полностью поддерживается.

const client = new Client({
    brokerURL: 'wss://broker.example.com/ws',

    reconnectDelay: 5000
});

При временной потере сети клиент создаёт новое TLS-соединение.

Типичные ошибки WSS

Неверный сертификат

Ошибка:

ERR_CERT_COMMON_NAME_INVALID

Причина:

  • домен не совпадает с сертификатом.

Истёкший сертификат

Ошибка:

ERR_CERT_DATE_INVALID

Причина:

  • сертификат просрочен.

Mixed Content

Ошибка:

Mixed Content: The page was loaded over HTTPS...

Причина:

  • попытка подключения через ws://.

Ошибка upgrade

Ошибка:

Unexpected response code: 400

Причины:

  • reverse proxy не поддерживает Upgrade;
  • отсутствуют заголовки;
  • неверный location.

TLS handshake failed

Причины:

  • неподдерживаемая версия TLS;
  • проблемы cipher suite;
  • старый браузер;
  • неверная SSL-конфигурация.

Использование JWT через WSS

Очень распространённая схема:

const client = new Client({
    brokerURL: 'wss://broker.example.com/ws',

    connectHeaders: {
        Authorization: `Bearer ${token}`
    }
});

Поскольку WSS шифрует канал, токен защищён от перехвата.

Cookie также могут использоваться для аутентификации.

Особенно важны флаги:

Secure
HttpOnly
SameSite

Secure требует HTTPS/WSS.

Производительность WSS

TLS добавляет накладные расходы:

  • TLS Handshake;
  • шифрование;
  • дешифрование;
  • управление сертификатами.

Однако в современных системах влияние обычно минимально.

Session Resumption

TLS поддерживает повторное использование сессий.

Это уменьшает:

  • время переподключения;
  • нагрузку CPU;
  • задержки reconnect.

HTTP/2 и WSS

WebSocket не использует HTTP/2 напрямую.

Обычно схема выглядит так:

HTTPS → HTTP/2
WSS → HTTP/1.1 Upgrade

Это нормальное поведение.

Балансировщики нагрузки

При работе WSS часто используются:

  • AWS ELB;
  • Nginx;
  • Cloudflare;
  • HAProxy;
  • Kubernetes Ingress.

Важно поддерживать:

  • sticky sessions;
  • WebSocket Upgrade;
  • long-lived connections.

Таймауты proxy

Reverse proxy может закрывать соединения.

Типичные параметры:

proxy_read_timeout 3600;
proxy_send_timeout 3600;

Без увеличения timeout соединения будут неожиданно разрываться.

Cloudflare и WSS

Cloudflare поддерживает WebSocket Proxying.

Особенности:

  • автоматический TLS;
  • защита DDoS;
  • CDN;
  • WAF;
  • SSL termination.

Безопасность STOMP-фреймов

Даже при использовании WSS необходимо:

  • валидировать входящие сообщения;
  • ограничивать размер payload;
  • фильтровать заголовки;
  • проверять авторизацию;
  • ограничивать подписки.

WSS защищает транспорт, но не бизнес-логику.

Ограничение размера сообщений

Пример серверных ограничений:

  • RabbitMQ frame_max;
  • Spring WebSocket limits;
  • ActiveMQ transport limits.

Это защищает систему от:

  • memory overflow;
  • DoS-атак;
  • чрезмерной нагрузки.

CORS и WSS

Для браузерных WebSocket важны origin-политики.

Сервер может проверять:

Origin: https://app.example.com

И отклонять чужие домены.

CSP и WSS

Content Security Policy может блокировать WebSocket.

Пример разрешения:

connect-src 'self' wss://broker.example.com;

Использование STOMP.js в production через WSS

Типичная production-схема:

Frontend SPA
    ↓
WSS
    ↓
Nginx / Load Balancer
    ↓
RabbitMQ / ActiveMQ / Spring Broker

RabbitMQ и WSS

RabbitMQ Web STOMP поддерживает WSS.

Пример URL:

wss://rabbit.example.com/ws

Часто используется плагин:

rabbitmq_web_stomp

Spring Boot и WSS

Spring WebSocket также поддерживает TLS.

Конфигурация endpoint:

registry.addEndpoint("/ws")
        .setAllowedOriginPatterns("*");

После настройки HTTPS endpoint автоматически становится доступным через WSS.

ActiveMQ и WSS

ActiveMQ поддерживает SSL Transport Connector.

Пример:

<transportConnector
    name="secure-stomp"
    uri="stomp+ssl://0.0.0.0:61614"/>

Диагностика WSS-соединений

Полезные инструменты:

Инструмент Назначение
Chrome DevTools Анализ WebSocket
openssl Проверка TLS
wscat Тестирование WebSocket
Wireshark Анализ трафика
ss/netstat Проверка сокетов

Проверка WSS через wscat

Пример подключения:

wscat -c wss://broker.example.com/ws

Логирование STOMP.js

Для диагностики:

const client = new Client({
    brokerURL: 'wss://broker.example.com/ws',

    debug(str) {
        console.log(str);
    }
});

Логируются:

  • CONNECT;
  • CONNECTED;
  • SEND;
  • SUBSCRIBE;
  • ERROR;
  • heartbeat.

Безопасное хранение URL

Нежелательно жёстко кодировать адреса:

brokerURL: 'wss://prod.example.com/ws'

Обычно используются:

  • environment variables;
  • конфигурационные файлы;
  • runtime config;
  • Docker secrets.

Практика разделения окружений

Часто применяются разные endpoint:

Окружение URL
Development ws://localhost:8080/ws
Staging wss://staging.example.com/ws
Production wss://api.example.com/ws

Рекомендации по безопасности

Критически важные практики:

  • использовать только WSS в production;
  • отключать старые TLS-версии;
  • регулярно обновлять сертификаты;
  • использовать HSTS;
  • ограничивать Origin;
  • проверять JWT;
  • ограничивать payload;
  • включать rate limiting;
  • использовать reverse proxy;
  • мониторить reconnect storms;
  • логировать ошибки TLS;
  • использовать heartbeat.
Оглавление