Re: [TLS] Next protocol negotiation

Marsh Ray <marsh@extendedsubset.com> Wed, 20 January 2010 16:54 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34E203A6837 for <tls@core3.amsl.com>; Wed, 20 Jan 2010 08:54:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Level:
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 WAQxFxkrzHAm for <tls@core3.amsl.com>; Wed, 20 Jan 2010 08:54:43 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 47BDC3A6823 for <tls@ietf.org>; Wed, 20 Jan 2010 08:54:43 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NXdpH-0002Rc-0t; Wed, 20 Jan 2010 16:54:39 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 49349631F; Wed, 20 Jan 2010 16:54:33 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+Ocl/EwdCsa0JjaZ+NpeLt0fwZlGPQ134=
Message-ID: <4B573548.3090804@extendedsubset.com>
Date: Wed, 20 Jan 2010 10:54:32 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Steve Dispensa <dispensa@phonefactor.com>
References: <C77C8BDE.E62A%dispensa@phonefactor.com>
In-Reply-To: <C77C8BDE.E62A%dispensa@phonefactor.com>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Next protocol negotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jan 2010 16:54:44 -0000

Steve Dispensa wrote:
> On 1/20/10 10:26 AM, "Marsh Ray" <marsh@extendedsubset.com> wrote:
>> One point of view is that firewall admins are ports because of their
>> intentional policies and it is their right to control what goes on on
>> their own network.
> 
> That's giving many administrators too much credit; the new WizBang
> FireScannerProxyWallThingy(TM) is configured to automatically block anything
> and everything, because that's what WizBang's coders read was best practice
> in the latest Gartner report, and the administrator is only dimly aware of
> what's really going on. He just knows he can check the box on this year's
> SAS-70 audit.

That's an intentional policy which is their right to set (whether it's a
good one or not).

> Surely you're right some of the time, but I suspect stuff gets automatically
> blocked more often than not.

Blocking outbound connections based on destination port number is
particularly stupid since it's a parameter trivially controlled by an
attacker.

It's more a tactic to discourage people within the organization from
using new protocols. Malware won't have any problems though.

There will never be a clean and standardized way to get around firewalls
that are trying to block you. Once a technique shows up on the radar,
sooner or later it will get subjected to policy. The radar seems to get
faster over time, too.

For a high-profile company like Google to develop a new transport for
the web, the best method might very well be to just get a proper port
number allocation and make the protocol useful and secure enough that
admins actually let it thorough. One thing that might help would be to
make it easy for filtering proxies to inspect.

- Marsh