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

Charles

Think we may have covered some of this in the call just now, but...

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

Purchase phone on O2. Access www.content.com. Buy PAYG SIM on  
Vodafone. Access www.content.com and get transcoded version.

Neither mother, nor www.content.com have changed their configuration -  
but the security is different in both cases.

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

Well exactly... but there are mechanisms which have been promoted for  
saying "it's secure now", including the padlock icon. And in the case  
of transcoded HTTPS they're not actually correct any more. Some might  
argue that having degraded security whilst believing you have true end- 
to-end is worse than knowing correctly that you have no security at all.

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

Not sure I get that - can you clarify for me?

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

...or access the HTTPS service from a HTTP-provided page which has  
been transcoded without the users knowledge - e.g. the search results  
page of a search engine. So I'm not sure this assumption holds.

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

I think I agree, but what I'm talking about is a proxy inserted into  
the connection twixt client and server without the knowledge of either  
party.

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

Both are explicit decisions on the part of the user, and very  
reasonable imho.

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

I think I am talking about this - apologies for not making that  
clearer...

Tom

--
Future Platforms
e: Tom.Hume@futureplatforms.com
t: +44 (0) 1273 819038
m: +44 (0) 7971 781422
work: www.futureplatforms.com
play: tomhume.org

Received on Tuesday, 3 February 2009 16:08:18 UTC