[asterisk-bugs] [JIRA] (ASTERISK-28257) res_http_websocket: PING / PONG opcodes break data reception

[Jeremy Lainé (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-28257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeremy Lainé updated ASTERISK-28257:
------------------------------------

    Description: 
Currently, PING / PONG opcodes are handled together with data reception. At a high level the logic looks like:

- retrieve frame header
- retrieve frame payload and apply unmasking
- (reply to PING and stop here ONLY if replying fails)
- (handle CLOSE opcode and stop here)
- put payload into a re-assembly buffer and return it to the caller

When data and PING / PONG opcodes and data are received consecutively, Asterisk behaves properly. However RFC 6455 specifies that control opcodes (PING / PONG / CLOSE) can be received in the middle of a fragmented message. In this case, Asterisk's logic breaks down, resulting in a truncated message being received.

My suggestion to fix this is to align the behavior with the new CLOSE handling code and return immediately, without exposing the payload to the caller.

  was:
Currently, PING / PONG opcodes are handled together with data reception. At a high level the logic looks like:

- retrieve frame header
- retrieve frame payload and apply unmasking
- (reply to PING)
- (handle CLOSE opcode and stop here)
- put payload into a re-assembly buffer and return it to the caller

When data and PING / PONG opcodes and data are received consecutively, Asterisk behaves properly. However RFC 6455 specifies that control opcodes (PING / PONG / CLOSE) can be received in the middle of a fragmented message. In this case, Asterisk's logic breaks down, resulting in a truncated message being received.


> res_http_websocket: PING / PONG opcodes break data reception
> ------------------------------------------------------------
>
>                 Key: ASTERISK-28257
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28257
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_http_websocket
>    Affects Versions: 16.1.1
>            Reporter: Jeremy Lainé
>
> Currently, PING / PONG opcodes are handled together with data reception. At a high level the logic looks like:
> - retrieve frame header
> - retrieve frame payload and apply unmasking
> - (reply to PING and stop here ONLY if replying fails)
> - (handle CLOSE opcode and stop here)
> - put payload into a re-assembly buffer and return it to the caller
> When data and PING / PONG opcodes and data are received consecutively, Asterisk behaves properly. However RFC 6455 specifies that control opcodes (PING / PONG / CLOSE) can be received in the middle of a fragmented message. In this case, Asterisk's logic breaks down, resulting in a truncated message being received.
> My suggestion to fix this is to align the behavior with the new CLOSE handling code and return immediately, without exposing the payload to the caller.



--
This message was sent by Atlassian JIRA
(v6.2#6252)