[hybi] Upgrade Mechanism and HasMat (was Re: Extensibility mechanisms?)

[Salvatore Loreto <[e-mail]>]

Hi Adam,

first let me thank you, Willy, Maciej  for the discussion about 
cross-protocol vulnerability,
having the explanation and picture of the problem always help the 
discussion and boost the
possibility to find a good solution.

from my personal point of view,
I see more value to work on a general solution to secure the HTTP 
Upgrade mechanism
against cross-protocol vulnerability, instead of trying to draft 
something ad-hoc for WebSocket

actually that sounds at least to me as something that perfectly fit in 
the HasMat BoF.

    "The goal of this working group is to standardize a small number of
    selected specifications that have proven to improve security of Internet
    Web applications. The requirements guiding the work will be taken from
    the Web application and Web security communities.

It would be extremely good if you (or someone else) can arrange a short 
presentation about this issue during the HasMat BoF!
If nobody volunteer I can prepare a couple of slides (taking advantage 
of what you have discussed in this thread)
and ask 5 minutes to the HasMat chairs to present them.


I also think the wg should also investigate the TLS+NPN approach, that 
is quite promising but we have also consider
that it also a work in progress.

cheers
Sal




On 7/22/10 10:08 AM, Adam Barth wrote:
> On Wed, Jul 21, 2010 at 11:49 PM, Willy Tarreau<[e-mail]>  wrote:
>    
>> On Wed, Jul 21, 2010 at 11:11:58PM -0700, Adam Barth wrote:
>>      
>>> On Wed, Jul 21, 2010 at 10:54 PM, Willy Tarreau<[e-mail]>  wrote:
>>>        
>>>> On Wed, Jul 21, 2010 at 09:40:00PM -0700, Adam Barth wrote:
>>>> If this is indeed the issue you're talking about, then I don't see why
>>>> the HTTP-based handshake could be a problem there.
>>>>          
>>> Well, it certainly *could* be a problem if improperly designed.
>>>        
>> Indeed, and as such the -76 one is, because the first bytes can be used
>> to send a second HTTP request to a server through a reverse-proxy while
>> at this point this should only be WebSocket and not HTTP.
>>      
> Interactions with both proxies and reverse proxies are important to
> consider for HTTP-based handshakes because we're likely to get deeper
> into their state machines.  I'm not sure I understand precisely the
> issue you're referring to, but that's why they pay Ian the big bucks.
>
>    
>>> As a
>>> community, we don't have a good science of cross-protocol
>>> vulnerabilities.  We certainly can't understand all possible
>>> interactions between all protocols.  We have to reason about these
>>> attacks indirectly, for example by reduction.  It's possible to reason
>>> about the security of an HTTP-based handshake by reduction to already
>>> existing abilities the attacker has, provided the protocol is designed
>>> with that sort of reasoning in mind.  Blithely hoping "HTTP likeness"
>>> will avoid all issues isn't sufficient.
>>>        
>> That's why I'm trying to reduce the amount of blind emissions during the
>> handshake.
>>      
> Attacker-controlled blind emission is definitely a bad idea.  Fixed
> once-and-for-all strings are probably not that bad.  Bytes chosen
> uniformly at random for each request are best.
>
>    
>>>> It's not more than any other common HTTP request,
>>>>          
>>> Keep in mind that attacker can only generate a very stylized subset of
>>> HTTP requests in browsers today.  Stepping outside that subset
>>> requires careful consideration.
>>>        
>> My concern is also that we're becoming too much different from this
>> stylized subset, by introducing special features that nobody cares
>> to qualify possible negative impacts nor means of exploitation. I'd
>> rather stick to something well mastered which shares the same class
>> of possible vulnerabilities and attacks as the other ones targetting
>> the same agents, so that when we spot one and fix it, the issue is
>> fixed for all uses.
>>      
> I didn't understand the concrete implications of this paragraph.
>
>    
>>>> Basically we should get this :
>>>>
>>>>   - the client sends an HTTP handshake (headers only)
>>>>   - the server responds with its HTTP handshake
>>>>   - the client checks the response and only then forwards
>>>>     data.
>>>>
>>>> This standard scheme protects against cross-protocol attacks (as I
>>>> understand them) as the client does not send anything unless the
>>>> server proves its ability to understand the client protocol. Also,
>>>> the request and response are different HTTP messages, so a simple
>>>> echo server can't return the valid handshake by accident.
>>>>          
>>> We're worried about more complex servers than just an echo server.
>>> That's why the proof of understanding is more complex.  Certainly an
>>> identical client ->  server and server ->  client message would be a
>>> poor design.  However, just because they're not identical doesn't mean
>>> we're out of the woods.
>>>        
>> I agree, but at least we can enumerate the strict requirements for
>> the client to accept to send data to the server, which reduce the
>> exposure. Right now with a properly designed HTTP upgrade handshake,
>> you require a very precise set of criteria in the response that only
>> a server understanding the protocol could send because a non-WS
>> server would not have invented them. And one advantage of HTTP upgrade
>> is that the response MUST start with "HTTP/1.1 101". Anything else
>> won't match, which considerably limits the ability to inject the
>> response into the server's mouth. For instance, my SMTP server sends
>> me a "220 mail.home.local" first, which does not match HTTP/1.1. Some
>> other protocols will for instance send "Error: GET /xxx unknown command".
>> In fact, the parts we expect from the response cannot be guessed from
>> the command by non-WS aware servers. This is what makes it quite robust
>> already.
>>      
> You're describing a defense which we've been calling rigidity.  By
> making the handshake rigid, it's harder to squeeze though some other
> protocol's state machine.  However, you can imagine protocols that are
> vulnerable to a perfectly rigid handshake.  As an example, imagine a
> protocol like gopher where the attacker might be able to control all
> the bytes returned by the server (e.g., because the server accepts
> uploads).
>
> There's value to having other defenses against cross-protocol attacks
> in addition to rigidity.  Just as Greg's nonce isn't magic security
> pixie dust, neither is rigidity.
>
>    
>>>> So with this, I'm sorry I don't see what class of cross-protocol
>>>> attacks remain and which ones we should actively protect against,
>>>> so if you have good examples, it would be nice if you could take
>>>> some time to share them.
>>>>          
>>> Designing a secure protocol doesn't mean enumerating all attacks and
>>> making sure we avoid them all.  We're not smart enough to envision all
>>> attacks.
>>>        
>> Agreed. Otherwise it's a lost game. But they can serve as examples to
>> try to defeat a design however.
>>
>>      
>>> Instead, we need to convince ourselves that no attacks are
>>> possible, which is much the opposite problem.  I don't have a pile of
>>> attacks in my back pocket.  Instead, I can tell you that the protocol
>>> presented earlier in this thread is unlikely to be free of
>>> cross-protocol vulnerabilities because it lacks a number of defenses
>>> and mitigations, some of which you've listed in your message.
>>>        
>> Yes, but as Scott said it, it was a proposal to work on something with
>> a constructive approach. Not everyone is perverted enough to think how
>> a protocol can be abused, and that's why we need a variety of people to
>> work on the same protocol.
>>      
> I'm take some offense at being called perverted.
>
> Adam
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>
>    


-- 
Salvatore Loreto
www.sloreto.com