4

In a client-server communication scenario over secure websocket, client is authorized securely and from there on, I have two choices:

  1. Assign a unique random ID (session) and check that on subsequent communications.
  2. rely on socket connectivity and keep a handle to the socket object (which internally use it's own session).

For sure the first choice is secure if has been implemented properly. My question is, if the second one is secure. If someone be able to intercept websocket connection in such a way that connection is not dropped, this choice could not be considered secure. Should I worry about that?

Xaqron
  • 306
  • 1
  • 10
  • 1
    If the webSocket is using SSL, then it cannot be "intercepted" after it was connected. This is one of the fundamental protections of SSL. – jfriend00 Oct 04 '17 at 16:07
  • @jfriend00: Thanks. I was not sure since sometimes we user heartbeat to ensure connectivity (i.e. if cable is unplugged we both sides does not get notified of disconnection). Please post it as answer do I can accept. – Xaqron Oct 04 '17 at 16:13
  • 1
    Once authorized, a connection can't be intercepted. But be aware of [Cross-Site WebSocket Hijacking](https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html) - which can affect the authorization phase. – paj28 Oct 04 '17 at 16:18
  • It makes me wonder if physical layer spoofing with full session listening could allow such an attack due to NAT if on the same physical network? – Robert Mennell Oct 04 '17 at 16:23
  • 1
    @RobertMennell - The physical connection can be subverted, but because of the encryption involved in SSL/TLS, the intercepted data cannot be read and any attempt to send data will be rejected because of invalid encryption. The PKI (use of public key/private key) means of establishing the encryption keys protects them from being snooped during connection establishment. – jfriend00 Oct 04 '17 at 16:30

1 Answers1

4

If the webSocket connection is using SSL/TLS, then it cannot be "intercepted" or "hijacked" after it was connected. This is one of the fundamental protections of SSL/TLS.

Part of establishing such a connection is that the endpoints securely end up with encryption keys (created via the public key/private key technology) and one intercepting the connection (a so-called man-in-the-middle-attack) will not have appropriate encryption keys and thus will not be able to either read data being sent or inject data onto the connection. They can't read because data is encrypted with keys they don't have. They can't send data because they don't have the proper keys to encrypt data that will pass incoming security tests.

jfriend00
  • 524
  • 2
  • 7