W3C home > Mailing lists > Public > public-bpwg@w3.org > January 2009

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

From: David Storey <dstorey@opera.com>
Date: Tue, 20 Jan 2009 14:01:55 +0100
Cc: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
Message-Id: <E9A619F5-C58E-48BC-8733-8EEDC338471F@opera.com>
To: Luca Passani <passani@eunet.no>


On 20 Jan 2009, at 12:59, Luca Passani wrote:

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

It is quite obvious you don't deal with such stuff.  My main job at  
Opera is site compatibility, and working with web sites to fix issues  
in Opera.  We contact sites day in, day out.  Just getting replies  
from 200 sites (which is a tiny fraction of those using SSL) would  
take best part of a year, probably more, never mind getting past the  
support person, to someone that knows what one is talking about, then  
finding a manager that can make a decision, then coming to consensus.

I'm not sure where you get the covers 95%+ of the traffic either.   
That is not true.

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

David Storey

Chief Web Opener,
Product Manager Opera Dragonfly,
Consumer Product Manager Opera Core,
W3C Mobile Web Best Practices Working Group member

Consumer Product Management & Developer Relations
Opera Software ASA
Oslo, Norway

Mobile: +47 94 22 02 32
E-Mail: dstorey@opera.com
Blog: http://my.opera.com/dstorey
Received on Tuesday, 20 January 2009 13:02:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:53 UTC