Subject: [hybi] Why mask the attacker's host name in the handshake? (was Re: draft-abarth-websocket-handshake-00)

From: Adam Barth <[email-masked]>
Date: Mon, 18 Oct 2010 16:24:36 -0700

We discussed the problems with no obfuscating the handshake in
<https://docs.google.com/document/edit?id=1hRLcVc8FHsXOQvaulG2KmvGKepgFffcevyJn-dAEsrI&authkey=COOWhaAD&hl=en#>,
namely:

1) Once the user agent speaks the attacker's host name on the socket,
it's entirely likely the request will be routed to the attacker's
virtual host.
2) If the entity doing the routing (e.g., a virtual hosting provider
such as 1and1) doesn't properly implement Upgrade, they will likely
expect subsequent traffic on the socket from the user agent to be
formatted as HTTP.
3) Once the attacker completes the handshake, he can cause the browser
to emit sequences of bytes that look enough like HTTP to confusing the
server but violate various HTTP security invariants imposed by the
user agent.

One robust solution to this problem is to never utter the attacker's
name on the socket.  That way, when the user agent completes the
handshake, the user agent can have reasonable assurance that the
entity listening to the socket (e.g., the virtual hosting provider,
not the virtually hosted content) understands that subsequent traffic
will conform to the WebSocket protocol rather than the HTTP protocol.

Adam

On Mon, Oct 18, 2010 at 4:15 PM, Brodie Thiesfield <[email-masked]> wrote:
> I appreciate the concern of cross protocol attack once the binary
> WebSocket packets start flowing on the connection, however I do not
> see how the use of a real HTTP Upgrade (or CONNECT) is any less secure
> than any other standard HTTP request.
>
> The server and intermediaries processing the initial WebSocket request
> is either:
> * a HTTP capable server that sees millions of these requests both good
> and malformed and has been dealing with them for years
> * a non-HTTP server that already needs to deal with GET/POST HTTP
> requests from attacking browsers with arbitrary header/key pairs
>
> By using a bog standard HTTP GET+Upgrade or CONNECT initial request,
> it allows us to continue using existing HTTP infrastructure.
> Connections to the desired virtual host and resource selection via the
> URL is still possible. If the possible endpoints are restricted by the
> WebSocket spec to ports >1000, then browser attacks using WS on DNS
> etc can be made essentially moot.
>
> Once the connection has been upgraded (or CONNECT'ed), then change to
> using an obfuscated stream, but changing the protocol before that
> appears to gain nothing but loses much. Of course, support can be
> added for a new protocol like what is suggested, but we all know that
> software upgrades just don't happen that often.
>
> I propose that a combination of the existing HTTP Upgrade using Greg's
> suggestions to make it fully HTTP compliant (or a no-frills HTTP
> CONNECT request), with Adam's ideas for obfuscation of the byte stream
> after the 101/connect is completed.
>
> GET /desired/url HTTP/1.1
> Host: virtual.example.com
> Connection: Upgrade
> Upgrade: WebSocket
> Sec-WebSocket-Key: jiminy
> Sec-WebSocket-Protocol: chat superchat
> ...
> CRLF
>
> 101 Sure
> Sec-WebSocket-Key: cricket
> Sec-WebSocket-Protocol: superchat
> ...
> CRLF
>
> obfuscated bytes
>
> Regards,
> Brodie
>
>
>
>
> On Tue, Oct 19, 2010 at 5:37 AM, Maciej Stachowiak <[email-masked]> wrote:
>>
>> On Oct 18, 2010, at 12:33 PM, James Graham wrote:
>>
>>>
>>>
>>> On Mon, 18 Oct 2010, Adam Barth wrote:
>>>
>>>> I've taken the liberty of writing up Eric and my handshake proposal as
>>>> an Internet draft:
>>>>
>>>> http://www.ietf.org/id/draft-abarth-websocket-handshake-00.txt
>>>>
>>>> This draft is heavily based on
>>>> draft-ietf-hybi-thewebsocketprotocol-03.  In particular, I just sliced
>>>> out Section 5 of that draft and edited it to describe the new
>>>> proposal.  It's obviously very rough editorially, but hopefully it
>>>> will be useful to have a concrete basis for conversation.
>>>
>>> This looks really useful Adam, thanks.
>>>
>>> Do we have some sense of where we are with respect to this handshake proposal? I have the general sense that a majority of people, but not everyone, feel that the basic design is better than the -03 handshake. Is that wrong? In particular the thread that Eric started suggested broad agreement that obfuscating user-supplied data is an good approach to preventing cross-protocol attacks.
>>>
>>> There are still clear disagreements on obfuscating everything vs allowing certain pieces of routing information to pass through in the clear. Is this something where we need to make an informed tradeoff, or is there some experiment we can run to determine the best option? The same question applies to using CONNECT since some people seemed concerned about this part of the proposal.
>>
>> I really liked Eric's division of the handshake proposal into three mostly-separable concerns. It seems like the first, masking payload data (as opposed to routing data) has been discussed thoroughly and there do not seem to be strong objections remaining. It would be good to have similar discussions for the other two aspects.
>>
>> Also, it might be useful to have tracker issues for those three sub-proposals.
>>
>> Regards,
>> Maciej
>>
>> _______________________________________________
>> hybi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/hybi
>>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Brodie Thiesfield <[email-masked]>
Date: Tue, 19 Oct 2010 08:40:41 +0900

> it's entirely likely the request will be routed to the attacker's

I assume you mean the attacker's target, but yes, surely this is the goal.

> server but violate various HTTP security invariants imposed by the

It is true that the original request is pure HTTP (either the Upgrade
or a CONNECT) and the attacker gets to control the contents, but
existing servers both HTTP and non-HTTP must already deal with these
requests from attacking clients, and the attacker already has this
control for those requests.

I am proposing that following the initial request, all traffic follows
your proposal for obfuscating the byte stream is used to ensure that
the attacker cannot send bytes that they control anymore. The
advantage is that virtual hosting is still supported while we get the
security of removing control of the subsequent byte stream from the
attacker.

> will conform to the WebSocket protocol rather than the HTTP protocol.

The same assurances are here with a plain HTTP request. If a valid
reply is received from the initial request, then we can be assured
that the server is correctly encoding the response, i.e. it knows
WebSocket. Alternatively at the server end, if it expects another HTTP
request, then it will only get the obfuscated byte stream and so
should soon disconnect.

Regards,
Brodie

---

From: Adam Barth <[email-masked]>
Date: Mon, 18 Oct 2010 16:57:22 -0700

> security of removing control of the subsequent byte stream from the

There's a subtle point here.  If the attacker provides the server part
of the handshake, then the attacker knows the client-to-server key.
Once the attacker knows the encryption key, the attacker can generate
a plaintext that encrypts to a chosen ciphertext.  The attacker can,
then, chose a cipher text that case problems for the other folks
virtually hosted on the same machine.

(The payload encryption buys us security in other scenarios.)

Adam

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 19 Oct 2010 06:23:25 +0200

> expect subsequent traffic on the socket from the user agent to be

No Adam, I can't agree with that. You decided to use CONNECT exactly to
cover this. CONNECT+200 *means* that what follows is pure data. While we
must ensure that non WS aware components should be protected, we don't
have to protect some deliberately broken components that would ignore
that.

Clearly, if we don't get the routing information at the HTTP level, then
the whole thing is basically useless. Trying to secure something that does
not work is pointless.

I really think we should restart from Eric's idea to split the work in 3
points.

Regards,
Willy