Re: [hybi] Why not just use ssh?

Gabriel Montenegro <gmonte@microsoft.com> Wed, 01 September 2010 00:15 UTC

Return-Path: <gmonte@microsoft.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 953463A6859 for <hybi@core3.amsl.com>; Tue, 31 Aug 2010 17:15:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTehqIaLBQQs for <hybi@core3.amsl.com>; Tue, 31 Aug 2010 17:15:48 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 6DC383A684D for <hybi@ietf.org>; Tue, 31 Aug 2010 17:15:48 -0700 (PDT)
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 31 Aug 2010 17:16:12 -0700
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.218.10; Tue, 31 Aug 2010 17:16:12 -0700
Received: from TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com ([169.254.5.40]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Tue, 31 Aug 2010 17:16:10 -0700
From: Gabriel Montenegro <gmonte@microsoft.com>
To: Adam Barth <ietf@adambarth.com>, Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [hybi] Why not just use ssh?
Thread-Index: AQHLSUzSR2eDhQU26kquYicz/SaRxpL8gHaAgAAGiAD//7V2oA==
Date: Wed, 01 Sep 2010 00:16:16 +0000
Message-ID: <CA566BAEAD6B3F4E8B5C5C4F61710C110FAFBCBD@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com>
References: <d48398080b610405d982ffd924f58e27.squirrel@sm.webmail.pair.com> <AANLkTin8CiHFoOSFdcRPern5YY-FdODC4GST+BrP3t_j@mail.gmail.com> <AANLkTi=fn2JE7a0b_0KFFLwq3eG_-xnaRazXAMPGi0N3@mail.gmail.com>
In-Reply-To: <AANLkTi=fn2JE7a0b_0KFFLwq3eG_-xnaRazXAMPGi0N3@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Why not just use ssh?
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 01 Sep 2010 00:15:50 -0000

> On Tue, Aug 31, 2010 at 1:55 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> > Adam: I'm not entirely clear on your point. I agree that if the HTTP
> > version is more vulnerable to cross-protocol attacks than attackers
> > will exploit it, but if the HTTP and HTTPS versions are equally
> > vulnerable, why would attackers favor HTTP? What am I missing.
> 
> I'm fairly convinced that the TLS version is free of cross-protocol vulnerabilities.
> However, the same cannot be said for the non-TLS version.  The security
> argument for the non-TLS version is pretty dodgy, IMHO.  So, I don't think the
> two are equally vulnerable.

I think there's two meanings of "offering both TLS and non-TLS versions".  
1. allow the protocol to use either HTTP or HTTPS (+Upgrade) variants of WebSockets (i.e., either ws: or wss: URLs).
2. *deploy* a given service over both HTTP and HTTPS (+Upgrade) variants of WebSockets (a given service over both ws: and wss:)

One does not imply the other (as we see with many web services today). If your policy does not allow the plain HTTP ws: variant, then the server will not reply with a 101 to the Upgrade request from the client. 

I might have missed that part of the discussion, but, if the server is replying to an Upgrade (perhaps over HTTPS) with a 101, and with a random nonce sent by the client, how is this vulnerable to a cross-protocol attack? 

The NPN mechanism is not a slam-dunk in the TLS working group, judging from the exchanges there, but still you suggest that NPN be the *only* mechanism allowed for Websockets. I'm fine with it being investigated for later use (in line with Alexey and Salvatore's messages to the list, and in line with the created ticket). But I think it would be a bad idea to impose NPN as the one and only available mechanism as you claim. Even within NPN usage you're not free of applying policy, as there is the potential for multiple certs being used for a given WS service, and whenever you have such options there is the possibility of a bidding-down attack (not very different from what is possible #2 above is true). 

Is the argument that NPN saves on round-trips? That is very important, particularly for certain applications, like search, but does the data shown, say, at the Velocity conference apply equally to long-lived sessions (such as a web chat)?