Re: [TLS] Next protocol negotiation

[Yoav Nir <[e-mail]>]

On Jan 20, 2010, at 6:52 PM, Adam Langley wrote:

> 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.)

Currently, it is, but processing power is cheap and getting cheaper.

> 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.

Actually, I think this will shift the cost/benefit analysis of the SSL-inspecting proxies.  As more applications move to the "all the Internet over port HTTPS" paradigm, the administrators will have more incentive to deploy these proxies. If policy says that all files sent to people in other companies needs to be scanned by the data leakage prevention software, and some application like Skype sends files to your contacts over port 443, then you need something to look into the SSL. So I agree with Marsh - the proxy will become more common with time.

> 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.
>