Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

SSLStrip Now In the Wild

CmdrTaco posted more than 5 years ago | from the not-the-marisa-tomei-kind dept.

Security 208

An anonymous reader writes "Moxie Marlinspike, who last week presented his controversial SSL stripping attacks at Black Hat Federal, appears to have released his much-anticipated demonstration tool for performing MITM attacks against would-be SSL connections. This vulnerability has been met with everything from calls for more widespread EV certificate deployment to an even more fervent push for DNSSEC."

cancel ×

208 comments

Sorry! There are no comments related to the filter you selected.

Alternatives (4, Interesting)

jetsci (1470207) | more than 5 years ago | (#26957343)

I guess the question then is, what do we use as an alternative? What can we even do?

Re:Alternatives (2, Informative)

Anonymous Coward | more than 5 years ago | (#26957375)

dude at informationweek wrote this [informationweek.com] . looks like not much end users can do.

Re:Alternatives (1)

jetsci (1470207) | more than 5 years ago | (#26957411)

First off, SSL isn't broken and Marlinspike doesn't say that, either. What is broken is how users perceive a secure Web session from an insecure one.

Apparently this only affects those who don't pay attention...nothing to see here.

Re:Alternatives (4, Informative)

hal9000(jr) (316943) | more than 5 years ago | (#26957539)

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.

Re:Alternatives (0)

Anonymous Coward | more than 5 years ago | (#26959149)

actually if any of you guys payed ANY attention you'dt notice this lil tibit of info

" Marlinspike's SSLstrip sits on a local network and intercepts traffic. When it detects an encrypted HTTPS (Hypertext Transfer Protocol Secure) site, it automatically substitutes a look-alike of the intended destination as an unencrypted HTTP site. That switching trick strips away the security that prevents a third party from stealing or modifying data, while telling the server that an encrypted page has been sent.

To better impersonate the security measures some users have come to expect, "SSLstrip" even adds a padlock icon that appears beside the URL, offering users a false sense that they can safely input secure information. "People seem to like the padlock," Marlinspike says. "

Re:Alternatives (1)

Onymous Coward (97719) | more than 5 years ago | (#26959287)

Slashdotters from the prior related story suggested the following tweaks to make SSL connections more obvious and identified:

    Site name in "Site ID Button":
        http://news.cnet.com/8301-13554_3-9974672-33.html [cnet.com]
    Yellow background in address bar:
        http://news.cnet.com/8301-13554_3-9974221-33.html [cnet.com]

Re:Alternatives (1)

arndawg (1468629) | more than 5 years ago | (#26957543)

dude at informationweek wrote this [informationweek.com] . looks like not much end users can do.

I see he uses ARP-Spoofing to re-route the traffice via the infected host. A good managed switch comes a long way in defeating arp-juggling I guess.

Re:Alternatives (1)

Creepy Crawler (680178) | more than 5 years ago | (#26958599)

And a lot of managed switches are garbage. Basic attacks of fake arp requests will easily overload these kinds of switches.

And ARP poisoning sill is very effective.

Re:Alternatives (1)

maxume (22995) | more than 5 years ago | (#26959299)

End users can demand and use a https only browser (it could also include domain whitelisting.).

I suppose that isn't a trade off that people will want to make, but it isn't that hard to categorically prevent the attack.

Re:Alternatives (1, Funny)

Anonymous Coward | more than 5 years ago | (#26957397)

I guess the question then is, what do we use as an alternative? What can we even do?

IP over Avian Carriers [faqs.org] ! I'd like to see them do a man in the middle attack on PIGEONS!

Re:Alternatives (5, Funny)

jetsci (1470207) | more than 5 years ago | (#26957421)

It's called a shotgun.

Re:Alternatives (1)

tick-tock-atona (1145909) | more than 5 years ago | (#26957489)

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.

Re:Alternatives (2, Funny)

jetsci (1470207) | more than 5 years ago | (#26957503)

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

Re:Alternatives (1)

spartacus_prime (861925) | more than 5 years ago | (#26959153)

Better call a locksmith.

Re:Alternatives (1)

jiriw (444695) | more than 5 years ago | (#26958823)

So much for RFC 1149 [ietf.org] and 2549 [ietf.org] ... Guess I need to upgrade then. Now where did I leave that 300bd modem. It should somewhere over ...[CARRIER SHOT]

Re:Alternatives (2, Funny)

Lostlander (1219708) | more than 5 years ago | (#26957749)

Watch out for Packet Loss [wikipedia.org] It can be quite high in certain areas especially if you're rural. Also be aware of Hackers [wikipedia.org]

EPA Crackdown: No More IP Over Open Air (1)

WED Fan (911325) | more than 5 years ago | (#26958079)

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 Robinson for 3 nights starting next full moon."

EPA spokesman Harvy Jamal Foshizelmeyer explained the crackdown, "This is hardly a carbon neutral means of communication."...

Re:Alternatives (5, Informative)

SuperNothing307 (1399851) | more than 5 years ago | (#26957553)

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)

Re:Alternatives (2, Insightful)

3p1ph4ny (835701) | more than 5 years ago | (#26958587)

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 secure page.

Re:Alternatives (0)

Anonymous Coward | more than 5 years ago | (#26958843)

that's when you just type in: https://www.usbank.com
I've done this with google (before it was doing SSL)
sometimes I'll put in a gibberish username just to be taken to the https page.

Re:Alternatives (1)

dachshund (300733) | more than 5 years ago | (#26959033)

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.

Try Wachovia's site: http://wachovia.com/ [wachovia.com]

Lock icon: check.
Unsecured HTTP page: check.

I don't have a Wachovia account, so I can only assume that the actual UID/password info goes over SSL, but that's irrelevant to this attack.

Shared private keys. (1)

wiredog (43288) | more than 5 years ago | (#26957567)

Public key crypto-systems.

Not buying anything online via the web-browser.

OK, that last is crazy talk.

VeriSign Warranty Plan (0)

Anonymous Coward | more than 5 years ago | (#26958583)

VeriSign provides Warranty Protection to consumers to reimburse them for exposure to these types of risks. It can be found here http://www.verisign.com/repository/netsure/netsure2.html [verisign.com]

Re:Alternatives (5, Insightful)

Lord Ender (156273) | more than 5 years ago | (#26958625)

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.

Sounds ugly (1)

indi0144 (1264518) | more than 5 years ago | (#26957395)

can anyone care to explain this for the unwashed masses? I was just starting to use SSL for my home server hoping to learn to use it for my clients servers. Is this so bad as it sounds? ty

Re:Sounds ugly (1)

cosmocain (1060326) | more than 5 years ago | (#26957465)

Is this so bad as it sounds?

Technical: Yes.
Real-world-home-server: No.

Talk about choices...

Re:Sounds ugly (5, Insightful)

^BR (37824) | more than 5 years ago | (#26957491)

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

Huge pet peeve (4, Insightful)

QuoteMstr (55051) | more than 5 years ago | (#26957541)

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.

Re:Huge pet peeve (0)

Anonymous Coward | more than 5 years ago | (#26957819)

And what about servers using vhosts on a single IP?

Re:Huge pet peeve (1)

QuoteMstr (55051) | more than 5 years ago | (#26957951)

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.
  • Use a wildcard SSL certificate
  • Purchase additional SSL certificates

Frankly, if you're legitimate enough to be accepting sensitive information over SSL, you have the resources to use employ of these options.

Re:Huge pet peeve (1)

MBCook (132727) | more than 5 years ago | (#26957929)

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 (4, Insightful)

QuoteMstr (55051) | more than 5 years ago | (#26957981)

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:

  1. The form being submitted is on a non-encrypted page
  2. The form's action refers to a page served over HTTPS

The user should not be able to disable the warning; its existence will lead webmasters to change condition 1.

Re:Huge pet peeve (2)

thePowerOfGrayskull (905905) | more than 5 years ago | (#26958585)

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:Huge pet peeve (2, Interesting)

QuoteMstr (55051) | more than 5 years ago | (#26958627)

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:Huge pet peeve (1)

AnyoneEB (574727) | more than 5 years ago | (#26958837)

Hint: Forms with password boxes contain secret information.

Of course, plenty of sites send passwords over HTTP (hopefully no banks...), so a blanket warning on passwords being sent unencrypted would just train users to ignore the warning. Furthermore, the use of passwords sent via HTTPS forms is still training users to type their passwords into phishing sites (if they manage to get to one via a typo or convincing e-mail (my credit card company includes links to their site in their e-mails, faking those e-mails with a slightly different link would be trivial)), but better auth methods are not easy to switch to.

Re:Huge pet peeve (1)

QuoteMstr (55051) | more than 5 years ago | (#26958917)

Furthermore, the use of passwords sent via HTTPS forms is still training users to type their passwords into phishing sites

Hopefully, the anti-phishing features of recent browsers will reduce the danger of this attack vector.

Re:Huge pet peeve (1)

AceJohnny (253840) | more than 5 years ago | (#26958447)

browsers should display a warning when submitting a form on an unencrypted page to an encrypted URL.

They already do. In fact, that's the very first thing I disable on a newly-installed browser. Otherwise I get this annoying and useless dialog everytime I use Google!

Maybe you mean displaying a warning on forms that include an input type="password" field, those where characters appear as stars?

Re:Huge pet peeve (1)

behindthewall (231520) | more than 5 years ago | (#26959139)

Entirely agree. There was a nascent guideline for users: Check the "padlock". Check that the protocol is https.

Designers then started breaking this. To avoid an extra https serve, particularly on a front page or popular page. For the sake of "Design", including putting a sign in form on the front page. Etc.

At least I knew to, if at all possible, force the site to serve up an https version of the sign on page. Most users have no clue about that. And the means for accomplishing this vary. Sometimes, you can do it by replacing "http" with "https" and resubmitting. Sometimes by submitting a blank form. Sometimes you have to populate the form with garbage in order to get by initial checks; the "error" page that comes back when the garbage credentials aren't found is served as https, if you're lucky.

Users were just learning to secure their transactions, when those who presumably had interest in the users' doing so, broke the paradigm, and broke it hard.

I'm at the end of my patience with such fools, who consider themselves professionals.

I'll also mention the idiots who populate their https pages with http references to components. Once you pull in one unencrypted piece, you've opened the door to exploitation. Get a f*cking clue.

Re:Huge pet peeve (0)

Anonymous Coward | more than 5 years ago | (#26959233)

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.

Using Firefox? Tools -> Options -> Security -> Warning messages -> Settings -> "Display a warning message when I submit information that is not encrypted."

If I remember correctly, it's enabled by default.

Of course, every person I know disables that warning the moment they make their first Google search and get a warning they're about to transmit unencrypted information.

Displaying a warning message every time a user performs a search is a great way to train users to click 'OK' on every security dialog as soon as it pops up.

Re:Huge pet peeve (1)

skeeto (1138903) | more than 5 years ago | (#26959275)

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.

I couldn't agree more. I have seen this a number of times and it really bothered me. Every time I came across this, I would check the HTML source to be sure the "action" attribute pointed at https (or could that still bite me somehow?). I haven't seen this bad behavior in awhile, though.

Re:Sounds ugly (1)

Elledan (582730) | more than 5 years ago | (#26957705)

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 transactions and communications vital to world economies. In my opinion it would be unfair to say that end users should 'just pay attention'. I know very well that I don't scrutinize everything whenever I'm buying something online or using my bank's web interface.

The solution to this is really to stop using HTTPS for 'secure' access and use something better, even if it means a lot of 'inconvenience'. Seriously, sometimes we all love to play Russian roulette with our finances and more...

Re:Sounds ugly (1)

QuoteMstr (55051) | more than 5 years ago | (#26957877)

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 problems these protocols face today. You can't pretend these problems will go away if you shuffle some bytes on the wire around and publish a new RFC.

If you want to solve the problem, you need to change the model these protocols embody. What would be your proposed change, exactly?

Re:Sounds ugly (0)

Anonymous Coward | more than 5 years ago | (#26958185)

Let me guess: you think SMTP is to blame to spam, too.

I think laziness is to blame to typos.

Re:Sounds ugly (1)

morgan_greywolf (835522) | more than 5 years ago | (#26957641)



Normal:
You <-----HTTP-----> Bank
You <---HTTP---Bank Redirects to---> Bank SSL
You <--HTTP+SSL--->Bann

pwn3ed:
You <----HTTP---> MITM <----> Bank
You <----HTTP---> MITM <--Redirects to MITM fake SSL---> Bank
You <----HTTP ---> MITM

Re:Sounds ugly (4, Informative)

hal9000(jr) (316943) | more than 5 years ago | (#26957811)

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.

Moxies video is pretty clear.

Not the end of the world (5, Informative)

DigitalSorceress (156609) | more than 5 years ago | (#26957497)

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 (3, Interesting)

IBBoard (1128019) | more than 5 years ago | (#26957591)

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).

Re:Not the end of the world (2, Interesting)

QuoteMstr (55051) | more than 5 years ago | (#26957739)

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 unnecessary.

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.

Re:Not the end of the world (2, Interesting)

hal9000(jr) (316943) | more than 5 years ago | (#26957865)

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?

Re:Not the end of the world (2, Insightful)

QuoteMstr (55051) | more than 5 years ago | (#26958419)

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 name, the user will see both its beginning and end and know something strange is going on.

Re:Not the end of the world (1)

characterZer0 (138196) | more than 5 years ago | (#26958477)

What if the address bar highlighted the portion of the address that is the domain name? It would then be obvious if the domain name was being spoofed.

Re:Not the end of the world (1)

QuoteMstr (55051) | more than 5 years ago | (#26958511)

That's another good idea, but I think users might not be alarmed by seeing the entire address bar highlighted in that way as long as it still reads paypal.com/foo/bar/qux/blah/blah/blah. Again, it's the difference between making a security indicator subtle and making it almost impossible to miss.

Re:Not the end of the world (1)

chihowa (366380) | more than 5 years ago | (#26959027)

I've been playing around with the Windows 7 beta and whatever IE version it uses does that. "domain.tld" is black and the rest of the address is grayed out. I was actually pretty impressed, though I'm not sure how it works with very long addresses.

Re:Not the end of the world (1)

themacks (1197889) | more than 5 years ago | (#26958671)

That would be easy to get around as well. Just append junk to the end of the domain. Such as:

www.paypal.com/foo/bar/...341/do.myevildomain.com/?page=securelogin&more=ramdomcrap&people=fallforanything

Then the domain would not be visible and we are back to square one.

Re:Not the end of the world (1)

QuoteMstr (55051) | more than 5 years ago | (#26958719)

No, I'm talking about truncating the domain name in the middle, not the entire URL. Long URLs will still have their path and query-string portions trail off to the right, but the beginning and end of the domain name will always be visible.

Re:Not the end of the world (1)

Vellmont (569020) | more than 5 years ago | (#26957919)


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 around the corner.

I'm not sure there is a really good solution to this problem. The obvious solution is a more secure browser. That's better, but the downside is of course the continuous update treadmill.

The real problem. (1)

TheLink (130905) | more than 5 years ago | (#26958819)

The real problem is the browser makers do not care about security. They only care about the appearance of security.

For example, browsers don't do the SSH style thing where they warn you if the cert changes for a previously recognized site.

Go look at all the built-in CA certs in your browser sometime. Count them if you can.

How sure are you that none of the CAs there won't be tricked/bribed into signing a cert for *.mybank.com ? Who has audited them?

All it takes is just one CA, and AFAIK, none of the popular browsers will warn you that the cert for mybank.com has changed.

In fact, you might be safer if you removed all the CA certs from your browser, and just got your browser to recognize certs from the few https sites that you actually use, on a per cert basis rather than per CA basis.

Then when someone tries to trick you to going to https://www.mybank.com|.cgi-bin.co/ you will get a prompt for the https cert, and then you might notice something strange going on...

Which do you think is a bigger threat to your security? Your bank server using the same ssl cert for years, or someone pulling a cert swap or MITM or XSS trick on you?

But guess what, your bank probably has to renew their cert every year or so and pay $$$ to do so. Is that really for security reasons? Maybe for the CA's financial security, but I doubt it's for yours or the bank's.

The browser makers fill their browsers with certs from dozens of companies. They don't blacklist companies that have been known to screw up and do dubious stuff (like issuing Microsoft certs to people who aren't microsoft, and do naughty DNS stuff).

It's all just a show to make the sheep feel safe.

Re:The real problem. (1)

QuoteMstr (55051) | more than 5 years ago | (#26958891)

It's all just a show to make the sheep feel safe.

The problems you identify with the CA infrastructure are real, but switching to an SSL-style OH-MY-GOD-THE-CERT-CHANGED system introduced vulnerabilities to several different attacks, desensitizes users to security problems, and cannot provide assurance of identity --- only that the site is the same one that you spoke to last time.

Closing your eyes, plugging your ears, and singing "la la la ssh la la la self-signed la la la" won't solve a single thing when someone uses a MITM attack to intercept the first connection to a site.

We can better address the CA problems by making incentives line up in the correct way. Change the system so that the CAs have a financial incentive to not issue fraudulent certificates --- either regulate them, allow regular users to subscribe to a CA verification service, or require that more than one CA sign a particular certificate.

But half of American banks forced HTTP login (0)

George_Ou (849225) | more than 5 years ago | (#26958629)

But half of American banks forced HTTP login http://blogs.zdnet.com/Ou/?p=201 [zdnet.com] . Then there's the fact that people never manually type in HTTPS and they rely on an auto redirect, but the redirect could be intercepted and changed to HTTP. The solution requires a modification of web browsers and DNS to automatically enforce HTTP policy because people will ignore HTTP 100 out of 100 times and they will ignore fake certificate warnings 199 out of 200 times. EV is not the solution to this problem because it still relies on the human to make the decision on security.

See http://www.circleid.com/posts/20090219_https_web_hijacking/ [circleid.com]

Security is a social issue. Educate! (5, Insightful)

QuoteMstr (55051) | more than 5 years ago | (#26957501)

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:Security is a social issue. Educate! (1)

IBBoard (1128019) | more than 5 years ago | (#26957697)

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.com/ [website.com] ... (also mentioned here [informationweek.com] )

I'd like to see fewer people using self-signed certificates that train users to ignore SSL warnings.

I'd like to see that as well, but for that to happen you need to provide a way for low risk and not for profit sites to get certificates that are accepted by browsers but without the fees. I've set up my email (Webmail, IMAP and SMTP) with SSL certificates, but it took some searching to find someone who would give me a free SSL certificate and even then the issuer isn't in most browser's approved list. I'm protecting a small amount of traffic from lazy eavesdroppers, not protecting a financial institution - I don't need the expense and the insurance.

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.

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?

Re:Security is a social issue. Educate! (1)

QuoteMstr (55051) | more than 5 years ago | (#26957807)

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 status bar section?

You and I know to look for these signals, but most users don't. They'll see the padlock and think they're good to go. We need to train them to look for obvious unspoofable signals that are common across browsers, like the green background under the address bar of an EV site.

If we tell a bunch of high school students, "don't enter your credit card information into any website unless you see a padlock icon on the status bar and a blue background on the icon next to the address bar", what they'll get out of it (if they're listening at all) is "mumble mumble look for the padlock mumble mumble." We need to make security blindingly obvious!

I'd like to see that as well, but for that to happen you need to provide a way for low risk and not for profit sites to get certificates that are accepted by browsers but without the fees.

I think the EV model here is useful. Create a new CA that's specifically marked as being free and make browsers display a different UI for a site encrypted by a certificate originating with this free CA --- say, an orange address bar. Making the free-encrypted UI different will encourage users to not treat self-signed sites as being as secure as CA-verified ones, and won't diminish the value of a CA-verified certificate. It'll also train users to understand different degrees of security.

Re:Security is a social issue. Educate! (1)

Culture20 (968837) | more than 5 years ago | (#26958055)

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

https://login.paypal.com|login.php?oEEnt39ju4wHEhehw&=$*Y$JJSFJIsEE36879899696969696933...200morecharacters.fakedomain.ru

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! (0)

Anonymous Coward | more than 5 years ago | (#26958323)

>I'd like to see fewer people using self-signed certificates that train users to ignore SSL warnings.

Better yet, make the browser handle self-signed certs better than 'oh its not signed by verisign, thus its evil'... On FF3 if I go on a website that's using a self-signed cert, it won't let me use that website until I click through three to five different security warnings all of which begging and pleading for me to not accept the cert. In reality, of course, not everything is sensitive enough that it needs a verisign EV cert; If I'm logging into a message board I don't require the same security than if I'm logging into a bank or PayPal account. It should just let me through, say it's using a self-signed cert, and warn me again if the cert changes. On the flipside, it should be throwing up the big warnings for completely unencrypted connections, ESPECIALLY if it's from a site that uses verisign EV certs.

Re:Security is a social issue. Educate! (1)

QuoteMstr (55051) | more than 5 years ago | (#26958463)

It should just let me through, say it's using a self-signed cert, and warn me again if the cert changes

One problem with this approach is that it's impossible to revoke a self-signed certificate if it's compromised. Another is that users will always see the OH-MY-GOD-THE-CERT-CHANGED warning every time the certificate expires, or when the site moves to a conventional CA-signed certificate.

A better option that still gives you want you want is a special free CA that the browser recognizes and that will give the user a different, low-security-indicated UI indicator. This solution still gives you most of what you want and is much more secure for everyone involved.

Re:Security is a social issue. Educate! (0)

Anonymous Coward | more than 5 years ago | (#26958649)

No, the solution to to encrypt everything on the Internet. Everything should be SSL across the board.

There could also be a central authority of some sort that can issue low-cost or free trusted and untrusted certs. Although that does get kind of complicated.

Re:Security is a social issue. Educate! (1)

QuoteMstr (55051) | more than 5 years ago | (#26958691)

No, the solution to to encrypt everything on the Internet. Everything should be SSL across the board.

That'd be nice, but it's not going to happen soon, and for plenty of different reasons. We need to focus on solutions that are feasible now, not pie-in-the-sky ideas that will only be implemented after even more massive damage is done.

Re:Security is a social issue. Educate! (-1)

Anonymous Coward | more than 5 years ago | (#26958749)

seriously, who are you guys and what did you do to the real slashdot crowd? They handing out mod point to everyone these days or what?

Ok here we go, 1 bank , 1 client and 1 mitm.

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?

educating users about useless security measures is the real problem here.

Re:Security is a social issue. Educate! (5, Informative)

QuoteMstr (55051) | more than 5 years ago | (#26958799)

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.

Re:Security is a social issue. Educate! (1)

thePowerOfGrayskull (905905) | more than 5 years ago | (#26959163)

Education won't actually help. Most users do not know what a certificate is for. They have been trained to know that if a secure icon is present it's good. Many will have a basic knowledge that a secure connection is a sign that the info they send can't be eavesdropped; and maybe that it has something to do with being stored safely on the bank's (or whatever) web site.

When web browsers or people start talking about certificates, eyes glaze over. Most people don't know what a certificate is. If they get an expired warning, or get denied due to a cert being self-signed, they have no idea what that means - beyond the fact that something is preventing them from completing their transaction. At this point they get frustrated, not educated.

Now: all of this /can/ theoretically be fixed with education. But most computer users don't want to be educated. They want to go make their purchase, and be reasonably comfortable in the fact that a) their information is only seen by the people they want, and b) that nobody is going to steal it.

BUsiness and people have gone a long way to making the web accessible and friendly to non-technical people. e-commerce and banking web sites are built around analogies designed to make people think of a storefront transaction - and when you're making a transaction with a store or a bank, you know who you're working with because you went there yourself. Trying to educate people that the storefront transaction that they've long since trained to accept as the real thing, might not actually be the real thing, is a losing battle.

Phrased differently: try explaining the concept that even though someone drove to the bank, they might not be at the bank unless the teller shows them official identification. And then try explaining that even when the teller shows identification, they STILL might not be who they say, you should also call the official bank phone number and see if the teller's phone rings. But wait, even THAT isn't enough, you should contact the state licensing board to ensure that yes, they licensed THIS TELLER to handle your money.

Re:Security is a social issue. Educate! (1)

QuoteMstr (55051) | more than 5 years ago | (#26959261)

Most users do not know what a certificate is for....They have been trained to know that if a secure icon is present it's good.

You're right. We can't count on users being any more than idiots. They'll just look for a secure icon. The trick is convincing them to look for the correct security icon, and to check that the address in the browser matches the site in the window.

These techniques are very simple, on par with looking both ways before crossing the street. I think almost everyone can be taught basic due diligence when it comes to security.

Re:Security is a social issue. Educate! (0)

Anonymous Coward | more than 5 years ago | (#26959279)

> The solution is user education.

The idea of user education fails miserably with the all too common problem of the Dancing Bunnies [msdn.com] :
at the end of the day, the user still wants to see the dancing bunny, and they'll do whatever's necessary to bypass your carefully constructed barriers in order to see the bunny

Re:Security is a social issue. Educate! (1)

QuoteMstr (55051) | more than 5 years ago | (#26959369)

I don't think the dancing bunny problem is quite so severe when users have to enter their credit card numbers or bank account information. The media has done a good job of whipping up a frenzy about identity theft.

Re:Security is a social issue. Educate! (1)

Jay L (74152) | more than 5 years ago | (#26959337)

We need to train users to be vigilant, because nasty people are trying to steal their information.

Why is that any more likely to work than training people not to be nasty?

Re:Security is a social issue. Educate! (1)

jddj (1085169) | more than 5 years ago | (#26959343)

The solution is user education.

fail.

You're dealing with average people, not bright geeks. People won't read. They don't learn, and arguably they shouldn't need to do so to use someone's web site.

People - even some knowledgeable IT folks I know - think that the "lock" icon means an entire transaction, from client to server, is secure - not just that a transaction is conducted through an encrypted pipe.

They think the lock means:

  • "you have to have a password to use this site"
  • "the web site is specially protected from attack"
  • "nothing can see or affect what's happening on my web browser"

None of that is true about working SSL.

Just what are your plans for educating 3-400 million people out of this fog?

The "lock" icon and the marketing text about security has fostered a consistent misconception in their minds. Good luck changing it.

EV certificates (2, Interesting)

Lieutenant_Dan (583843) | more than 5 years ago | (#26957601)

"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:EV certificates (1)

QuoteMstr (55051) | more than 5 years ago | (#26957649)

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.

Re:EV certificates (1)

Lieutenant_Dan (583843) | more than 5 years ago | (#26957891)

Thanks for info; that's probably exactly how it happens. In an environment with a captive audience, you issue your own cert and 99.9% of the corporate users won't even notice.

Re:EV certificates (1)

blueg3 (192743) | more than 5 years ago | (#26957889)

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:EV certificates (1)

The Moof (859402) | more than 5 years ago | (#26958083)

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:EV certificates (2, Insightful)

QuoteMstr (55051) | more than 5 years ago | (#26958219)

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 are almost no repercussions for issuing a fraudulent CA. In theory, browsers are supposed to remove rogue CAs from their CA lists, but in practice that doesn't happen: they're too afraid of "breaking the web" and being sued to actually punish CAs for having lax security.

Comodo, for example, delegates its CA business to fly-by-night subsidiaries who issue certificates with no verification whatsoever. This is the worst situation imaginable from a security perspective, but even after this contemptible practice was exposed, neither Microsoft nor Mozilla Corp. removed the Comodo root certificate. I've personally removed it in all the browsers I use, but most users won't do that.

Comodo's behavior is no surprise, however. For them, it makes sense from an economic point of view. Yelling and screaming will change nothing. The EV program is slightly better in that it's an industry agreement to perform better validation, but it'll inevitably succumb to the same market forces. As EV certificates become more entrenched, it'll become too difficult to punish rogue EV vendors, and we'll be in exactly the same situation we are today with standard SSL certificates.

CAs validating websites and taking payment from them creates the same perverse incentives that led credit rating agencies to contribute to the current economic crisis. You can't count on people's goodwill to make them do the right thing: if you want the right thing to happen, you need to make the right thing the easy or profitable thing.

There are a couple solutions to the incentive problem:

  1. 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.
  2. 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.

Re:EV certificates (2, Insightful)

Timothy Brownawell (627747) | more than 5 years ago | (#26959141)

There are a couple solutions to the incentive problem:

  1. 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.
  2. 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'.

Or use something based on "can't fool all of the people all of the time" like Perspectives (see sig), where instead of having a CA that gives the site owner a certificate, there are a bunch of public servers that you ask whether they see the same key you see for whatever site you're going to.

Re:EV certificates (2, Insightful)

QuoteMstr (55051) | more than 5 years ago | (#26959207)

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 live at this point?

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'.

That's a thought. But first we need DNSSEC, which would make me a happy man in any case. :-)

Or use something based on "can't fool all of the people all of the time" like Perspectives

That solves some problems, but I'd rather have a robust CA system so that nobody has to be in that group of fooled people. Perspectives also adds significant latency to the connection and has other technical problems, but combined with other security measures, I don't see it as being all bad.

Re:EV certificates (1)

Lord Ender (156273) | more than 5 years ago | (#26958915)

You are wrong. It is impossible to MITM properly-implemented SSL without having access to a trusted CA.

Re:EV certificates (1)

LanMan04 (790429) | more than 5 years ago | (#26959349)

That's probably being sold by Thawte. And considering that a lot of browsers out there still don't support EV.

IE7 does
Firefox 3 does
Safari does

So what browsers don't that people actually use? No, Opera doesn't count. :)

Hype (2, Interesting)

TheRealJobe (1125771) | more than 5 years ago | (#26957631)

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.

SSL Strip = Porn? (0)

drewzhrodague (606182) | more than 5 years ago | (#26957647)

Is this porn for the security researcher? I guess I should RTFA.

Re:SSL Strip = Porn? (1)

Zwicky (702757) | more than 5 years ago | (#26957971)

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.

Re:SSL Strip = Porn? (0)

Anonymous Coward | more than 5 years ago | (#26958139)

No, look at the source code of the page. He commented it out, probably due to bandwidth issues.

Posting anon to not screw up moderation.

SSLStrip redirects to index now (2, Informative)

exloterum (1478921) | more than 5 years ago | (#26958153)

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?

Re:SSLStrip redirects to index now (1)

Zwicky (702757) | more than 5 years ago | (#26958371)

OK good answer.

Thanks; my mistake. :)

Re:SSLStrip redirects to index now (0)

Anonymous Coward | more than 5 years ago | (#26959255)

He says that he hadn't published the link yet, someone just figured out what it was going to be and slashdotted it. =(

So is redirecting to https (1)

xaositects (786749) | more than 5 years ago | (#26957999)

prior to them inserting login information safe? For instance, for the business application I develop, I check to see if the user accessed the login page via ssl, and if not, I user header('Location https://blah/ [blah] to get them to the ssl login page. To me that should be good, but the site above seems to indicate even that is not safe since a person could spoof the cert as soon as the site is accessed. Or perhaps I'm not quite understanding it clearly.

Re:So is redirecting to https (1)

QuoteMstr (55051) | more than 5 years ago | (#26958053)

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.)

An anarchist resource since 2004? (2, Interesting)

edgewedge (1481513) | more than 5 years ago | (#26958363)

Holy crap, looking at the source to sslstrip, this was written in 2004! I wonder if the anarchist underground hacking scene has had access to this for all that time? Why release it now I wonder?

Bank of America is partway there (1)

uberhobo_one (1034544) | more than 5 years ago | (#26958579)

For a time, Bank of America's main page was http://, even though you entered your account information into a secure form. Some people raised a stink and they changed it. Before that occurred, I decided to use one of NoScript's features to force the entire domain bankofamerica.com to use https://.

For a while it worked great until a few months later when I signed up for another service on their website that monitored your credit report activity. For about a week, every time I clicked on the link to take me to the login page for that service, I would get a page that told me the link was broken. After calling customer support a few times to see if the site was functional, I realized that the redirect script/server didn't support https, and that I was getting a dead redirect as a result.

I think forcing https on domains is a good idea, but it can be easily undermined by one link in the chain not playing nice.

Has SSL ever actually worked properly ? (1)

billcopc (196330) | more than 5 years ago | (#26958943)

I'm going to stick my neck out and say that SSL is a false security. Any twit with $29.95 can buy an SSL cert. The mere fact that a page is encrypted via SSL seems to convince people that they are dealing with a reputable site.

I'm much less worried about packet sniffing, and more about fake sites like I see every day in the steady flow of spam. There are many ways to steal someone's private data, all much easier than being on the right network, at the right time, sifting through gbits/sec of garbage for a vulnerable SSL connection.

Say you have an account at the First Bank of Fnarg, and the real web site is "www.firstbankoffnarg.com", what's to prevent an amateur from setting up "www.firstbankofnarg.com", copying the templates, and buying an SSL cert from any registrar ? Send out a legit-looking email with the link, a this will fool a staggering number of people.

It doesn't matter how often you tell them "Don't click on email links", people will do it anyway. They do it because they are lazy, inattentive and hurried. There is no technological cure against human nature.

Re:Has SSL ever actually worked properly ? (1)

QuoteMstr (55051) | more than 5 years ago | (#26959017)

I'm going to stick my neck out and say that SSL is a false security....I'm much less worried about packet sniffing, and more about fake sites

SSL works very well for the kind of attacks it was designed to counter. We need other mechanisms to protect against others. Why would you expect one technique to cover all vulnerabilities?

Major browsers already include anti-phishing features that check blacklists. These blacklists will reduce, but not completely eliminate, the fraud caused by phishing schemes. A few people will always fall prey to them, but through education and centrally-managed blacklists, we can hopefully reduce the number far enough that phishing becomes more trouble than it's worth.

Moxie Marlinspike (0)

Anonymous Coward | more than 5 years ago | (#26959093)

Funny, I went to high school with this guy, and he made a small cameo appearance in a dream I had last night, for no apparent reason. I remember visiting http://room101.thoughtcrime.org/ [thoughtcrime.org] back in the early days -- '95 or so.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?