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

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

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

Received on Tuesday, 20 January 2009 00:25:23 UTC