Re: The TLS hammer and resource integrity

On 28.03.2012 17:14, Martin Thomson wrote:
> On 28 March 2012 05:55, Martin Thomson wrote:
>> We have already touched on this in discussions of SPDY, but I wanted
>> to make a statement on this prior to the meeting on Thursday.
>>
>> TLS is a great tool in the protocol design toolbox.  It provides a
>> great many things together.  Confidentiality, integrity,
>> authorization, and so forth.  Therefore, it is very easy to pick up
>> that tool and apply it without a complete analysis of the treat 
>> model
>> and what aspects of that model it addresses.
>>
>> Mixed content (see Monday's plenary topic) is a good example of 
>> where
>> TLS doesn't necessarily provide the best trade-off of all the 
>> security
>> options present.  The classic concern is that I have a TLS-secured
>> page that pulls in content over HTTP in the clear.  That unsecured
>> content can then potentially poison the entire page.
>>
>> The property that is required in the mixed content scenario is
>> integrity.  The host page might not care that confidentiality is
>> maintained when requesting this content, but it really does care 
>> that
>> the content matches the content that it expects.
>>
>> Today, the only option we have available to deal with this problem 
>> is
>> TLS.  And along with our integrity (and source authentication), we
>> also get confidentiality.  This is occasionally desirable, but
>> frequently, it is merely consequential.
>>
>> One significant downside to this arrangement is that confidentiality
>> also rules out intermediation options that could be hugely 
>> beneficial.
>>  Now it is no longer possible to cache copies of JQuery all over the
>> web.  (TODO: deal with obvious CDN counter-argument)
>>
>> Intermediation is a fundamental part of the web architecture and
>> building a protocol that makes this inherently difficult would be a
>> disservice to the web.
>>
>> The separation of resource integrity from communication
>> integrity/confidentiality is something that I know others have been
>> thinking about.  I'd like to see this discussed in HTTP/2.0.
>>
>> --Martin
>>
>> long p.s. I should include a reference to the work from decade, that
>> deals with exactly this sort of problem in an environment that
>> consists entirely of unauthoritative "intermediaries".
>>
>> One proposed solution, which should probably be at least considered,
>> is to provide a content-specific identifier for a resource.  That is 
>> a
>> resource is identified by a hash of its representation, so that a
>> modified representation can be easily detected.  This might actually
>> be more restrictive than is entirely ideal, but it is worth knowing
>> about:see draft-farrell-decade-ni.
>
> I forgot an important point:
>
> As we develop a more nuanced view of what security means, how we
> communicate with users and signal in protocols becomes more relevant.
> Showing a lock icon or green/blue address bar has a meaning that 
> users
> think that they understand.  For those that pay that much attention,
> this is a sign that entering credit card details is OK.

All of which is countered with the tiny little fact that said 
green/padlock says nothing about whether the transaction is either 
confidential or private, or going where the user thinks its going. It 
merely says *a* trusted place is connected. Full stop, end of story, 
hand your corporate admin a credit card number to continue.

The amount of trust that users are being taught to place in such 
simplistic arbitrary green/yellow/red colorations far out of sync with 
reality of what they mean.

I completely agree that this needs to be addressed, but the transport 
appears to be doing everything right so far. We have port-443 with 
mandatory TLS. We have Upgrade: to roll out TLS into the unsecured 
areas. We have ubiquitous HTTP middleware capable of receiving and 
sending TLS hop-by-hop or end-to-end as desired. It is the 
implementations which are lagging in support or opting out of using 
security far too often for comfort.

AYJ

Received on Wednesday, 28 March 2012 05:15:30 UTC