[dns-operations] need recommendation for filtering outbound HTTPS

Grant Taylor gtaylor at tnetconsulting.net
Sun May 12 16:26:05 UTC 2019


On 5/12/19 1:10 AM, Paul Vixie wrote:
> i see that squid is not the only forward proxy available for HTTPS 
> now. for example:
> 
> https://superuser.com/questions/604352/nginx-as-forward-proxy-for-https

I don't see any discussion of certificates for Nginx's forward proxy 
CONNECT support.  This makes me think that it's not functioning as an 
SSL / TLS bump in the wire like Squid can.

I don't see how Squid, Nginx, ATS, Apache HTTPD, et al. can perform DoT 
/ DoH filtering without getting into the the TLS stream.

Or is the idea to filter on what the client is wanting to CONNECT to? 
If that's the case, I'd worry that DoT / DoH traffic could be protected 
with Domain Fronting.

Apache HTTPD can be configured as a forward HTTP / HTTPS proxy 
supporting the CONNECT method.  I don't think Apache HTTPD can do SSL / 
TLS bump in the wire like Squid can.

> is this the state of the art? to prevent DoH bypasses to the 
> DNS monitoring and policy controls (see https://dnstap.info/ and 
> https://dnsrpz.info/) i use on my private networks,

It's my understanding, please correct me if I'm wrong, that DoT and DoH 
are designed specifically to be difficult ~> impossible to block for any 
reason.  It doesn't matter if the motivation is above board, like yours, 
or malicious, like a router compromise.

> i'm going to have to strip-search all outbound HTTPS that goes toward 
> any wide-area IP address known or suspected to offer DoH, and i'm going 
> to have to return 404 for any URI that matches a known DoH endpoint.

I think that's where we are headed with DoH.  I'm not as sure about how 
to do this with DoT, seeing as how it's not HTTPS.

> under TLS 1.3, with excrypted SID, none of the old transparent MiTM 
> methods will work any more. it's going to have to be an explicit proxy, 
> which every HTTPS speaker inside my network will have to import and 
> trust a certificate for.

Did you mean "encrypted SNI"?

What you describe is my understanding.  Especially since you can't 
control the TLS 1.3 parameters used like I think Jacques is describing. 
At least not as easily.  Especially on IoT devices / smart phones / 
tablets / etc.

> while i'd be happy to learn of commercial/proprietary solutions, 
> which i'd use on $dayjob's corporate network, and would blog about, 
> i also need to know how the F/L/OSS community is solving this kind of 
> problem today. hopefully it's not squid, but does it really require 
> that i run a patched version of nginx?

Does simply filtering the CONNECT destination suffice?  What about 
domain fronting?



-- 
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/3f6bf2c1/attachment.bin>


More information about the dns-operations mailing list