Subject: Re: [hybi] Dispatch an error event when no handshake response is received?

From: Tobias Oberstein <[email-masked]>
Date: Wed, 30 Oct 2013 05:49:51 -0700

>I think it makes sense to _fail_ when the underlying connection is opened successfully but is closed by the server before the client receives a handshake response. 

Not sure I understand:

When a server encounters an error during handshake processing, the only 2 options it has are:
S1) return HTTP error
S2) immediately drop/close the underlying TCP

I think both are fine, S1 being more "cooperative", but S1 more resilant to DoS.

When a client encounters an error during handshake processing it might have 2 options (depending on error severity):

C1) perform a WS closing HS
C2) drop/close the underlying TCP

Not sure if C1 makes any sense .. since the client cannot be sure the server actually is a WS server in this case.

E.g. if a mandatory WS HS response header is missing: C2
If WS subprotocol mismatch, client _could_ perform C1.

Not sure.

/Tobias

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 30 Oct 2013 21:59:30 +0900

On Wed, Oct 30, 2013 at 9:49 PM, Tobias Oberstein <
[email-masked]> wrote:

> >I think it makes sense to _fail_ when the underlying connection is opened
> successfully but is closed by the server before the client receives a
> handshake response.
>
> Not sure I understand:
>
> When a client encounters an error during handshake processing it might
> have 2 options (depending on error severity):
>
> Not sure if C1 makes any sense .. since the client cannot be sure the
> server actually is a WS server in this case.
>

This is yet another topic. Sorry for being unclear. I was just wondering if
we should fire error event or not, and I believe we should...

---

From: Tobias Oberstein <[email-masked]>
Date: Wed, 30 Oct 2013 06:10:36 -0700

>This is yet another topic. Sorry for being unclear. I was just wondering if we should fire error event or not, and I believe we should... 

Ahh. So you refer to the WebSocket _API_ ... in browsers? If so, would that be IETF's/RFC6455's business or WHATWG's?

In the substance matter I agree: the WS browser API should fire an error event upon the initial handshake failing. It probably even should fire error if no handshake is started at all because e.g. I provide a invalid WS URI.

Since developers might just expect that: handle any WS error (be it before handshake, during handshake or thereafter) in one place: the WS object's error event handler.

There is one aspect: somewhere/someone brought up that the error reason MUST NOT disclose unwanted info (to a potentially evil script): e.g. HS failed because TLS cert invalid. Otherwise scripts could probe around in intranets etc. It is however a pain (this TLS fail in particular): browser won't render a dialog (since WS is a subresource) and WS error won't disclose TLS error also. So a good script has no chance of giving the user useful feedback .. like check site cert, import some cert or such.

/Tobias

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 30 Oct 2013 22:19:15 +0900

On Wed, Oct 30, 2013 at 10:10 PM, Tobias Oberstein <
[email-masked]> wrote:

> >This is yet another topic. Sorry for being unclear. I was just wondering
> if we should fire error event or not, and I believe we should...
>
> Ahh. So you refer to the WebSocket _API_ ... in browsers? If so, would
> that be IETF's/RFC6455's business or WHATWG's?
>

We can cover this case by adding texts to the WebSocket API. But unless
there's no mistake in RFC 6455, the WebSocket API just refers to events
defined in RFC 6455. For example,

> If the user agent was required to fail the WebSocket connection or the
WebSocket connection is closed with prejudice, fire a simple event named
error at the WebSocket object. [WSP]

It's connecting _fail the WebSocket connection_ defined in RFC 6455 with
the error event defined in the WebSocket API. The issue I pointed is that
in RFC 6455, it's not explicitly defined how to deal with connection close
without no handshake response data. The client will _close_ or _fail_.

>
> In the substance matter I agree: the WS browser API should fire an error
> event upon the initial handshake failing. It probably even should fire
> error if no handshake is started at all because e.g. I provide a invalid WS
> URI.
>
>
OK!

> Since developers might just expect that: handle any WS error (be it before
> handshake, during handshake or thereafter) in one place: the WS object's
> error event handler.
>

Agreed.

>
> There is one aspect: somewhere/someone brought up that the error reason
> MUST NOT disclose unwanted info (to a potentially evil script): e.g. HS
> failed because TLS cert invalid. Otherwise scripts could probe around in
> intranets etc. It is however a pain (this TLS fail in particular): browser
> won't render a dialog (since WS is a subresource) and WS error won't
> disclose TLS error also. So a good script has no chance of giving the user
> useful feedback .. like check site cert, import some cert or such.
>

Right. Error detail must not be delivered. Just making "connection close
without no handshake response data" fire an error event doesn't break the
rule. Yes.

---

From: "Joonas Lehtolahti" <[email-masked]>
Date: Wed, 30 Oct 2013 15:22:25 +0200

On Wed, 30 Oct 2013 15:10:36 +0200, Tobias Oberstein  
<[email-masked]> wrote:
> intranets etc. It is however a pain (this TLS fail in particular):  
> browser won't render a dialog (since WS is a subresource) and WS error  
> won't disclose TLS error also. So a good script has no chance of giving  
> the user useful feedback .. like check site cert, import some cert or  
> such.

Who says that a browser cannot give the user a sensible feedback even if  
an error happens with subresource? It actually bothers me that browsers  
usually don't give any info to users when some resource on a page has a  
problem. The user just sees a broken website but has no clue as to why it  
is broken. The last example of this was Twitter having no stylesheet or  
images because the resource server certificate check was not temporarily  
working, but all the user saw was the broken page even though the browser  
knew exactly why it didn't load the extra resources. So in my opinion the  
browser can and should display, not necessarily a dialog, but some  
indicator (red mark on address bar, for example) from which the user can  
click to get a dialog with detailed information on what has gone wrong.  
And this would apply to WebSocket also, the script can be clueless about  
certificate problem, but the user could have the option of seeing that and  
possibly remedy the situation (accept invalid cert, get missing root cert,  
etc.).

Just my few cents on this a bit off-topic part.

- Joonas

---

From: Tobias Oberstein <[email-masked]>
Date: Wed, 30 Oct 2013 06:41:58 -0700

> load the extra resources. So in my opinion the browser can and should display,
> not necessarily a dialog, but some indicator (red mark on address bar, for
> example) from which the user can click to get a dialog with detailed
> information on what has gone wrong.

Thats a good idea! It solves the issue of no user feedback, and is e.g done today already for mixed content sites (insecure subresources for secure page).

FWIW, we have been working around this TLS issues in the context of WS using 2 approaches (besides making the cert valid of course):

1) Redirecting the user to the WS URL, but HTTP(S) scheme, and having the WS server render a status HTML page itself (when it gets a HTTP/GET without Upgrade to WS header). The user can then accept cert and such.

2) Serving all content and WS from same server.

/Tobias