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 01:44:32 +0100
Cc: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
Message-Id: <F4171248-5244-4B83-804F-4E4A0CE31B63@opera.com>
To: Luca Passani <passani@eunet.no>


On 20 Jan 2009, at 01:24, 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.
>
> 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.
>
> 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.

Just to make it clear, the proxy encrypts and decrypts its own SSL  
session, and doesn't intercept another session.  It requests a session  
from the site and another from the users.  A session is not intercepted.

The all happy part isn't true.  Your proposal is an unworkable  
solution. I hope the W3C isn't about specifying unworkable solutions,  
so I dout that is a solution they can put forward.

>
>
> 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.
>
> 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 00:45:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:59 UTC