About WebSocket:

WebSocket is an application layer communication protocol (RFC 6455) that establishes a persistent full-duplex communication channel over the web. This allows both the client and server to transfer data simultaneously. This protocol is mainly used to create transport tunnel for other non-HTTP protocols used in applications such as messaging, video conferencing and multiplayer games.

WebSocket is basically a feature within HTTP that offers additional functions and benefits for the web applications. It uses HTTP connection upgrade to tunnel other application data like MQTT, WebRTC etc.

WebSocket is just like HTTP protocol for client-server communication, but offers some extra features like:

WebSocket is particularly used in websites where the client needs constant updates from server. If HTTP was to be used in this case, the client had to flood the server with requests for information and each request would be part of a different connection. But with WebSocket, once a connection is established, it can stay persistent till one of the parties closes it, and the server can constantly feed the client with information.

WebSocket Messages in HAR Capture:

If any HAR “entries” contains WebSocket frame, then the “_resourceType” field (i.e., the type of resources to be loaded) inside that entry is set as “websocket" and the actual WebSocket messages are present inside the “_webSocketMessages” field.

The image below illustrates how WebSocket works - 

A WebSocket communication is initiated through HTTP connection upgrade. Here the client sends a HTTP/1.1 GET request to the server saying that it wants to open a WebSocket connection. This request contains different WebSocket specific headers like

• “Connection: Upgrade” and “Upgrade: websocket” indicating that the client is asking the server to upgrade the connection to a WebSocket connection.
• “Sec-WebSocket-Version” indicating the WebSocket version to be used
• “Sec-WebSocket-Key” used by the server to create “Sec-WebSocket-Accept”

Note: WebSocket URIs do not use http:// or https:// scheme. It always uses a new scheme called ws:// or wss:// (for secure WebSocket) to establish a WebSocket connection.

In HAR file, a typical WebSocket handshake (client) request looks like – 

Here, all the WebSocket specific headers like “Upgrade”, “Connection”, “Sec-WebSocket-Key”, “Sec-WebSocket-Version”, URI which starts with the “wss://” scheme etc are present in key-value pairs inside that HAR entry.

If the server accepts the WebSocket connection request, it replies with HTTP response with status code 101 (Switching Protocols). The response header contains some specific headers like – 

• “Upgrade: websocket” and “Connection: Upgrade” indicating that the protocol change is approved by the server.
• “Sec-WebSocket-Accept” indicating that the server is ready to initiate the WebSocket communication with the client.

Note: Anything other than response status code 101 indicates that the WebSocket handshake is not completed.

In HAR file, the server handshake response looks like – 

In a HAR capture, the WebSocket response related information like “Sec-WebSocket-Accept”, “Connection: Upgrade”, “Upgrade: websocket” etc are present in key-value pairs inside that HTTP response header. Also, the “status”, “statusText” and “httpVersion” must be set as “101”, “Switching Protocols” and “HTTP/1.1” respectively.

When the HTTP handshake is completed, the actual data transfer starts between the client and the server in full duplex mode. In HAR file, the actual WebSocket messages are present inside the “_webSocketMessages[]” array inside HAR “entries” field. Please see the below image - 

Inside the array, each WebSocket frame contains several tags like – 

1. type – direction of the WebSocket messages transferring between client to server (send) or server to client (receive)
2. time – time in EPOCH format when the data is transferred over WebSocket
3. opcode - the frame type of the WebSocket frame
4. data – the actual payload transferring over WebSocket protocol

WebSocket Support in BreakingPoint HAR Simulation

We have added the support for WebSocket in our new BPS feature HTTP Archive Record (HAR) Simulation and it is released in ATI-2022-15 StrikePack. Now, if a HAR capture contains any WebSocket session, then it will be simulated through HAR Simulation and can be encrypted by both TLS 1.2 and TLS 1.3. 

We have also added 2 new HAR simulation superflows which contains WebSocket sessions – 

1. Quora WebSocket HAR Replay over TLS1.2

This simulates the WebSocket session in the HAR collected from user chat function of the Quora webpage as of June 2022. This WebSocket session is initiated via HTTP1.1 connection upgrade over a single TCP connection encrypted by TLS1.2.

2. Quora WebSocket HAR Replay over TLS1.3

This simulates the WebSocket session in the HAR collected from user chat function of the Quora webpage as of June 2022. This WebSocket session is initiated via HTTP1.1 connection upgrade over a single TCP connection encrypted by TLS1.3.
 

Leverage Subscription Service to Stay Ahead of Attacks

Keysight's Application and Threat Intelligence  subscription provides daily malware and bi-weekly updates of the latest application protocols and vulnerabilities for use with Keysight test platforms. The ATI Research Centre continuously monitors threats as they appear in the wild. Customers of BreakingPoint now have access to attack campaigns for different advanced persistent threats, allowing them to test their currently deployed security controls’ ability to detect or block such attacks.