- From: David Storey <dstorey@opera.com>
- Date: Tue, 20 Jan 2009 01:44:32 +0100
- To: Luca Passani <passani@eunet.no>
- Cc: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
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