SSL/TLS (what provides the “s” at the end of “https” that you are told to always look for) has been a hot topic recently. Google Chrome and other browsers have started marking sites that don’t use SSL/TLS as “not secure”. This has many people upset. For the most part, the arguments seem to be centered around the fact that many sites don’t ask you to submit passwords or other sensitive information in order to read information from the site. SSL/TLS was primarily developed to help keep that type of information safe during “transit” by encrypting it between your computer and the server. From this standpoint, those arguments are correct. The problem is that security isn’t just about keeping data secret… it is a combination of three things: Confidentiality (keeping secret data secret), Integrity (making sure that the data or information isn’t modified from it’s original source), and Availability (just like it sounds – making sure the data/information is available when you want to use it). While SSL/TLS was primarily developed for confidentiality, it also helps with integrity. When a attacker standing between the destination server and your computer (a Man in the Middle or MitM), can’t see the plain text of the data being transferred, they also can’t inject additional content in the encrypted data or modify the content in the encrypted data.
Let’s show a few examples. I am going to setup a MitM attack against my own computer. I don’t think anyone would argue that a MitM attack isn’t possible, so instead of focusing on that; I’m going to focus on how that can be used to cause critical issues with integrity. For this demonstration, I will be using Burp Suite. This wouldn’t be my tool of choice if I was actually running a MitM attack during a pen-test as it requires me to configure the browser to proxy its information through Burp instead of using ARP poisoning or other MitM attacks that you would use against an unwilling victim. (While those tools could also perform the same functionality, the point of this post isn’t to show someone how to maliciously attack other people – it is to show the concepts a malicious attacker would use.) For the purposes of this demo, we will look at scripting.com. Scripting.com is operated by Dave Winer. Dave is a brilliant person who has had a very positive effect on the internet as we know it today; but he is very outspoken against the concept of marking websites that don’t use SSL/TLS as “not secure”. Important note: I am not attacking his website; I am attacking my own computer. I would never attack a website without the permission of the website owner. The modifications that I will be making to the traffic in transit affect my computer only, and do not affect anyone else.
We will start with a very basic example – I will add a heading to scripting.com that says “I love TLS and think every site should use it!”. Within Burp, I have already configured it to listen on all interfaces of my computer over port 8080. I then move into the Match and Replace section of Burp which allows me to set a rule to automatically alter content on traffic flowing through the proxy. I tell it to take “<body>” (which should be on pretty much any web page), and replace it with “<body><h1>I love TLS and think every site should use it!</h1>”.
After that, I configure FireFox to use my proxy, and I load Dave’s article on Google and HTTP. Sure enough, the heading that I added shows up when I load the article. I don’t think that’s the content that Dave wanted to communicate to his audience.
Ok… so what if it isn’t a big deal to change what the website says? Well, that’s where code injection comes into play. For this demonstration, I will inject malicious javascript into the page. This is from the BeEF framework which then gives me various levels of control over the user’s browser. Next, I’ll clear my cache and cookies in the FireFox browser (to ensure that I don’t use any of the content from the last unwanted modification to the page); and then reload the page.
This time, nothing appears out of place to the user, but if we look at the source of the page, we can see my malicious javascript loaded into the browser.
This may seem like nothing, but my FireFox browser running on my Windows 10 machine is now vulnerable to a XSS attack from my Kali Linux machine running BeEF. I can see this by looking at the web GUI for BeEF and seeing my Windows computer (192.168.1.115) listed in the Online Browsers section.
Now I can send an attack from BeEF. I’m going to try and trick the user into thinking they need to log into Facebook in order to continue reading the article.
In fact; there are a number of “fun” things that I can do from BeEF, including install persistence in the browser (so that even if the user is no longer under control of my proxy, their browser is still infected with my code from BeEF), exploiting plugin vulnerabilities in the browser, various forms of phishing attempts, and even recording audio or taking a picture/video of the user through their webcam if the browser allows that functionality.
So… does SSL/TLS fix everything?
Not necessarily – it depends on how the site administrator setup SSL/TLS. The reality is that many users don’t pay attention to whether or not the browser shows the “s” in “https”. This means that even if a site supports and forces https on the server-side, it may not be forced on the user’s side. Let’s run an example against one of my own testing domains – https://im-a-teapot.net. Normally, this site would force https if you are not experiencing a MitM attack combined with SSL stripping. This time, I’m going to use Burp to strip SSL/TLS from the request. If we view this site from a regular browser, you will see that it loads over https. If you load it from my browser that is undergoing a MitM attack, you can see that it loads without SSL/TLS. (Note, under normal circumstances, I have a function on the site enabled that would cause a redirect loop during an SSL strip attack. I did disable that feature for this demonstration.)
Loading on my normal browser
Loading on the browser affected by the MitM attack
So… if SSL/TLS can’t fix user behavior, what’s the point?
Well, there are things that you can do along with enabling SSL/TLS. For one thing, as a website owner, you can enable HSTS and force your website to load over SSL/TLS; which will stop most SSL Strip attacks. For another, as a user, you can install HTTPS Everywhere to help force your browser to https so you don’t need to remember to do it yourself.
What if I don’t care if my site is secure or not?
Dave does make a excellent point on his article “Google and HTTP” – the web isn’t safe. He makes the point that maybe everything shouldn’t be safe. If that’s your opinion, that’s totally fine; but there are obvious issues with not using SSL/TLS that have been demonstrated in this article and by a number of other security researchers. If you don’t want your site to be secure, that is your choice – but that doesn’t mean that the average user shouldn’t be alerted to the fact that there are security problems with the site. If you are worried that they might get scared when they see that label and back out of your site because they don’t understand exactly what isn’t secure; that’s fine. If they don’t understand exactly what isn’t secure, then they certainly don’t understand what the risks of visiting your site are. If they choose to stick to the safe side, good for them – they should be able to make that decision (although, lets be honest – most people probably wouldn’t). No one is doing away with sites that aren’t secured with SSL/TLS; we just want people to be able to understand that there are risks to those sites, and let them make an informed decision on whether or not to use that site.
One last note
Just because a website uses SSL/TLS and the browser says it is “secure” does not necessarily mean that it is safe or secure. All that “badge” means is that they encrypt the traffic between your computer and their server. It does not mean that it isn’t a phishing site, or that once the site has the information that they necessarily handle it safely – it just means that you are reasonably protected against MitM attacks being able to successfully compromise your information or your computer.
