1

Assume a 100% secure websocket site where the webserver serves all files: html, js, css, etc, and the websocket serves all data between client and server.

Obviously the initial ssl handshake is between the client and webserver on the default https port, but wss will be on a different port, so does it have to handshake again?

The reason I'm asking is because websockets & spdy aren't working together yet (so I've read), so I'm hoping to get around it by having spdy on the webserver and rely on keep-alive for wss since some claim spdy isn't much faster (if at all) than keep-alive after the handshake spdy faster than keep-alive https?.

Community
  • 1
  • 1

2 Answers2

1

No. The SSL protocol determines how the client and server negotiate the cipher suite to be used, Authenticate one another, transmit certificates, establish session keys, and transmit messages.After the handshake completes successfully, all of the data that flows over the new SSL session is protected by the cryptographic algorithms and session keys that were agreed to during the handshake.

Travis G
  • 1,592
  • 1
  • 13
  • 18
1

While most of what Travis said is factually true, I'm unclear why he answered "no" to your question.

When the client opens the HTTPS connection to the webserver, the webserver may serve up JS that initiates WebSocket connections using wss:// to a different origin (may be the same host, but as you described, it is a different port). This is a different connection. An SSL handshake has to be separately performed for each connection.

What Travis said is true for a SSL session, and if the WebSocket used the same connection as the https:// document fetch, then it would be correct to answer "no". But since the wss:// WebSocket connection initiation will use a different connection, it requires another SSL handshake.

William Chan
  • 61
  • 1