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?
-
1Server can enforce HTTPS too; try replacing every https request with http and most likely you get "too many redirects" message. (facebook for example)– KyslikMay 31, 2016 at 6:41
-
1Moxie Marlinspike has a good presentation on mitm attacks that replay or strip SSL traffic - youtube.com/watch?v=ibF36Yyeehw– SachoMay 31, 2016 at 11:53
-
With a properly developed application, you can shape input validation to only accept https urls. Moreover, if your web server is setup accordingly, http requests will become https. Of course, this dodges many of the other issues mentioned by others, but, if you're not doing at least what I have mention, then you've got work to do. However, I think the end game to your scenario comes in with the CA scheme. The IP of the destination matters.– Anthony RutledgeMay 31, 2016 at 15:54
-
2Q: "Doesn't the web server determine whether to connect via HTTP or HTTPS?" A: No, the client does.– Ajedi32May 31, 2016 at 16:07
Add a comment
|
4 Answers
The decision on whether to use HTTP or HTTPS is the client's.
If the user goes directly to http://example.com, an attacker could simply hijack that connection and perform a man-in-the-middle attack. If the user goes directly to https://example.com, then the attacker must spoof the SSL/TLS connection somehow; doing so without showing the user an invalid certificate warning requires the attacker to have access to a Certificate Authority's private key. This situation should never happen. Without this, the user's browser would reject the connection, not allowing the attacker to redirect.
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.
answered May 30, 2016 at 20:39
-
See also Is firefox disabling of insecure TLS fallback part of the HSTS spec? (full disclosure: the accepted answer is my own).– userMay 31, 2016 at 11:39
-
1Additionally, while it isn't supposed to happen, it does happen: A Controversial Surveillance Firm Was Granted a Powerful Encryption Certificate (May 27, 2016 15:25 EST). The article title is oversimplified for the general public; the company was granted by Symantec a certificate with the right to sign further certificates turned on, for alleged "internal testing purposes".– userMay 31, 2016 at 11:40
-
Regarding this statement "requires the attacker to have access to a Certificate Authority's private key", isn't it also true that an attacker could spoof the SSL connection if they somehow managed to install their own CA root certificate on the machine? Its also possible on a windows desktop which has IIS installed to run a spoof site locally with a self signed certificate which will be automatically trusted by the browser.– rdansMay 31, 2016 at 15:44
-
4@rdans If the attacker controls the private key for any CA certificate installed on the victim's system, then yes, that is potentially a viable MITM attack vector for an attacker that has access to the data transmission path.– userMay 31, 2016 at 15:46
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.
-
Well, they could send the response, but the client would reject it as invalid because the certificate doesn't match, correct?– jpmc26May 31, 2016 at 21:07
-
@jpmc26 No. If the server can't demonstrate a matching certificate then the client will refuse to even finish the TLS handshake, way before it sends its HTTP request. (Note that HTTPS is just plain HTTP wrapped by a TLS tunnel) Jun 1, 2016 at 9:01
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.
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?
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.
Doesn't the web server determine whether to connect via HTTP or HTTPS?
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.
And DNS lookup is done before they connect to the server.
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 google.com
Couldn't they just tell the client to connect via HTTP instead of HTTPS?
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.
