DNS over TLS / HTTPS with TLS Inspection

Question

Hello everyone, 
 
 today the first occurences of DNS over TLS showed up in one of our customers logs. We have TLS Inspection rolled out at the company and are asking ourselves if the TLS Inspection also inspects DNS over TLS traffic and DNS over HTTPS traffic (if it's not blocked by the application filter anyway) or if we should just outright block the traffic. 
 For clarification: Normally we like the clients to first ask any local DNS servers, and if they are not available, we reroute DNS traffic to trusted servers with the help of the firewall, but as of now doing the same to DNS over TLS did not occur to us. 
 
 I'm interested in your experiences how you handle DoT / DoH at your company and am looking forward for your answers. 
 
 Kind regards, 
 Markus

Michael Dunn · Accepted Answer

Your firewall rules will determine if the traffic is allowed or blocked. The SSL/TLS inspection rules will determine if the TLS traffic is decrypted. If the TLS is decrypted then we will rewrite the TLS handshake so that it is using our Certificate Authority. The caller may be okay with that if it trusts the CA, but may also decide not continue (at which point I assume it would fall back to traditional DNS). It it is TLS decrypted and the connection is established, it is examined to see if it is HTTPS. If it is, the Web Filtering applies If it is not HTTPS then it is just allowed.

Michael Dunn · Answer

Any form of encrypted traffic is a potential avenue for threats. I don't think DNS over TLS is specifically an issue more than others. Here is a more full picture: A TLS connection is attempted on port 853. DPI engine will look at the SNI (Server Name Identification) to determine the FQDN of who it is contacting. The FQDN can be blocked by Web policy. If ATP configured, the FQDN and IP is checked against Command and Control servers. GeoIP and Country Blocking can apply. If TLS Decryption is performed The decrypted traffic on port 853 is examined to see if it is HTTP. If it is then web policy and a/v is performed. The decrypted traffic is given to the IPS / App Control engine. If TLS Decryption is not performed The undecrypted traffic is given to the IPS / App Control engine. If you look in a TLS connection and it is not HTTP traffic you don't actually know what it is. Maybe it is DNS, or SMTP, or any number of existing protocols. Or theoretically (but not practically) a custom malware protocol. You can take a guess based on the port. That being said, the IPS / App Control engine CAN detect many things that are not HTTPS. There is a specific detection for DNS over TLS - I don't know if it only works with decrypted TLS or if it does undecrypted as well. So if you are worried about Command and Control - ATP will block it before it gets decrypted. IMO the case -------- Now as for DNS over HTTPS (which occurs on port 443). For example https://dns.google/dns-query As above, the SNI is checked against ATP. The SNI is also checked against web policy. The few that I checked are categorized as Information Technology. Web policy blocks for URL group (domain name only) are applied. If decrypted, it is HTTPS. Web policy blocks for URL group (domain name and path) are applied. Virus scanning occurs. dnsprivacy.org/.../

LuCar Toni · Answer

It highly depends on the implemention of DNS on those devices. Often times, they are using certificates as well and check if somebody reroutes something - Meaning, if you do something with this traffic, they will stop interacting with the traffic. 
 Blocking it, like doing on QUIC, helps to get DNS plain running but throws often times errors. 
 DNS over TLS is a privacy feature for IOT devices or browsers - So you need to think about the use cases. Sometimes you need to simply allow it and check the devices (Endpoints etc.) or in terms of IOT isolate those devices.

DNS over TLS / HTTPS with TLS Inspection

Top Replies