英文:

Secure WebSocket Server (TLS and wss)

问题

我在web服务器上运行一个静态HTTPS页面，提供有效的证书。在我的页面上，有一个创建WebSocket连接的JavaScript。

new WebSocket('wss://WebSocket服务器的IP');

websocket服务器收到的第一件事是来自客户端的请求。但请求本身是加密的！websocket服务器应该如何读取加密的请求？当Web客户端连接到HTTPS页面时，会进行TLS握手，以后的一切都是加密的，包括发送到websocket服务器的请求也是加密的。但独立运行的websocket服务器如何知道解密的密钥呢？wss WebSocket是否能正常工作？

以前一切（HTML页面和websocket服务器）都可以正常工作，当我使用HTTP和ws时。现在我必须切换到HTTPS和wss。

英文:

I run a static HTTPS page on a webserver providing a valid certificate. On my page, there is a JavaScript creating a websocket connection.

new WebSocket('wss://IpOfWebsocketServer');

The first thing the websocket server receives is a request from the client. But the request itself is encrypted! How should the websocket server read the encrypted request?? When a web client connects to the HTTPS page there is made a TLS handshake and everything later is encrypted - also the request to the websocket server is encrypted. But how should the separately running websocket server know the key to decrypt? Can wss websockets run at all?

Everything (HTML page and websocket server) worked fine earlier when I used HTTP and ws. Now I must switch to HTTPS and wss.

答案1

得分: 1

代码部分不需要翻译，以下是翻译好的内容：

The first thing the websocket server receives is a request from the client. But the request itself is encrypted! How should the websocket server read the encrypted request??

Websocket 服务器首先收到的是客户端的请求。但是请求本身是加密的！Websocket 服务器应该如何读取加密的请求？

The exact same way that an HTTPS server reads encrypted HTTP messages. A TLS session is established between client and server before any application data is exchanged. The TLS session decrypts any data being received, and encrypts any data being sent.

WebSocket 服务器读取加密的请求的方式与 HTTPS 服务器读取加密的 HTTP 消息的方式完全相同。在客户端和服务器之间在交换任何应用数据之前，都会建立一个 TLS 会话。TLS 会话会解密接收到的数据并加密发送的数据。

So, an HTTPS client connects to an HTTPS server, negotiates a TLS session first, and then exchanges HTTP messages that are encrypted/decrypted by that TLS session.

因此，HTTPS 客户端首先连接到 HTTPS 服务器，首先协商一个 TLS 会话，然后交换由该 TLS 会话加密/解密的 HTTP 消息。

The exact same thing happens with WebSockets, too. A WSS client connects to an WSS server, negotiates a TLS session first, then negotiates the WebSocket handshake using HTTP messages (encrypted by TLS), and then exchanges subsequent WebSocket messages (encrypted by TLS).

WebSockets 也是完全相同的情况。WSS 客户端连接到 WSS 服务器，首先协商一个 TLS 会话，然后使用由 TLS 加密的 HTTP 消息协商 WebSocket 握手，然后交换后续的 WebSocket 消息（由 TLS 加密）。

When a web client connects to the HTTPS page there is made a TLS handshake and everything later is encrypted

当 Web 客户端连接到 HTTPS 页面时，会进行 TLS 握手，随后的所有内容都会被加密。

The exact same thing happens for a secure WebSocket connection, too.

对于安全的 WebSocket 连接，情况也是完全相同的。

But how should the separately running websocket server know the key to decrypt?

但是，独立运行的 WebSocket 服务器应该如何知道解密的密钥？

It doesn't know the original key used by the TLS session of the HTTPS page, nor does it need to know. The WebSocket client will establish a separate TLS session with the WebSocket server, with its own key that only the WebSocket client and WebSocket server share with each other.

它不知道 HTTPS 页面的 TLS 会话使用的原始密钥，也不需要知道。WebSocket 客户端将与 WebSocket 服务器建立一个独立的 TLS 会话，使用仅 WebSocket 客户端和 WebSocket 服务器彼此共享的自己的密钥。

Note, this is separate from the per-frame masking key that a WebSocket client must use for every frame of data it sends to a WebSocket server after the WebSocket handshake is complete. That masking key is contained inside of each frame, and is always used even if TLS is not employed to encrypt the underlying connection between client and server.

请注意，这与 WebSocket 客户端在 WebSocket 握手完成后必须用于发送到 WebSocket 服务器的每帧数据的帧屏蔽密钥是分开的。该屏蔽密钥包含在每个帧内，即使没有使用 TLS 来加密客户端和服务器之间的底层连接，也始终使用该密钥。

Can wss websockets run at all?

WSS WebSocket 绝对可以运行。

英文:

> The first thing the websocket server receives is a request from the client. But the request itself is encrypted! How should the websocket server read the encrypted request??

The exact same way that an HTTPS server reads encrypted HTTP messages. A TLS session is established between client and server before any application data is exchanged. The TLS session decrypts any data being received, and encrypts any data being sent.

So, an HTTPS client connects to an HTTPS server, negotiates a TLS session first, and then exchanges HTTP messages that are encrypted/decrypted by that TLS session.

The exact same thing happens with WebSockets, too. A WSS client connects to an WSS server, negotiates a TLS session first, then negotiates the WebSocket handshake using HTTP messages (encrypted by TLS), and then exchanges subsequent WebSocket messages (encrypted by TLS).

> When a web client connects to the HTTPS page there is made a TLS handshake and everything later is encrypted

The exact same thing happens for a secure WebSocket connection, too.

> But how should the separately running websocket server know the key to decrypt?

It doesn't know the original key used by the TLS session of the HTTPS page, nor does it need to know. The WebSocket client will establish a separate TLS session with the WebSocket server, with its own key that only the WebSocket client and WebSocket server share with each other.

Note, this is separate from the per-frame masking key that a WebSocket client must use for every frame of data it sends to a WebSocket server after the WebSocket handshake is complete. That masking key is contained inside of each frame, and is always used even if TLS is not employed to encrypt the underlying connection between client and server.

> Can wss websockets run at all?

Of course.