4

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.

3 Answers 3

8

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 added1, 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.

5
  • This question is about services that are only available over https. It's outside the scope of sslstrip. Mar 27, 2014 at 9:37
  • @user2675345 no it's not, even for services only available via https you either need to enter a url by hand or click a link, if you do not explicitly add the HTTPS by hand or the source of the clicked link was HTTP then SSL Strip is very relevant. Mar 27, 2014 at 13:48
  • I go to twitter.com and I am given twitter.com. SSL strip does not work if there is no plaintext version of the site. Mar 27, 2014 at 16:18
  • @user2675345 That is because twitter uses HSTS so your browser automatically goes to the HTTPS version. So after you visit the page once the browser stops checking the HTTP version, but it still must connect with HTTP the very first time (unless the browser vendor includes twitter as flagged as HSTS "out of the box" which is very possible). Mar 27, 2014 at 17:03
  • I've looked it up and I think you're right. Thank you for the clarification. +1 Mar 28, 2014 at 8:58
0

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.