Doh and chat gpt

[JonathanLee]

@johnpoz What I’m trying to get at is this: it feels like we aren’t given the tools we really need on the client side, but PFSense does give us the tools to block those same capabilities from being used. It ends up becoming a cat-and-mouse game rather than a clean, unified solution.
Ideally, there should just be a single, straightforward approach—“use this for DoH”—and since PFSense already supports DoH, we should simply let PFSense manage all outbound DoH instead of having to chase it down on every client.

But we can’t and the NSA recommends we do. Yes a client problem but unbound can do doh

[johnpoz]

@JonathanLee yeah unbound can do doh - I had a post awhile back that showed how to do it, you even chimed in on the thread.

that is not a problem - the problem is you can not force a and OS to use what you want.. There is zero reason to use dot or doh on your own secure local network..

Doh has been problem since day one.. That some app can use another dns then the one you tell the OS to use is going to be problematic..

[tinfoilmatt]

@JonathanLee DoH does not work like you apparently think it does. The best you can really do to block it, which you should be doing, is DNSBL and IPBL known-DoH providers.

Your DNS forwarder or caching stub resolver (meaning dnsmasq or Unbound) should be configured to only query a trusted DoT provider (or providers) of your choosing.

[JonathanLee]

@tinfoilmatt Yes exactly that is why I was wondering where the RFC was to perform the NSA recommendations, hence to use only an approved DoH outbound, it's not currently possible and we are given no options to do so. If there was an RFC to control the DoH outbound maybe we could do that. Again to have DoH working in unbound might give us an advantage as it would be under development for if and when they have and ability to do the "NSA" based recommendations.

[tinfoilmatt]

@JonathanLee Let me try a different way: you do not want to be using, nor do you want any of your devices to be using DoH whatsoever.

[JonathanLee]

@johnpoz I cant agree more with you, I guess my question is why would the NSA recommend we do that "use a single enterprise based DoH server when required" its not possible and if they recommend it where is the RFC to be able to do this? There is none that I know of anyway, also IDS I think does not have a category to alert on DoH use too, so it's like the NSA making a recommendation that has no possible solution currently outside of the wackamole solution.

[tinfoilmatt]

@JonathanLee The NSA is recommending that, in a large enough enterprise where LAN segments are susceptible to sniffing from the inside, that DoH be implemented for local (meaning local to the enterprise LAN) network host DNS queries.

[tinfoilmatt]

This assumes that the network operator/s or admin/s would continue to maintain full visibility over DNS traffic (in plaintext) on the LAN.

[JonathanLee]

@tinfoilmatt But they are also making references to command and control over DoH externally, meaning outbound also right? I mean internally we could set it up with Unbound @johnpoz and I talked about this a couple years ago, requires some certificates, but outbound has no real catch all solution, outside of MIME blocking on get requests, again once you do this Microsoft goes crazy because they have some ones they want left alone.

[tinfoilmatt]

@JonathanLee I believe they refer to the fact that malicious actors operating C2 servers are able to conceal LAN activity by designing their malware to query DoH servers under their control. To the LAN operator, this traffic would appear to simply be regular ol' HTTPS (and therefore encrypted) traffic.

[JonathanLee]

@tinfoilmatt Maybe a containerized instance of something was able to do this.