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

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

Absolutely false. This solution is totally viable. Don't take Opera's 
word for it: Just track the top 200 sites which require HTTPS login in 
your system (which covers 95%+ of the traffic), contact the site owner 
to get approval and off you go. Very viable. Also create a process by 
which  content owners can add their sites to the whitelist (of course, 
they'll need to prove who they are).

Of course, this may mean less content to transcode, but this is a 
different story. Is it W3C's responsibility to run to the rescue of 
transcoders' abusive business practices?

Let me ask you a question. I am a content provider. I don't want my 
content to be transcoded so I decide to use HTTPS. What am I doing 
wrong? why isn't this protecting me from transcoders?

For the practical possibilities:

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

Personally, I would be OK with this idea. Staying silent would mean that 
transcoder can keep doing it, but they would be unable to quote W3C in 
defense of what many will perceive as an abuse.


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

Would you write best practices for Peer2Peer downloading? I guess you 
wouldn't, because peer2peer means illegal downloading of copyright 
material in most cases. I don't really see a difference between this and 
breaking HTTPS. If someone does it, they do it at their own risk.
If W3C does write guidelines for p2p, they should at least also write 
"downloading copyrighted material is illegal". Simple, isn't it?


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

just a big mess. Far from bringing order, it would give an excuse to 
transcoders and others to do whatever they want with HTTPS. And it would 
also cover W3C with ridicule as a side effect.

Luca

Francois Daoust wrote:
> 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 11:59:51 UTC