Re: [hybi] failed TLS handshake: which close code?
"Richard L. Barnes" <rbarnes@bbn.com> Mon, 24 October 2011 13:53 UTC
Return-Path: <rbarnes@bbn.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A949221F8D9E for <hybi@ietfa.amsl.com>; Mon, 24 Oct 2011 06:53:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9gfWdZ1Ny8u for <hybi@ietfa.amsl.com>; Mon, 24 Oct 2011 06:53:30 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id F08D721F8D9D for <hybi@ietf.org>; Mon, 24 Oct 2011 06:53:29 -0700 (PDT)
Received: from ros-dhcp192-1-51-60.bbn.com ([192.1.51.60]:55580) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1RIKy1-0001kk-Ap; Mon, 24 Oct 2011 09:53:29 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <CADkeqZWGEc6s=6UnQqzU5uGy+Jci5d7n9We+9kcHj+o8=y2SwA@mail.gmail.com>
Date: Mon, 24 Oct 2011 09:53:28 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <363A8979-63BA-489F-A1A0-A8A3287891C6@bbn.com>
References: <634914A010D0B943A035D226786325D42D0B036D6D@EXVMBX020-12.exch020.serverdata.net> <CADkeqZXXRkXCRrONLr5thwOqNVUxNWU0Q-9E0R0i=4S-bc-LFw@mail.gmail.com> <CADkeqZXDvu-JY8aZHJJPRH-_JnF196JjA_JG6X_1yrYSiAekuA@mail.gmail.com> <CADkeqZWdFrmEyJEmHy+tfgsJXS1nU3ASx20-=uwwLY6EZogc0A@mail.gmail.com> <7ECB103B-4C75-49B2-A29B-ABCF91B3DB36@bbn.com> <CADkeqZWGEc6s=6UnQqzU5uGy+Jci5d7n9We+9kcHj+o8=y2SwA@mail.gmail.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: Apple Mail (2.1084)
Cc: hybi@ietf.org
Subject: Re: [hybi] failed TLS handshake: which close code?
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2011 13:53:30 -0000
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 > >
- Re: [hybi] failed TLS handshake: which close code? Richard L. Barnes
- [hybi] failed TLS handshake: which close code? Tobias Oberstein
- [hybi] Fwd: failed TLS handshake: which close cod… Alexey Melnikov
- Re: [hybi] failed TLS handshake: which close code? Alexey Melnikov
- Re: [hybi] Fwd: failed TLS handshake: which close… Peter Thorson
- Re: [hybi] Fwd: failed TLS handshake: which close… Alexey Melnikov
- Re: [hybi] failed TLS handshake: which close code? Alexey Melnikov
- Re: [hybi] failed TLS handshake: which close code? Richard L. Barnes
- Re: [hybi] Fwd: failed TLS handshake: which close… Peter Thorson
- Re: [hybi] failed TLS handshake: which close code? Tobias Oberstein
- Re: [hybi] failed TLS handshake: which close code? Tobias Oberstein
- Re: [hybi] Fwd: failed TLS handshake: which close… Tobias Oberstein
- Re: [hybi] Fwd: failed TLS handshake: which close… Tobias Oberstein
- Re: [hybi] Fwd: failed TLS handshake: which close… Richard L. Barnes
- Re: [hybi] Fwd: failed TLS handshake: which close… Tobias Oberstein
- Re: [hybi] Fwd: failed TLS handshake: which close… John Tamplin
- Re: [hybi] Fwd: failed TLS handshake: which close… Richard L. Barnes
- Re: [hybi] Fwd: failed TLS handshake: which close… Richard L. Barnes
- Re: [hybi] Fwd: failed TLS handshake: which close… Gabriel Montenegro