Re: [hybi] Websocket over TLS keep-alive overhead

[Jamie Lokier <[e-mail]>]

Takeshi Yoshino wrote:
>    Hi,
>    Chromium is using 1/n-1 record splitting for TLS 1.0 connection w/ CBC
>    mode cipher to work around BEAST exploit. So, even a WebSocket frame
>    with 1 octet payload (client -> server, 7 octets in total. AES block
>    size (16) * 2 - SHA1 HMAC size (20) - padding length field size (1) >
>    7, so 1 application data record with 32 octets payload is enough) will
>    be packed into two TLS records with big padding.
>    re: TLS compression, it's disabled on Chromium to address another
>    exploit called CRIME.

It might make sense if TLS could transmit its own, much shorter,
keepalive messages, which are for the sole purpose of keeping the link
alive.  I would guess, since they have no other effect, that they
wouldn't be exploitable in the same way.  Is that right?

It would be best if they could be invoked from the higher layer rather
than generated in TLS itself (because the higher layer will have a
better idea of the keepalive patterns that it needs), and if they were
one-way keepalives rather than PING/PONG to avoid amplification
attacks, and because PING/PONG is not the most efficient keepalive
pattern.

Is there provision in TLS for that sort of thing now?

(Of course over mobile links, it would make much more sense for power
efficiency to have a single, aggregated keepalive stream for all
sockets rather than one per active websocket, or some other way of
taking advantage of the phone's existing mobile link-level keepalives
which it already does and are designed for efficiency.)

-- Jamie