SSL Wars: The SSL Strikes Back

In my last few posts I reviewed some of the SSL type vulnerabilities. These vulnerabilities were the result of SSL misconfigurations. Today I will address a client side SSL/TLS exploit.

How many people do you know who access secure websites by typing HTTPS://www.securesite.com in the address field of their browser? The vast majority of people just place the website name (www.securesite.com) in the address field of their browser and let the chips fall where they may. So I guess my question would be “How does the browser know whether to send me to a secure site (HTTPS) or send me to an insecure site (HTTP)”? Does the browser see www.securesite.com in the browser and flip a virtual coin to decide whether or not to direct me to an insecure (HTTP) or secure (HTTPS) connection? Does the browser read www.securesite.com and think to itself “I bet that site should be established over a secure connection today,” or does the computer just use magic to decide whether to establish a secure connection or not?

I will now attempt to explain the great mystery and technical awe and wonder of how the browser determines whether to establish a secure or insecure connection... Ready... Here goes: If the type of connection is not specified in the address field of the browser (HTTP or HTTPS), then the connection defaults to being established over HTTP. In other words, if I type www.securesite.com into my browser, the browser will default to HTTP://www.securesite.com. *Whew, That was tough to explain.* So the question is how do I end up using a secure connection (HTTPS) if the browser defaults to a non-secure connection (HTTP)?

In all reality most people only encounter HTTPS through HTTP. In other words, people are directed to secure connections through insecure connections. Secure connections (HTTPS) are generally established through redirects or links.

Let’s discuss how HTTPS is encountered through redirects. Suppose I am the owner of a company which sells bobsleds to people who live in the Sahara desert (I just fired the head of marketing). I set up a website named www.hotsledsforhotclimates.com. In order to purchase a sled we require people to provide SSN, Checking Account Number, and three different credit cards using our website. I have a doctorate degree in quantum cryptography so I know that sending all this sensitive information over an insecure connection like HTTP is not a good idea. I decide that if someone tries to access my webpage through HTTP that they should probably be redirected to a secure connection (HTTPS). “Franz” (A desert dwelling hermit from the Sahara desert) decides he wants to purchase a bobsled in case it snows. Franz has heard that the site www.hotsledsforhotclimates.com has the type of bobsleds he is looking to purchase. Bob opens his browser and types www.hotsledsforhotclimates.com into the address field of his browser. The browser sends the request to HTTP://www.hotsledsforhotclimates.com. The request is sent to my website which promptly tells Franz’s browser that it must use HTTPS to connect to www.hotsledsforhotclimates.com. The web browser is redirected to HTTPS://www.hotsledsforhotclimates.com. Franz purchases his bobsled and the world is right again.

The second way that people generally encounter HTTPS is through links. Suppose that a site is dedicated to the hottest companies who sell bobsleds to people who live in the Sahara desert. Nothing on the website is confidential so the site does not require a secure connection (Everything is sent through HTTP). The site has links which redirects people who wish to purchase one of these bobsleds to hot sleds for hot climates. The link which points to hot sleds for hot climates is HTTPS:// www.hotsledsforhotclimates.com. Franz (Our beloved hermit) is reviewing the site dedicated to the hottest companies who sell bobsleds to people who live in the Sahara desert and decides that he must purchase a bobsled from one of these companies. In a moment of weakness Franz decides to use his children’s college fund to purchase a bobsled (The sleds are very expensive). He selects the link for HTTPS:// www.hotsledsforhotclimates.com and is quickly sent to a secure site where he can purchase the bobsled of his dreams. Franz purchases his bobsled and everyone is happy (except for his poor kids who will now be forced to attend a small community college).

So to reiterate, people encounter HTTPS through HTTP (More specifically, redirects and links). So what is stopping attackers from intercepting all links and redirects which tell the browser to use HTTPS and replace them with links which point to HTTP? Why can’t attackers place themselves between the customer (Franz) and the web site www.hotsledsforhotclimates.com and modify all redirects and links destined for HTTPS and replace them with links to HTTP? What would stop an attacker from setting up an insecure connection with the customer and a secure connection with the website and act as a middleman between them? The answer to these questions is: essentially nothing! In fact, a tool named SSLStrip performs this type of attack with minimal effort.

SSLStrip works as follows. An attacker performs a man in the middle attack to place themselves between the client and the server. Whenever SSLStrip sees links or redirects which try to send the customer to a secure connection (HTTPS), it replaces the links with insecure versions of these links (HTTP). SSLStrip sets up a secure connection with the site HTTPS:// www.hotsledsforhotclimates.com and an insecure connection with the customer HTTP:// www.hotsledsforhotclimates.com.SSLStrip even places a padlock favicon in the corner of the customer’s browser to make them think they are connected over a secure connection. The attacker takes the information sent from the customer (Username, Password, SSN, Credit Cards) and logs them to a file for future review. The attacker then uses their secure connection with the server to forward this information to the web server.

So what should you do in order to prevent falling prey to this attack? First, if you type www.securewebsite.com into your web browser or access a link which redirects to a site requesting sensitive information (Username, Password, SSN, Credit Card, etc), manually verify you are redirected to a secure connection HTTPS://www.securewebsite.com. This can be accomplished by looking at the web address listed in the browser and verifying the address starts with HTTPS. Although this safeguard may make it more difficult for an attacker to exploit this vulnerability, a dedicated attacker using an advanced Homograph attack may still be able to successfully exploit this vulnerability. Second, you can manually type HTTPS:// before the website you are trying to access. This will verify the connection is immediately connected through HTTPS and is never sent through HTTP redirects. Once you access the site through manually placing HTTPS// before the site name, the site can be saved as a bookmark for quick access over SSL in the future.

-Gary McCully