[dns-operations] need recommendation for filtering outbound HTTPS

[Paul Vixie]

On Monday, 13 May 2019 02:31:31 UTC Grant Taylor wrote:
> On 5/12/19 6:36 PM, Paul Vixie wrote:
> > to be clear, if there's a CONNECT verb, it's not bump-in-the-wire.
> 
> Please elaborate.
> 
> Are you saying that because the client is actively talking to the proxy
> and as such it's not a transparent operation without the client's knowledge?

right. specifically, if the client is talking to a proxy, it knows it is 
talking to a proxy, and i have to give it a proxy. i can't make a routing 
decision based on where it's trying to go without a proxy (some external tcp/
443 listener) and say, i don't like that destination, please talk to my proxy 
instead.

note also, the client can connect to a dotted quad or hexed quadquad, if it 
knows what address it wants. or it might just connect to a domain name, if it 
knows it has to use a proxy and doesn't bother to look up the address. this 
means my proxy has to be prepared to recognize a DOH endpoint by address or by 
name, in order to decide what to do next.

that's where it gets truly harsh:

> My understanding is that CONNECT is supposed to proxy at the TCP level,
> not HTTP level.  So Squid's (and I'm sure other proxies) behavior to
> take the CONNECT (or transparent) and terminating it locally to to
> function as an HTTP proxy, despite the CONNECT, seems like a MitM ~>
> SSL-bump-in-the-wire to me.  Perhaps the difference is in terms.

terminologically i've been calling that a downgrade rather than BITW, because 
the only way i'm going to learn the SNI is if i act like i only understand TLS 
1.2 (and not 1.3) after intercepting the CONNECT and forcing it to make its 
long-distance TLS connection to me instead of to the real (remote) endpoint. 
this is what GFW has to do, and it is known to break clients who "know" that 
their server can speak 1.3. GFW does not care about this breakage, but then, 
GFW is also blackholing all of google. i do care, and i can't.

> ...Sure downgrading TLS 1.3 to 1.2 will make things simpler.
> 
> However, if you block outgoing connections by default and explicitly
> allow some connections, I think you can likely break DoH and DoT in that
> they are not already explicitly allowed.  As such the client will need
> to fall back to regular unencrypted DNS to get the public key needed to
> prime eSNI.  Thus leaking data that can be used to filter connection.

i can only get the leak i need if i force the explicit use of a proxy, 
intercept CONNECT toward known DOH names or addresses, and then force a 
downgrade to TLS 1.2. that is, for me at this time, a bridge too far. as far 
as i can work out from the theory, it's what Palo Alto Networks NGFW has to be 
doing. jacques from CIRA says this causes him no (enterprise) trouble. i fear 
it may cause me some (home network) trouble.

> HTTP(S) and SOCKS proxy don't have that ability.  But Proxy Auto
> Configuration does and can tell clients to go DIRECT.

say more? i know it can say "don't use a proxy" but i don't know that it can 
say "use a proxy if your destination is on the following list of suspicious 
places".

> I agree that it probably needs to be everything that comes to it.  But I
> think PAC can be leveraged to be more intelligent about what comes to it.
> 
> I say probably because I wonder just how far down the rabbit hole we can
> go with the proxy initially intercepting TCP connection while pretending
> to be the client to the upstream server before it could no longer
> leverage kernel options to splice the two connections together while
> stepping out of the mix.

splicing only works if you have an out of band path to the far end to tell it, 
here's your connection and encryption state, take over for me. that works 
inside a private or public cloud. it won't work across the WAN internet.

...starting a new thread on the last point you've made here.

-- 
Paul