Re: [hybi] Extensibility mechanisms?

[Mike Belshe <[e-mail]>]

BTW - Isn't the creation of this problem really because we allow arbitrary
UTF-8 written by the JS application?  If we had a true framing layer (where
frames have headers, instead of allowing UTF-8), would these attacks be
real?  It seems to me that the simplest frame header would be sufficient to
prevent all of these attack vectors, but the frame headers could contain
nonces or whatever other security information is needed too.

The reason I mention this is because as we look to using a TLS/NPN, we can
potentially get rid of the first round trip.  There was a lot of support for
that idea within the group.  But, we can *only* do so if we don't have JS
able to write directly to the socket.  If JS is able to write UTF-8 to the
socket, then skipping the first round trip opens a security vulnerability as
depicted by Maciej & Adam here.

Mike


On Thu, Jul 22, 2010 at 12:18 AM, Maciej Stachowiak <[e-mail]> wrote:

>
> 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
>
>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>