Apparently this only affects those who don't pay attention...nothing to see here.
Can you make the claim you are 100% vigilant 100% of the time?
It's more subtle than that. It takes away one of the biggest indicators that there is an SSL problem--the dialogs. Watch the presentation video [blackhat.com]. It's pretty cool. What Moxie shows is that often the indicators of SSL enabled and not enabled are practically non-existent. It's easy to see how most users, even tech savvy ones, could be fooled.
Check to see if the URL to the site begins with http:/// [http] before you login. If it does, and it's displaying a padlock icon (suggesting that it is 'secure'), then you're being attacked. Really, you should already be wary when a site asks you for login information over HTTP rather than HTTPS.
Also, as interesting as this attack is, it should be noted that it does require the attacker to have network access (so he can perform the MITM attack, usually through ARP spoofing). There are a number of ways to fight arp spoofing, but if you're on a small network, just set static arp tables on your machines and you've done pretty much all you can do. The attacker can still attempt to get access at your ISP and on the other end, at the web host, but handling that much traffic without being noticed would be difficult, so I doubt one would try it. (and I'm sure someone will now prove me wrong...:P)
Check to see if the URL to the site begins with http:/// [http] [http] before you login. If it does, and it's displaying a padlock icon (suggesting that it is 'secure'), then you're being attacked. Really, you should already be wary when a site asks you for login information over HTTP rather than HTTPS.
Even this doesn't work. Legitimate banks do this (http://www.usbank.com is one, who I've banked with in some fashion since I had a net worth of over $50). Note that after you type your username in, you're taken to a
Really, you should already be wary when a site asks you for login information over HTTP rather than HTTPS.
Maybe. The login form might be located on an HTTP page, but as long as the form submits to an HTTPS page, your login credentials are still SSL-encrypted. Conversely, if you have an HTTPS login form, but the form action goes to an HTTP site, your credentials are NOT encrypted.
The login form might be located on an HTTP page, but as long as the form submits to an HTTPS page, your login credentials are still SSL-encrypted.
In general, yes, but one of the 'tricks' of sslstrip is that it changes the content of the HTTP-served page so that the (formerly) HTTPS submission page is no longer HTTPS, but HTTP.
Say for example you're using an unsecured wireless access point at an Internet cafe. There can be an attacker five miles away with a high gain antenna listening for someone to log into their bank by a login page that only encrypts the password. When your computer sends out the request for your bank's page, if the hacker's computer is fast enough, it can impersonate the wireless access point and send a version of your bank's login page with the password encryption stripped and the password redirected to whatever computer your attacker wants. When the real server finally responds to your request a few milliseconds later, your computer will think it's a mistaken duplicate and ignore it. This is not a theoretical attack, it has been publicly demonstrated. Your first login attempt may fail as the password is redirected to the attacker, but once your attacker has your password, he can return things to normal so your second login attempt will succeed. You'll just think you mistyped the password on the first try.
Your first login attempt may fail as the password is redirected to the attacker, but once your attacker has your password, he can return things to normal so your second login attempt will succeed. You'll just think you mistyped the password on the first try.
That's why I always type my password in wrong on purpose the first time!
We don't need an alternative to SSL. We need browsers to implement proper UI. The user MUST be made aware if clicking a button would transmit a password in cleartext. The user MUST be made aware exactly which domain they are connected to during an SSL session. On a large busy screen, a tiny bit of text in a corner is the wrong way to do this.
These guys [pigeonwatch.co.uk] now have your credit card number, and the passwords to your email and bank accounts. The good looking one on the right also has your girlfriend's email & phone number.
But did he get the combination number to her chastity belt? I haven't actually seen the thing but it must exist since I can't get anywhere near there...
UPI - Crow Agency, WYOMING - The Federal Environmental Protection Agency has issued a crackdown order on a traditional method of communication and possible free public access to the Internet. The method utilizes traditional Native American techniques with a modern twist. Computer signals called packets are translated into smoke signals and released into the atmosphere. The first message sent using this technique contained the message, "The casino is now open. $3 Black Jack and Texas Hold 'em. Smokey Robinso
Reading TFA, it seems to me that there IS something that the end user can do to protect themselves: Look for the https:/// [https] in the address bar and DON'T LOOK THERE (favicon.ico area) FOR THE PADLOCK... the padlock should be down in the statusbar area where it always is.
Out of reflex, I always check that my URL starts with https:/// [https] and I check the cert when I'm dealing with someplace new. Now, I'm just always going to check the cert... even if I'm connecting to a site I use all the time.
If Moxie really wanted to make things tougher, they could maybe add a cert to their tool. THAT would make it so you'd only notice if you read the cert and realized it wasn't what it was supposed to be.
If you read some of the articles (Forbes and a linked one) he can spoof the appearance of a valid certificate as well using International Domain Names. The certificate won't be valid for the site that you wanted, but that won't matter because it'll have redirected you to https://a/ [a] load of characters that look like 'paypal.com/somepath' but are actually non-ASCII characters].evil.com with a wildcard certificate for *.evil.com and look like https://paypal.com/some-path-here-that-is-really-really-really-really-long.evil.com/ [paypal.com]
For the basic attack then actually checking for HTTPS and a proper validation (not just a padlock, but a padlock and the other markers), but for the fuller attack that takes advantage of the IDN then you'd probably need to read the certificate itself, which would require you to know which certificate you're expecting, which would require something like a page with the signature on saying "look for this", which could then also be spoofed (in cases where it was worth it, e.g. a bank).
The certificate won't be valid for the site that you wanted, but that won't matter because it'll have redirected you to https://a/ [a] load of characters that look like 'paypal.com/somepath' but are actually non-ASCII characters].evil.com with a wildcard certificate for *.evil.com and look like https://paypal.com/some-path-here-that-is-really-really-really-really-long.evil.com/ [paypal.com]
Hrm. I must have missed that; it's a clever trick. Then again, I've always thought international domain names were gratuitously unneces
The solution to this problem is simple, and I'm surprised browsers don't do this already: add fake '/' character isn't in the IDN blacklist. In Firefox, network.IDN.blacklist_chars already contains plenty of things that look like '/'. Maybe other browsers need to follow its example.
Do you know if FF will detect blacklist characters for all TLD's or just the non-IDN TLD's like.com and.net?
Another, perhaps more reliable option would be to change how long URLs are displayed. Right now, if a domain name exceeds the length of the address bar, it's truncated on the right. Consider: www.paypal.com/foo/bar/qux/sessionid/12341/do.myevildomain.com. If this URL is displayed as:
www.paypal.com/foo/bar/qux/sessionid/123
the user will be fooled. What if, instead, the truncated domain name looked like this?
www.paypal.com/foo/bar/...341/do.myevildomain.com
That way, no matter what evil junk is in the domain nam
Look for the https:/// [https] in the address bar and DON'T LOOK THERE (favicon.ico area) FOR THE PADLOCK
So great.. you teach everyone to LOOK FOR THE HTTPS, and that means you're safe!
Then, the attackers simply use a variant of the (similar URL method), and are sure to include SSL, so the URL is (for example) https://www.mybank.com.com.cn/ [com.com.cn] (or whatever fools the user).
Even if you could somehow re-train millions of people successfully to understand one particular attack mode, another one will always be right aroun
This attack does not break SSL in any way. It simply tricks users into entering sensitive information into unencrypted context.
The solution is user education. We need to train users to look for the browser padlock icon. We need to add browser extensions that heuristically detect credit card numbers being entered into unencrypted sites and to warn the user. We need to train users to click "no" on security dialogs when they appear. We need to tell users that a padlock icon a website puts next to a form is unacceptable. We need to train users to be vigilant, because nasty people are trying to steal their information.
I'd like to see fewer people using self-signed certificates that train users to ignore SSL warnings. I'd like to see public service advertisements. I'd like to see basic computer safety classes in public schools. User education is the only hope we have against stupid users!
The fault lies partly with browsers too. Firefox, particularly, should never have toned-down the non-EV SSL user-interface --- sure, making EV special is fine, but allowing sites to spoof the SSL UI with a favicon is unacceptable. People have been saying this ever since Firefox 3 came out, but maybe now someone will pay attention to us.
We need to train users to look for the browser padlock icon
But this can spoof that as well for many users (and even for Firefox users it might make the unwary feel safe).
We need to add browser extensions that heuristically detect credit card numbers being entered into unencrypted sites and to warn the user.
He also mentions methods for using IDN (Internation Domain Names) and wildcard SSL certificates to spoof HTTPS versions that look even more like the real thing than https://yourbank.com.some.evil.website. [website.com]
He also mentions methods for using IDN (Internation Domain Names) and wildcard SSL certificates to spoof HTTPS versions that look even more like the real thing than
This problem is easy to solve technically with an IDN character blacklist. The https-to-http redirection is far more insidious.
HTTPS puts a blue background behind the favicon and the padlock and certificate domain in the status bar. What kind of favicon can ever spoof the entire blue background. More importantly, what favicon can ever spoof the s
HTTPS puts a blue background behind the favicon and the padlock and certificate domain in the status bar. What kind of favicon can ever spoof the entire blue background. More importantly, what favicon can ever spoof the status bar section?
Why can't a favicon start with a blue background? Can't a favicon from the target site get a new blue background dynamically easily? Who pays attention to the status bar? What about TFA's assertion of being able to use
They handing out mod point to everyone these days or what?
No, they must be handling out mod points to people who have a fucking clue how SSL works. SSL is designed specifically to counter your simplistic scenario.
the mitm intercepts (and blocks) client's attempt to start an ssl session with bank, instead the mitm makes the ssl connection with the bank AND the client. Where is your https and padlock icons now?
The MITM won't be able to give the client the proper certificate for the domain name the client thinks he's connecting to. The browser will detect this mismatch and give the user a broken padlock icon and a security warning. Because we've educated the user, he'll know to look for the padlock icon, and that a broken padlock icon means "danger". Attack averted.
That's probably being sold by Thawte. And considering that a lot of browsers out there still don't support EV.
Extended validation? When I pay for a digital cert, I expect a high level of validation anyways. Makes you wonder, what level of validation they've been doing for the past few years.
SSL always MITM as one of its exploits. There's a lot of network gear (e.g. Cisco's IronPort) that do just that in order to enforce security policies of an organization.
SSL always MITM as one of its exploits. There's a lot of network gear (e.g. Cisco's IronPort) that do just that in order to enforce security policies of an organization.
That's still impossible unless you're okay with the client getting the wrong certificate. In a corporate environment, you can just install a CA certificate in every client and the user will be none-the-wiser. But in general, SSL is not vulnerable to undetected MITM attacks.
If you've paid for digital certificates, shouldn't you know what level of validation they've been doing?
Also, as far as I know, all modern browsers support EV certificates, but not all of them differentiate EV certs from regular ones. Firefox 3, however, does.
Makes you wonder, what level of validation they've been doing for the past few years.
If the credit card making the purchase was declined or not.
I do not like the whole "EV certification" thing. Not because I dislike the process or what it's designed to do, but because CA's were already supposed to be doing the verification in the first place (apparently, they weren't). Now they want to charge more money to do what they were originally supposed to do.
I do not like the whole "EV certification" thing. Not because I dislike the process or what it's designed to do, but because CA's were already supposed to be doing the verification in the first place (apparently, they weren't). Now they want to charge more money to do what they were originally supposed to do.
Like most human behavior, this problem can be explained by economics.
The problem is that the CA system creates the wrong incentives. You, as a CA, want to sell as many certificates as possible. There ar
There are a couple solutions to the incentive problem:
Make users pay CAs to validate websites: this puts the economic incentives in the right place, but users will resent paying for what used to be "free". Personally, though, I'd subscribe to an enhanced validation service.
Change CAs into non-profits: the problem with this approach is that funding would then have to come from the government or some other organization. Can you imagine "PayPal, stop accepting payments for contraceptives or we'll revoke your certificate, you liberal hippies"?
I wish I could come up with better ideas.
Having a CA funded by anyone but the website also doesn't work, since the site needs to get a certificate from the CA before going live. And unless it's ICANN running the CA, a site might need to get certs from multiple CAs if people in different countries or with different browsers want to talk to them.
Hmm, there's a thought. Self-signed certs, with the root cert fingerprint available as a DNS record, using DNSSEC. Then get the real-world identity info from 'whois'.
Having a CA funded by anyone but the website also doesn't work, since the site needs to get a certificate from the CA before going live.
I don't see why a site requesting a CA needs to be live. Consider FooCA, a for-pay CA that users subscribe to, or that ISPs subscribe to on behalf of their users. (There are other models --- this is just an example). If BarInc wants a certificate from FooCA, BarInc just applies to FooCA as soon as BarInc incorporates and obtains BarInc.com. Why would BarInc.com need to be l
Please don't get me wrong, this will make a nice addition to a toolbox.
However, the hype I have seen tied to this tool is overwhelming.
It seems like conferences have become more reliant on over-hyping items like these to promote the conference name more than anything else.
You could also try to read about it...
The problem is not with SSL, it's with an attacker redirecting the traffic before it is in SSL, as your typical banking session usually start in plain HTTP. People then fail to understand the visual clues given by their browser.
This attack is a nice technical MITM/social engineering mix, countermeasures are not really purely technical, if banks stopped to be cheap and did all their serving over HTTPS there would not be any HTTP traffic to modify in the first place...
A site should never lead the user to type sensitive information into a form on an unencrypted page, even if the form's data goes to an encrypted location when submitted. Doing this trains users to be lazy. What's even worse is trying to alleviate users very correct fears by putting a padlock icon next to the form. That's even worse: doing that trains users to believe that a website can signal its own trustworthiness apart from the browser UI, and that could have disastrous consequences.
I have a technical solution, but it won't be popular: browsers should display a warning when submitting a form on an unencrypted page to an encrypted URL. Since web designers are afraid warnings will spook users, they'll switch to making the form-entry pages encrypted as well.
This would be great, except that most users don't read warnings. They click through them in whatever looks like the most likely path to allow them to finish what they started.
And what about servers using vhosts on a single IP?
More people need to use RFC3546 Server Name Indication [hightechsorcery.com] for SSL name-based virtual hosting. All major browsers already support it; the only barrier is Apache and OpenSSL. mod_gnutls for Apache, however, works perfectly.
Even in the absence of RFC3546 [ietf.org] support, there are several workarounds:
Your form has to submit a single, non-virtually-hosted URL to work properly anyway. Just put the page that displays the form in this location as well.
In essence one could say that the issue in this case is _not_ with SSL, but with HTTP, and similar protocols which have never considered security except as an afterthought (HTTPS is plain HTTP over SSL).
FTPS for example, which is FTP over SSL, is hardly used at all and instead protocols like SCP reign for secure FTP. If people would just stop what they're doing for a moment and realize that the issue is that we're using an inherently unsecure, stateless protocol wrapped inside a security blanket for trans
The solution to this is really to stop using HTTPS for 'secure' access and use something better
Let me guess: you think SMTP is to blame to spam, too.
In both cases, the protocol is not the problem. In fact, both protocols are well-designed and effective. Blaming the protocol is a gross oversimplification of the problem and a cop-out. If you were to do enough work to propose a solution, you'd realize that quickly. Any new protocol that did the same job as HTTP or SMTP would run into the same intrinsic problem
SSL is NOT broken. It is still an effective way to encrypt network traffic.
The attack breaks down two ways. Proxying web traffic between a user and a sensitive site like a bank and/or repsenting a URL to a user that looks legitimate but isn't.
The indicators that you are on an SSL site are varied. A lock in the lower right of the window (FF3), to the right of an address bar (IE 6 and below), or a green address bar (IE7 EV cert) or a green indicator to the left of the address bar (FF3). All except the EV SSL certs are pretty subtle. The success relies on the fact that there are so many varied ways that SSL protection is presented to the user, can you keep track of it all. Quick, which sites use EV certs? You don't know so you don't know what to expect.
So, the attack does a couple of things to fool you. First it proxies your web traffic to secure sites re-writing urls that start with HTTPS to HTTP. The only indicator in browsers is no lock. If you are not looking for it, then you probably won't miss it. But wait, since we are rewriting URL's, why not replace the favicon with a lock. Yummy.
The second type of attack is to proxy HTTPS to HTTPS, but this time the SSL session between you and the proxy is enabled with a valid and trusted SSL certificate. No SSL dialog boxes. Here is how it works. IDN is used so that countries can represent URL in their native character sets. Some non-ascii characters look like characters. So use them to fool the user. These are called homographs. Browsers will convert some IDN based on the TLD. But other TLD, like country codes TLD, the browser won't. The assumption being a.com hostname should be ASCII while a TLD for China should be IDN.
Knowing that, get a hostname in a CC TLD. Get a certificate for your hostname. Then create a really long hostname using IDN so that the TLD portion will be pushed off the end of the address bar. You can forge any legitimate web site this way and the only indicator is either examining the certificate or looking at the TLD in the URL. There are IDN that look like slashes, so making a "path" is easy.
Hm, the article and summary both list it as SSLStrip but the only software I can find on the site is SSLSniff [thoughtcrime.org], which appears to be it? Maybe it was renamed because the link as given in the summary redirects to the main page.
It's completely different. He's had SSLSniff listed on there for awhile now. All requests made to SSLStrip now redirects to the index page. Maybe he doesn't want to exceed his bandwidth?
There is nothing you, as a web application developer, can do to mitigate this problem other than educating users and busting the IT department's balls to get them to improve real network security.
(Well, you could use clever Javascript to try to heuristically detect funny business in the page location, but if you're important enough, an attacker will just the detection Javascript when proxying your site.)
Alternatives (Score:4, Interesting)
Re: (Score:2, Informative)
Re:Alternatives (Score:5, Informative)
Can you make the claim you are 100% vigilant 100% of the time?
It's more subtle than that. It takes away one of the biggest indicators that there is an SSL problem--the dialogs. Watch the presentation video [blackhat.com]. It's pretty cool. What Moxie shows is that often the indicators of SSL enabled and not enabled are practically non-existent. It's easy to see how most users, even tech savvy ones, could be fooled.
Parent
Re:Alternatives (Score:5, Informative)
Also, as interesting as this attack is, it should be noted that it does require the attacker to have network access (so he can perform the MITM attack, usually through ARP spoofing). There are a number of ways to fight arp spoofing, but if you're on a small network, just set static arp tables on your machines and you've done pretty much all you can do. The attacker can still attempt to get access at your ISP and on the other end, at the web host, but handling that much traffic without being noticed would be difficult, so I doubt one would try it. (and I'm sure someone will now prove me wrong...:P)
Parent
Re: (Score:3, Insightful)
Even this doesn't work. Legitimate banks do this (http://www.usbank.com is one, who I've banked with in some fashion since I had a net worth of over $50). Note that after you type your username in, you're taken to a
Re: (Score:3, Interesting)
Really, you should already be wary when a site asks you for login information over HTTP rather than HTTPS.
Maybe. The login form might be located on an HTTP page, but as long as the form submits to an HTTPS page, your login credentials are still SSL-encrypted. Conversely, if you have an HTTPS login form, but the form action goes to an HTTP site, your credentials are NOT encrypted.
Re:Alternatives (Score:4, Informative)
The login form might be located on an HTTP page, but as long as the form submits to an HTTPS page, your login credentials are still SSL-encrypted.
In general, yes, but one of the 'tricks' of sslstrip is that it changes the content of the HTTP-served page so that the (formerly) HTTPS submission page is no longer HTTPS, but HTTP.
Parent
Re:Alternatives (Score:5, Informative)
>as long as the form submits to an HTTPS page, your login credentials are still SSL-encrypted.
No, If any part of a page is not encrypted then an attacker can effectively strip all encryption from the entire page. See this page from a Microsoft Internet Explorer programmer: http://blogs.msdn.com/ie/archive/2005/04/20/410240.aspx [msdn.com]
and this page about airpwn where attendees at a security conference had the images in their web pages turned upside down.
http://www.informit.com/guides/content.aspx?g=security&seqNum=158 [informit.com]
Say for example you're using an unsecured wireless access point at an Internet cafe. There can be an attacker five miles away with a high gain antenna listening for someone to log into their bank by a login page that only encrypts the password. When your computer sends out the request for your bank's page, if the hacker's computer is fast enough, it can impersonate the wireless access point and send a version of your bank's login page with the password encryption stripped and the password redirected to whatever computer your attacker wants. When the real server finally responds to your request a few milliseconds later, your computer will think it's a mistaken duplicate and ignore it. This is not a theoretical attack, it has been publicly demonstrated. Your first login attempt may fail as the password is redirected to the attacker, but once your attacker has your password, he can return things to normal so your second login attempt will succeed. You'll just think you mistyped the password on the first try.
Parent
Re: (Score:3, Interesting)
Your first login attempt may fail as the password is redirected to the attacker, but once your attacker has your password, he can return things to normal so your second login attempt will succeed. You'll just think you mistyped the password on the first try.
That's why I always type my password in wrong on purpose the first time!
Re: (Score:3, Informative)
Lock icon? No.
Shared private keys. (Score:2)
Public key crypto-systems.
Not buying anything online via the web-browser.
OK, that last is crazy talk.
Re:Alternatives (Score:5, Insightful)
We don't need an alternative to SSL. We need browsers to implement proper UI. The user MUST be made aware if clicking a button would transmit a password in cleartext. The user MUST be made aware exactly which domain they are connected to during an SSL session. On a large busy screen, a tiny bit of text in a corner is the wrong way to do this.
Parent
Re:Alternatives (Score:5, Funny)
Parent
Re: (Score:2)
Re: (Score:2, Funny)
Re: (Score:3, Funny)
EPA Crackdown: No More IP Over Open Air (Score:2)
UPI - Crow Agency, WYOMING - The Federal Environmental Protection Agency has issued a crackdown order on a traditional method of communication and possible free public access to the Internet. The method utilizes traditional Native American techniques with a modern twist. Computer signals called packets are translated into smoke signals and released into the atmosphere. The first message sent using this technique contained the message, "The casino is now open. $3 Black Jack and Texas Hold 'em. Smokey Robinso
Not the end of the world (Score:5, Informative)
Reading TFA, it seems to me that there IS something that the end user can do to protect themselves: Look for the https:/// [https] in the address bar and DON'T LOOK THERE (favicon.ico area) FOR THE PADLOCK... the padlock should be down in the statusbar area where it always is.
Out of reflex, I always check that my URL starts with https:/// [https] and I check the cert when I'm dealing with someplace new. Now, I'm just always going to check the cert... even if I'm connecting to a site I use all the time.
If Moxie really wanted to make things tougher, they could maybe add a cert to their tool. THAT would make it so you'd only notice if you read the cert and realized it wasn't what it was supposed to be.
THAT's scary.
Re:Not the end of the world (Score:4, Interesting)
If you read some of the articles (Forbes and a linked one) he can spoof the appearance of a valid certificate as well using International Domain Names. The certificate won't be valid for the site that you wanted, but that won't matter because it'll have redirected you to https://a/ [a] load of characters that look like 'paypal.com/somepath' but are actually non-ASCII characters].evil.com with a wildcard certificate for *.evil.com and look like https://paypal.com/some-path-here-that-is-really-really-really-really-long.evil.com/ [paypal.com]
For the basic attack then actually checking for HTTPS and a proper validation (not just a padlock, but a padlock and the other markers), but for the fuller attack that takes advantage of the IDN then you'd probably need to read the certificate itself, which would require you to know which certificate you're expecting, which would require something like a page with the signature on saying "look for this", which could then also be spoofed (in cases where it was worth it, e.g. a bank).
Parent
Re: (Score:3, Interesting)
Hrm. I must have missed that; it's a clever trick. Then again, I've always thought international domain names were gratuitously unneces
Re: (Score:3, Interesting)
Do you know if FF will detect blacklist characters for all TLD's or just the non-IDN TLD's like
Re: (Score:3, Insightful)
Another, perhaps more reliable option would be to change how long URLs are displayed.
Right now, if a domain name exceeds the length of the address bar, it's truncated on the right. Consider:
www.paypal.com/foo/bar/qux/sessionid/12341/do.myevildomain.com. If this URL is displayed as:
www.paypal.com/foo/bar/qux/sessionid/123
the user will be fooled. What if, instead, the truncated domain name looked like this?
www.paypal.com/foo/bar/...341/do.myevildomain.com
That way, no matter what evil junk is in the domain nam
Re: (Score:2)
Look for the https:/// [https] in the address bar and DON'T LOOK THERE (favicon.ico area) FOR THE PADLOCK
So great.. you teach everyone to LOOK FOR THE HTTPS, and that means you're safe!
Then, the attackers simply use a variant of the (similar URL method), and are sure to include SSL, so the URL is (for example) https://www.mybank.com.com.cn/ [com.com.cn] (or whatever fools the user).
Even if you could somehow re-train millions of people successfully to understand one particular attack mode, another one will always be right aroun
Security is a social issue. Educate! (Score:5, Insightful)
This attack does not break SSL in any way. It simply tricks users into entering sensitive information into unencrypted context.
The solution is user education. We need to train users to look for the browser padlock icon. We need to add browser extensions that heuristically detect credit card numbers being entered into unencrypted sites and to warn the user. We need to train users to click "no" on security dialogs when they appear. We need to tell users that a padlock icon a website puts next to a form is unacceptable. We need to train users to be vigilant, because nasty people are trying to steal their information.
I'd like to see fewer people using self-signed certificates that train users to ignore SSL warnings. I'd like to see public service advertisements. I'd like to see basic computer safety classes in public schools. User education is the only hope we have against stupid users!
The fault lies partly with browsers too. Firefox, particularly, should never have toned-down the non-EV SSL user-interface --- sure, making EV special is fine, but allowing sites to spoof the SSL UI with a favicon is unacceptable. People have been saying this ever since Firefox 3 came out, but maybe now someone will pay attention to us.
Re: (Score:2)
But this can spoof that as well for many users (and even for Firefox users it might make the unwary feel safe).
He also mentions methods for using IDN (Internation Domain Names) and wildcard SSL certificates to spoof HTTPS versions that look even more like the real thing than https://yourbank.com.some.evil.website. [website.com]
Re: (Score:2)
This problem is easy to solve technically with an IDN character blacklist. The https-to-http redirection is far more insidious.
Re: (Score:2)
HTTPS puts a blue background behind the favicon and the padlock and certificate domain in the status bar. What kind of favicon can ever spoof the entire blue background. More importantly, what favicon can ever spoof the status bar section?
Why can't a favicon start with a blue background? Can't a favicon from the target site get a new blue background dynamically easily? Who pays attention to the status bar? What about TFA's assertion of being able to use
with a real SSL cert for fakedomain.ru? Note, apparently | can be a character that is not | or / but shows up just like /
Re:Security is a social issue. Educate! (Score:5, Informative)
No, they must be handling out mod points to people who have a fucking clue how SSL works. SSL is designed specifically to counter your simplistic scenario.
The MITM won't be able to give the client the proper certificate for the domain name the client thinks he's connecting to. The browser will detect this mismatch and give the user a broken padlock icon and a security warning. Because we've educated the user, he'll know to look for the padlock icon, and that a broken padlock icon means "danger". Attack averted.
Parent
EV certificates (Score:2, Interesting)
"for more widespread EV certificate deployment"
That's probably being sold by Thawte. And considering that a lot of browsers out there still don't support EV.
Extended validation? When I pay for a digital cert, I expect a high level of validation anyways. Makes you wonder, what level of validation they've been doing for the past few years.
SSL always MITM as one of its exploits. There's a lot of network gear (e.g. Cisco's IronPort) that do just that in order to enforce security policies of an organization.
Re: (Score:2)
That's still impossible unless you're okay with the client getting the wrong certificate. In a corporate environment, you can just install a CA certificate in every client and the user will be none-the-wiser. But in general, SSL is not vulnerable to undetected MITM attacks.
Re: (Score:2)
If you've paid for digital certificates, shouldn't you know what level of validation they've been doing?
Also, as far as I know, all modern browsers support EV certificates, but not all of them differentiate EV certs from regular ones. Firefox 3, however, does.
Re: (Score:2)
Makes you wonder, what level of validation they've been doing for the past few years.
If the credit card making the purchase was declined or not.
I do not like the whole "EV certification" thing. Not because I dislike the process or what it's designed to do, but because CA's were already supposed to be doing the verification in the first place (apparently, they weren't). Now they want to charge more money to do what they were originally supposed to do.
Re: (Score:3, Insightful)
Like most human behavior, this problem can be explained by economics.
The problem is that the CA system creates the wrong incentives. You, as a CA, want to sell as many certificates as possible. There ar
Re: (Score:3, Insightful)
There are a couple solutions to the incentive problem:
I wish I could come up with better ideas.
Having a CA funded by anyone but the website also doesn't work, since the site needs to get a certificate from the CA before going live. And unless it's ICANN running the CA, a site might need to get certs from multiple CAs if people in different countries or with different browsers want to talk to them.
Hmm, there's a thought. Self-signed certs, with the root cert fingerprint available as a DNS record, using DNSSEC. Then get the real-world identity info from 'whois'.
Or use something based on "can't fool all
Re: (Score:3, Insightful)
I don't see why a site requesting a CA needs to be live. Consider FooCA, a for-pay CA that users subscribe to, or that ISPs subscribe to on behalf of their users. (There are other models --- this is just an example). If BarInc wants a certificate from FooCA, BarInc just applies to FooCA as soon as BarInc incorporates and obtains BarInc.com. Why would BarInc.com need to be l
Hype (Score:2, Interesting)
Re: (Score:2)
Is this so bad as it sounds?
Technical: Yes.
Real-world-home-server: No.
Talk about choices...
Re:Sounds ugly (Score:5, Insightful)
Parent
Huge pet peeve (Score:5, Insightful)
A site should never lead the user to type sensitive information into a form on an unencrypted page, even if the form's data goes to an encrypted location when submitted. Doing this trains users to be lazy. What's even worse is trying to alleviate users very correct fears by putting a padlock icon next to the form. That's even worse: doing that trains users to believe that a website can signal its own trustworthiness apart from the browser UI, and that could have disastrous consequences.
I have a technical solution, but it won't be popular: browsers should display a warning when submitting a form on an unencrypted page to an encrypted URL. Since web designers are afraid warnings will spook users, they'll switch to making the form-entry pages encrypted as well.
Parent
Re: (Score:2)
IE did that, at least back in the 6 days. I don't know if it still does.
It trained users to click "don't warn me again".
Since there was (and still is) no way to discern what is being sent (important stuff or just a Google search) that box is obnoxious and useless.
Re:Huge pet peeve (Score:5, Insightful)
IE's warning appeared on all form submissions. I agree that warning was worse than useless.
I'm talking about warning only when the following conditions apply:
The user should not be able to disable the warning; its existence will lead webmasters to change condition 1.
Parent
Re: (Score:3)
This would be great, except that most users don't read warnings. They click through them in whatever looks like the most likely path to allow them to finish what they started.
Re: (Score:3, Interesting)
Of course users won't actually read the warning. The point is to annoy users so that webmasters eliminate the behavior causing the annoying warning.
Re: (Score:2)
More people need to use RFC3546 Server Name Indication [hightechsorcery.com] for SSL name-based virtual hosting. All major browsers already support it; the only barrier is Apache and OpenSSL. mod_gnutls for Apache, however, works perfectly.
Even in the absence of RFC3546 [ietf.org] support, there are several workarounds:
Re: (Score:2)
FTPS for example, which is FTP over SSL, is hardly used at all and instead protocols like SCP reign for secure FTP. If people would just stop what they're doing for a moment and realize that the issue is that we're using an inherently unsecure, stateless protocol wrapped inside a security blanket for trans
Re: (Score:2)
Let me guess: you think SMTP is to blame to spam, too.
In both cases, the protocol is not the problem. In fact, both protocols are well-designed and effective. Blaming the protocol is a gross oversimplification of the problem and a cop-out. If you were to do enough work to propose a solution, you'd realize that quickly. Any new protocol that did the same job as HTTP or SMTP would run into the same intrinsic problem
Re:Sounds ugly (Score:5, Informative)
The attack breaks down two ways. Proxying web traffic between a user and a sensitive site like a bank and/or repsenting a URL to a user that looks legitimate but isn't.
The indicators that you are on an SSL site are varied. A lock in the lower right of the window (FF3), to the right of an address bar (IE 6 and below), or a green address bar (IE7 EV cert) or a green indicator to the left of the address bar (FF3). All except the EV SSL certs are pretty subtle. The success relies on the fact that there are so many varied ways that SSL protection is presented to the user, can you keep track of it all. Quick, which sites use EV certs? You don't know so you don't know what to expect.
So, the attack does a couple of things to fool you. First it proxies your web traffic to secure sites re-writing urls that start with HTTPS to HTTP. The only indicator in browsers is no lock. If you are not looking for it, then you probably won't miss it. But wait, since we are rewriting URL's, why not replace the favicon with a lock. Yummy.
The second type of attack is to proxy HTTPS to HTTPS, but this time the SSL session between you and the proxy is enabled with a valid and trusted SSL certificate. No SSL dialog boxes. Here is how it works. IDN is used so that countries can represent URL in their native character sets. Some non-ascii characters look like characters. So use them to fool the user. These are called homographs. Browsers will convert some IDN based on the TLD. But other TLD, like country codes TLD, the browser won't. The assumption being a
Moxies video is pretty clear.
Parent
Re: (Score:2)
Hm, the article and summary both list it as SSLStrip but the only software I can find on the site is SSLSniff [thoughtcrime.org], which appears to be it? Maybe it was renamed because the link as given in the summary redirects to the main page.
SSLStrip redirects to index now (Score:2, Informative)
Re: (Score:2)
There is nothing you, as a web application developer, can do to mitigate this problem other than educating users and busting the IT department's balls to get them to improve real network security.
(Well, you could use clever Javascript to try to heuristically detect funny business in the page location, but if you're important enough, an attacker will just the detection Javascript when proxying your site.)