Subject: [hybi] Clarify wheter HTTP responses other than 101 are valid

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 27 Mar 2011 14:43:31 +0200

Hi, draft-ietf-hybi-websocket-requirements-02 states that:

------------------------------------------
   REQ. 9:  The protocol SHOULD make it possible and practical to reuse
      existing HTTP components where appropriate.

   Reason: Reusing existing well-debugged software decreases the number
   of implementation errors as well as the possibility to introduce
   security holes, and increases development speed, especially when the
   WebSocket server is implemented as modules that plug in to existing
   popular Web servers.
------------------------------------------

However draft-ietf-hybi-thewebsocketprotocol-06 states:

-----------------------------------------
   The handshake from the server is much simpler than the client
   handshake.  The first line is an HTTP Status-Line, with the status
   code 101:

        HTTP/1.1 101 Switching Protocols

   Any status code other than 101 MUST be treated as a failure if
   semantics of that status code are not defined in the context of a
   WebSocket connection, and the websocket connection aborted
-----------------------------------------

So, could a websocket server reply 401 in order the WS client to
resend the handshake request containing credentials?
Could a websocket server reply a 3XX response to make a redirection?
Could a websocket server reply 403 to indicate the client that it's
not allowed for this service?
Could the websocket server reply 404 in case the request URI doesn't
exist in the server?

It seems that the above text still relies on the old concept of
"websocket looks like HTTP but it's not HTTP".

IMHO this should be clarified in the draft.

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 27 Mar 2011 20:47:10 +0800

> Could the websocket server reply 404 in case the request URI doesn't 

All of these are ultimately failures to complete the upgrade.

Clarification would be nice.

I also don't really get the qualification: "if semantics of that status code are not defined in the context of a WebSocket connection".  Seems like redundant to me.

---

From: Philipp Serafin <[email-masked]>
Date: Sun, 27 Mar 2011 18:28:00 +0200

I believe there may be significant use-cases for 401 and 3xx responses,
especially if WS endpoints would at one point be used as part of public
web-apis. (Kind of like Rest-style apis are used today.)
Like in HTTP-based apis, a provider could send 301 responses if an
endpoint has changed or could use 307 responses for simple
load-balancing. If this this doesn't pose too high of an implementation
burden for clients, it might be useful to think about keeping those
features.

Regards,
Philipp Serafin

On 27.03.2011 14:47, Thomson, Martin wrote:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Adam Barth <[email-masked]>
Date: Sun, 27 Mar 2011 13:09:13 -0700

Adding support for non-101 status codes has security consequences.  In
the interest of actually finishing the protocol, let's hold off on
adding support for more use cases for this iteration of the protocol.

Adam

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 27 Mar 2011 22:43:02 +0200

2011/3/27 Adam Barth <[email-masked]>:
> Adding support for non-101 status codes has security consequences.

Which ones?

> In the interest of actually finishing the protocol, let's hold off on

Then a requeriment in draft-ietf-hybi-websocket-requirements-02 is false:

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adam Barth <[email-masked]>
Date: Sun, 27 Mar 2011 14:12:40 -0700

>> Adding support for non-101 status codes has security consequences.

Redirects, especially, but other ones as well (even 200).

>     existing HTTP components where appropriate.

The current draft already makes it possible and practical to reuse
existing HTTP components where appropriate.

Adam

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 27 Mar 2011 23:18:23 +0200

> Redirects, especially, but other ones as well (even 200).

If redirects are not a problem in "normal" HTTP, why should them be a
security problem in WebSocket handshake?

> The current draft already makes it possible and practical to reuse

What do you mean with "possible and practical to reuse"? currently
it's not defined what should happen if the client receives a response
other than 101 during the handshake (well, it's specified that it
should consider it an error). I don't think this can be called "HTTP
reuse".

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adam Barth <[email-masked]>
Date: Sun, 27 Mar 2011 14:32:11 -0700

> security problem in WebSocket handshake?

I'm not really that interested in being drawn into this discussion at
this time.  Suffice it to saw that supporting non-101 status codes has
security consequence and would require further analysis, delaying
shipping the protocol significantly.  I'd prefer to ship what we have
and consider supporting more use cases in a future iteration of the
protocol.

Adam

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 27 Mar 2011 23:46:00 +0200

2011/3/27 Adam Barth <[email-masked]>:
> Suffice it to saw that supporting non-101 status codes has
> security consequence and would require further analysis

Then maybe you mean "supporting non-101 status codes COULD have
security consequence..." :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 28 Mar 2011 10:29:30 +1100

> adding support for more use cases for this iteration of the protocol.

Adam,

I do agree we want to start another long discussion about security
consequences of non-101 responses.
However, I don't think that prohibition is the answer either.

Firstly, I actually don't think we can prohibit non-101 responses.  We
have consensus that  before the 101 the handshake must be HTTP
compliant, and sending 400, 401, 301, 500, 503 are all HTTP compliant
responses that will very likely be seen no matter what we say here.

So I think the protocol must allow these responses as valid ways to
fail the upgrade.

However, it is a totally different matter to say if clients should
respond to these codes (eg by following redirects or providing
credentials).     The protocol may allow redirects, but the browsers
may decide for security or other reasons not to follow them.
Obviously for portability, we want browsers to mostly act the same,
but maybe that common behaviour should be decided by the HTML5 working
groups rather than by the protocol spec.

So we should make sure the text of the protocol spec makes it clear
that non-101 response codes may be seen.  The spec can also say that
it is a decision of the particular client if any non-101 responses are
acted on or ignored.

cheers

---

From: Patrick McManus <[email-masked]>
Date: Mon, 28 Mar 2011 15:32:31 +0200

> responses that will very likely be seen no matter what we say here.
I basically agree with this - I would put it even stronger. Before the 
101 this is HTTP and therefore the ietf websockets draft really doesn't 
have much to say other than what is already covered by HTTP. HTTP says 
if the response is 101 then start doing the upgraded protocol, otherwise 
this is still HTTP. The draft could use some clarification here.

Personally I think to be successful UA's are going to need to implement 
401s, redirects to pages that set cookies based on closed algorithms 
(and then probably redirect again), etc... Whether or not a UA chooses 
to chase a redirect (or prompt for auth, or whatever) is, as always, up 
to them.

Adam, I'm interested in specific classes vulnerabilities you see there. 
Even in generalities. They might be arpopos for the security 
considerations section.

---

From: Gabriel Montenegro <[email-masked]>
Date: Mon, 28 Mar 2011 13:44:34 +0000

> 101 this is HTTP and therefore the ietf websockets draft really doesn't have
> much to say other than what is already covered by HTTP. HTTP says if the
> response is 101 then start doing the upgraded protocol, otherwise this is still
> HTTP. The draft could use some clarification here.

I actually think that saying less gets us in less trouble. I'd delete all this text, because as long as we say that it is HTTP up to the point that the handshake is completed *successfully* then this is covered already by RFC2616:

http://tools.ietf.org/html/rfc2616#section-10.3 on redirection 3xx: " The action
   required MAY be carried out by the user agent..."

The main point is that there is a MAY, so it is completely optional to the client whether to heed such 3xx redirects. One could argue that httpbis has even better language, but that MAY is enough for anybody not feeling entirely comfortable with heeding redirects to ignore them.

> Personally I think to be successful UA's are going to need to implement 401s,
> redirects to pages that set cookies based on closed algorithms (and then
> probably redirect again), etc... Whether or not a UA chooses to chase a redirect
> (or prompt for auth, or whatever) is, as always, up to them.

Exactly. Per RFC2616, no need to say anything more.

> Even in generalities. They might be arpopos for the security considerations
> section.

This is a good point. The fact that clients have the option to respond calls for some guidance or considerations.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 28 Mar 2011 15:47:32 +0200

> Exactly. Per RFC2616, no need to say anything more.

The the draft should NOT say:

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Patrick McManus <[email-masked]>
Date: Mon, 28 Mar 2011 15:50:11 +0200

> I actually think that saying less gets us in less trouble. I'd delete all this text, because as long as we say that it is HTTP up to the point that the handshake is completed *successfully* then th…

yes.. I got a little carried away with the "put it even stronger" bit. 
That was wrt wg discussion; the draft only needs to point at the HTTP 
RFC and remove the language about aborting a websocket connection that 
does not yet exist.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 28 Mar 2011 18:18:11 +0200

On Mar 28, 2011, at 3:32 PM, Patrick McManus wrote:
> I basically agree with this - I would put it even stronger. Before the 101 this is HTTP and therefore the ietf websockets draft really doesn't have much to say other than what is already covered by HTTP. HTTP says if the response is 101 then start doing the upgraded protocol, otherwise this is still HTTP. The draft could use some clarification here.

That is exactly what I was going to write.  If a client says that it
is using HTTP, then it is governed by all of HTTP's client requirements
and expected behavior.  The same goes for servers that say they are
sending an HTTP message.  This does not change until after the Upgrade
exchange is completed successfully.

That said, there is nothing in HTTP that requires a client to follow
a redirect -- that is a choice made by client configuration and/or
nature.  Any valid HTTP response can (and should) be understood without
an implication that the websocket clients behave like a browser when
handling those responses.

....Roy

---

From: John Tamplin <[email-masked]>
Date: Mon, 28 Mar 2011 12:45:30 -0400

> handling those responses.

As long as it a WebSocket client/server that only cares about talking to
WebSocket endpoints is acceptable under the spec, then I am fine with it.

If a simple server implementation requires implementing a full HTTP server
to handle all the possibilities before Upgrade, then I think that is a
problem.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 28 Mar 2011 19:19:54 +0200

On Mar 28, 2011, at 6:45 PM, John Tamplin wrote:
> If a simple server implementation requires implementing a full HTTP server to handle all the possibilities before Upgrade, then I think that is a problem.

A full HTTP server implementation is only as complicated as the
resources it chooses to supply answers for.  I can write one in
a dozen lines of perl (without using LWP).  It is certainly far
less complex than figuring out how to respond to a WS handshake,
so don't worry about that.

....Roy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 29 Mar 2011 21:12:13 +0200

> Could the websocket server reply 404 in case the request URI doesn't

One more question in this topic:

Usually most protocols have a response code for indicating server
failure (for example a HTTP server can reply 500/503 in case it has
detected an error atr server side, or perhaps it's congested thsi
time). What about WebSocket? do we assume that the WS server should
never indicate the client an error in server side?
Of course, the most appropriate response would be a 500/503 during the
handshake, this is, making the handshake a fully HTTP requests (not
just the request, but also the responses).

The draft should, IMHO, tell about it. If not, WS clients wouldn't be
ready for handling server errors (each WS client developer would
decide what to do in that case as the draft says absolutely nothing
about it).

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>