Веб-сокеты и безопасность
Я хочу разместить некоторые приложения на основе веб-сокетов, которые должны быть доступны только через страницу https. Таким образом, сервер генерирует страницу https со случайным ключом внутри. Я хочу использовать этот ключ, чтобы защитить кого-то извне от косвенного доступа к веб-сокетам.
Я мог бы заставить каждого клиента веб-сокета отправлять ключ на серверы веб-сокетов и закрывать соединение, если ключ не совпадает. Однако я предпочел бы обновить сами веб-сокеты, чтобы передать ключ, и автоматически отклонить соединение, если ключ не совпадает. (таким образом, если будет представлено новое приложение, нет шансов забыть осуществить проверку).
Я осмотрелся и не нашел много подробной документации о том, как работают веб-сокеты.
Первоначальное рукопожатие соединения wss отправляется открытым текстом (если я прикреплю ключ к этим пакетам, может ли человек в середине перехватить их?). Если нет, есть ли стандартный способ отправки метаданных такого типа по соединению, или я должен просто взломать исходные файлы websocket?
Я использую libwebsockets на стороне сервера и jquery.websockets на стороне клиента.
1 ответ
Безопасные соединения WebSocket обновляются только после установления безопасного соединения:
Если /secure/ имеет значение true, клиент ДОЛЖЕН выполнить TLS-квитирование по соединению после его открытия и перед отправкой данных о квитировании [RFC2818]. Если это не удается (например, сертификат сервера не может быть проверен), тогда клиент ДОЛЖЕН завершить соединение WebSocket и прервать соединение. В противном случае вся дальнейшая связь по этому каналу ДОЛЖНА выполняться через зашифрованный туннель [RFC5246].
Клиенты ДОЛЖНЫ использовать расширение индикации имени сервера в квитировании TLS [RFC6066].
На стороне клиента WebSocket интерфейс предоставляется браузером - к тому времени, когда вы добираетесь до onopen Событие рукопожатие уже завершено. Вы можете положить ключ в protocol, но это определенно будет взломать (так как protocol предназначен для использования в реальных зарегистрированных протоколах, а не в механизмах аутентификации).
Альтернативой является просто обернуть WebSocket в вашу собственную библиотеку, которая обрабатывает обмен ключами в первом сообщении, чтобы вашему прикладному уровню не пришлось беспокоиться о деталях.