Re: [hybi] Call for interest: multiplexing dedicated for WebSocket

Roberto Peon <fenix@google.com> Thu, 30 May 2013 18:28 UTC

Return-Path: <fenix@google.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 8405821F8EFC for <hybi@ietfa.amsl.com>; Thu, 30 May 2013 11:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 10f-a7KgBcFN for <hybi@ietfa.amsl.com>; Thu, 30 May 2013 11:28:53 -0700 (PDT)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id DCBE121F8EF2 for <hybi@ietf.org>; Thu, 30 May 2013 11:28:52 -0700 (PDT)
Received: by mail-la0-f50.google.com with SMTP id ed20so574774lab.23 for <hybi@ietf.org>; Thu, 30 May 2013 11:28:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=poLSB5a/qI3oL9a4+5s+3+i3HwRCv+m4BNifgbm7PuM=; b=ZSkH05mbEg/hfUFoSNa5YiwNVnM0Vwg5imgETgH1iiM/xDMveQnV5W57KmUrxC1Z69 heew098BPw0t7mh79TKPw94PefyfP3SmkbOYLIgz7qu8kfdYpnUTfxwrUIDhDkiUIgFa oAVLhYeektwbzJ4egCU9FS5DgSokPtMlPBJLLJHHrHX1D3EJUMIpset/qr4YszkpJ7mZ 0TyWjRBuHB6i1E8FU67/9piMIKa+RkY+Og4BFeKdrusTHkxPnWBm975U9aFI1hkbjJNX hyyv1p27sW4DwVwfnBlJqnwHgq79VRvBdhzIJRfXeRCgKEuYmDGDrNYIR/TB3lMmm5Nc 3L+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=poLSB5a/qI3oL9a4+5s+3+i3HwRCv+m4BNifgbm7PuM=; b=CEVhqYDKWqlJhTP40sVbWQQ7HYpUwHx5w5WV9IgvrSzSa1JPs8CjhB+ILqzOoiuQ3K 85tro+vUUdkkm4DWCqbS1yxH+RwPLSnVLv8czQBc1uh3uwQy3TaYtX434KiHo0rAN458 2oPfxiiehs6t4zBdz0FvoX55weqFz/B/7dBAIveuKgRwOHolqhCqQXaRWX8QixXIwhKb j2fMGRu//0JpaMvLuJWCFoMhI7UrcI0jYeZ7c3eWr9E6zFEJLbTpDVZSRgBZ8UTV1AEs c6RUX+tiiBkfKR4Wi4MBBab68T9cZU8+VJg2LYOw1B/BpnZCbHbLvoTksEeUYATgRUB1 9tPQ==
MIME-Version: 1.0
X-Received: by 10.112.158.6 with SMTP id wq6mr4334241lbb.108.1369938531652; Thu, 30 May 2013 11:28:51 -0700 (PDT)
Received: by 10.112.76.231 with HTTP; Thu, 30 May 2013 11:28:51 -0700 (PDT)
In-Reply-To: <51A70DF9.5010601@tavendo.de>
References: <CAH9hSJZxr+aG7GZa4f-dUOTGj4bnJ+3XxivUX4jei5CMyqN4LQ@mail.gmail.com> <634914A010D0B943A035D226786325D4422C319646@EXVMBX020-12.exch020.serverdata.net> <CAH9hSJYrrbSM3TTSKCQ=AMcwCfE4zqNAa1kuAvecrXZTLqy2gQ@mail.gmail.com> <634914A010D0B943A035D226786325D4422C3DA774@EXVMBX020-12.exch020.serverdata.net> <CAHixhFrTk79A07BjQCgvep_+bmA4rGG1ZvqmoS6gsQYNPyPoZA@mail.gmail.com> <CAH9hSJYFa+bqN=e7x87W+Xvq-st70nbzUXniQaPme2fzspCjWA@mail.gmail.com> <51A70DF9.5010601@tavendo.de>
Date: Thu, 30 May 2013 11:28:51 -0700
Message-ID: <CAGzyod6daSOvAVHU6B=Qr0xDqNca_8iXrFYr0gTGdqZPryFFpA@mail.gmail.com>
From: Roberto Peon <fenix@google.com>
To: Tobias Oberstein <tobias.oberstein@tavendo.de>
Content-Type: multipart/alternative; boundary=001a11c268308b27ba04ddf3ab56
X-Gm-Message-State: ALoCoQnYdaufkXvidZE+Hrr5q/PBG5Yh7SLpjG79lIz1CYIctPRHgz7W6gjk1Bvd7+zZPVEKK7ewTAw7P0RxYhmJpNYn+/gigouogXYi56zJHtReYk0sj5SXvRlFBPqEFhzzS8hQa6aegdgYD5lJ1U7RYJpXEZVoHMUghaMagjsJcAUUabejzzIn7eq6obem0wBWMaUuJqDA
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket
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: Thu, 30 May 2013 18:28:54 -0000

Different schemas have nothing to do with the CRIME attack.
A pure HTTPS or WSS scheme could still be attacked with CRIME, with its
success depending on the way the compression mechanism works.
With the current HTTP/2 proposals it would be pretty difficult to attack
using the techniques in the CRIME attack.

The way CRIME works is to have a 3rd party include links to the
site-to-attack. Thus it doesn't matter if the schemes are http, https, ws,
wss, whatever.
So, a restriction against muxing ws and wss together makes no sense as it
provides no security benefit for CRIME.
-=R


On Thu, May 30, 2013 at 1:29 AM, Tobias Oberstein <
tobias.oberstein@tavendo.de> wrote:

>  Am 30.05.2013 09:28, schrieb Takeshi Yoshino:
>
> On Thu, May 30, 2013 at 1:12 PM, Adam Rice <ricea@google.com> wrote:
>
>>   So d) - f) cannot be multiplexed over the same physical WS as a) - c)?
>>>
>>> Or can an implementation just "silently" transport a)-c) also over wss,
>>> and hence multiplex all of a) - f) over 1 physical WS?
>>>
>>
>>  The handshake does not currently include the schema, so there would be
>> no way to communicate to the server that a)-c) were supposed to be ws:, not
>> wss:.
>>
>
>  Right. I missed that point.
>
>
>>   Even if this was amended, both client and server would have to be
>> careful that no ambient authority leaked from the wss: channels to the ws:
>> channels. For example: the client would have to be careful not to send
>> "secure" cookies with the ws: handshakes, and the server would have to be
>> careful not to apply any authority contained in a client TLS certificate to
>> the ws: logical channels.
>>
>>  For this reason, I think it would be easiest not to attempt to
>> multiplex ws: and wss: onto a single TCP/IP connection.
>>
>
>  Compression contexts, etc. also need to be isolated carefully to protect
> it from attack like CRIME.
>
>
>
> I also agree with Adam. To summarize, given the possible "issues" of
>
> - client cert based auth
> - "secure" cookies / ambient authority
> - compression contexts / CRIME
>
> (plus complexities like: what if an app opens ws://domain.com, and then
> _later_ opens wss://domain.com? Upgrade to TLS not possible anymore ..
> cannot TLS handshake in the middle of an already established non-TLS TCP
> where some traffic already traveled .. the WS handshake at least.)
>
> I think it would be good to include explicit text into the MUX draft, e.g.
>
> """
> An implementation MUST NOT multiplex multiple logical channels to
> WebSocket addresses with different schemes (ws: versus wss:) on a single
> physical WebSocket connection.
>
> For example, two WebSocket connections to ws://domain.com and
> wss://domain.com must not be shared on a single physical WebSocket
> connection to domain.com.
> """
>
> I also think it would be helpful to include explicit text describing what
> WebSocket addresses are eligible for sharing, e.g.
>
> """
> An implementation MAY multiplex multiple logical channels to different
> WebSocket addresses if and only if the WebSocket addresses share the same
> WebSocket scheme, the hostname resolves to the same IP address and the same
> port.
>
> For example, connections to all of the following WebSocket addresses may
> be multiplexed over a single physical WebSocket connection (assum
> domain.com, domain2.com and sub1.domain.com all resolve to the same IP
> address):
>
> ws://domain.com
> ws://domain.com:80
> ws://domain.com/foo
> ws://domain.com:80/foo
> ws://domain.com/bar
> ws://domain2.com
> ws://sub1.domain.com
> ws://sub1.domain.com:80
> ws://sub1.domain.com:80/bar
>
> Note: When a WS address does not specify an explicit port, the port is the
> default port for the given WS scheme (ws: = 80 and wss: = 443).
> """
>
>
>
>
> /Tobias
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>