If a CA or a DNS provider gets hacked, could they just change all the websites registered through them, or what could they do?
If I recall correctly, that actually happened a long while back. Maybe 15 or 20 years ago. I’d have to do some web searching to refresh my memory and get details. It was in an era when SSL/TLS was pretty new and most operating systems didn’t have full support for certificates, etc. so each browser had a list of trusted root certificates.
It allowed bad actors to do man in the middle attacks on basically any service using SSL/TLS.
Anyway, there was a mad rush to remove the hacked service’s certificate information from the trusted store on each app, etc. and get updates out to users. And legitimate sites that happened to used the hacked CA provider for their certs had to find a new CA provider as fast as they could.
Nothing happens. It’s just you have some trouble accessing the internet, until you switch to another DNS provider. DNS is not secure in the first place, the security of the internet does not depend on a single DNS service being reliable and secure. In some countries DNS are intentionally wrong for certain websites in order to block them, yet this can be easily bypassed so they still have to rely on SNI-based block.
This is much more serious than DNS. We do have certificat transparency, so it cannot go unnoticed.
1 Like
DNS poisoning is not nothing.
Like I said the security of the internet does not depend on DNS being secure. All websites use https, and you cannot connect with a wrong or spoofed DNS, so you are just blocked, but nobody sees or modifies the traffic. You can always use DoH or DoT or proxies.
What are you talking about? Did you even bother to read?
This results in traffic being diverted to any computer that the attacker chooses. Put simply, a hacker makes the device think it is connecting to the chosen website, when in reality, it is redirected to a different website by altering the IP address associated with the domain name in the DNS server.
Https encrypts data in transit and has nothing to do with how domain name servers work.
You cannot redirect to another website under https with spoofed DNS. Redirect is an application level thing, while you cannot even establish the TLS connection with a wrong resolved IP because the spoofed site cannot complete the diffie-hellman stuff without the true private key.
This spoofing you mentioned only works with http, which is why I was mentioning https.
In other words, if you use a modern browser, you can only be blocked but not spoofed or hijacked if your DNS is spoofed. You can always change your DNS (if the attacker cannot quick-answer the DNS response), or use DNS-over-HTTPS to bypass this.
Please stop using Wikipedia as ground truth. It is general introduction, and may not apply to specific cases.
3 Likes
Can’t the DNS just direct you to wrong IPs with fake websites?
from what I read, without the certificate validation, your browser would show a clear warning.
DNS cannot redirect to another website. It’s not designed for this. Redirect is an application level thing.
An attacker on DNS system can only resolve the domain to a wrong IP and you get an error in the browser.
If you visit using http, the fake server can perform redirect, which is why modern browsers try not to use http by default. You can configure that.
Some websites also use HSTS to make sure you cannot accidentally connect via http.
Maybe this was the case ?
Likely. The time period is about what I remember.
Would it be possible to habe some Form of multisignature scheme for website certificates and maybe also their IPs to prevent a single third party entity from compromising them?
WebPKI trust model breaks.
Yes; but: Any “entity” between you and the web service reliant on WebPKI could “MitM”. For example, when Lenovo inserted ads into web pages. This is to say, the fragility of WebPKI[1] is not only on entities one has to explicitly trust (CAs / DNS providers), but also the implicit ones (like, random number generators, or time sources (!), or cryptography algorithms / implementations / libraries / modules).
The ripple effects are going to be really, really bad, depending on just what ends up being pwned.
- CAs (intermediates or root) can be revoked. Compromised keys can be rotated out. Compromised certificates can be denylisted.
- Not commonly used, but “CAA Extensions” can help shore up WebPKI from DNS zone record compromises.
This is one reason why some services shouldn’t rely on WebPKI, especially the ones with their own layer of e2ee (end-to-end encryption). /cc: @maqp
Or, of anything security sensitive, for that matter; for instance, see VeraCrypt’s documentation. ↩︎
1 Like
Isn’t this a totally different thing though?
Obviously if some system library has a backdoor then they can do stuff.
Depends. In terms of the trust model, those “things” exist at different layers. In terms of outcome of us all getting mass pwned, it is all the same.
Not a backdoor, but a vulnerability is enough. From recent past, vulnerabilities in “system library” is more likely than CAs being compromised.
Certificate Transparency was specifically designed to counter this problem. It was brought in after the DigiNotar attack.
1 Like
If a DNS provider is compromised and we assume the provider hosts an authoritative name server for a website, then an attacker can change the records for a website (by changing A(AAA) records to resolve to the IP of a malicious server) and also issue new certificates for that malicious server by completing DNS-01 or HTTP-01 challenges, therefore “redirecting” traffic to a different server.
In the above scenario changing your DNS provider or using DNS-over-HTTPS does not fix anything. Since there is only one authorative zone for a domain, all over DNS providers (recursively) use that zone.
2 Likes