Re: [hybi] Extensibility mechanisms?

[Mike Belshe <[e-mail]>]

On Mon, Apr 19, 2010 at 12:52 AM, Greg Wilkins <[e-mail]> wrote:

> Mike Belshe wrote:
>
> > Should intermediaries know about these protocols?  Why?
> > ...
> > If we run all websockets through SSL, the protocol is stronger.  And
> > poor users aren't left holding the bag wondering why they just got
> hacked.
>
>
> Mike,
>
> I'm not arguing against SSL or having that the
> default/preferred transport.
>
> But in many deployments, SSL will be terminated on a box
> remote from the application and the connection will go through
> intermediaries provided by many vendors for load balancing,
> aggregation, connection aggregation etc. The specification
> needs to support such intermediaries in 2020.
>
>
This is a fair point; but intermediaries within your (the site owner)
control is a solvable problem, whereas intermediaries outside your (the
user) control are not.

But to make it to 2020, we also need something that is
> deployable in 2010.  So that means respecting the HTTP
> protocol.
>
> What Ian is proposing is that a websocket client and server
> can just agree on some new field, that can be used to
> upgrade to any protocol they like eg BEEP!
>
> HTTP has an upgrade mechanism and it's called Upgrade.
> Websocket should not be allowed to subvert that with
> something like:
>
>   GET /something HTTP/1.1
>   Host: somewhere:80
>   Upgrade: WebSocket
>   Connection: Upgrade
>   My-Upgrade: BEEP
>
>        HTTP/1.1 101 Web Socket Protocol Handshake
>        Upgrade WebSocket
>        Connection: Upgrade
>        My-Upgrade: BEEP
>
>   <-- Beep frames -->
>
> Any intermediary involved will have seen that
> as an upgrade to WebSocket, not to BEEP.
> I can't see how that can be interpreted as
> a compliant HTTP upgrade.
>
>

>
>
>
> Finally,  if I  really try to imagine protocols
> in 2020, I can't see secure connections being
> allowed end to end in all environments.   For
> better or worse, Corporations (and even countries)
> like to monitor and apply policy to what their
> users are doing.  I can imagine that every
> hop will be encrypted, but I think that end
> to end will not be universal (unless there
> some some huge break out of progressive
> libertarian sentiment in fortune 500 and
> world governments).
>
>
I think you're not thinking big enough.  There are solutions to all of these
problems.  I have yet to talk to anyone that doesn't think SSL everywhere is
the right idea; but many people think as you do - that it is just too hard.
 If we take that approach (the give up approach), then of course it will
prove true.  If you think about it - you're saying that policy should drive
protocol.  But isn't it the other way around?  The protocol should drive
policy?

There is only one question to answer:  what is the right approach for users?
 Then, once determined, figure out how to get there.  If security is in the
future, we should make it secure now.

Mike



>
> regards
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>