[dns-operations] need recommendation for filtering outbound HTTPS

Pavel B Khramtsov p.khramtsov at msk-ix.ru
Sun May 12 17:45:45 UTC 2019


Саша, спасибо!

С уважением,
Павел

> 12 мая 2019 г., в 18:26, Grant Taylor <gtaylor at tnetconsulting.net> написал(а):
> 
>> 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
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations





More information about the dns-operations mailing list