[GTALUG] DNS-over-HTTPS - what's the use?

Nicholas Krause xerofoify at gmail.com
Tue Dec 24 00:10:32 EST 2019



On 12/23/19 5:43 PM, D. Hugh Redelmeier via talk wrote:
> | From: Giles Orr via talk <talk at gtalug.org>
>
> | Firefox now makes available DNS-over-HTTPS.  I'm a big fan of security
> | and privacy, but I'm struggling to see the gains here: we stop some
> | hypothetical observer from finding out what domain name we're querying
> | ... and then immediately turn around and ask that domain for a web
> | page.  You hid the destination in your first query ... only to
> | immediately expose it with your next query.
>
> I've not thought much about this so I probably have missed some
> issues.
>
> It is horrible that we haven't transitioned to DNSsec.  DNS is the
> single worst technical weakness with no excuse.  It's been 20 years of
> almost no adoption.
That's true. However the question is perhaps the cost of
SSL encryption on older 20 year computers so too expensive.
Actually most modern CPUs do encryption in instructions
due to this. Not sure if SSL is as expensive as AES or SHA
to compute but maybe it was.

Also encryption or at least implementations of it in protocols
was not taken that serious at that time. Perhaps society has
changed too which is good, but a lot of people forget that
the technical is dependent on other factors. Just stating
its a weakness does not really matter but asking why I
should care does. Look at Ipv6 or hardware supported
memory sanitizing as a example which was just being
added to hardware even through the issue has been
known for the last 5 years.
> Without DNSsec, active man-in-the-middle (MITM) attacks are easy and
> undetected.  By "active", I mean: modify the query or query results,
> not just observe them.
>
> ISPs do active MITM attacks.  Routers do them.  Corporations do them
> for their employees.  Governments do them.  Invisibly.
>
> I'd rather trust Mozilla than everyone on my query's route.
>
> My network does not use outside recursive nameservers.  I use my own
> in-house (literally) recursive nameserver.  I could switch it to use
> HTTPS to talk to Mozilla's recursive nameserver if I chose to (it
> would involve a small matter of programming because the off-the-shelf
> programs don't currently support this).
>
> The fact that Mozilla put the resolver in the browser is a little ugly
> but understandable.
>
> - they control the browser
>
> - they have to modify one piece of software, not try to push a new
>    feature on unwilling maintainers of perhaps a dozen pieces of
>    software, the most important of which are closed source.
>
>    This does not preclude those dozen pieces of software each adopting
>    the new protocol.
>
>
> (I've been annoyed that so much of a resolver is embedded in glibc.)
  That makes sense from any systems programmer who
requires nameservers or DNS. At this point not having it
is like not having a sockets library in my view. So the
question is why don't you think this outside of glibc
being already bloated in size compared to other
c libraries like musl?
>
> ================
>
> Conceptually, I don't like Mozilla being a single point of attack.
> This solution really must be replaced by something better.  But will
> it?
Doubtful in the future probably due to security not being
a "profit" to most companies sadly. You could set it up on the
root DNS servers and have a legacy version for non
DHSsec connections through. Granted this would require
a major agreement from all involved parties and basically
require rewriting core parts of the Internet.
>
> There is a chance that a make-do solution like this will de-motivate
> possible adoption of DHSsec.  That would be bad.
>
> ================
>
> HTTPS has more setup time than UDP or TCP.  But a single HTTPS pipe
> between your browser and Mozilla can carry many queries and responses
> (I assume that the DHS-over-HTTPS has been designed to support this).
>
> ================
>
> My tentative conclusion is that this is a hack but it is a quick and
> simple way to somewhat better security.  The slow but better ways are
> not working.
> ---
> Post to this mailing list talk at gtalug.org
> Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Cheers,
Nick


More information about the talk mailing list