Re: [TLS] Next protocol negotiation

[Adam Langley <[e-mail]>]

On Wed, Jan 20, 2010 at 8:26 AM, Marsh Ray <[e-mail]> wrote:
> Adam Langley 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. Port 443 is going to be less useful over time as more
> sites deploy SSL-inspecting proxies.

Organisations that deploy intercepting proxies and port blocking
middleware (etc) have reasonable policy goals that they are trying to
implement. These people, for the most part, are not bad nor evil.

But one cannot expect them to understand the value of the end-to-end
principle. They are evaluating different solutions and balancing cost
and utility, as it effects them. It turns out that many of them end up
choosing networking hardware for caching, virus-scanning, content
control etc.

These network based solutions can be cheap, but they achieve these
cost reductions, in part, by imposing negative externalities on the
rest of the world. It's the case these days that HTTP traffic will
usually be 'transparently' intercepted at least once. DNS traffic is
likewise adulterated, as are many other protocols. Because of this,
protocol advances are delayed or lost. (HTTP pipelining is one
example, there are many others including our own SDCH[1]).
Unfortunately, these losses to the world are non-obvious to many and
hard to measure.

TLS is attractive because it is obviously much more resistant to these
machinations. (I'm aware that such devices do exist to intercept SSL,
but they should hopefully be intrinsically more limited.)

I admit that by using TLS we are bypassing (preferably) these
middleware boxes. Because of this, the cost/benefit analysis of these
boxes will hopefully shift so that people start to look for other
solutions. We know that we'll have to provide alternatives, but these
can be designed so as not to consign the public Internet to slow
stagnation at the bottom of the protocol stack.

[1] http://en.oreilly.com/velocity2008/public/schedule/detail/2598

> Port 443 to a proxy server with the CONNECT verb usually works.
>
> It is rumored that many firewalls will pass anything over port 53.
>
> On many corporate Windows PCs, the 'proxy server' info available in the
> registry is the only reliable way to make outbound connections.

Port 53 is not as clean as one might hope. CONNECT and port 443 often
works, but then we have the same issue as we currently face: how to
disambiguate protocols when the TCP port mechanism is unavailable.
Next protocol negotiation is our proposed solution.

> Thank you guys for caring about 200ms of my finite lifetime.

You're welcome although, as noted, the actual delay usually ends up
being several multiples for web pages as subresource discovery is
slowed down for other domains.


AGL