Re: [hybi] WebSocket, TLS and intermediaries

"Thomson, Martin" <Martin.Thomson@andrew.com> Wed, 21 July 2010 00:45 UTC

Return-Path: <Martin.Thomson@andrew.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 239303A69BB for <hybi@core3.amsl.com>; Tue, 20 Jul 2010 17:45:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.13
X-Spam-Level:
X-Spam-Status: No, score=-3.13 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_00=-2.599]
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 yoNE4nA+RMac for <hybi@core3.amsl.com>; Tue, 20 Jul 2010 17:45:09 -0700 (PDT)
Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 42AEA3A69B2 for <hybi@ietf.org>; Tue, 20 Jul 2010 17:45:09 -0700 (PDT)
Received: from [10.86.20.103] ([10.86.20.103]:52644 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S284895Ab0GUApZ (ORCPT <rfc822; hybi@ietf.org>); Tue, 20 Jul 2010 19:45:25 -0500
Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 20 Jul 2010 19:45:25 -0500
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 21 Jul 2010 08:45:19 +0800
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: Greg Wilkins <gregw@webtide.com>, Roberto Peon <fenix@google.com>
Date: Wed, 21 Jul 2010 08:47:28 +0800
Thread-Topic: [hybi] WebSocket, TLS and intermediaries
Thread-Index: AcsobP215VdlkMHyQwK4cYE4AMXu8QAAHS1A
Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB773169@SISPE7MB1.commscope.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>
In-Reply-To: <AANLkTikGLuKhFKd5YcuAKPit5TKzH2y6hYrC6rAyxG-c@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com
X-BCN-Sender: Martin.Thomson@andrew.com
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 00:45:11 -0000


Greg Wilkins on 21 July 2010 10:36 AM:
> 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.

+1

Despite the fact that a policy-enforcing proxy often causes a lot of grief, the alternative is worse.  We don't need another arms race.  Recognizing that people will enact policy, and providing ways that clients can cooperate, is more constructive than trying to circumvent policy measures.

--Martin