Re: [hybi] Extensibility mechanisms?

[Maciej Stachowiak <[e-mail]>]

On Jul 21, 2010, at 10:54 PM, Willy Tarreau wrote:

> Hi Adam,
> 
> On Wed, Jul 21, 2010 at 09:40:00PM -0700, Adam Barth wrote:
>> The more I read on this list, the more I think that folks here don't
>> understand the requirements on the protocol, especially the security
>> requirements.  That's understandable if you haven't worked extensively
>> with the browser security model.  Fortunately, Ian is an expert on
>> these topics and has more time to reply to this list than I do.
> 
> Unfortunately, if neither of you two can take some time to give concrete
> examples of what you're trying to protect against, you will constantly
> see proposals that don't fit your requirements.
> 
> My understanding of cross-protocol attacks (please correct me if I'm
> wrong) is the fact that a browser can be tricked into sending specially
> crafted data to an IP:port which it believes is one protocol while it's
> another one, the typical example being a form designed to send a POST
> to an SMTP server, which will ignore all the HTTP part it does not
> understand and will happily apply the body's data as SMTP commands. It's
> easy to put web sites on the net that build such forms so that browsers
> which get there are accidentely used to perform that attack.

There's at least three kinds of concerns about cross-protocol attacks and the WebSocket protocol, in the case where the client is the browser:

1) Hostile JS code running in the browser may use the browser's WebSocket client code to try to attack existing HTTP resources, if it can make a request that looks sufficiently like HTTP.
2) Hostile JS code running in the browser may use the browser's WebSocket client code to try to attack existing non-HTTP servers, if it can make a request that looks sufficiently like the service in question.
3) Hostile JS code running in the browser may use the browser's HTTP client code (e.g. via XMLHttpRequest) to try to attack newly created WebSocket servers, if it can make a request that looks sufficiently like WebSocket.

There is also another orthogonal dimension to the threat space:

A) Attacks on confidentiality, where the attacker is trying to get access to information from the resource being attacked which he or she should not be able to obtain.
B) Attacks on integrity, where the attacker is attempting to inject commands into a resource, without necessarily caring about getting a response back.


Cross-protocol attacks were much discussed earlier in the year, and I gave some sketches of attack scenarios here:
http://www.ietf.org/mail-archive/web/hybi/current/msg01198.html


> 
> 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. It's not more than
> any other common HTTP request, it's even better in that no data should
> flow until the server has correctly replied indicating proper support
> for the protocol.

What's "the HTTP-based handshake"? We have had several proposals for handshakes that start out looking like HTTP. They are not all equally effective in protecting against cross-protocol attacks, though some of them do have some protection..

Although I am not an expert on cross-protocol attacks, one thing I have learned is that the issues can be *extremely* subtle. This leads me to conclude that it's better to err on the side of caution, and design the protocol to be even more robust against such threats than we think is strictly necessary. 

I believe the TLS-based handshake (as proposed by Adam) is more robust than solutions involving nonces and challenge/response built into an HTTP-like handshake. The reason for this is that it's hard for the attacker to control the bytes sent, other than to cause the initiation of a TLS handshake, which is something that all network services are already exposed to by browsers. The attacker cannot get to the next-level protocol running over TLS unless the server explicitly opts in. With HTTP-based schemes, it takes much more care to avoid sending information as the "wrong" protocol.

However, HTTP-based challenge-response solutions are definitely better than not trying to address the issue at all.

Regards,
Maciej