[dns-operations] need recommendation for filtering outbound HTTPS

[Grant Taylor]

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?

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.

> also, in TLS 1.3 w/ encrypted SNI, the only way to do bump-in-the-wire 
> is to force a downgrade to TLS 1.2. this is what i expect "next-gen 
> firewalls" and the chinese "great firewall" to do. clients or servers 
> who won't tolerate the downgrade will fail, but that will be seen 
> by some network operators as the lesser cost (compared to allowing 
> DoH through.)

I'm not convinced of that.  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't outline more details than that.  But I feel like if you control 
the choke point between the client and the Internet, including it's 
unencrypted DNS, then you can do some things.

> i don't want to proxy everything. but the https proxy protocol, and 
> socks, do not have a way to tell the initiator, "you don't need me 
> for this connection, just try again without a proxy".

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

> TLS 1.3 w/ ESNI makes it impossible to be selective in what the 
> forward proxy decrypts, it has to be everything.

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.

There's always a TCP Reset and then not interfering with the next 
packets between the two IPs.

It's not perfect.  But it is enough to make me question things.  The 
questions are likely from a naive place.  But they are questions none 
the less.

> our alternatives and their costs have been carefully managed for 
> us here.

That has never stopped me from asking questions and listening while 
others explain why I'm wrong.  ;-)



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190512/0992dc62/attachment.bin>