Re: ACTION-893: ... the security issues triggered by links rewriting.

On Tue, 03 Feb 2009 13:48:15 +0100, Tom Hume  
<tom.hume@futureplatforms.com> wrote:

> To me, there are a few factors which make security implications of HTTPS  
> link rewriting more serious:
>
> 1. Users are not aware of it when it happens; my mother might enjoy a  
> fully-secure connection on her handset on O2, and an insecure one when  
> on Vodafone, say;

I must be missing something from earlier in the discussion. How would this  
occur in practice, other than by her having chosen some service?

> and be both unaware of the difference and unable to make an informed  
> decision as to security without understanding the underlying models for  
> it. Worse - the handset would likely use typical browser mechanisms  
> (e.g. a padlock icon) to reassure mater that she's enjoying full  
> security, when this is not in fact the case.

Unfortunately our dear Maters aren't really aware of the underlying  
security models anyway. The padlock says that there is encryption  
somewhere, but makes no claim that she is talking to who she thinks she is  
talking to - and phishing her is far more effective than cracking her  
https transaction. Which is why browsers have been working on better  
security and better ways of explainging it to people who actually don't  
even want to know.

> 2. Whilst key-loggers introduce similar problems in individual clients,  
> the security issue seems amplified by transcoders - in that a security  
> issue in a transcoder deployment would put many sessions at risk, not  
> one.

Against which, transcoders are large-scale targets for hacking and  
testing, so the time exposure is generally far shorter.

> 3. Some content providers might reasonably expect that by providing  
> services over HTTPS, they can be assured of end-to-end security; and  
> this does reduce such security.

Not as I understand it (let me be clear that in my assumption, the user  
has somehow explicitly permitted the browser to be using a transcoder -  
otherwise to get into the HTTPS stream you have to crack the cryptography  
or have a "corrupted" browser). In other words, the "end"s in this  
statement are undefined. The user has the right to choose whatever user  
agent they want on their end (this is a fundamental principle of the Web),  
and there is no a priori reason to require that those agents follow one or  
other development or operational model.

To take another analogy - if I am deaf, but I happen to trust the  
teletext/phone interpreting service, is there any reason why a bank should  
not let me talk to them through that service *at my option*? Yet that is a  
far clearer security risk. Or if I choose to use a voice browser (which  
transcodes the visual presentation into voice and transmits that to me  
over the open air) does that mean that I should not be able to use a  
secured service?

> As you (and I think others) have suggested, specifying data security  
> processes or standards might address these to some degree; and equally,  
> there are cases in which HTTPS is used when full end-to-end security  
> isn't an absolute requirement. But there's no way for a content provider  
> to indicate this.

Any content provider without an EV certificate is not offering the user  
much idea about what is at the provider end anyway. HTTPS is a secure tube  
for transactions, but it is not a person-to-person security, and doesn't  
have the facility to be so. Writing guidelines which legitimate such use  
is in any case providing security guidance which is plain wrong. It  
protects transactions across a certain transmission, but makes no claims  
about what is done at either end of that transmission.

So suggesting that a *user-selected* transformatin is de-authorised by the  
use of HTTPS strikes me as wrong. Again, I may have misundersttod  
something somewhere, if we are talking about transcoding where the user  
has no way of finding out that it is happening. Equally, I recognise that  
just as a user can be convinced to install a piece of malware, they could  
be in principle be convinced to use a hostile or malicious transcoder  
(this is phishing 101). However, that doesn't imply transcoding is bad any  
more than it implies that software is bad.

cheers

Chaals

> On 3 Feb 2009, at 12:02, Charles McCathieNevile wrote:
>
>> If this seems odd, then please explain the opposite - in what way is it
>> not a set of distributed processes communicating with each other? That  
>> is
>> how all but the most elemental software works. And software like screen
>> readers make themselves what Luca is calling a "man in the middle"
>> directly intercepting the video stream at times. Yet we don't generally
>> see people trying to block this transformation.
>
> --
> Future Platforms
> e: Tom.Hume@futureplatforms.com
> t: +44 (0) 1273 819038
> m: +44 (0) 7971 781422
> work: www.futureplatforms.com
> play: tomhume.org
>
>
>
>
>



-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Tuesday, 3 February 2009 14:39:16 UTC