Re: [hybi] On TLS-only Approaches

[John Tamplin <[e-mail]>]

On Sun, Aug 22, 2010 at 11:47 PM, Maciej Stachowiak <[e-mail]> wrote:

> 1) Would such devices be likely to offer WebSocket services? That doesn't
> seem likely to me, given my knowledge of the typical uses for this sort of
> thing (embedded Web-based configuration interface).
>

They currently offer AJAX web pages, so I would not be surprised if they
would.


> 2) Even the very underpowered hardware in embedded devices is rapidly
> getting more powerful. I don't think TLS is unreasonable in terms of
> computational cost for future embedded services.
>

I am thinking code size is a problem, especially if you mandate any
base cipher set, as well as the computation required for low-end devices to
run RSA.


> 3) I would guess the challenge for embedded devices that *do* want to
> provide WebSocket services is that they can't practically ship with a valid
> certificate. To address this without creating security holes, we would
> likely need two URI schemes (ws: and wss:) with two different NPN protocol
> identifiers. ws: would not require a valid cert, wss: would. The reason two
> different NPN protocol identifiers are required is to prevent
> man-in-the-middle attacks against wss: services accessed using ws: by making
> it impossible to access them via ws:.
>

Another related question:  as I understand it, TLS has some fairly
significant per-message overhead, on the order of 5 bytes per record, plus
the overhead for the encryption algorithm.  For AES128 CBC with SHA1, you
have a 20 byte hash plus padding up to 16 byte multiples, so that means
small frames will be enormously inefficient under TLS.  For example, we have
just been arguing for a handful of bytes in the framing, and this would
immediately use a minimum of 25 extra bytes per frame.   By the time you
count uncompressed TCP/IP headers and WS framing, we have used more than
half of the bytes in a low-power FACH frame for mobile devices (depending on
the carrier configuration about 128-256 bytes).

Unless there is some lower overhead option, it doesn't seem like that can be
mandated for all WebSocket connections.

-- 
John A. Tamplin
Software Engineer (GWT), Google