Let's say someone does an ARP spoofing or DNS poisoning attack to redirect traffic to their own web server. If the real site has an SSL/TLS certificate, would that stop the hacker from redirecting let's say google.com to their own server? Doesn't the web server determine whether to connect via HTTP or HTTPS? And DNS lookup is done before they connect to the server. Couldn't they just tell the client to connect via HTTP instead of HTTPS?
|
|
The decision on whether to use HTTP or HTTPS is the client's. If the user goes directly to In the case of Google and a number of other websites, they set the HTTP Strict Transport Security (HSTS) header, which causes the user's browser to cache a rule saying that they should never ever visit the site via plaintext HTTP, even if the user asks for it or Google itself redirects to a HTTP URL. The browser will automatically re-write the URL to HTTPS, or block the request entirely. This also prevents the user from clicking through a certificate warning in most browsers; the option simply isn't there. |
|||||||||||||||||
|
|
No, the DNS lookup does not tell the client if it should connect via HTTP or HTTPS. The browser decides that - if you enter an HTTP URL it will request without TLS on port 80, and if you enter an HTTPS one it will request with TLS on port 443. So it is the client, and not the server, that decides. If the server gets a request over a protocol it does not prefer it can issue a redirect by responding with a 300 status code and a location header. However, if the original request is over HTTPS the man in the middle would need a valid certificate to be able to send that response. And if he had that, there would be no need to redirect to HTTP in the first place. |
|||||||||
|
|
First of all I think the biggest thing that OP missed is that SSL/TLS negotiation happens first. Only AFTER safe connection is negotiated and validated, there can be any HTTP communication. HTTPS is a big misnomer, it's just your plain old HTTP only sent over completely independent SSL/TLS.
Certificates are checked and TLS is established before any HTTP takes place. With wrong cert, the connection will never be established in the first place. No room for redirects.
No, the client does. By either opening socket and sending HTTP request in plain text, or by opening socket, performing full SSL/TLS negotiation and then sending HTTP request.
Yes, but the client checks the certificate against the DNS name. So I can DNS spoof you into coming to me instead of Google, but I'll still need a certificate issued to
No. They never get a chance to do this. |
|||||||||
|
|
If you happen to have a certificate authority that will validate any certificates for any domain, that's when you have a huge problem. Prior to certificate pinning by the browsers that is done only to the domains that they have an interest in, everyone else has to depend on CAs' not behaving badly, which is why there is a repository of collated SSL certs with which you can verify if it changes from spoofing. Or rather there should be. |
|||
|
|
