[jakelazaroff]

The guarantee TLS provides is not that content is unable to be modified, but that any modifications are detectable.

The router (or anything else between your computer and the server) can modify the content in transport to its heart's content, but it won't be able to sign it with the domain's private key, and so the browser will always know when such modifications have taken place and flag them as malicious.

[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.

[tialaramex]

At a high level this is true, but in practice it's not what's happening, TLS 1.3 makes this tidier so let's use that example:

1. Alice proposes to send encrypted messages to Bob, she hopes this first, unencrypted, message reaches Bob (but if it doesn't she'll be fine, except that she reveals she wanted to talk to Bob) and it has a Diffie-Hellman Key Share inside it which is just basically a number Alice got by doing some mathematics on a (different) random number that Alice never tells anybody, even Bob.

2. Somebody receives Alice's message, they do the other half of the Diffie-Hellman Key Share, and send that to Alice. Both this somebody and Alice now (thanks to DH) have a set of symmetric encryption keys nobody else knows. So using symmetric encryption they immediately have an encrypted channel between Alice and whoever somebody is.

3. The somebody sends Bob's certificate over the encrypted channel. But Bob's certificate is a public document, it does NOT prove this is Bob.

4. If this is really Bob he wraps up everything they both said so far (message from Alice, reply from Bob, sending back a certificate etcetera) and Signs that with his private key which is paired with the public key inside his certificate. He sends the signature to Alice over the encrypted channel. He _could_ also demand a certificate & signature from Alice at this point but on the web basically nobody does this.

5. Now Alice knows this is really Bob and can safely send messages on the encrypted channel to Bob.

There's no need for any messages to be signed with Bob's key after step 4, all messages are protected with the symmetric encryption keys agreed in steps 1 & 2.

Simply "flagging" things if they're apparently changed isn't good enough, bad guys can use this to create an "Oracle" which destroys security eventually. Instead modern TLS with AEAD will simply abort the entire connection after decrypting a message which has been tampered with, and (correct implementations of) TLS refuse to give you partially decrypted messages, either the whole message arrives and is decrypted successfully, or it hasn't and you can't have the data. Thus an adversary learns nothing from tampering: They know they tampered with the message, and it's not a surprise this blew up the connection - doing it again, and again, and again teaches them nothing further.

If you want to see how it could go wrong otherwise, check out videos of "Lucky Thirteen" which gradually guesses bits of data your browser is wiling to send repeatedly over HTTPS connections while it improves the guess (e.g. cookies). A modern browser mitigates this attack by making the timing involved impractical, but AEAD is better.