Re: ACTION-893: Start putting together a set of guidelines that could help address the security issues triggered by links rewriting.

Luca Passani wrote:
> 
> 
>>  In short, there is a trade-off on security when HTTPS is used
>>  without client-side certificates. The conclusion I draw is that I don't
>>  think we can infer that Content Providers must be opposed to
>>  transcoding because they use HTTPS.
> 
> Francois, I am not sure what you are trying to obtain with this kind of 
> reasoning, anyway your logic does not seem very solid.
> 
> The point here is that those who use HTTPS do not want anyone to 
> interfere with their data. Some may be OK with transcoding, but the 
> others are not. The second group are the ones for which HTTPS must be 
> respected no matter what. You cannot say "because someone may be OK with 
> transcoders breaking end2end security, then it must be OK for everyone 
> that end2end security is broken by transcoders". It's not logical.

My point here is that we shouldn't base our argumentation on what 
some/most/a few Content Providers or users want. I'm pretty sure that if 
we ask Content Providers (and users) "do you want things to be secure?", 
they will reply "Sure!". They will also reply "Sure!" to "do you want 
your content to be accessible by anyone and on any device?". We should 
rather focus on what is being done, why, and see if there are things 
that may be done to ensure content stays as secure as possible.

 From an architectural point of view, it doesn't look so bad to have 
limited browser clients and to deport heavy processing on to server 
parts. The problem is that there is no absolutely secure and end2end way 
to do that. One could imagine that instead of tunneling the HTTP content 
on a secure layer, we could perhaps only encrypt portions of the content 
that contain sensitive information. I think XML Encryption can do just 
that, but I have no idea whether this can be considered robust enough. 
If it is, then it could be one way to keep sensitive information secure 
while enabling transcoding in the middle in the future.

Even if that's possible, it is not currently supported by browsers 
anyway. In the meantime, there is a need, because personalization is 
everywhere on the Web and login forms all use HTTPS, no technological 
solution, and one possibility triggered by the fact that security on the 
Web currently relies more on the user authenticating the server than on 
the server authenticating the user. In theory, if a third-party 
transcoder replaces an end2end connection by an end2proxy + proxy2end 
connection, then the user should be told that his HTTPS session is with 
the transcoder and not with the origin server. In practice, the user 
won't understand anything, and information on the HTTPS session on 
mobile browsers is hard to find anyway.

In the end, we may:
  1. stay silent. I'm not sure it solves anything, but we're a "best 
practices" working group, and these are "needed practices when you do 
something that is not a best practice". We may not be in the correct 
position to say anything here. Besides, recommendations tend to be 
easily misunderstood, so it may not be that a bad idea.
  2. explicitly forbid links rewriting and/or changing the HTTPS 
endpoint, and promote mobile web best practices ("You want things to 
work, make them work!"). The risk is of course to have cool guidelines 
that no one follows in practice.
  3. acknowledge that it is being done and start from there to try to 
find ways to limit the impact, and maximize security. This could be more 
useful to raise awareness on the dangers of playing with secure content.

The guidelines will never say: "Sure, go ahead, replace end2end secure 
connections by end2proxy + proxy2end connections, no big deal", simply 
because it is not true.

> 
> If I create an HTML document, that's probably because I want to publish 
> it on the web. Granted, my intention may be to publish on an Intranet, 
> but inferring that all HTML documents are made to be published on 
> Intranets is not a logical implication.

I do not understand what this refers to. I only mentioned corporate 
intranets as a use case that already makes use of client-side 
certificates, the point being that it is possible.


> 
> If anything, your reasoning supports the solutions I explained to David 
> yesterday: since someone may be OK with transcoders breaking HTTPS for a 
> good reason, go and ask site owners whether they accept the idea that a 
> transcoder decrypts and re-encrypts HTTPS. Do this and we are all happy.

I would be happy too. But this solution is not viable. It does not scale.


> 
> Again, I don't understand what your final goal is here. HTTPS is the 
> foundation of e-commerce. Why would W3C create a document which 
> implicitly weakens this foundation? please explain, because this is 
> beating me.

This could be a reason to stay silent. I think we should at least 
explore all the issues and potential solutions before we decide not to 
say anything.


Francois.



> 
> Luca
> 
> Francois Daoust wrote:
>> I see "HTTPS is end2end security" being exchanged in the discussion.
>> I can't help thinking that there is a "yes, but" here.
>>
>> HTTPS is end2end security, but one of the ends is usually not 
>> identified, or rather not "properly" identified. There is an asymmetry 
>> in the way HTTPS is being used today: server-side certificates are the 
>> rule, while client-side certificates are reserved for very specific 
>> needs such as access to corporate intranets, or income tax declarations.
>>
>> The use of client-side certificates makes it possible for servers to 
>> assert that the end-user is really the end-user, because the
>> authentication is inherently more secure when the user is asked for 
>> something he knows (password) *and* for something he has 
>> (certificate). It would make it possible to reject ends that are 
>> actually something in the middle, or someone else who happens to know 
>> the user's credentials.
>>
>> What I find interesting is that there has been support for client-side 
>> certificates for some time on desktop-browsers (I do not know if that 
>> is the case on mobile browsers, but that's not really the point here) 
>> and yet it didn't take (or hasn't taken yet, it all depends on your 
>> point of view).
>>
>> Client-side certificates come with a series of shortcomings. They are 
>> a pain to install, understand, and use. They need to be installed on 
>> all the devices a user may use to browse the Web (or carried out on a 
>> USB key). Besides, they could be stolen, and in the particular case of 
>> Content Transformation, delegation mechanisms could also be used to 
>> make them available to proxies anyway. In short, the solution is not 
>> so wonderful.
>>
>> But, if Content Providers truly wanted to protect their data more than 
>> to enable the ease of access, client-side certificates would be much 
>> more of a rule, and users would have been educated on them. The 
>> man-in-the-middle possibility has always existed and is the base of 
>> most phishing attacks.
>>
>> In short, there is a trade-off on security when HTTPS is used without 
>> client-side certificates. The conclusion I draw is that I don't think 
>> we can infer that Content Providers must be opposed to transcoding 
>> because they use HTTPS.
>>
>> Francois.
>>
> 
> 
>

Received on Tuesday, 20 January 2009 10:11:03 UTC