[dns-operations] need recommendation for filtering outbound HTTPS
gtaylor at tnetconsulting.net
Mon May 13 02:31:31 UTC 2019
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.
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
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
> 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...
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
More information about the dns-operations