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

++
On Nov 29, 2012 2:11 AM, "Jamie Lokier" <jamie@shareable.org> wrote:

> 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
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>