IETF Logo Mail Archive

Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04

"Olle E. Johansson" <oej@edvina.net> Thu, 30 January 2014 09:26 UTC

Return-Path: <oej@edvina.net>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139CF1A044E; Thu, 30 Jan 2014 01:26:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZlUmzFy2hvx; Thu, 30 Jan 2014 01:26:19 -0800 (PST)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 9475E1A03E9; Thu, 30 Jan 2014 01:26:15 -0800 (PST)
Received: from [192.168.40.68] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id E8C8793C2A1; Thu, 30 Jan 2014 09:26:11 +0000 (UTC)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <1E320318-64CE-4F8B-AB76-8C4A5244379A@cisco.com>
Date: Thu, 30 Jan 2014 10:26:11 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <02B7636E-68F1-4513-B214-44635162874D@edvina.net>
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com> <A25E55DD-59E3-4F43-BE9A-6304378FAE0B@cisco.com> <CALiegf=mn1Lg6ihhf8hamn6rVpkLnF3ydGxm1tK1JaNMaioxoQ@mail.gmail.com> <CAEqTk6Q2Dv4a2P-8KJtK=xGZx=mmayt_YdagF2=JyoJ1oYQu7w@mail.gmail.com> <1E320318-64CE-4F8B-AB76-8C4A5244379A@cisco.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
X-Mailer: Apple Mail (2.1827)
Cc: Ben Campbell <ben@nostrum.com>, DISPATCH <dispatch@ietf.org>, "rai@ietf.org" <rai@ietf.org>, "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" <draft-pd-dispatch-msrp-websocket.all@tools.ietf.org>
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 09:26:21 -0000

On 29 Jan 2014, at 19:11, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

> 
> On Jan 29, 2014, at 10:16 AM, Peter Dunkley <peter.dunkley@crocodilertc.net> wrote:
> 
>> Even if TLS is left as MUST all of the additional checks from the RFC cannot be enforced on the client because (in a browser) you don't have any access to that information.
> 
> So help educate me on what is missing and lets go get that fixed in web sockets. 
> 

THis is interesting. If I parse the W3C WebSocket API specification correctly, the script is not allowed to know WHY a Websocket connection failed. It's just a big failure. I would like to understand why they made this choice.

I wonder if this mixes TLS authentication with TLS encryption. We are not allowed to set up an encrypted WS connection to a self-signed cert or in general a server with a cert signed by an unknown CA even if we want to.

I just did a quick check - someone else may know ways around this. (I hope).

/O

----
User agents must not convey any failure information to scripts in a way that would allow a script to distinguish the following situations:

	• A server whose host name could not be resolved.
	• A server to which packets could not successfully be routed.
	• A server that refused the connection on the specified port.
	• A server that failed to correctly perform a TLS handshake (e.g., the server certificate can't be verified).
	• A server that did not complete the opening handshake (e.g. because it was not a WebSocket server).
	• A WebSocket server that sent a correct opening handshake, but that specified options that caused the client to drop the connection (e.g. the server specified a subprotocol that the client did not offer).
	• A WebSocket server that abruptly closed the connection after successfully completing the opening handshake.
In all of these cases, the the WebSocket connection close code would be 1006, as required by the WebSocket Protocol specification. [WSP]

Allowing a script to distinguish these cases would allow a script to probe the user's local network in preparation for an attack.
-----

v2.23.0 | Report a Bug | By Email