Detecting DoH using PF

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Detecting DoH using PF

eriklauritsen
Hi,

Is a DNS over HTTPS recognizable somehow so that it can be fingerprinted
and redirected or blocked using pf?

I am thinking about the ability of PF to detect when requests are coming from
a windows machine for example.

Kind regards,
Erik

Reply | Threaded
Open this post in threaded view
|

Re: Detecting DoH using PF

Paul de Weerd
Hi Erik,

On Mon, Feb 17, 2020 at 06:07:59PM +0000, Erik Lauritsen wrote:
| Hi,
|
| Is a DNS over HTTPS recognizable somehow so that it can be fingerprinted
| and redirected or blocked using pf?

I haven't studied this in close detail, but since it's just a "normal"
(albeit generally small) HTTPS request, I doubt they can be easily
fingerprinted.  But I wonder: what is your interest?

My concern is not users using safe (encrypted) transports for their
DNS lookups, but users unwittingly sending their data to certain large
companies.  To that end I've populated a table in pf with IP addresses
from https://en.wikipedia.org/wiki/Public_recursive_name_server and
simply have

        block out log from any to <openrecursor>

to prevent anyone on the local network from accessing them.  Some of
them are more popular than others but it works well enough:

# pfctl -vvt openrecursor -T show | awk '/\[/ {p+=$4; b+=$6} END {print p, b}'
14672 1100046

so 14672 packets / 1100046 bytes blocked to these open recursors.
Note that the rule blocks both DoH as well as 'normal' DNS or DoT
requests.

| I am thinking about the ability of PF to detect when requests are coming from
| a windows machine for example.

OS fingerprinting looks at TCP characteristics; DoH requests are
inside an encrypted transport and (probably) hard to discern from
'normal' HTTPS traffic.

Cheers,

Paul 'WEiRD' de Weerd

--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/                 

Reply | Threaded
Open this post in threaded view
|

Re: Detecting DoH using PF

Peter Müller
Hello *,

for detecting DNS over HTTPS traffic without interfering with the connection, perhaps
these articles might be helpful:
- https://dshield.org/forums/diary/Is+it+Possible+to+Identify+DNS+over+HTTPs+Without+Decrypting+TLS/25616
- https://dshield.org/forums/diary/More+DNS+over+HTTPS+Become+One+With+the+Packet+Be+the+Query+See+the+Query/25628

Thanks, and best regards,
Peter Müller


> Hi Erik,
>
> On Mon, Feb 17, 2020 at 06:07:59PM +0000, Erik Lauritsen wrote:
> | Hi,
> |
> | Is a DNS over HTTPS recognizable somehow so that it can be fingerprinted
> | and redirected or blocked using pf?
>
> I haven't studied this in close detail, but since it's just a "normal"
> (albeit generally small) HTTPS request, I doubt they can be easily
> fingerprinted.  But I wonder: what is your interest?
>
> My concern is not users using safe (encrypted) transports for their
> DNS lookups, but users unwittingly sending their data to certain large
> companies.  To that end I've populated a table in pf with IP addresses
> from https://en.wikipedia.org/wiki/Public_recursive_name_server and
> simply have
>
> block out log from any to <openrecursor>
>
> to prevent anyone on the local network from accessing them.  Some of
> them are more popular than others but it works well enough:
>
> # pfctl -vvt openrecursor -T show | awk '/\[/ {p+=$4; b+=$6} END {print p, b}'
> 14672 1100046
>
> so 14672 packets / 1100046 bytes blocked to these open recursors.
> Note that the rule blocks both DoH as well as 'normal' DNS or DoT
> requests.
>
> | I am thinking about the ability of PF to detect when requests are coming from
> | a windows machine for example.
>
> OS fingerprinting looks at TCP characteristics; DoH requests are
> inside an encrypted transport and (probably) hard to discern from
> 'normal' HTTPS traffic.
>
> Cheers,
>
> Paul 'WEiRD' de Weerd
>

Reply | Threaded
Open this post in threaded view
|

Re: Detecting DoH using PF

Tim Baumgard
In reply to this post by eriklauritsen
On Mon, Feb 17, 2020 at 1:19 PM Erik Lauritsen <[hidden email]> wrote:
> Is a DNS over HTTPS recognizable somehow so that it can be fingerprinted
> and redirected or blocked using pf?
>
> I am thinking about the ability of PF to detect when requests are coming from
> a windows machine for example.

As Paul asked, what's the reason behind your question?  Privacy? The
solution for you depends on you how much work you want to do and what
you have for a network, devices, and applications.

Blocking requests is a reasonable solution with some caveats. Remember
that you'd have to keep the configuration updated, though probably
infrequently. Applications and devices may use their own factory-set DNS
settings and not those specified by your DHCP server, so they may fail
if they can't connect to a server blocked in pf(4). This means that some
things you can't fully configure like IOT devices, TVs, game consoles,
or that one thing your boss likes may not work or may not work after a
future update. This isn't as much of a problem if the network can be
segmented so that the pf(4) rules apply to only certain devices, but it
does involve a little extra work.

Redirecting or relaying the request requires some form of deep packet
inspection since the requests are encrypted. This also requires a local
certificate authority that is trusted by the devices on the network,
which may not be possible for everything on it. Devices like those
listed above may fail. Again, this may not be an issue if you can
segment your network so that you're only relaying the requests from the
devices that you can install the local CA certificate on, but I'm not
sure if a program to relay DoH requests exists anyway.

As far as I'm aware, "enterprise policies" can be used to disable DoH in
some OSes and applications. All devices and applications have to support
them and be configured to use them to fully block them. Things that
don't support them will get through.

Again, you have to think about your situation and what you want to
accomplish. If the above shortcomings are okay with you, pick the one
that works best for your situation.

That said, this is what I do personally for my own network:

I don't knowingly use any devices, OSes, or applications on my network
that use DoH other than Firefox, and all my main devices--desktop,
laptop, phone, tablet--are known to obey the DNS settings from
dhcpd(8). My network is also segmented. My current "works well enough
for me" solution to cover Firefox without changing its settings on every
device is to add this to my unbound.conf(5):

    # By default, disable DoH for Firefox.
    # https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https
    local-zone: "use-application-dns.net" always_nxdomain

This means that all the things I really care about privacy-wise with
regards to DoH are fine. Be aware that Firefox apparently still uses DoH
if the setting is turned on in its preferences. For what it's worth, the
OpenBSD port of Firefox disables DoH by default.

Tim