[austincheney]

That is true after the certificate chain is validated by the browser, but not before. A malicious router attack could just as easily modify the initial http request so that the user is directed to the domain on a spoofed IP before HTTPS trust violation. The malicious http server would also have to spoof the original cert though, but then they get malicious trusted https on the trusted domain that returns similar looking code.

[jakelazaroff]

It doesn't matter. The browser can use the SSL certificate and the corresponding public key to verify that the contents of the connection originated from the server at the domain it expects. Unless the server's private key or browser's root certificates are compromised, the connection cannot be spoofed without being detected.

[austincheney]

You really didn't read what I wrote. If the malicious site uses the valid domain and a spoofed cert for that domain it cannot tell the difference and will establish the very same trust. The browser has no way of knowing if the requested domain is hosted from the appropriate IP address. This is all handled by the DNS system. DNS lookups and caching are not a function of the browser.

Perhaps you will take it more seriously if it comes from Wikipedia: https://en.wikipedia.org/wiki/Certificate_authority#Validati...

[jakelazaroff]

I did read what you wrote, but it's incorrect because you can't create a valid certificate for a domain you don't control.

> If the malicious site uses the valid domain and a spoofed cert for that domain it cannot tell the difference and will establish the very same trust. The browser has no way of knowing if the requested domain is hosted from the appropriate IP address.

In your scenario, the browser receives the spoofed certificate. The domain matches, but when it checks the certificate chain against its root certificates, it can't find a matching signature. Because of this, the browser knows the certificate hasn't been signed by a certificate authority it trusts, and it throws up that warning page about visiting an unsafe site.

Your Wikipedia article (and my earlier caveat about the server's private key being compromised) refers not to spoofing a cert, but to the CA being tricked into signing a certificate for a party who doesn't control the domain:

> In particular, it is always vulnerable to attacks that allow an adversary to observe the domain validation probes that CAs send.

In this case, requests to that specific domain would be vulnerable to man-in-the-middle attacks. However, it's outside the scope of TLS, which only ensures security in transport when neither the client nor the server have been compromised; it has nothing to do with securing private keys or verifying control of a domain in the first place.

[pixl97]

Spoofed certs are difficult, especially if you turn off certs like let's encrypt with dns.

[Dylan16807]

> A malicious router attack could just as easily modify the initial http request so that the user is directed to the domain on a spoofed IP before HTTPS trust violation.

If the initial request is HTTPS, everything is validated, and a spoofed redirect is impossible.