[dns-operations] need recommendation for filtering outbound HTTPS

[Paul Vixie]

On Sunday, 12 May 2019 07:51:04 UTC Rubens Kuhl wrote:
> I would try ATS before resorting to Squid:
> https://trafficserver.apache.org/ <https://trafficserver.apache.org/>
> 
> While I don't know if it actually works for your use case, I always found
> that codebase to be much cleaner than Squid.

thanks. it won't work, not really. when an http/https initiator uses a proxy, 
it expects that after it issues its CONNECT, it has a raw TCP/IP connection to 
the far end, and begins crypto negotiation with that far end, even if it 
already did crypto negotiation to reach the proxy by HTTPS. so, unless i'm 
willing to intercept that byte stream, pretend to be the far end, offer a 
certificate that the initiator might not accept, and force a downgrade to TLS 
1.2... my only control point will be the argument to the proxy CONNECT verb, 
which can be a raw IP6 or IP4 address, or a domain name. this has two costly 
consequences for me:

1. i have to decrypt every outbound HTTPS session, by which i offer no 
incentive to distant server operators to keep DoH (the /dns-query URI) from 
being served on the same listener address as non-DoH (all other URI's). i 
really want to reward operators like 8.8.8.8 and 9.9.9.9 who have promised not 
to serve non-DoH HTTPS traffic and DoH HTTPS traffic from the same address.

2. i have to anti-alias all possible names for any DoH listener address, as 
well as fully enumerating all DoH listener addresses, which can be expected to 
move around via techniques similar to "fast flux" in order to evade blocking. 
i have anti-aliasing powers (DNSDB) but most operators don't. i expect i'll 
have to actually try the DoH (/dns-query URI) with every distant address that 
any of my internal HTTPS-via-proxy initiators want to connect to, in order to 
build my own "whitelist" of listener IP addresses who don't support DoH.

so far, RFC 8484 authors: 1, me: 0.

-- 
Paul