Subject: Explicit proxy options and defaults

From: Stephen Farrell <[email-masked]>
Date: Sat, 07 Dec 2013 18:37:46 +0000

So Tim raised an important point about options for proxies and
defaults that I think maybe warrants its own thread.

Let's assume for a minute the WG manage to design an acceptable
solution that allows for Yoav's corporate proxy. That means
that Yoav would have one of two things going on when he uses
TLS from a web browser: a direct TLS connection or a connection
via an explicit proxy that decrypts and re-encrypts.

But, don't we really need three options: 1) direct, 2) via
explicit TLS proxy that decrypts (as above) and 3) via explicit
TLS proxy and CONNECT (where the TLS proxy doesn't decrypt and
there is an e2e TLS session providing confidentiality).

It seems to me that (1) and (3) match the currently deployed
web and so need to be maintained as the respective defaults for
when there is no proxy and when there is an explicit proxy.
(And I like (3) since its a security improvement over today's
web for proxy auth.)

And if an acceptable solution for (2) is found, that has to be
the non-default or else we're changing the semantics of HTTP.
In other words, (3) has to be the default for explicit proxies
since that's semantically the same as what we do today.

Is this on the right track, or would (3) as the default for
explicit proxies mean that the incentives for explicit proxies
decrease again to the point where they're not considered
worthwhile by those who'd implement them?

FWIW, its seems to me (wearing no hats) that "(2) without (3)"
would represent an overall worsening in the security of http/tls
whereas a "(2) and (3) with (3) as default" outcome could be
described as neutral or positive, depending on how (2) worked
and on what's likely to be implemented and deployed.

Regards,
S.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 8 Dec 2013 01:33:01 +0200

Hi, Stephen

The choice between (2) and (3) is with the proxy. How it communicates 
that choice to the client is up to the group, but in any case doesn't 
seem to matter much security-wise. Adding authentication and encryption 
to the connection to the proxy regardless of whether it decrypts or not 
is also a good thing.

Having the proxy choose (2) should not be seen as an alternative to (3). 
(3) doesn't allow the proxy to do anything except maybe domain name 
filtering. So (2) is an alternative to the MitM proxies that require 
installing a CA certificate and signing phony certificates. Killing off 
those practices is a win IMO.

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 08 Dec 2013 20:39:50 +0000

On 12/07/2013 11:33 PM, Yoav Nir wrote:
> Hi, Stephen
> 
> The choice between (2) and (3) is with the proxy. 

Maybe I wasn't being clear. Let me try again:

If there is a reasonable (2) then I'm asking that both (2) and
(3) be supported but for (3) to be the default.

The explicit proxy should be just one of the players who
can say no in this game.

> How it communicates
> filtering. 

Precisely. And that (3) is the currently specified semantics for
https via a proxy so needs to be the default.

(2) is the new thing that you want to introduce where the proxy
gets to decrypt.

> So (2) is an alternative to the MitM proxies that require

Yes, one can argue that introducing (2) might help kill off the
alternative of MITMing TLS. But equally doing away with (3) which
we have now means weakening https:// URI security in a real sense.

S.

---

From: Peter Lepeska <[email-masked]>
Date: Sun, 8 Dec 2013 17:13:45 -0500

"The explicit proxy should be just one of the players who
can say no in this game."

+1

---

From: Yoav Nir <[email-masked]>
Date: Mon, 9 Dec 2013 00:19:17 +0200

> https via a proxy so needs to be the default.

What I'm missing in this discussion is what default means. The client 
connects to the explicit proxy. It can now either send a CONNECT (or is 
the new notation ":connect"?) or a "GET https://something.example.com". 
One will work, the other won't, depending on the proxy. I don't see 
where defaults come into play.
> we have now means weakening https:// URI security in a real sense.

Whereas for servers people can argue that TLS is a small part of the 
cost, for a proxy, decrypting and re-encrypting is a huge part. The 
bandwidth that a proxy can support is likely 10 times greater for 
CONNECT vs GET. People will never do the GET unless there is a very good 
reason that justifies the cost, and if such a reason exists (filtering, 
caching), they won't agree to CONNECT at all.

Yoav

---

From: Ted Hardie <[email-masked]>
Date: Mon, 9 Dec 2013 14:11:16 -0800

On Sun, Dec 8, 2013 at 2:19 PM, Yoav Nir <[email-masked]> wrote:

> Whereas for servers people can argue that TLS is a small part of the cost,
> for a proxy, decrypting and re-encrypting is a huge part. The bandwidth
> that a proxy can support is likely 10 times greater for CONNECT vs GET.
> People will never do the GET unless there is a very good reason that
> justifies the cost, and if such a reason exists (filtering, caching), they
> won't agree to CONNECT at all.
>
>
So, I think we largely agree on this, but that the way you have stated
makes it hard to tease out.  Let me test my understanding with a slight
reformulation:

A proxy can be configured to either act on a flow or to allow a flow to
pass.  If it is configured to allow a flow to pass, it will support CONNECT
for that flow (for example, an enterprise might require all flows pass
through a proxy, but permit CONNECT for targets within its own
administrative domain).  If it is configure to act, it must decrypt any
encrypted flow before acting, then re-encrypt the result after the action
(e.g. in order to log a communication's content).  Because the latter is
more expensive, it is not often the default, but when it is required,
CONNECT will never be substituted for it.

Is that a fair reformulation of your point?

If so, I tend to agree, with two caveats:  because the whole system tends
to be more heavyweight in support calls this configuration set is more rare
than it should be; there are cases where the second configuration is the
overall default (because it is simpler to configure and there is no
capacity constraint for that particular system).

To return to Stephen's point, I don't see any harm in declaring CONNECT to
be the default semantic, but I agree that there is a clear need to improve
the other proxy semantics.  If an explicit proxy can only tell a client on
a per destination basis that it doesn't support CONNECT, using it will mean
a big performance penalty much of the time.

Ted

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 10 Dec 2013 12:59:18 +0200

On Mon, Dec 09, 2013 at 02:11:16PM -0800, Ted Hardie wrote:

> If an explicit proxy can only tell a client on

I don't see immediately why it would need more than 1 client-proxy RTT, which
should be quite fast in most cases...

Maybe mobile environments where transmitting has big latency?

-Ilari

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Dec 2013 17:13:47 +0200

On Mon, 9 Dec 2013 14:11:16 -0800, Ted Hardie wrote:
Whereas for servers people can argue that TLS is a small part of the cost, for a proxy, decrypting and re-encrypting is a huge part. The bandwidth that a proxy can support is likely 10 times greater for CONNECT vs GET. People will never do the GET unless there is a very good reason that justifies the cost, and if such a reason exists (filtering, caching), they won't agree to CONNECT at all.
 So, I think we largely agree on this, but that the way you have stated makes it hard to tease out.  Let me test my understanding with a slight reformulation:
A proxy can be configured to either act on a flow or to allow a flow to pass.  If it is configured to allow a flow to pass, it will support CONNECT for that flow (for example, an enterprise might require all flows pass through a proxy, but permit CONNECT for targets within its own administrative domain).  If it is configure to act, it must decrypt any encrypted flow before acting, then re-encrypt the result after the action (e.g. in order to log a communication's content).  Because the latter is more expensive, it is not often the default, but when it is required, CONNECT will never be substituted for it.
Is that a fair reformulation of your point?
[YN] Yes, this is true for firewalls and content filters. Since writing this, I got convinced that caching proxies might be willing to allow either CONNECT or GET at the client's discretion.

If so, I tend to agree, with two caveats:  because the whole system tends to be more heavyweight in support calls this configuration set is more rare than it should be; there are cases where the second configuration is the overall default (because it is simpler to configure and there is no capacity constraint for that particular system).
[YN} I'm pretty sure that explicitly configuring the proxy on all clients is the major cause of support calls. If (like today) it requires messing with the trust, that's a big additional cost to acting on a flow.

To return to Stephen's point, I don't see any harm in declaring CONNECT to be the default semantic, but I agree that there is a clear need to improve the other proxy semantics.  If an explicit proxy can only tell a client on a per destination basis that it doesn't support CONNECT, using it will mean a big performance penalty much of the time.
[YN] I think I agree, although I still don't know what "default" means in this context. The client can ask for either semantic, and the server can accept, deny, or deny while hinting that the other one would work. Either way, the client has to ask for a semantic explicitly. There's no default.  I can see something like this working, though. Of course you'll have to use authenticated TLS with the proxy for that.

CONNECT tools.ietf.org:443 HTTP/1.0

405 Method Not Allowed

GET https://tools.ietf.org/

200 OK

If that's the sense of "default", then I'm fine with it.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Dec 2013 10:10:10 -0800

On 10 December 2013 02:59, Ilari Liusvaara <[email-masked]> wrote:
> Ted wrote:

This is a good point.  Even where the proxy is hard to reach,
connecting to a new site at a cost of one (extra) RTT doesn't sound
like a bad thing.

> Maybe mobile environments where transmitting has big latency?

In the mobile case, assuming that you are going to continue
transmitting, that front-loaded latency is a price that is going to be
paid regardless.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 11 Dec 2013 09:47:30 +1300

On 2013-12-11 04:13, Yoav Nir wrote:
> CONNECT vs GET. People will never do the GET unless there is a very
> good reason that justifies the cost, and if such a reason exists
> (filtering, caching), they won't agree to CONNECT at all.
>  So, I think we largely agree on this, but that the way you have
> stated makes it hard to tease out.  Let me test my understanding with
> a slight reformulation:
> A proxy can be configured to either act on a flow or to allow a flow
> to pass.  If it is configured to allow a flow to pass, it will support
> CONNECT for that flow (for example, an enterprise might require all
> flows pass through a proxy, but permit CONNECT for targets within its
> own administrative domain).  If it is configure to act, it must
> decrypt any encrypted flow before acting, then re-encrypt the result
> after the action (e.g. in order to log a communication's content).
> Because the latter is more expensive, it is not often the default, but
> when it is required, CONNECT will never be substituted for it.
> [YN] Yes, this is true for firewalls and content filters. Since
> writing this, I got convinced that caching proxies might be willing to
> allow either CONNECT or GET at the client's discretion.
> 
> If so, I tend to agree, with two caveats:  because the whole system
> tends to be more heavyweight in support calls this configuration set
> is more rare than it should be; there are cases where the second
> configuration is the overall default (because it is simpler to
> configure and there is no capacity constraint for that particular
> system).
> [YN} I'm pretty sure that explicitly configuring the proxy on all
> clients is the major cause of support calls. If (like today) it
> requires messing with the trust, that's a big additional cost to
> acting on a flow.
> 
> To return to Stephen's point, I don't see any harm in declaring
> CONNECT to be the default semantic, but I agree that there is a clear
> need to improve the other proxy semantics.  If an explicit proxy can
> only tell a client on a per destination basis that it doesn't support
> CONNECT, using it will mean a big performance penalty much of the
> time.
> [YN] I think I agree, although I still don't know what "default" means
> in this context. The client can ask for either semantic, and the
> server can accept, deny, or deny while hinting that the other one
> would work. Either way, the client has to ask for a semantic
> explicitly. There's no default.  I can see something like this
> working, though. Of course you'll have to use authenticated TLS with
> the proxy for that.
> 

I've been trying to figure out how to get a sequence like the above to 
work for some time now.
Sadly Connection:keep-alive support in a lot of middleware assumes that 
CONNECT means close and there are no semantics defined around CONNECT 
after an 3xx/4xx/5xx response like that, there appear to be only two 
options that might work portably (or at least break in a easily 
recoverable manner):

@ CONNECT tools.ietf.org:443 HTTP/1.1
@ Transfer-Encoding: chunked
@ Connection:keep-alive
@

# HTTP/1.1 405 Method Not Allowed
# Connection:keep-alive

@ 0\n
@ GET https://tools.ietf.org/ HTTP/1.1
...
== backup on 100 is to send encrypted data. But now we have to 
chunked-encode it and pass to the TLS library from a de-chunked buffer 
instead of read the socket via the library.

OR

@ CONNECT tools.ietf.org:443 HTTP/1.1
@ Upgrade: HTTP/1.1
@ Connection:keep-alive
@

# HTTP/1.1 405 Method Not Allowed
# Connection:keep-alive

@ GET https://tools.ietf.org/ HTTP/1.1
...
== backup on 101 or 200 is to send encrypted data as before.

Amos