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

Yep, its not about _sending_ a close frame (which would be silly). Its about signaling the application.

There are already two close code which must not be used on the wire and are
only there for signaling errors to the application: 1005 and 1006.

The spec says they must not be used on wire, the spec does not speak about
whether the codes must only be used when a WS connection previsously existed ..

Von: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] Im Auftrag von Alexey Melnikov
Gesendet: Montag, 24. Oktober 2011 15:29
An: Richard L. Barnes
Cc: hybi@ietf.org
Betreff: Re: [hybi] failed TLS handshake: which close code?

Hi Richard,
On Mon, Oct 24, 2011 at 2:22 PM, Richard L. Barnes <rbarnes@bbn.com<mailto: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<mailto: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<mailto: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<mailto:tobias.oberstein@tavendo.de>>
>
>
> Hi Tobias,
>
> On Mon, Oct 24, 2011 at 3:58 AM, Tobias Oberstein <tobias.oberstein@tavendo.de<mailto: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<mailto:hybi@ietf.org>
> https://www.ietf.org/mailman/listinfo/hybi