Re: Securing DNS traffic

[Steffen Nurpmeso <steffen%sdaoden.eu@localhost>]

Sad Clouds wrote in
<20200525152338.beed20b18e42642ec340305e%gmail.com@localhost>:
 |On Fri, 22 May 2020 22:38:19 +0100
 |Sad Clouds <cryintothebluesky%gmail.com@localhost> wrote:
 |
 |> It seems there are two main security enhancements for DNS:
 |> 
 |> 1. DNSSEC - digital signatures for DNS records to verify they haven't
 |> been tampered with.
 |> 
 |> 2. DNS over TLS - encryption of DNS traffic for privacy. This goes via
 |> port 853 and could be over TCP or UDP (DTLS), although it's not clear
 |> to me if both TCP and UDP are always supported, of if it's mainly TCP.
 |
 |I've been doing some more research and came across this article on DNS
 |hijacking
 |
 |https://www.fireeye.com/blog/threat-research/2019/01/global-dns-hijackin\
 |g-campaign-dns-record-manipulation-at-scale.html
 |
 |Some of the techniques they describe seem to follow these steps:
 |
 |1. DNS account is compromised and either A or NS records are changed to
 |   point to a bogus server.
 |2. User connects to "email.mydomain.com" which is sent to a bogus
 |   server that acts as a "man in the middle", collecting credentials
 |   and then forwarding everything to the real "email.mydomain.com"
 |
 |I think TLS was designed to avoid "main in the middle" attacks, but it
 |seems in this case a bogus server is using its own "valid" TLS
 |certificate and then proxying connections to the real server.
 |
 |I don't quite understand how this works. Is it the case of somebody
 |creating a second valid TLS certificate for "email.mydomain.com" in
 |order to masquerade as a genuine email server? So if different CAs can
 |issue such certificates, how do you mitigate such attacks? Isn't this a
 |flaw in the PKI design to have different CAs that can vouch for the same
 |domain?

First TLS works with a local pool of trusted certificates.
Any remote party who has a certificate that has been signed by one
of the certificates in your local CA pool is automatically
trusted.

Then DNS is a decentralized datastore with some root servers
(though in fact there are multiple "roots" as some countries do
not like that most of those root servers are in fact USA).  Then
there are (local) stub resolvers (like in the C library, some of
them fully caching answers, some reissuing each and every
request), then recursive resolvers, which can fully handle DNS
with redirects and data collection etc. unless a query (of a stub
resolver or what) can be truly answered (or not, of course).
Data is organized in zones, and servers/recursive resolvers can
transfer entire zones, iirc most RFCs regarding DNS dealt with
zone transfers (by then).  This localizes data and effectively
avoids lots of internet traffic.
Iirc correctly you get authoritative results from recursive
resolvers (servers) which got their data via zone transfer.
And you simply trusted the "authoritative" bit in the response.

DNSSEC extends this by offering zone administrators the
possibility to sign their data, in theory these signatures are
duplicated down and even arrive in stub resolvers, these can then
verify that the actual data is correct.
There is a tree/chain of trust among the DNS up to the root
servers, so . signs .ORG signs ME.ORG. signs *.ME.ORG.  Never did
that, but think that is the thing.  You can resolve that tree
downwards, verifying data you get.  The certificates and the
mechanism is totally distinct from the CA pool of TLS.

Which i personally totally dislike.  But especially i dislike that
CMS aka maybe x509 aka the certificates of TLS could be used for
much more, their use is artifically restricted.  I do not like
that this crypto mess is torn apart and lots of different
standards are involved, and have to be audited, where one would be
sufficient.  (Then you could for example just make a TLS handshake
with root servers to get the necessary info to verify that your
.ORG signature is correct, and ditto...)
Also DNS/TLS and DNS/DTLS have been standardized twenty years to
late, it should all have been designed as a unity, imho.  The same
is true for UTF-8 for hostnames instead of IDNA.  All imho.

You need to trust your DNS provider, twenty years ago just as well
as today.  It is just that for one no man-in-the-middle can look
at the communication (TLS), and that you can cryptographically
verify that the data is really correct ("DNSSEC").  The latter
only if any parties that your DNS provider contacts ship the
signatures down along with responses, of course.
And there was EDNS ~20 years ago already, TCP should not be
necessary for neither of DNSSEC nor TLS (regarding packet size).

 |Under the "Prevention Tactics" the article talks about "revoking
 |malicious certificates", but what tools/methods are there to tell you
 |which certificates are malicious?
 --End of <20200525152338.beed20b18e42642ec340305e%gmail.com@localhost>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)