Re: [hybi] WebSocket, TLS and intermediaries

Maciej Stachowiak <mjs@apple.com> Wed, 21 July 2010 01:20 UTC

Return-Path: <mjs@apple.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 A584E3A6A84 for <hybi@core3.amsl.com>; Tue, 20 Jul 2010 18:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level:
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 KuC6JFIWx1u2 for <hybi@core3.amsl.com>; Tue, 20 Jul 2010 18:20:31 -0700 (PDT)
Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id EE25E3A69B0 for <hybi@ietf.org>; Tue, 20 Jul 2010 18:20:30 -0700 (PDT)
Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id ED37C9EAB2B5 for <hybi@ietf.org>; Tue, 20 Jul 2010 18:20:46 -0700 (PDT)
X-AuditID: 11807137-b7b43ae000004f8e-b4-4c464b6e247d
Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay16.apple.com (Apple SCV relay) with SMTP id D4.57.20366.E6B464C4; Tue, 20 Jul 2010 18:20:46 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_KG934hvKPjXk82SQ1QDmlA)"
Received: from [17.151.78.226] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L5V00JU2VQM6V10@gertie.apple.com> for hybi@ietf.org; Tue, 20 Jul 2010 18:20:46 -0700 (PDT)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <AANLkTikGLuKhFKd5YcuAKPit5TKzH2y6hYrC6rAyxG-c@mail.gmail.com>
Date: Tue, 20 Jul 2010 18:20:46 -0700
Message-id: <852209CE-F064-4FE3-A6FC-A91A90DEF749@apple.com>
References: <h2w5c902b9e1004152345j992b815bz5f8d38f06a19181a@mail.gmail.com> <Pine.LNX.4.64.1004160701250.751@ps20323.dreamhostps.com> <4BC860FD.8080007@webtide.com> <Pine.LNX.4.64.1004161952530.751@ps20323.dreamhostps.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> <AANLkTinihlL2sn3Kiwtcl7QYKhFlvmj9lvmH4_z02xF7@mail.gmail.com> <FC1F510E-6D48-4D75-A356-F455C9FD5BD8@apple.com> <AANLkTiko_Pjie0FNRvLHsh5PAotW2a6OH=6oapEhJBOQ@mail.gmail.com> <AANLkTikGLuKhFKd5YcuAKPit5TKzH2y6hYrC6rAyxG-c@mail.gmail.com>
To: Greg Wilkins <gregw@webtide.com>
X-Mailer: Apple Mail (2.1081)
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] WebSocket, TLS and intermediaries
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, 21 Jul 2010 01:20:32 -0000

On Jul 20, 2010, at 5:35 PM, Greg Wilkins wrote:

> 
> 
> On 21 July 2010 10:15, Roberto Peon <fenix@google.com> wrote:
> 
> Schools and other institutions will block port 443 if they feel unacceptable content is flowing over it and they have other means of dealing with it.
> I believe that this means that we need an 'authorized proxy' model. No proxy would be fully transparent (unless it was a reverse proxy representing the real endpoint), however it should be exceptionally easy to install a policy allowing the proxy explicitly. It is a hair more annoying for the user than no proxy, but it gives schools, etc. a way to control the computers that they own without blocking port 443 for everyone and everything.
> 
> +1
> 
> As Mike has said, there are good motives and bad motives for intermediaries. We have to find a way to allow the good motives to be supported, even if that costs a bit of complexity in the handshake/protocol.
> 
> Having explicit intermediaries would be very useful for knowing  timeouts, optimizing keepalives and security considerations.

In the TLS case, authorizing an intermediary has to require some form of explicit configuration on at least one of the client or the server. Otherwise it is vulnerable to MITM. On the server side, the intermediary could plausibly have access to the server's certificate, so it can just pretend to be the endpoint to the client. On the client side, there has to be some way to authorize a root cert for use with WebSocket, so the intermediary can MITM you. If it needs to be easier than this, then that seems like primarily a browser UI issue, not a protocol issue.

We could do other things for the non-TLS case, but I am increasingly convinced that the non-TLS case is uninteresting.

Regards,
Maciej