Re: [hybi] Insight you need to know: Browsers are at fault when servers crash

[Willy Tarreau <[e-mail]>]

On Mon, Jul 26, 2010 at 12:36:28AM -0400, John Tamplin wrote:
> On Mon, Jul 26, 2010 at 12:23 AM, Mike Belshe <[e-mail]> wrote:
> 
> > Sounds like what you've said is that Android devices are too wimpy to do
> > encryption?  I bet the iPhone can handle it.  :-)
> >
> 
> No, actually I am thinking of even wimpier devices, such as what goes in
> some set-top boxes, or various small network attached devices (like
> $35 Ethernet switches), etc.  Many of these have some web-based UI, and I
> think it would be useful to say decisively whether such platforms are
> intended targets for WebSockets.  If they are, I don't think requiring
> encryption or compression is acceptable.  I am not saying it is required
> that they are supported, just that we need to recognize a decision is being
> made there one way or the other and better to make it explicit.
> 
> Personally, I think we should make expensive features optional, which means
> that a) we have to decide the amateur programmer requirement since that has
> previously been used to squelch any suggestion for negotiation and b) these
> optional features can't be used for base-level security in the protocol,
> such as avoiding cross-protocol attacks.

Well, maybe one solution *could* be to have HTTP-compliant headers
carrying the handshake and an encryption key and the data being
encrypted using a cheap symmetrical algorithm such as AES (or even
cheaper) for which many small implementations already exist ?

It would be a lot cheaper than TLS, would bring the randomness the
security guys are looking for, and allow cheap devices to use it.

And the exchanged key could be the same in each direction and serve
as the nonce as well. The client sends it over a header, expects to
get the same one in response, then both ends use it to exchange
encrypted data over the connection.

Regards,
Willy