Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 42 subscribers
  • Views 6597 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DNS over TLS / HTTPS with TLS Inspection

Markus Flüß

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



This thread was automatically locked due to age.
Parents
  • +1

    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.

  • 0 in reply to Michael Dunn

    Thank you, the last sentence was exactly what I was looking for. In this case we will probably block DNS over TLS outright. I imagine that by the encrypted nature of this traffic it is much loved by intruders communicating with their C&C servers and the like, and because of the firewall just allowing this traffic even in the case of decrypting it it poses too much of a potential threat.

    Thank you!

Reply
  • 0 in reply to Michael Dunn

    Thank you, the last sentence was exactly what I was looking for. In this case we will probably block DNS over TLS outright. I imagine that by the encrypted nature of this traffic it is much loved by intruders communicating with their C&C servers and the like, and because of the firewall just allowing this traffic even in the case of decrypting it it poses too much of a potential threat.

    Thank you!

Children
  • +1 in reply to Markus Flüß

    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/.../

Unfiltered HTML