RE: Explicit proxy options and defaults

On 2013-12-11 04:13, Yoav Nir wrote:
> 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.
> 405 Method Not Allowed
> 200 OK
> If that's the sense of "default", then I'm fine with it.
> Yoav

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):

@ Transfer-Encoding: chunked
@ Connection:keep-alive

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

@ 0\n
@ GET 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.


@ Upgrade: HTTP/1.1
@ Connection:keep-alive

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

@ GET HTTP/1.1
== backup on 101 or 200 is to send encrypted data as before.


Received on Tuesday, 10 December 2013 20:47:57 UTC