Re: [hybi] failed TLS handshake: which close code?

To quote the WebSocket API:
"
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.
"

So if TLS fails and the client has to _Fail the WebSocket Connection_, then the API only reports an error; it does not provide a close code.  Which is appropriate, because the existence of a close code presumes the existence of an established WS connection, which does not exist in this case.

--Richard

On Oct 24, 2011, at 9:29 AM, Alexey Melnikov wrote:

> Hi Richard,
> 
> On Mon, Oct 24, 2011 at 2:22 PM, Richard L. Barnes <rbarnes@bbn.com> wrote:
> +1
> 
> It's silly to require the WS implementation to send a close frame in plaintext after the TLS connection fails.  I don't even think this sort of thing would be supported by standard TLS libraries.
> Right. But the TLS-related code(s) might have to be allocated for use in the WebSocket API. 
> 
> --Richard
> 
> 
> 
> On Oct 24, 2011, at 9:09 AM, Alexey Melnikov wrote:
> 
> > On a second thought: TLS fails before WebSocket connection is established, so (unless I am missing something) TLS related close codes will never be sent on the wire. However reserving some WebSocket codes is still a good idea.
> >
> > On Mon, Oct 24, 2011 at 2:04 PM, Alexey Melnikov <alexey.melnikov@isode.com> wrotetL
> > That was supposed to be sent to the mailing list. The WG should consider adding multiple codes if needed.
> >
> >
> > ---------- Forwarded message ----------
> > From: Alexey Melnikov <alexey.melnikov@isode.com>
> > Date: Mon, Oct 24, 2011 at 1:34 PM
> > Subject: Re: [hybi] failed TLS handshake: which close code?
> > To: Tobias Oberstein <tobias.oberstein@tavendo.de>
> >
> >
> > Hi Tobias,
> >
> > On Mon, Oct 24, 2011 at 3:58 AM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
> > Hybi-17:
> >
> > """
> > 4. Opening Handshake
> > ...
> > 4.1. Client Requirements
> > ...
> >   5.  If /secure/ is true, the client MUST perform a TLS handshake over
> >       the connection after opening the connection and before sending
> >       the handshake data [RFC2818].  If this fails (e.g. the server's
> >       certificate could not be verified), then the client MUST _Fail
> >       the WebSocket Connection_ and abort the connection.  Otherwise,
> >       all further communication on this channel MUST run through the
> >       encrypted tunnel.  [RFC5246]
> > """
> >
> > When the client fails the TLS handshake (i.e. because of invalid server certificate),
> > which close status code would be appropriate to use for signaling that specific
> > reason to the caller?
> >
> > Is it supposed to use a close status code from the following range?
> >
> > """
> >   3000-3999
> >
> >      Status codes in the range 3000-3999 are reserved for use by
> >      libraries, frameworks and application.  These status codes are
> >      registered directly with IANA.  The interpretation of these codes
> >      is undefined by this protocol.
> > """
> >
> > Or are those only for "use on wire" not for signaling the caller?
> >
> > For example, Firefox currently provides the calling JavaScript with a "1006 Abnormal Connection Close":
> >
> > """
> >  1006
> >
> >      1006 is a reserved value and MUST NOT be set as a status code in a
> >      Close control frame by an endpoint.  It is designated for use in
> >      applications expecting a status code to indicate that the
> >      connection was closed abnormally, e.g. without sending or
> >      receiving a Close control frame.
> > """
> >
> > However, this could be multiple things and is not giving the real reason to the JS.
> > The JS thus can't react specifically ..
> >
> > TLS handshake probably deserves a separate 1XXX close code.
> >
> >
> >
> > _______________________________________________
> > hybi mailing list
> > hybi@ietf.org
> > https://www.ietf.org/mailman/listinfo/hybi
> 
> 