Re: Draft finding - "Transitioning the Web to HTTPS"

I think, again, it would be helpful to more clearly dis-ambiguate the
various classes of proxies, since their properties - in terms of the
implications of the transition to HTTPS and in terms of the possible
solutions - are quite different.

As Mark (N) has pointed out, the increasing use of reverse proxies close to
user endpoints (aka CDNs) makes that section of traffic amendable to an
HTTPS transition.

For traditional forward proxies, configured by users into their browsers, I
wonder whether there are solutions based on proxy authentication and
sub-resource integrity, coupled with user consent to this authenticated
proxy having access to browsing behaviour ? At least that seems like an
avenue worthy of some consideration.

The case of interception proxies - which is where the MITM concerns are
strongest - seems very different and should be called out as such.

...Mark

On Mon, Jan 5, 2015 at 4:13 AM, Harry Halpin <hhalpin@ibiblio.org> wrote:

> On Mon, Jan 5, 2015 at 12:04 PM, Tim Berners-Lee <timbl@w3.org> wrote:
> >
> > On 2014-12 -19, at 16:18, Tim Berners-Lee <timbl@w3.org> wrote:
> >
> >
> > On 2014-12 -11, at 07:46, Henri Sivonen <hsivonen@hsivonen.fi> wrote:
> >
> > On Tue, Dec 9, 2014 at 1:28 AM, Mark Nottingham <mnot@mnot.net> wrote:
> >
> > * The example of a village with poor access (e.g., in Africa) has
> regularly
> > been
> >
> > brought up in the IETF as an example of a population who want shared
> > caching, rather than encryption. The (very strong) response from folks
> >
> > who
> > have actually worked with and surveyed such people has just as regularly
> > been that many of these people value security and privacy more.
> >
> >
> >
> > That's interesting.  Data?  (((The school I remember in Rwanda which ran
> of
> > one VSAT 128k link I think we just interested in getting some
> connectivity
> > for their class and caching was crucial.  They used a custom router/cache
> > which was designed for that situation. I don't think they were concerned
> > about people spying on or falsifying the wikipedia pages they were
> reading
> > in the class.  But maybe I missed that.  Maybe they now have fibre. Or
> maybe
> > in general the switch from wifi  to mobile 3g data  where there is not
> real
> > opportunity for people to push in a community cache. )))
> >
> > But to argue about this without data is not forward progress.
> >
> >
> >
> > Thank you for bringing this up.
> >
> > It seems to me that there is a pattern that people find the theory of
> > forward proxies architecturally appealing and then try to find use
> > cases that fit the architecture.
> >
> >
> > I don't see a pattern.
> >
> >
> >  You [Henri and Mark] make fun of these "people" on their hobbyhorses as
> a
> > way of discounting their argument, which is not constrictive.
> >
> > As it happens I just talked to someone who runs a small remote island
> with
> > about 400 people.
> > I didn't ask but he brought it up of his own accord, that with everyone
> on
> > wifi and a (17Mb/s ?17MB/s ? he wasn't sure) link supporting everyone, he
> > had been recommended and was planning to install a commercial island-wide
> > web proxy cache product, as he felt a lot of people watched the same
> movies.
> >
> > His concern about bandwidth and response time was paramount. He wasn't
> > primarily, as far as I could see, concerned about the privacy of the
> folks
> > being invaded by foreign power and the extent to which that was affected
> as
> > he made the decision as to how to balance running a proxy with getting
> more
> > bandwidth.
> >
> > If the videos are all https: then he won't be able to cache them, except
> --
> > not to worry, the tools he buys will probably include MITM attack tools,
> so
> > in fact he *will* be able to cache things after all. But it is ironic
> that
> > the only thing would drive him in that scenario to install MITM attack
> > system, which makes the whole operation much less secure in many ways, is
> > the trend toward https: for movies.    If people were happy to have the
> > movies they watch spied on, then they would retain the ability to have
> > end-end secure communications across the net for other things.
> >
>
> However, in terms of ethics, I would hold that disabling an
> architecture of pervasive surveillance is probably more important than
> the speed of watching movies in terms of the future of the Web. In
> that regard, the long-term goal should be able to make such MITM
> attacks impossible as the same architecture that leads to MITM attacks
> for "legitimate" uses will inevitably be used for repressive purposes
> IMHO.
>
> The question then is how can we create an architecture that allows a
> proxy-like features (i.e. fulfills the use-cases of internet proxying)
> without actually interfering with traffic? This seems like it could be
> something that could be offloaded into browsers and OS-level
> functionality. Ditto, how can we do caching for some cases like movies
> on the server-side while still encrypting to the client? These are all
> soluable problems likely that need to be fully understood.
>
> > Just saying that the economics of this and the balance between the
> various
> > concerns are not to be understood well with a few anecdotes and some bar
> > BOFs.
>
> I agree in general, and this is precisely the kind of hard question
> that the academic/industrial research community, OECD, and others
> should be tackling.
>
>     cheers,
>        harry
>
> >
> >
> > The previous hobbyhorse of this kind
> > was "transcoding proxies".
> >
> >
> > [irrelevant mildly disrespectful argument deleted]
> >
> > [...]
> > --
> > Henri Sivonen
> > hsivonen@hsivonen.fi
> > https://hsivonen.fi/
> >
> >
> >
> >
> > timbl
> > director hat off
> >
>
>