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

+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.

--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