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

On Tue, 20 Jan 2009 23:47:15 +0100, Tom Hume
<Tom.Hume@futureplatforms.com> wrote:

>
> I've built sites myself that fit that criteria. For instance - an  
> iTunes-style music store for a startup I worked for in 99. HTTPS for  
> login, just to protect the password, but beyond that no need for HTTPS.  
> No credit cards stored or anything like that.
>
> In that case, as a content provider I'd be happy for mobile users to be  
> able to access their MP3s through a transcoded version of the service...  
> and would be happy to have security slightly degraded.

And this is the crux of the issue. A few people use HTTPS because they
somehow think that it won't allow transformation services. In practice,
that is clearly not true - any service where the the client is distributed
(such as Opera Mini) will still work.

Opera Mini is a two-part client. One part is installed on the end-user's
telephone, and it interprets contentsent by the other part. The other part
is maintained "in the cloud", and is a process running which communicates
to the service being used, and then makes that legible for the user's
endpoint.

If you think of an XWindow server, would it make sense to say that anyone
using HTTPS insisted that the browser was not running remotely over X? I
find that hard to believe. So why does it matter when the browser is
running over Opera Mini's customised process? (There is of course an
orthogonal argument about how secured the internal processes are, whether
in a distributed client system or in a common or garden browser. But that
isn't relevant here except to sites which deliberately block certain
browsers because they are not sufficiently secure).

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.

As Francois also pointed out, as well as Tom's case (which I think it
pretty common, just mentally flipping through top sites) HTTPS doesn't
secure the other end very well either - EV certificates are the baseline
for suggesting that it might, and they are still not that common.

In other words, we have a protocol that, between two end points which know
nothing much about each other, blocks unknown third parties from listening
in. It says nothing at all about what happens at *either* of those end
points - and not should it.

Assuming that HTTPS means "I insist on knowing the precise browser model
of my user, and only accept certain variations" seems a stretch. There are
systems that blacklist Opera Mini (and all kinds of other browsers), and
Opera Mini is careful to identify itself. I think that clearly a
transcoding system should identify itself - but I don't believe that the
majority of sites using HTTPS give two hoots about transcoding systems any
more than they care to block browsers known to have major security
problems.

So this talk of "abusive business practices" strikes me as nonsense. A few
organisations who are particularly paranoid or have extremely tight
requirements already block services such as Opera Mini. Many others are
very happy to have it working or have gone out of their way to make it
work (still using HTTPS), and in any case are not using HTTPS to suggest
that content should not be transformed at all (that horse was never even
in the web stable - browsers  decide on their own how to transform
content, and have always done so in different ways). End users are
choosing to use services, and how much data to provide to those services,
whether that be a single piece of software installed on their machine or a
distributed process or set of processes the user daisy-chains together on
their own. Somehow suggesting that users should not be able to do this,
because people offering web content and services to them don't like the
idea, seems to me an argument that doesn't reflect much of reality (would
Luca's your "95% of cases is good enough" test, for example).

Transparent proxies are a slightly different kettle of fish. They have
been a part of the Web since the early days - since the beginning of the
mobile web. While HTTPS has had the effect of not letting them interfere
with a transaction, this is because their model is fundamentally different
to services the user has chosen. If the user chooses a browser which
distributes processing (or an acceleration service) then it is an obvious
corrollary that they accept the distributed service handling their data.
If some operator places this in the way and does not inform the user
(because they provide a browser that doesn't explain its terms of service,
for example), then that is to do with sales and advertising practices
providing information to the user, not with the technology itself.

Something that strikes me as a more profitable alternative for a group
recommending best practices in this area is that they indeed outline
processes and protocols for data security in intermediate systems.

Some simple ones would be restrictions on data stored and on handling of
data storage,

Trying to stretch a directive that says "this presentation is already
optimised for your client, you don't need to try and make it look better"
into "I am not prepared to offer this service to your system because I am
not happy about the security of it" seems as big a stretch in the wrong
direction as claiming "I want a connection to the client where no
*unknown* third party can drop in" also means "and I am not prepared to
work with a client model that has distributed processing".

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 Tuesday, 3 February 2009 12:03:12 UTC