1

If a device sends a request to https://example.com and someone spoofs the DNS response to redirect the request to some malicious server. Would the attacker be able to modify the packets during the TLS handshake to make the original request domain name match and therefore establish the connection?

Reveles
  • 13
  • 2
  • What you describe does not need to happen. "someone spoofs the DNS response to redirect the request to some malicious server." means the attacker will be able to reply with IPs it controls, not the real one. With that, there is nothing changing in the name, and depending on what it does it could even have a certificate issued for the name (if it controls BGP routing for example at least for some time) – Patrick Mevzek Jan 25 '21 at 21:55

1 Answers1

1

TL;DR: No.

The TLS connection needs to validate the server certificate, and the attacker will not have a valid example.com certificate. He can either create a self-signed certificate, or a certificate signed by a CA (Certificate Authority) that he owns. And that attacker will not own a valid CA that is trusted by browsers unless he is a government, and even if he is, his CA will be blacklisted very fast.

On both cases, the client browser will show the "Invalid Certificate" warning, and the client will have to acknowledge that and tell the browser to load the site anyway.

That's why TLS was created: to defeat MitM attacks like that. With the certificates and list of trusted CAs, every client can be sure that he is talking to the server he thinks he is talking to, and nobody but he and the server can know what is being transmitted.

There are a couple issues with TLS (and SSL before it) that can allow an attacker to know what is being transmitted or change something, but those attacks are quickly patched.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • 1
    So if the attacker used his own certificate the request would be blocked only by browsers? If the victim ran « curl https://example.com » the DNS spoofing would then work wouldn’t it? – Reveles Jan 20 '21 at 02:22
  • Curl will reject it, wget will reject it, links, lynx, elinks, w3m, every well written software that handles HTTPS will reject it. – ThoriumBR Jan 20 '21 at 11:54
  • But if the attacker used a valid certificate from Let’s Encrypt for example how can curl detect that the certificate does not belong to example.com ? A part from the domain name being exchange during the TLS handshake? – Reveles Jan 20 '21 at 14:24
  • 1
    Let's Encrypt won't issue a certificate for `example.com` to a random person. The person must prove ownership of the domain before being issued the certificate, and that proof includes either changing a DNS record, or hosting a special page on a defined path on the webserver. – ThoriumBR Jan 20 '21 at 14:38
  • "He can either create a self-signed certificate, or a certificate signed by a CA (Certificate Authority) that he owns." and it can also, in some cases, also create a certificate for the name, with any publicly known CA. See this example of BGP hijack, after which any DV validation will work: https://medium.com/oracledevs/bgp-hijack-of-amazon-dns-to-steal-crypto-currency-a90dd29cb3ab. (should be thwarted by CAs doing multiple points of validation, or DNSSEC) – Patrick Mevzek Jan 25 '21 at 21:56
  • An attacker that can execute a BGP hijack don't need a DNS spoof... – ThoriumBR Jan 26 '21 at 00:20