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

On Tue, 03 Feb 2009 17:07:24 +0100, Tom Hume  
<tom.hume@futureplatforms.com> wrote:

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

Mother has a new sim card. She has a new phone number. She has a new  
pricing structure for web access. She presumably had to change her access  
point, and although that *may* have happened automatically my personal  
experience is painful when I want to do so, including repeated messages  
saying "download new configuration?" and "change configuration?" and the  
like trying pretty hard to clarify to me that something has changed (and  
that I have to agree to pay for the change).

While she may not understand the fine details, and you could argue about  
how informed her consent was, I think it is pretty clear that she has in  
fact changed her configuration.

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

It isn't that they are not correct any more. The padlock said "there is a  
secure connection as part of this transaction". It never said where to, or  
where from - in other words it was accurate but not very useful  
information. That's why browsers have been working to do things better for  
as long as the MWI has existed.

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

Indeed. But the logical conclusion is to do away with the padlock, and  
stop telling people that HTTPS is something it isn't.

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

The balance of risk is not simple. Transcoders are potentially richer  
targets for crackers, but also generally have far better mechanisms for  
detecting both a crack and an attempted crack.

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

Let me distinguish again between a man-in-the-middle *attack* and a  
user-selected service. The former case can easily arise in the use of  
unencrypted HTTP through packet-sniffing - this is what gave rise to HTTPS  
in the first place.

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

which happens either because one party made a choice they didn't  
understand, or because someone cracked the HTTPS stream. The second case  
is a man-in-the-middle attack as understood in security terms. The first  
case is an issue of trade practices - if your Mum doesn't know what she  
bought, then that is generally not the fault of the people who made it,  
but the people who sold it to her, or her own fault for not asking  
(different cultures around the world have a different take on where the  
balance point of responsibilities lies, but the general notion is pretty  
common).

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

Right. So if the user chose to use a particular service that distributes  
its processing over a network, rather than around a particular computer,  
isn't that also a user decision?

>>> So suggesting that a *user-selected* transformation 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...

I don't think you are talking about any technical break in the chain  
though - the integrity of communication from server to user agent (with  
one end chosen by the client somehow, one chosen by the service provider,  
and everyone hoping that the user connected to the service they were  
looking for and not some phishing service that looks sort of like it)  
hasn't been broken.

The user's understanding of the service they have contracted is something  
like the a content provider's decision to serve different things to  
different users. It is an interesting topic for market (de-)regulators,  
but technical guidance for services should be wary of straying into it.

cheers

Chaals

-- 
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 Wednesday, 4 February 2009 18:13:18 UTC