HTTPS does not prevent DNS spoofing, since these two protocols work at different layers and in fact HTTPS, because of the X.509 certificates that underline the Web PKI, need the DNS (both at certificate issuance time and also at client verification time), while the DNS does not need HTTPS to work (of course when you do not use it explicitly like with the newer "DNS over HTTPS" trend).
DNSSEC instead does prevent DNS spoofing.
Why? Because it is easy to get DV certificate nowadays, and those are delivered after a check either on some HTTP or DNS resource, and if the underlying IP is spoofed, then the certificate is issued without problems.
So, given www.example.com that has a very nice certificate (even an EV one), if example.com is handled by nameservers ns1.example.net and ns2.example.net, then:
- anyone getting access to
example.net domain (controlling it),
- or anyone being able to change records on
ns1.example.net or ns2.example.net
- or anyone controlling
example.com at its registrar and being able to change its nameservers
- or anyone being able to change DNS resolution on the fly for
www.example.com at least locally
even temporarily, will be able to map www.example.com to an IP address of its choosing (either directly, or indirectly by controlling the nameservers IP addresses instead), and then go to whatever automated DV-issuing well known CA to get a proper validated certificate, that will be recognized as fully trusted by any modern HTTPS client.
Using HTTPS here does not guarantee in any way that the remote end is really what it is: it "guarantees" the hostname but certainly not the IP address!
Exactly to mitigate these attacks (the third point of the list about), good CAs employ the following two techniques (or should employ them) at certificate issuance time:
- use a DNSSEC validating resolver: if the domain name is DNSSEC enabled, then any on the fly change of records will get detected
- use multiple vantage points and correlate the response: for domain names not being DNSSEC enabled, checking their resolution almost at the same time from diverse source will lower (but never render to 0) the risk of someone being able to change the response in-flight (because it would need either to do it in multiple places at the same time, or do it very closely to the nameservers, in which case the attacker is kind of already in the second point listed above, that is the control of the nameservers)
And in fact things are even worse than that because an attack can still happen with full proper DV certificate allowance even without any IP address change, if IP addresses are hijacked, as it happen "regularly" with BGP either as an error or an attack. In such cases, it means that someone is able to get all the traffic for a given IP address (or block) and study it exactly at it wants (and it can even be almost impossible to detect - except for some added latencies - if then the traffic is redirected properly to the legitimate owner of the IP). If it asks a CA to deliver the certificate, the DNS or HTTP validation mechanism will end up to the "true" IP except that the traffic to this IP will go to the attacker, and hence the validation will pass.
All of the above happens "regularly", some recent cases:
- https://dyn.com/blog/bgp-hijack-of-amazon-dns-to-steal-crypto-currency/
Yesterday morning we posted a tweet (below) that Amazon’s
authoritative DNS service had been impacted by a routing (BGP) hijack.
Little did we know this was part of an elaborate scheme to use the
inherent security weaknesses of DNS and BGP to pilfer crypto currency,
but that remarkable scenario appears to have taken place.
[..]
However, the users of networks that accepted the hijacked routes
(evidently including Google’s recursive DNS service) sent their DNS
queries to an imposter DNS service embedded within AS10297.
- https://dyn.com/blog/bgp-dns-hijacks-target-payment-systems/
As in the Amazon case, these more recent BGP hijacks enabled imposter
DNS servers to return forged DNS responses, misdirecting unsuspecting
users to malicious sites. By using long TTL values in the forged
responses, recursive DNS servers held these bogus DNS entries in their
caches long after the BGP hijack had disappeared — maximizing the
duration of the attack.
[..]
Passive DNS observations between the 10th and 13th of July showed
*.datawire.net domains resolving to 45.227.252.17 – IP address space registered as being in Dutch Caribbean island of Curaçao, but routed
out of breakaway region of Luhansk in eastern Ukraine.
- https://www.theregister.co.uk/2018/04/24/myetherwallet_dns_hijack/
Victims had to click through a HTTPS error message, as the fake
MyEtherWallet.com was using an untrusted TLS/SSL certificate. The
bandits have amassed $17m in Ethereum in their own wallet over time.
[..]
Crucially, this DNS hijacking was possible after miscreants pulled off
a classic BGP hijacking attack on AWS. MyEtherWallet.com uses Amazon's
Route 53 DNS service so that when people try to visit the dot-com, AWS
looks up and returns to web browsers the IP addresses of the wallet
website's web servers.
Between 11am and 1pm UTC today, someone was able to send BGP – Border
Gateway Protocol – messages to the internet's core routers to convince
them to send traffic destined for some of AWS's servers to a renegade
box in the US.
That last case shows that, even where HTTPS should have helped (the attacker did not even go all the way to generate a DV certificate while they could technically, they just used a simple self signed one, that triggers alerts in any HTTPS client in its default configuration of trusting only a specific list of CAs), finally it does not because people just bypass the warnings. But here it is clearly a UI/UX problem and not the underlying TLS protocol error.
