Servers

SSL: Broken even more

Lately, security conferences have been bad news for SSL. The recently held Black Hat DC 09 was no different, with independent security guru Moxie Marlinspike explaining quite convincingly how he was able to completely bypass SSL security.

In January I wrote an article, SSL: Really broken this time, in which I described how forged certificates could be created if the signing Certificate Authority used the MD5 algorithm for signing. That wasn't too difficult of a problem to rectify; it just required Certificate Authorities to use SHA-1 instead of MD5. Even so, most people in the know realized that it won't be too long before SHA-1 has the same problem as MD5

SSLsniff

Well, I'm afraid that cracking SHA-1 is the least of our problems. You may remember Moxie Marlinspike, he's the developer of a sophisticated hacking tool called SSLsniff. The application exploits vulnerabilities in Internet Explorer, allowing Man-in-the-Middle (MitM) attacks even if SSL connections are used. Microsoft eventually fixed the vulnerabilities by disallowing leaf certificates to act as signing certificates.

Even with the vulnerability fixed, SSLsniff is still a powerful tool. As evidence, SSLsniff was used to demonstrate MitM attacks by the group of cryptographers who discovered the MD5 exploit I mentioned earlier.

SSLstrip

Moxie Marlinspike's new and improved tool is called SSLstrip. Quite simply, SSLstrip allows an ill-intended attacker to capture sensitive personal information without even worrying about encryption. Moxie Marlinspike decided to sidestep the encryption process once he realized that users almost always request Web pages using the http (unencrypted) prefix. That's even the case for the more confidential Web sites like those provided by financial institutions as shown below:

After the initial portal page is brought up, https is enabled after some user intervention as the following image shows:

SSLstrip is simply a MitM proxy that advantages this flaw/oversight in the https process by stepping in between the user and in this case the bank's Web server. Let's look at the process using me as the guinea pig:

  1. I enter the URL http://www.usbank.com into the Web browser.
  2. I then type my user name in the appropriate box and hit enter.
  3. SSLstrip captures the URL and my username.
  4. SSLstrip connects to the USBank Web server and provides my username.
  5. SSLstrip then returns the new Web page provided by the bank Web server to my computer.
  6. I provide my password and hit enter.
  7. SSLstrip once again captures that information and transmits it to the bank Web server. As far as the bank Web server knows, I'm officially logged in.
  8. SSLstrip once again passes the new Web page provided by the bank Web server to my computer. I then go about my business.

Something is wrong though, how come the "s" is missing from http in the URL? I thought the bank's Web site was secure. It's not there because the SSL connection was setup between my attackers' computer and the bank's Web server. I was getting all the correct Web pages sent to my computer, but not over secure channels. Guess who now has my log in credentials?

I realize that an observant user would more than likely be aware of the sleight of hand taking place here, but then I suspect that many more will be fooled by this. For more details about the exploit, please view Moxie Marlinspike's Black Hat presentation New Tricks for Defeating SSL in Practice (pdf). He did a great job explaining the entire process.

Even sneakier

In Moxie Marlinspike's presentation, he points out a few other techniques that can be applied to make the unsecure Web page look more convincing. Most Web browsers display the favicon supplied by the Web server right next to the URL in the address bar. What SSLstrip allows you to do is replace the favicon with one of your choosing.

By doing this many more people will be fooled as they have been told to look for a closed lock and if it's there then they can be assured that they are safe.

It's even possible for the attacker to supply a real SSL connection to the requesting computer with a URL that's almost identical to the one asked for. The difference being a few extra characters at the end. Moxie Marlinspike explains in the next slide:

Change the Web browser

We humans are creatures of habit; I doubt that anyone would argue that. Knowing that, I honestly can't say that I'd catch the deception every time myself. One good thing is that this dilemma has been talked about by others. I was fortunate that TechRepublic's managing editor Jason Hiner alerted me to George Ou's article HTTPS web hijacking goes from theory to practice.

The article explains that developers need to give Web browsers enough intelligence to know whether the connection should be SSL encrypted or not and if encryption isn't occurring to disallow the connection. George also mentions that Google is working on this very problem in their early versions of the Chrome 2.o Web browser. Hopefully other Web browser developers will follow suit.

Final thoughts

First, I'd like to thank Black Hat for the use of their logo and Moxie Marlinspike for the use of his presentation slides in this article. I also admire his wanting to make everyone aware of this potentially serious attack vector.

I realize that this exploit is one that requires inattentiveness on our part. Fortunately, most people I talk to mention that they wouldn't get caught by this. Just to test that theory, think back to the last time you went to a Web site that used SSL. Did you check the URL? Were you sure that the traffic was encrypted? I didn't.

Worried about security issues? Who isn't? Delivered each Tuesday, TechRepublic's IT Security newsletter gives you the hands-on advice you need for locking down your systems and making sure they stay that way. Automatically sign up today!

About

Information is my field...Writing is my passion...Coupling the two is my mission.

182 comments
rufusion
rufusion

It seems to me that this could be mitigated by the browser vendors by: - Attempting connection to HTTPS by default, if the address given does not specify a protocol (as GOu pointed out, most people just type in "www...") - Failing over to HTTP if the site does not respond to HTTPS (or refuses the connection), and finally - Failing over to HTTPS if the site does not respond to HTTP (or refuses the connection). This could marginally increase connection time as the browser waits for a timeout. The last item is needed because if this were the (de facto or otherwise) standard for browsers, web sites could *refuse* connections via HTTP, rather than redirecting them to HTTPS. I agree with LongOfTooth's recommendation that users can protect themselves by creating and using bookmarks to commonly-visited secure sites, and specifying https: in the bookmark. The cost, in both monetary and performance terms, of an SSL certificate is nominal these days. Any site handling confidential data absolutely must provide their site over HTTPS, and even those sites that don't handle confidential data should consider it anyway. Setting the browser to try HTTPS (either first or anytime HTTP fails) would allow site administrators to reject HTTP connection attempts wholesale, instead of referring them to the HTTPS (and risking the referral being intercepted). Although I guess then the programmer of SSLStrip could then have it watch for refused HTTP connections and use *that* to jump in as a proxy. All the more reason to program browsers to use HTTPS by default. Any thoughts?

Michael Kassner
Michael Kassner

I was just checking my NoScripts setting and I rememebered that there is an https configuration tab. Noscripts will allow you to pick sites that NoScripts will force an https connection. I think that is one answer to this problem. Well as long as you use FireFox. Or that may be a good reason to start using FireFox.

Kevin.Tam
Kevin.Tam

Hi...great little article...not sure if I understand the full idea of the exploit though. Could I clarify? PROBLEM: 1) SSLStrip looks out for HTTPS links in HTTP traffic to identify its potential victim. 2) Once found, it then uses the Man in the Middle exploit on that line of communication to read the unencrypted client's data stream whilst passing on the encrypted data to the webserver which thinks it is still talking to the real client. SOLUTION? If the above is correct, why not run a one-way start up page with NO https links thereby avoiding identification as a target as in step 1 above? ie: 1) User points to http://somedomain.com 2) The index.html has a redirect with no other content or user interaction whatsoever or runs this php in the index.php - OR..would the mere fact of the file having "https" in it in point 2 above ID it to SSLStrip? If that's the case, you'll just have to tell the users to always expect each page to be encrypted. Hmmm...anyone know of a script which will throw up a dialog window when a page isn't running through SSL? Kev

dprows
dprows

What if you use a redirect on your website to force users to https? I run a website for a credit union and if someone comes to the site using http I force them to https. Would this fix the problem? I do it by placing the following code at the top of my pages (using php): Credit Union's URL has been replaced by 'www.anywherecu.com' to protect the cu.

techrepublic@
techrepublic@

First, the exploits described in the article have very little to do with SSL weaknesses. Second, I don't see what the "big deal" is. To accomplish those proxy tricks the system must already be compromised. If the system is compromised then a better approach to stealing passwords would be to alter the browser so that any form with a password field would also be sent to the hacker. Any of these approaches would be far more difficult to detect by the user. Any other data, not just passwords, that passes by the browser could be compromised the same way.

JCitizen
JCitizen

or HTTPS:\?? Or is this common? I ran the URL through the web certificate checker and it comes out squeaky clean; in fact I've never seen such super clean ratings for a web site! Sorry to ask this question, before reading all the post, but I've been cramped for time lately. It may be a while before I get back here to read the rest of the posts.

Michael Kassner
Michael Kassner

I've been trying to find more about SSLstrip, but the actual process/code hasn't been reverse engineered and Moxie Marlinspike to his credit is keeping quiet about the details. At least as far as I know or have been able to find out. George Ou has what I consider the best plan that's not really difficult to implement. "There needs to be an automated mechanism that ensures the end user's security which requires zero knowledge or participation from the end user to work. We can create such a secure mechanism with minor changes to DNS and web browsers. First, we use DNS to publish a list of websites that must operate in HTTPS through custom DNS records. Second, the web browser will automatically force a connection to an HTTPS page if instructed to do so by DNS and it will maintain a list of websites that are only to operate in secure HTTPS mode. We do this second part because we cannot always assume that DNS is trustworthy especially in the case of wireless hotspots. The DNS mechanism would only work as a toggle on to force HTTPS for all future web browsing sessions but it would not be permitted to toggle off HTTPS unless it was a trustworthy DNSSEC server. This means that once a user successfully visits a secure website for the first time, they will always remain secure for that website even if they cannot trust the DNS server they're using on public wireless hotspots." It's not perfect, George even admits that, but it has the potential to work.

JCitizen
JCitizen

many of my secure sites have no padlock or https:\ prefix in the URL when I visit the main logon page; this to keep such a scenario from happening? I visit a LOT of secure sites that have no visual cues but do NOT transmit over non SSL traffic. I've checked their certificates and they are squeaky clean!! Go figure!

Michael Kassner
Michael Kassner

Thanks for the comment, it was definitely appreciated.

Michael Kassner
Michael Kassner

Do the visitors log on the first page that shows up? If so what if they have that page cached? I like your approach as it will eliminate many problems. I wonder why everyone doesn't do that. Is there a performance hit or any foreseeable issues?

Michael Kassner
Michael Kassner

I see your point of it not being an issue with the SSL protocol. Still do you at least admit that it potentially is capable of affecting millions of people that feel SSL is secure? Your suggestion that the system is compromised is where we differ. What concerns me is that SSLstrip doesn't have to compromise anything. It just sits quietly in the traffic. If I misunderstood you I apologize and would appreciate any further edification.

JCitizen
JCitizen

as our clients aren't as savvy as we are and will only go so far to secure their machine depending on budget. With such knowledge I can give them informed advice, to make the most economic defense decisions. With the blended defense I provide my clients your scenario would be more difficult for the cracker, whereas this SSL exploit cannot be mitigated easily.

Michael Kassner
Michael Kassner

Could you explain it in more detail? What Web site are you referring to?

Kevin.Tam
Kevin.Tam

Michael: thanks for thinking through our discussion if "forcing https via .htaccess at the web server & scripting pages themselves to check they are working through https" works. I note your comment about Kaminsky's bug. Don't know if I've read it right..but has it been fixed? Check out DNS checker in the top right of... http://www.doxpara.com/

JCitizen
JCitizen

had a privacy feature in their PC-cillin product that would automatically reduce pre-defined data to asterisks, if it detected the private data in question leaving the computer on port 80 without SSL, email, and Internet Messenger. It must have been SSL service aware, to tell the difference, it saved my bacon more than once. Norton used to do the same thing in 2004 thru 2006. I don't know if what I have now in NIS 2009 is anybetter than a password vault.

Kevin.Tam
Kevin.Tam

Thanks the reply Michael and the thoughts. I also appreciate the information George contributes for us to chew over too. The "Must-work-on-https" DNS list is an idea but as pointed out, depends on getting the user to an uncompromised DNS - the last point being too dependent on user awareness - the possible weakest link in this scenario. This is all fine however if the browser itself is aware of sites that have to be on https..but until that's implemented, I think we need to do our own work of enforcing the https connection (we should perhaps to this anyway rather than depend on 3rd parties like the DNS & the web browser). Since we're trying to make this transparent to the user, how about this? 1) Force all traffic to your site to run on https via the RewriteEngine command in .htaccess 2) Build into all the pages a function (eg: via php) to check that it is running through a SSL connection and alerting the user if it isn't. If we are getting the user to stop operating the page via feature 2 above, we avoid the clear text from user victim to MITM problem? However, if I'm looking at this correctly, we still have the problem of where a more sophisticated MITM is running 2 separate SSL connections - one to user victim and one to webserver, and therefore still able to read all the info. Given you don't know the deeper details of how SSLstrip ID's its potential victims, the above is the remaining problem? I still wonder if the one-way redirect I mentioned in my 1st post would do that job...

Michael Kassner
Michael Kassner

All sites using https will still accept http requests. I shown that in the USBank example. I'm curious to learn how you start out using http or https.

dmm99
dmm99

Perhaps I am not understanding this, but the solution is already implemented. My web browser is set up to warn me any time it switches between http and https. I then have to click OK to allow the switch. Annoying, yes, but I know at all times whether I am using SSL or not. So then this exploit wouldn't work, right? I would go to logon to my bank, and either I wouldn't get any warning about switching to https (a red flag) or else I would get a warning that it was switching to http (a red flag). Am I missing something? Isn't the problem really that most people find these warnings annoying, so they turn them off entirely?

dprows
dprows

They do login on the first page they come to. I do not see a performance hit by doing this redirect. If this won't protect against this issue, then browsers should default to https and then automtically try http if it doesn't work. Would this prevent this issue?

micha
micha

It's the SSLstrip man in the middle that's talking to the website. That MitM proxy machine will get the redirect, NOT the original client. The MitM will do the PKI exchange. The original client will still be getting (unencrytped) pages back from MitM. And MitM will still be getting (unencrypted) data from the client. Or is there something I'm missing??

charlow
charlow

Michael, No I would not admit that this would potentially affect millions of people. SSLStrip cannot sit quietly in the traffic. It can only sit quietly in the traffic if some proxy server that the user uses is infected with this program or th PC they are using is infected. Does SSLSTrip run on a router? Is SSLStrip a replacement for a DNS server? Can SSLSTrip run on any other system besides a windows environment? The only way this could happen without the users knowledge is if the DNS server that the user uses for name res is infected or if they are behind a firewall/proxy that is infected or their PC is infected. Anything can be proven in a lab environment but its still highly unlikely to affect millions. The Black Plague still exists in a lab.

Dumphrey
Dumphrey

that somehow got inserted into a large web proxy set up, or a dns server thats been poisoned to redirect to the sslstrip box. In neither case would the end users computer have to be infected/compromised for this exploit to function.

JCitizen
JCitizen

for Consumer Reports you see no HTTPS in the address bar and no padlock; but when you check that URL's certificate, it is spotless. http://www.consumerreports.org/cro/index.htm?view=Login To get these things to show, you have to purposely fudge your logon so that you are redirected to a page that actually shows you these things. There is nothing wrong with their security for now, but without the visual cues, you would have to save the fudge page as a favorite, so you could get visual cues, without testing the page everytime. I'm sure you can see how this could be time consuming for some folks on many of the sites I've discovered this. And thanks again for the SSL page test site, I use it religiously on new sites and check old ones occasionally too. Very detailed reports result with this valuable tool.

JCitizen
JCitizen

into the console for that feature. I had real difficulty dropping Norton and PC-cillin because of this fantastic security feature. Many other products claim similar capability, but are either actually password vaults or just usage track eliminators. The ability to actually automatically block sensistive data from leaving the PC was quite the feature in my book. When I would absent-mindedly submit personal data without checking the SSL indicators, PC-cillian would put out blank or asterisk filled fields. This would happen on forms, email, and IM messages. People would look at it and ask me what the heck happend!? And I'd slap my head and realized the data should never have gone out unencrypted. It was a real education in data security for me when I started back into regular computing. To the best of my knowledge Trend Micro and Symantec were the only ones doing it. I have no idea if they still do. Like I said before, it looks like Norton simply uses password vaults now. It would be neat to know if Trend is still doing this and test it through SSL email on Gmail. (edited) I correct myself - I think Agnitum Outpost Firewall Pro was attempting this, but since they fail a lot of leak test from independent labs, I got the yips trying to use them. They had a lot of bugs on XP x64.

Michael Kassner
Michael Kassner

How did PC-cillin determine what was private? did you have to tell it? That's really interesting, thanks J.

Michael Kassner
Michael Kassner

I'm sure it won't be too long before someone reverse engineers SSLstrip and we all will be off to the races. Ironically, I consider Kaminsky's bug as much if not more of a problem and there has been precious little work done to rectify that. I realize it's a huge undertaking but it's a big problem too.

Kevin.Tam
Kevin.Tam

..but since we won't ever live in an ideal world (wouldn't be having this conversation otherwise) perhaps the onus needs to be the webserver/webpages to keep the user in https (webserver) & alert the user if & when it isn't (webpages). You state: "So, if the Web server can supply the "use SSL flag" it would eliminate the problems and simplify everything." That's my point exactly. From what I understand from various sites, it is possible to force a https connection using RewriteEngine in the .htaccess of the website's directory ie: https all the time even if the user only types in http (or the equivalent) in the URL address bar. You state: "Still, I think having the Web site publish the need to use https is too late in the process." Agreed. I'm hoping that the above .htaccess method avoids the unencrypted user-to-MITM data stream part of the situation in the first place. Again, without knowing what triggers SSLstrip to pick up a connection, hard to tell. However, the script in the webpage is just to alert the user that there's a problem (not running through https) if and when it occurs. In this case, does the web browser really need to "know ahead"?

Michael Kassner
Michael Kassner

You are saying that the Web browser has the ability to understand that it's supposed to use https for the connection in question. I think then you, George Ou, and I agree on that aspect. We differ as to what entity supplies that information. If I can humbly speak for him, George and I feel that has to come from the DNS server. Still we both admit that has all sorts of problems. So, if the Web server can supply the "use SSL flag" it would eliminate the problems and simplify everything. Still, I think having the Web site publish the need to use https is too late in the process. For some reason, I feel that the Web browser needs to know this even before the initiation of the SSL handshake.

Kevin.Tam
Kevin.Tam

..the idea is that the *web pages themselves* do and will alert the user when they are not running through https. That should negate the need for DNS or web browser dependencies? And if you're not remotely qualified to talk about this, I'd say I'm not even on the same planet. Like you, I'm hoping someone better skilled will be "ah ha"ing about this now and be kind enough to share their thoughts. Hopefully it will be easy enough for us all to implement :)

Michael Kassner
Michael Kassner

Yet, I must mention that I'm not remotely qualified when it comes to appropriate Web host design. I do know that with DNSSec, a lot of the vulnerabilities will go away. Still it's going to be years before that's in place. Verisign just mentioned that they will have their DNS servers converted, but not until 2011: http://www.techworld.com/news/index.cfm?rss&newsid=111315 The only thing I see as a problem is that how does the Web browser know it needs to be running https. Truth be told, I think it's going to take some bright person with an "out of the box" solution to resolve all of these problems. I appreciate your thoughts and comments to be sure as they may give you or someone an "ah ha" moment.

Michael Kassner
Michael Kassner

Always try adding an s in the URL. I almost always do that now, especially if I have a hunch that the site will be using SSL.

JCitizen
JCitizen

not very secure practice huh? I've only just started using the address bar, as I found the autocomplete is faster than looking for links/favorites. I'm pretty lazy when it comes to typing. I'll have to change that practice on my next job.

Michael Kassner
Michael Kassner

Did anything about BH09 especially stand out in your mind? I've been to only one BH and I don't think I slept the whole time.

marrio
marrio

In my experience, Joe User would not be checking for an 's' let alone a padlock symbol. The minority who do would be vastly outnumbered by those who fall for this trick. End result: the bad guys win. Great article - good work at BH09. Let's hope they fix it... if it can be fixed.

Michael Kassner
Michael Kassner

If you have a link or favorite setup to use https or type https in, then there is no problem anyway. If you use auto-complete without https in the address in the browser and SSLstrip is in the mix, you will not get warned and that's where the problems lies.

dprows
dprows

The cost of purchasing/renewing certificates and the fact that people don't usually type https when typing an address.

Michael Kassner
Michael Kassner

That would eliminate the problem, well at least this problem. I'd love to ask some more questions. I bet you can tell that this isn't my area of expertise. First, why do you think Web hosting sites just don't use https for all sites?

Michael Kassner
Michael Kassner

I has a lapse in my synapses. It's still a good idea, but not helpful with SSLstrip. Thank you for pointing that out.

Michael Kassner
Michael Kassner

It also doesn't have to be on the victim computer or other proxy server. SSLstrip builds on the MitM attack exploit that's available quite freely on the Internet. The application has everything that's required to make sure the victim's computer is accessing the Internet and going to the Web pages that they want. This is especially easy if Wi-Fi access is used. I can go to any open hot spot, setup my computer to act as the stronger AP, and get all sorts of computers connecting to my system.

Michael Kassner
Michael Kassner

You are bringing up two very important issues. The DNS issue should bet a great deal better once DNSSec is implemented by all of the DNS providers. This issue with SSL, could be controlled by using intelligent Web browsers that know which sites are SSL enabled and will refuse the connection if it's not https.

Dumphrey
Dumphrey

how deeply the whole system needs to be reworked. Can we really make end-to-end SSL truly secure if DNS can be broken/poisoned/exploited to allow the middle man? What if a version of this was able to run on routing hardware? (a wee far fetched I admit, but within realm of possibility.) And also, what police force, government agency would not like to make use of this to gather evidence. But how do we verify they are using it within legal bounds? Security is no longer about keeping out the lone cracker out to make a name for them self, but in resisting the attempts by organized groups out to profit in a big way.

d_g_l_s
d_g_l_s

And I think we need to go further with this as this is the crux of the issue. This is the original setup for security that has now the possibility of compromise, just like the method of whacking a key in the average door to make it unlock automatically. This needs to be thought through thoroughly to ascertain a better way to handle the process. As the key is passed so too the password has to be passed. So how to get this to work without the possibility of interception? Is the issue the passing of the key or is it the route taken? What it we have made the route to be unchangeable? Not sure if it's possible but is there a way to secure the DNS servers so they are "tamper proof"? All this to say that I'm wondering if there are some other ways that this can be "fixed" so that the SSL security can still work, as it's still a very good method outside of this one new exploit.

dcolbert
dcolbert

That is the danger of this. Your machine could be completely secure, and defended well enough that if the MiM launched an attack or tried to dump a trojan or downloader, it would reject it - but your SSL information would still be completely compromised. It is in the false sense of security that you've got an encrypted tunnel across the public network that is protecting your confidential data. With Cain and Abel, I've described it this way... Imagine that you have a key that you need to hand off to someone you've never met. You call this person to arrange a hand-off, but a third person is listening on the line. Your arrangement is "One of us will come to the other one's office between 2 and 4 PM tomorrow". The third party who is eves-dropping shows up at the office where the key is, and presents himself as YOU and gets the key. Then he boogies back to the YOUR office, presents himself as the "key-holder", and passes the key along to you. From that point forward, the evesdropper is the man in the middle, passing the key, and any information, back and forth between the two legitimate parties - but with access to any confidential information that they have locked with the key. You think he is the OTHER party, and the other party thinks he is YOU.

JCitizen
JCitizen

hopefully I will continue to endeavor to strengthen my weakness in the use of the English language to transfer my thoughts more efficiently. =)

Michael Kassner
Michael Kassner

Thanks for sharing that Web site. It's a great idea.

JCitizen
JCitizen

Michael and I appologize. I was testing that URL with this tool. http://www.networking4all.com/en/support/tools/site+check/ I did this because the usual visual cues weren't present in IE 7; like the padlock and HTTPS:\ prefix. I thought this was informative and apparently it wasn't - again, my appologies!

Michael Kassner
Michael Kassner

Still, I think your process of verification is suspect. I say that mostly from the fact that the URL you provided is not helpful. From your comments J, you appear to rely on what the entity provides to determine whether it's secure or not. Am I understanding it correctly. I know you so I feel that I'm not getting it, sorry.

Editor's Picks