If an attacker has the ability to modify data transferred over an Internet connection, can he or she affect TLS?

Question

Now that Google, Twitter, and some other sites require a TLS connection to access their sites, when you go to http://www.twitter.com it redirects to https://www.twitter.com/. If an attacker had access to your Internet line, could he or she have the connection running over HTTP with a fake version of Twitter?

If a user nearly never checks for a secure connection on sites, and they type "twitter.com" which first checks "http://www.twitter.com/" and not "https://www.twitter.com/", could an attacker modify the HTTP connection to create a fake Twitter website without the user noticing? I'm assuming browsers try the HTTP version first rather than the HTTPS version first, but if I'm wrong please let me know.

Answer 1

Yes, and this is exactly what the SSL Strip attack did, while using the unsecure HTTP connection it transparently turned all HTTPS links in to HTTP links and proxied the connection, if you did not notice that you where not on a HTTPS connection you could easily send confidential data over a unsecure connection.

As a web site admin you can combat this by setting HTTP Strict Transport Security, what this does is once you connect to the site once all future connections to that site will be via HTTPS till the header expires or the client's cache of HSTS sites is cleared, any attempts to connect to HTTP will automatically be redirected to HTTPS.

However this does not protect you if the clients very first connection to your site was intercepted, but it does help you in situations like you describe in your question where the browser tries HTTP if you don't have any prefix added¹, HSTS will automatically force that HTTP link in to a HTTPS link if the site is stored in the client's HSTS cache.

^{1: It is not that the browser that automatically checks for HTTPS if it can't find HTTP. The way it works is the HTTP page will just be a redirect page to the HTTPS page if you hit it.}

Answer 2

An attacker really doesn't need access to the "Internet line" to redirect someone to a fake web page. If an attacker has access to the sever he/she would be able to do some cloning and change the I.P address of to whatever he would like - but you could use "phishing" technique to redirect to another url. Computer are only as smart as the user - so while a computer could do so much to hold your security it is still up to that user to be aware. The Internet could be your friend or enemy.

Answer 3

You might want to read up on IDN homograph attacks or script spoofing. Since characters outside of the usual a–z (case insensitive), 0‒9, and - (hyphen-minus) can now be used, the possibilities have greatly expanded. Whereas previously, you could only hope to trick users by using combinations like vv to substitute for w, now any Unicode homographs can be employed and some of these homographs are identical when rendered pixel by pixel! Here is one example for Twitter (with the Unicode code points in parentheses) generated using an online tool specifically for this purpose:

Original: twitter (74,  77,  69,  74,  74, 65,  72)
Fake:     twіttеr (74,  77,  456, 74,  74, 435, 72)

The first one is real, but the second one is fake. Depending on the font, not all the "fake" versions may look right. Characters from less supported code blocks may render using a completely different font from the rest of the string and tip off the victim.

There is a simple defense against the attack however: render the Unicode domain name as the underlying Punycode (a separate topic you can read about on your own), or selectively render as Punycode for domain names that have characters from multiple Unicode blocks.