Re: [hybi] Experiment comparing Upgrade and CONNECT handshakes

[Scott Ferguson <[e-mail]>]

Adam Barth wrote:
> On Sat, Nov 27, 2010 at 10:00 PM, Scott Ferguson <[e-mail]> wrote:
>   
>> Ian Fette (イアンフェッティ) wrote:
>>     
>>> On Sat, Nov 27, 2010 at 8:24 AM, Adam Barth <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>
>>>    On Sat, Nov 27, 2010 at 8:16 AM, Willy Tarreau <[e-mail]
>>>    <mailto:[e-mail]>> wrote:
>>>    > On Sat, Nov 27, 2010 at 07:51:17AM -0800, Eric Rescorla wrote:
>>>    >> What's the argument *for* having an insecure handshake?
>>>    >
>>>    > There's no argument *for* having an insecure handshake, there
>>>    are arguments
>>>    > for having a safe HTTP-compliant handshake.
>>>
>>>    The handshake we're proposing is both safe and HTTP compliant.
>>>
>>>    Kind regards,
>>>    Adam
>>>
>>>
>>> I really appreciate all the work you and others have done with this paper.
>>> I have a few questions I'd like to ask if you wouldn't mind.
>>>
>>> #1, if we changed the non-bogus Host header to be the real host, do you
>>> believe that would have any substantial negative impact?
>>> #2 Is there anything else that is in the handshake proposal that is
>>> perhaps HTTP compliant by the letter but not the spirit? (Other than CONNECT
>>> vs UPGRADE -- I think you've made that case.)
>>>
>>> I personally don't care strongly enough about the above to call them a
>>> requirement, but a number of people on this list have raised the HTTP compat
>>> issue so I would like to better understand what that would imply with the
>>> proposal this paper suggests the group move forward with.
>>>       
>> The change of the CONNECT URI to the known host "websocket.invalid" makes a
>> difference, because a server can dispatch the known "websocket.invalid" host
>> to a websocket handler. (The earlier scrambling of the URI was unworkable.)
>>     
>
> This change is already incorporated in the current version of
> draft-abarth-websocket-handshake.
>   

This really shows the disadvantage of the "procedural" style of spec
writing. By obfuscating the intention of the spec, you make it difficult
to see changes or to evaluate what the proposal is doing.

And, bluntly, not many people have the time to wade through and decode
the obfuscating junk.

-- Scott

>   
>> In other words, there's a difference between a well-known
>> "websocket.invalid" host and a bogus host. A truly bogus host would be a
>> problem (and wouldn't be HTTP in any meaningful way).
>>
>> That's from the end-server perspective. I don't know about proxies, although
>> I'd think a websocket-aware proxy could unpack the embedded URL and forward
>> based on it.
>>     
>
> Great.  I'm glad it works for you.
>
> Adam
>
>
>
>