Re: The future of forward proxy servers in an http/2 over TLS world

You started by stating, without proof, that proxies are needed to block
requests. What are you actually trying to do, and why does that require a
proxy? Do your users opt-in to the feature, or are you trying to impose the
feature on unwilling users? How much control do you have over the user's
machine? Is your proxy installed on the user's machine (like an
anti-virus), on end-user routers, in ISPs, or in a third party? Are you
trying to block hosts or specific URLs? Do you need to inspect the body of
the request or the response, or the headers, or just the URL? How do we
know you're trying to do something that's even feasible in the first place?
(see the previous citation of RFC 3751)

etc.

On Tue, Feb 14, 2017 at 2:37 PM, Adrien de Croy <adrien@qbik.com> wrote:

>
> At the moment, it feels like the functions provided by proxy servers are
> being squeezed out by changes in the protocol.
>
> I can understand the desire for privacy, and we've had the argument about
> whether it should be available to all or not too many times already.
>
> However, there are other functions that a proxy is commonly used for that
> are becoming impossible with the direction TLS, HTTPS HSTS, cert pinning
> etc are going.
>
> Whilst I can understand a desire and need for privacy, an ability to be
> able to go to a website without betraying which site you're going to (e.g.
> see https://tools.ietf.org/html/draft-schwartz-dns-sni-01) there's
> probably 1 remaining IMO critical bona fide purpose for a proxy which is
> becoming very problematic for users.
>
> Blocking requests.
>
> So, do we feel there is still a place for blocking requests?  Our
> customers still certainly want this.
>
> Currently the user experience is either appalling (generic connectivity
> failure report which wastes a lot of user time), or requires deployment of
> a MitM, which is being squeezed out as well.  We should be able to do
> better, but it doesn't appear to be being addressed at all, and the gulf is
> widening.
>
> I believe we need to put some time into working out how we can allow a
> proxy to block requests without an awful user experience that costs users
> and tech support countless hours to deal with.
>
> This means we have a need to be able to respond to CONNECT with a denial,
> and some kind of message that can be displayed to the user.
>
> It may be that the only way this can be achieved is by the concept of a
> trusted proxy.
>
> Otherwise if the group consensus is that requests should not be blocked,
> we need to deal with the consequences of that.
>
> Adrien
>
> P.s. another key feature is caching, but that is becoming less useful
> anyway.  Customers can often live without caching, they do not tolerate
> being unable to block however.
>
>