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!

Black Hat Presentation Highlights SSL Encryption Flaws

timothy posted more than 5 years ago | from the well-hey-nothin's-perfect dept.

The Internet 152

nk497 writes "Hackers at the Black Hat conference have shown that SSL encryption isn't as secure as online businesses would like us to think. Independent hacker Moxie Marlinspike showed off several techniques to fool the tech behind the little padlock on your screen. He claimed that by using a real world attack on several secure websites such as PayPal, Gmail, Ticketmaster and Facebook, he garnered 117 email accounts, 16 credit card numbers, seven PayPal logins and 300 other miscellaneous secure logins."

cancel ×

152 comments

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

Oh god (3, Funny)

LordKaT (619540) | more than 5 years ago | (#26917389)

Someone fix the summary before my brain melts.

Re:Oh god (1, Offtopic)

mapsjanhere (1130359) | more than 5 years ago | (#26917471)

Well, if the hacker types like the submitter, I'm not too worried about my login credentials.

God forbid... (2, Insightful)

ThrowAwaySociety (1351793) | more than 5 years ago | (#26917649)

...hackers and phishers ever take a third-grade English class.

Typos, grammar errors, and awkward Google transalations probably do more to alert average users to scams than SSL certificate warnings.

Re:God forbid... (4, Insightful)

Anonymous Monkey (795756) | more than 5 years ago | (#26917961)

Reminds me of the first lesson in hacking: Social Engineering is More Powerful than Passwords. Only the other way around. If you learn what hackers do, you can avoid them (most of the time). And if their is a Master Hacker who can dupe me, I doubt their is much I can do to stop him. Thankfully I'm not important enough to be a target.

Re:God forbid... (0)

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

their => there

Re:God forbid... (2, Funny)

Joebert (946227) | more than 5 years ago | (#26918289)

The only question is, are you attempting to look unimportant so you will be looked over, or because you know someone will look at that as a dead give away that you're trying to "look" unimportant because you actually have a lot to hide and want to draw attention to yourself because you actually are, unimportant ?

Re:God forbid... (1)

osu-neko (2604) | more than 5 years ago | (#26919869)

If looking ordinary is suspicious, sure, I'm making myself a target. However, if the person who suspects looking ordinary is a cover for being important is using that strategy to find important people, I can rest easy knowing that, with that strategy, they'll have to work through about three billion false positives on average before they get to looking at me.

Re:God forbid... (4, Insightful)

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


Thankfully I'm not important enough to be a target.

A common myth, based on a belief that "hacking" is done by some smart guy sitting around thinking about which "important person" to go after next.

The answer (if you're smart enough and slightly lazy) is "why not everyone?" or at least "anyone that falls into the trap". An automated program doesn't really care who you are, if you're "important" or not. Only that it can trick you into losing some money. Personally I think that's why a lot of people fall for 419 scams.

Re:God forbid... (2, Interesting)

KillerBob (217953) | more than 5 years ago | (#26919679)

I think he was talking about people specifically trying to break into his box, presumably a server. Like him, I don't really think my server is that juicy a target. A determined hacker *can* break into it, no argument. But it's got enough of a deterrent in place, in the form of frequent updates by a sysadmin who subscribes to the mailing lists for all the software she's running, requiring SSH to log in, the non-existence of any remote administration tools except for SSH, only allowing one user shell access (unfortunately, I'm on a dynamic IP, else I'd be restricting it to IP as well), and said user having a password that expires every 30 days, to make it an unattractive target for that kind of attack.

When it comes to viruses, trojans, and other forms of malware, you're absolutely right. The human will always be the weak factor, and the software doesn't give a damn what human it's targetting. A little bit of common sense and a little bit of knowledge about how these kinds of things work will do wonders to protect you from harmful attack. But when it comes to securing a server against intrusion, it's not about preventing attack: there's nothing you can do short of taking the server offline to 100% guarantee that it won't be attacked. It's about making it enough of an annoyance to break into your computer that anybody who doesn't have a personal vendetta will go after an easier target.

Re:God forbid... (1)

msimm (580077) | more than 5 years ago | (#26920311)

I think he's saying he's probably smarter then the average program. A targeted attack, unlike a lazier automated attack still has a better chance of success. What you present is a low-hanging fruit argument.

Re:God forbid... (0, Offtopic)

Ginger Unicorn (952287) | more than 5 years ago | (#26918135)

Transalations? How well did your third grade go? :p

Re:Oh god (4, Funny)

gnick (1211984) | more than 5 years ago | (#26917623)

You simply misunderstood the summary - It's fine the way it is.

Independent hacker Moxie Marlinspike showed off several techniques to get fool the tech behind the little padlock on your screen.

"fool the tech" is a little bot that hides behind the padlock on your browser, watches what you're typing, and reports it back to Moxie. Moxie has several techniques for getting Fool behind the padlock. Why Moxie named the little tech Fool, I have no idea.

Re:Oh god (0)

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

SSlStrip is old news. Seen similar attacks to this performed many times. See also: surfjacking, sidejacking and SSL MiMT attacks.

Weak sauce.

Re:Oh god (3, Informative)

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

OK: "Some implementations of SSL encryption are flawed. These can be fixed. SSL encryption itself is not flawed."

Re:Oh god (0)

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

Cool. Can you enumerate which implementations are flawed for me? I need to know so 1) I can avoid them and 2) put whatever insignificant amount of pressure I can on developers to get the bugs fixed.

Anyone know of a test suite for SSL? If a site is using a SSL implementation which is flawed, can I test for it or is that something that only hackers can do?

If a page has a badge from VeriSign on it does that mean that it passed some battery of tests (at least at one point) to get it or is it merely a proof of purchase mark for certificates?

Re:Oh god (1)

IamTheRealMike (537420) | more than 5 years ago | (#26919785)

SSL is flawed, at least for the web. Usability studies have shown time and time again that the vast majority of people do not understand and will ignore the bad cert error dialogs. That's a pretty fundamental problem, and why Firefox now makes it really hard to bypass them, but all it's doing is putting a sticking plaster on a bullet wound.

Re:Oh god (3, Insightful)

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

You are absolutely wrong. SSL is not flawed. The UI browsers have implemented regarding SSL is flawed. The UI should make it clear to the users exactly where they are sending their information. It should also make it clear when they are submitting a password over plain text.

Mind hacked! (1)

BadAnalogyGuy (945258) | more than 5 years ago | (#26917395)

Independent hacker Moxie Marlinspike showed off several techniques to get fool the tech behind the little padlock on your screen.

What do you command, master...

Re:Mind hacked! (1)

PrescriptionWarning (932687) | more than 5 years ago | (#26917875)

Sounds more like an article by Mr. T.... fool!

Re:Mind hacked! (1)

Joebert (946227) | more than 5 years ago | (#26918349)

How do you know Mr. T isn't pretty handy with computers ?
How do you know Mr. T didn't hack in and create a Knight F Mowawk class ?

Black hat, (-1, Troll)

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

BLACK DICK.
Nigger man, nigger man.
Hee haw, jackin' his jaw,
Grabbin white wimminz' with greasy paws!

Hacking (3, Insightful)

eclectro (227083) | more than 5 years ago | (#26917433)

It's always about getting the fool.

Hacking isn't attacking the encryption. (1)

FooAtWFU (699187) | more than 5 years ago | (#26918281)

You don't attack the encryption. You attack how it's used.

(Well, okay, sometimes they're using WEP or ROT13 or memfrob, but in general...)

Sounds like OSI level 8 error (5, Insightful)

Seth Kriticos (1227934) | more than 5 years ago | (#26917499)

Come on, this does not highlight vulnerabilities of SSL, but errors in implementing it for specific platforms. This was always a weak point.

Disgusting grammar. (-1, Offtopic)

XcepticZP (1331217) | more than 5 years ago | (#26917545)

What a disgusting display of English grammar. Come on, Slashdot! I thought you editor's had better standards.

Re:Disgusting grammar. (5, Funny)

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

If you are going to criticize someone's grammar. Your post should be grammatically flawless. And your post isn't. That's laughable.

"I thought you editor's had better standards."

Re:Disgusting grammar. (5, Funny)

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

If you are going to criticize someone's grammar. Your post should be grammatically flawless.

If YOU are going to. criticize someone else's. Grammar. Don't use sentence fragments to do. It.

Re:Disgusting grammar. (5, Funny)

hairykrishna (740240) | more than 5 years ago | (#26918911)

Shatner, is that you?

Re:Disgusting grammar. (1)

palegray.net (1195047) | more than 5 years ago | (#26920893)

He's speaking the language of the deal.

Re:Disgusting grammar. (1)

msimm (580077) | more than 5 years ago | (#26920349)

Maybe he's writing in character? *queue fat man leaning at the top of a long staircase*

Re:Disgusting grammar. (1)

EvolutionsPeak (913411) | more than 5 years ago | (#26921113)

I think he just invoked Muphry's Law [wikipedia.org]

Re:Disgusting grammar. (0)

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

Woooooooosssssssshhhhhh!

Re:Disgusting grammar. (1, Funny)

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

Yeah, it should be, "I thought you're editor's had better standard's."

Re:Disgusting grammar. (1)

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

If you are going to criticize someone's grammar. Your post should be grammatically flawless.

Because the commenter is a professional writer? Do you expect the same level of grammatic correctness from a journalist and a janitor?

Re:Disgusting grammar. (0)

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

Yet another fine example of irony, present on 90% of the ./ posts that complain about spelling, grammar, or both.

Re:Disgusting grammar. (1)

mcgrew (92797) | more than 5 years ago | (#26919383)

What a disgusting display of English grammar. Come on, Slashdot! I thought you editor's [angryflower.com] had better standards

Oh look, the iron "E" is back.

Get fool the tech (-1, Offtopic)

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

Somebody set him up the bomb!

No problem at all (1)

Tei (520358) | more than 5 years ago | (#26917555)

Maybe the bad guys are busy elsewhere... wait...

It's not a problem with SSL /per se/ (5, Interesting)

MadMidnightBomber (894759) | more than 5 years ago | (#26917559)

It's a problem with sites that start out with http://example.com/ [example.com] and then transition to https://secure.example.com/ [example.com] .

If I read it right, encrypt it all, turn off http except as a 301 redirect to https and you should be fine. Anyone confirm this?

Course, you still should check the certificate is the one you're expecting.

Re:It's not a problem with SSL /per se/ (2, Interesting)

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

They did say in the video they rewrite the http->https redirects so I don't think that's the way. The only solution is to turn of HTTP completely, but that'd mean your users would have to type https:/// [https] to use port 443 and https all the time.

Re:It's not a problem with SSL /per se/ (4, Insightful)

zappepcs (820751) | more than 5 years ago | (#26917947)

What exactly is wrong with that? I'm sure that someone can write a script for FF that will detect the error and automatically add the 's' and resend. People had to get used to typing http://www/ [www] in the first place. It's not such a huge jump to add the 's'.

This is the same argument that I see with switching to Linux: oh, users will have to relearn things, it's different than Windows. Yet those same users have to relearn when they get a new cable box and remote. They have to relearn when they get a new microwave. They have to relearn when they get a new television. They have to relearn when they change banks, and on and on and on. It's a lame argument.

In the end, users in general are uninformed, lazy, and lack the drive to become well versed in computer security. SSL encryption issues are hardly the biggest security flaw in computing today. The biggest security flaw is between the ears of the end user. SSL issues hardly register on the list of problems behind the spread of the most devastating malware we know about today.

meh

Re:It's not a problem with SSL /per se/ (0)

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

Why don't we use httpss:// (super-secure) on port 806 then?

Re:It's not a problem with SSL /per se/ (1)

prefect42 (141309) | more than 5 years ago | (#26918591)

If I turn http off for my domain, but users type in http, then your malicious hacker can intercept the http request (even though it would never succeed), and respond with a redirect to https.

So turning off http does not solve this problem. It's still not a bug with SSL though.

Re:It's not a problem with SSL /per se/ (5, Insightful)

Qzukk (229616) | more than 5 years ago | (#26917833)

It looks like there are a couple of things, but their main one is a man-in-the-middle attack based on the user not paying attention to the browser's SSL flags. See the difference between page 61 and 62 of their presentation: https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf [blackhat.com]

They show on page 69 how it looks once they substitute a lock image for the favicon (if they had wanted to be Extra Evil, they'd have given their fake favicon a blue background, which would have made firefox 3 look exactly like it was SSL protected, except for the S missing in the URL)

They then proceed to show how allowing unicode in the hostname continues to confuse and confound people. Register a cert for *.foo.com, then set up a hostname of www.google.com[unicodeslashlike]login[unicodeslashlike]blah[unicodeslashlike]blah[unicodeslashlike]blah.foo.com and presto, you have a valid certificate for a site that looks more or less like https://www.google.com/login/blah/blah/blah.foo.com [google.com] , except that it's not hosted by google.

Basically all of these are attacks on the end user, what you do or don't do on the server won't change a thing.

Re:It's not a problem with SSL /per se/ (1)

sakdoctor (1087155) | more than 5 years ago | (#26918141)

They show on page 69 how it looks once they substitute a lock image for the favicon (if they had wanted to be Extra Evil, they'd have given their fake favicon a blue background, which would have made firefox 3 look exactly like it was SSL protected, except for the S missing in the URL)

WTF? No. The box where that icon is shown in FF3 isn't 16x16 pixels. Having a blue background would look weird and out of place.

Re:It's not a problem with SSL /per se/ (2, Insightful)

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

You are almost right. It is a combined flaw of both browsers and web site implementations. If just one of the two were flawed, it wouldn't be a major issue. But since both are, even security-conscious users are likely to get duped by this.

So many engineering disasters rely on multiple little things going wrong simultaneously...

Re:It's not a problem with SSL /per se/ (2)

mcgrew (92797) | more than 5 years ago | (#26919309)

"Disaster" is a pretty strong word. The Titanic was an engineering disaster, the Challenger and Columbia accidents were engineering disasters, that bridge that collapsed a few years ago was an engineering disaster, there was a type of cancer radiation machine a while back that was killing people because of a software bug that was an engineering disaster, the Ford/Firestone automobile rollovers were engineering disasters. To call getting hacked a disaster is a bit out of proportion.

Re:It's not a problem with SSL /per se/ (1)

osu-neko (2604) | more than 5 years ago | (#26920015)

A lot of people use disastrously bad comparisons. People who use hyperbole usually take it to astronomical levels.

Re:It's not a problem with SSL /per se/ (1)

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

If you read more carefully, you would notice that I did not specifically refer to this issue as a "disaster." My point was about small problems leading, unpredictably, to a much larger problem.

However, since this could be used to empty the life savings of thousands of people, it has the potential to lead to disaster.

Re:It's not a problem with SSL /per se/ (2, Interesting)

Deanalator (806515) | more than 5 years ago | (#26917925)

No, that will not fix this attack. I have not been able to find a copy of his tool online yet, but I am going to assume that he did it right.

This tool should still be able to pull down the html from the https the website, and present it to the user as an http site. No amount of javascript, HTTP redirects, or a href="https:// ... is going to save you in this case. The MITM proxy is always going to be able to strip any of that out, and replace it with something that keeps the clear session alive.

The way to fix this is to change the way firefox implements SSL. Once firefox has visited a website using SSL, firefox needs to automatically connect to SSL, and never trust unencrypted data from that site again. Even that won't help for websites on the first visit. I think firefox should also give big fat warnings if you attempt to POST a password field over an unencrypted channel (that means you slashdot). Furthermore, I am of the opinion that the SSL fingerprint should be cached at that moment as well, so the user can be warned if the cert ever magically changes. This would protect against the possibility of malicious people getting their hands on a root CA.

Re:It's not a problem with SSL /per se/ (1)

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


Once firefox has visited a website using SSL, firefox needs to automatically connect to SSL, and never trust unencrypted data from that site again.

There's at least one problem with that approach. The one I can think off the top of me head is the initial landing site might be http only, and the login site is https. So your browser goes to http://www.nameofmybank.com/ [nameofmybank.com] you click on a link to https://login.nameofmybank.com/ [nameofmybank.com] If the browser only cares about the whole site name, it'll only go to the http site when you start at the landing page. If that's the case, you're sunk and the attack works.

Such a fix would need to be domain wide (which may or may not work for some domains). So I'm not sure if there's any EASY, generalized way to fix this problem.

Re:It's not a problem with SSL /per se/ (1)

salimma (115327) | more than 5 years ago | (#26918883)

Makes me wonder: perhaps the OpenBSD team should design a secure browser next. OpenSSH does a lot of the things you mention -- loud warning if the server key changes under you, etc.

Re:It's not a problem with SSL /per se/ (1)

hardburn (141468) | more than 5 years ago | (#26919157)

SSL keys have to change regularly with expiration. This isn't just for repeat business for the CAs (although that is part of it); there are good cryptographic reasons why you want to be changing your keys every 2-5 years, depending on how paranoid you are. Technically, you should be doing the same with SSH keys, too.

Also, OpenBSD might have a good security track record, but OpenSSH does not.

Re:It's not a problem with SSL /per se/ (1)

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

Better disable javascript so that a web page doesn't simulate a password field and post that.

I think having a "banking mode" that enforced https and limited the domains that could be accessed at the same time would provide a better end user experience for secure browsing and for normal browsing.

Making it a separate app would trick people into thinking it was easy to switch in and out of banking mode.

Re:It's not a problem with SSL /per se/ (2, Interesting)

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


If I read it right, encrypt it all, turn off http except as a 301 redirect to https and you should be fine. Anyone confirm this?

Not really. You've only shifted the problem into one of intercepting and modifying the 301 redirect, from intercepting the individual links.

You could turn off http entirely, but then you'll get people complaining that your website doesn't work from the vast majority of people (hell, including me really).

This is really a browser problem, and a user problem. One way to fix this would be for the browser to recognize sites (domains really) that should be HTTPS ONLY, and refuses to use HTTP when going to them. I.e. the user types, clicks, or uses a bookmark to go to www.mybank.com, and instead of the default http, it goes to https. If it encounters a non-http link for that domain, it simply disobeys (or puts up a huge warning flag).

DNS? (1)

XanC (644172) | more than 5 years ago | (#26921057)

That sounds like a good idea. There could be a DNS option on the domain for secure-only. Of course DNS has had its own issues, but every bit helps.

Re:It's not a problem with SSL /per se/ (2, Informative)

AusIV (950840) | more than 5 years ago | (#26918269)

The problem is that a MITM can modify that 301 redirect from https://secure.example.com/ [example.com] to http://secure.example.com/ [example.com] Since they're in the middle of the transaction, they capture your packets and encrypt them before forwarding them on to https://secure.example.com./ [secure.example.com] The only indicator that something is amiss is the lack of an 's' in the protocol, which lots of people won't notice.

Alternatively, he might redirect from https://secure.example.com/ [example.com] to https://secure.example.com/.ijj.cn [example.com] , except that the slashes and dots in the last example are unicode characters that look like slashes and dots, so they don't register with the browser in the same way. He gets a legit cert to *.ijj.cn, then logs everything and forwards your responses to the address before .ijj.cn. For long URLS (which many secure logins have), the trailing .ijj.cn ends up past the end of your URL bar, and you don't notice.

After seeing Moxie's presentation, I'll be double checking every URL that needs to be secure to verify the 'https' protocol, and doesn't have any unusual endings. For things like the bank, I'll probably just bookmark the https version and never request the http version.

Re:It's not a problem with SSL /per se/ (1)

hardburn (141468) | more than 5 years ago | (#26919409)

As others have mentioned, sslstrip already handles any redirects you do. The user would have to explicitly type 'https://' every time. Further, there are certain things that are just no good over SSL. For instance, caching proxies aren't supposed to cache SSL connections. Doing everything over SSL sounds nice, but doesn't really work in practice.

The first use of of sslstrip was against implementations that didn't do enough checking on a chain of certificates. Some implementations still don't do it right, and I question the usefulness of the feature in the SSL standard.

The current version handles existing session cookies held by the client by sending a 302 request back with a Set-Cookies header that blanks them out, forcing the client to reload them. The MITM can then get the new session cookie.

In this case, the server will notice a client it's seen before getting new cookies. The client notices the server setting a new session cookie when it had already sent good ones. This could be used to build a signature of the attack, but on its own, there are too many ligitamate reasons on both sides for it to be a reliable attack signature.

There's a more general problem here, which is that we've taught people that the little padlock means the site is secure. This isn't necessarily the case, of course, but how do we teach people otherwise? It's unfair to say they need to be more careful when people have a larger life to live. How can we get users to verify the security of a site in a way that's almost as easy as looking for the padlock?

All your base are belong to us (-1, Offtopic)

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

All your base are belong to us.

OK, so don't implement the security. (5, Insightful)

russotto (537200) | more than 5 years ago | (#26917709)

If you don't implement the security, you're not secure. The author claims that some browsers don't check to see that an intermediate certificate is actually authorized to sign other certificates. So naturally there's a simple attack based on that, but it doesn't really show a flaw in SSL.

The author also complains about companies which post secure forms on non-secure pages, which is a valid complaint but is also a case of "You're using it wrong" rather than a problem with the protocols. Most users are never going to check for the lock (or whatever), so the basic problem will be with us forever, but banks don't have to screw it up by putting login forms on non-secure pages normally. Yes, it's convenient to have a login on a home page, and yes it would consume too many resources to make every home page hit into an https hit, but security ought to count for something, particularly with a bank.

Re:OK, so don't implement the security. (1)

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

No, the problem does NOT have to be with us forever. If browser makers simply gave pop-ups whenever a form with a password control were submitted: "Do you really want to send your password to asdfasdf.cn?" for ssl or "You are sending a password unencrypted! It could be intercepted by hackers. Are you sure you want to do this?" for http, then the problem would go away.

Re:OK, so don't implement the security. (1)

MobyDisk (75490) | more than 5 years ago | (#26918357)

But with his trick of using SSL + unicode characters, it would say:
"Do you really want to send your password to https://www.google.com/SecureLogin.asp?ijkll [google.com] "
Which looks perfectly valid.

Re:OK, so don't implement the security. (1, Insightful)

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

It's ironic that Slashdot displays "[google.com]" after the link, showing that the address can be made clear, and ruining your argument.

Re:OK, so don't implement the security. (1)

AnEducatedNegro (1372687) | more than 5 years ago | (#26918407)

And lets put a checkbox underneath that says 'Do not show this message in the future' so we don't annoy the hell out of all of our users!

Oh wait, browsers already do that. And then users check the box. And then they get suckered into these sites....

aEN

Re:OK, so don't implement the security. (1)

Deanalator (806515) | more than 5 years ago | (#26918617)

Sorry, but which browsers warn users about sending POST variables from password fields over unencrypted channels?

Maybe you are thinking of the "you are leaving an encrypted web page" warning that IE does.

Re:OK, so don't implement the security. (1)

nabsltd (1313397) | more than 5 years ago | (#26919607)

Not password fields per se, but any unencrypted POST can result in a warning dialog with pretty much any popular browser.

Firefox 3.x has the config on the Security tab in the options dialog...the "Warnings" section.

IE has the config on the Security tab in the options dialog...click the zone you want to affect, then click "Custom Settings" and find the "Submit non-encrypted form data" under "Miscellaneous".

As you can tell from my descriptions of how to find these, they aren't that "in your face", so maybe that could be improved.

Re:OK, so don't implement the security. (1)

Tx (96709) | more than 5 years ago | (#26918427)

I can't tell if this is humour or not. Are you on the Microsoft UAC team, or are you having a laugh?

Pop-up is bad, telling the user is good (3, Interesting)

jonaskoelker (922170) | more than 5 years ago | (#26919043)

If browser makers simply gave pop-ups

No. No no no! Death to pop-ups.

And here's why: they interrupt you in what you're trying to do. If they surprise you, you feel less in control of your environment which is bad (see http://en.wikipedia.org/wiki/Learned_helplessness [wikipedia.org] and http://en.wikipedia.org/wiki/Locus_of_control [wikipedia.org] ). If they don't they're pointless because you'll already know in advance what your answer is going to be, so why can't you just tell the program what your answer is when you tell it to go do whatever made it interrupt and annoy you?

A better solution is the slide-down bar which you probably know from using firefox. Instead of being in your way, it steals a little screen real estate near the edge and uses a color to tell you "you might want to pay attention here" without being in the way of what you really want to look at. Something similar happens when gedit and evince encounter an error.

They're much better than pop-ups, in the cases where you have enough room for the text you need to display to the user.

But you-the-browser probably should tell the user "Your password will be sent to $OTHER_DOMAIN. This is likely to be a security problem", so use a slide-down bar for this.

Re:OK, so don't implement the security. (1)

dave562 (969951) | more than 5 years ago | (#26920221)

Browsers already do that. The first time you use IE or Firefox and submit form data over HTTP it will tell you something to the effect of, "You are about to submit unencrypted data over the Internet where it might be intercepted. Do you want to do this?" Then right under that, there is a check box to disable the feature.

Re:OK, so don't implement the security. (1)

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

What I propose is specific to password controls, and would not have a 'permanently disable' button.

Would this annoy users? Yes. Would it save them from being hijacked? Yes. This is called a trade-off.

Re:OK, so don't implement the security. (1)

MasterOfMagic (151058) | more than 5 years ago | (#26920809)

Until they installed the Firefox extension that turns this feature off, and if that can't be done, until they download a version of Firefox with this hacked out.

People care more about a smooth experience than they do about security, which is why Microsoft will never do this, especially after the UAC debacle.

Re:OK, so don't implement the security. (1)

redJag (662818) | more than 5 years ago | (#26920787)

Pop-ups? You mean those annoying things I have to click OK to before my computer will do what I want? Putting those in doesn't make the problem go away, just shifts the liability even more on to the user.

using it wrong == out of compliance (1)

louzerr (97449) | more than 5 years ago | (#26919403)

If you're handling credit card data at least, you should (better) be familiar with PCI-DSS [pcisecuritystandards.org] . Basically, the credit card industry has gone to great lengths to set standards that can simply be followed to help assure that you're NOT handling data (or HTTP) in an insecure manner.

It's amazing what proper due diligence can do for you. It's also amazing how many people think because they CAN take credit card data online, that they automatically should.

Can you say criminal? (-1, Troll)

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

He admits to criminal activities and hasn't been charge ??? WTF?

It is one thing to examine and find a way around the security, so as to plug the hole...but to actually attack a number of sites and illegally obtain account information, is a crime...he needs to spend some time in jail as a reminder of how to work within the law...oh but wait...this is /. and code monkey criminals are worshiped...

Re:Can you say criminal? (0)

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

he needs to spend some time in jail as a reminder of how to work within the law

Don't be so clueless. Half the people at Black Hat are Feds. Reasoned accommodations were solidified years ago.

Re:Can you say criminal? (1)

Vectronic (1221470) | more than 5 years ago | (#26918275)

You bet we worship them...

Now that this is "out" (publicly anyways, probably been around for awhile) it can be resolved.

Besides, has anyone ever asked you to drive their car somewhere before? did you decide to take it to a chop-shop instead? or sell it?

Ever broke into your neighbours house and stole their stereo, just because you know they don't bother to lock the door?

Ever been waiting at the counter in a store/office/etc, and seen someones information? did you use their creditcard number? did you try and steal their identity?

Did you ever do that, then announce it publicly over 3 different types of media?

People don't type https:// (5, Interesting)

gzipped_tar (1151931) | more than 5 years ago | (#26917997)

One of the claims from the presentation (linked in TFA: https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf [blackhat.com] , PDF file) is "people don't type https:/// [https] " -- they reach SSL-enabled urls either by submitting a form (from non-SSL page!) or the result of HTTP redirect. And "that has made all the differences" according to the hacker.

Maybe we need a special TLD for HTTPS-only traffic. Let's say ".s". For a given URL, if the hostname is of ".s" domain but the protocol part is not "https:" (or other secure protocols) then the URL is invalid by standard. A browser should be mandated to use HTTPS for such a host if the URL is given incomplete (e.g. user typing "example.s" rather than "https://example.s/" in the Awesome Bar). It should also fail to use a non-secure protocol even if it's available for a ".s" site during any phase of communication.

I don't think this idea is good enough but it's the first thing coming to my mind..

Also I'd like to know more about another exploit mentioned in the presentation.. the failure to check the "Basic Constraints" field of a SSL cert. Is Firefox vulnerable?

Re:People don't type https:// (2, Interesting)

imemyself (757318) | more than 5 years ago | (#26918187)

I kind of agree with you about having something in DNS to tell the client that it must use SSL. When I read through the Powerpoint, I was wondering about using TXT records, or SRV records or some other type of DNS records to tell the client that it must connect using SSL.

I wonder how practical this would be? I think it would be easier to "bolt-on" than using a new TLD, but would it be more vulnerable to DNS spoofing than using a new TLD?

Definitely (1)

XanC (644172) | more than 5 years ago | (#26921087)

It can start as a specially-formed TXT and transition to its own field, like SPF did. DNS spoofing is its own problem; if they own DNS they have you anyway.

Re:People don't type https:// (0)

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

Balls to having a TLD that is secure. Just force EVERYTHING to run over SSL. While we are moving to IPv6 why don't we just cut all straight http traffic as well.

Encrypt the lot, suck up the negatives and this sort of vunerability should go away.

Re:People don't type https:// (1)

gujo-odori (473191) | more than 5 years ago | (#26918735)

The AC who said "balls to that" is right. Sure, it might work, but it's not needed, and the same people who make a lot of https exploits possible by embedding secure elements in insecure pages (like, uhhh, pretty much every financial institution, with a few exceptions) would not implement it, for the same reason they put that little secure login section in an insecure page: they don't want to spend the extra bandwidth and CPU time to run the whole site over https. If they would just do that - run a separate login page over https only, and run everything beyond it over https only, that would make exploits much harder. Simple, easy, safe, and they won't do it. Wonderful.

Re:People don't type https:// (1)

osu-neko (2604) | more than 5 years ago | (#26920225)

One of the claims from the presentation (linked in TFA: https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf [blackhat.com] , PDF file) is "people don't type https:/// [https] " -- they reach SSL-enabled urls either by submitting a form (from non-SSL page!) or the result of HTTP redirect. And "that has made all the differences" according to the hacker.

Hmm. I usually reach them from a bookmark. Rather than a special TLD, why not simply a meta tag that ensures anyone bookmarking the page gets the 'S' in the bookmark, even if they came to the non-SSL homepage. I notice, for example, that my bookmark for PayPal says "https://www.paypal.com", even though I'm sure they're reachable via the usual http. My bank's bookmark did not have the 'S', but I just changed it and works fine with it -- it really should have just had it all along.

The same guy. (2, Informative)

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

This is the same guy who published the infamous basic constraints IE vulnerability [thoughtcrime.org] a few years ago. His website and the software is www.thoughtcrime.org [thoughtcrime.org]

End to end encryption for a safe internet (5, Insightful)

master_p (608214) | more than 5 years ago | (#26918137)

End-to-end encryption is required at all levels of the internet. Until that is available, the internet will never be secure, because someone will be able to read the non-encrypted data you send and reply with a fake response.

Re:End to end encryption for a safe internet (1)

buchner.johannes (1139593) | more than 5 years ago | (#26919005)

Impossible for performance reasons, keyword: caching. A balance has been found.

The problem is with the trusting user, and can be (1)

gilado (1197463) | more than 5 years ago | (#26918193)

People click fake urls in their email, and provide their bank credentials to phishers.

The problem is that bank's website forces the user to authenticate themselves but currently there's no mechanism to force the website to authenticate themselves to the user.

The solution: Smart Cards (e.g. Credit Card with a chip) and Smart Card readers. Or a USB device doing the same; i.e. a fob

Of course the banks will have to spend a few bucks to provide that to their customers; currently it probably is cheaper for the bank to insure and stick the bill to the customer.

Re:The problem is with the trusting user, and can (1)

Joebert (946227) | more than 5 years ago | (#26918449)

What's the difference between data sent from the keyboard and data sent frm a smart card ?

If it still has to be transfered it doesn't matter what peripheral created the signal.

Re:The problem is with the trusting user, and can (2, Insightful)

gilado (1197463) | more than 5 years ago | (#26918499)

RSA encryption and authentication is the difference
You can't expect the user to do RSA authetication using a keyboard

But the chip in the smart card does exactly that.

Re:The problem is with the trusting user, and can (1)

zippthorne (748122) | more than 5 years ago | (#26918981)

But where do you use your smart card? I don't think i've ever seen an actual reader in person.

Re:The problem is with the trusting user, and can (0, Offtopic)

Kickasso (210195) | more than 5 years ago | (#26919521)

http://en.wikipedia.org/wiki/SecurID [wikipedia.org]
No reader is needed.

replying to myself (1)

Kickasso (210195) | more than 5 years ago | (#26919625)

Er... please mod down, make fun of, and otherwise disregard the parent comment. And this one, too.

Re:The problem is with the trusting user, and can (0)

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

The problem is that bank's website forces the user to authenticate themselves but currently there's no mechanism to force the website to authenticate themselves to the user.

No, the problem is that the user is sending their creds to the bank instead of verifying their creds.

Instead of sending your username + password over an encrypted channel, server sends you a key + challenge encrypted with your password. You send back the challenge, encrypted with their key, that proves you knew the password. Then you use the challenge to encrypt the rest of the data. If anybody intercepts it, everything is encrypted and your password isn't even in the data so they can't reuse it later. The only chance to intercept this would be the very first time the user went to the bank site, when they entered their password.

That's the gist of how SSL works.

Of course, if you registered a new account on the hacker's site and used the same password then they would know how to decrypt the bank's messages, which is why a better way is for the bank to store a smart card / USB fob public key instead of a password. But a smart card or fob certainly isn't necessary to prevent mitm hacks.

Re:The problem is with the trusting user, and can (1)

dave562 (969951) | more than 5 years ago | (#26920361)

Fraud is so prevelent the banks have written it off as a cost of doing business. I had my account compromised a couple of months ago. I called the bank on the same day that I noticed the fraud and by the end of the day they had credited my account for the fraud, opened an investigation, and setup a new account for me. I didn't even need to redo any of my direct deposits, or automatic billing because it all transfered over to the new account. Wells Fargo calls it a "lost stolen transfer". I'm sure that other banks have similar catchy phrases for their own process.

In my case, I made the mistake of buying WoW gold from China. It always comes down to user education. If a person knows how to use a computer, they can make educated decisions and keep themselves safe. I live in Long Beach, CA and my city has a couple of classes a month about how to avoid online fraud. They are directed toward seniors and anyone else who is interested. I haven't been to one, but they probably just cover the basics. "Your financial institution will never contact you asking for your personal information." "Unless you initiate the transaction, it's probably suspect." "This is how you type https://.../ [...] into the web browser."

Re:The problem is with the trusting user, and can (0)

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

It is a bit late now but actually ensuring no password is sent in the clear (i.e. browser controls password entry via its own unfakable UI, specifically the one for HTTP auth, but clarifying whether it is unsecure basic auth vs. secure digest auth) would at least partially solve this problem as well. I would not want to use it for a bank, but getting users used to typing their passwords straight into HTML forms where they will (most likely) be transmitted in the clear was a bad idea.

As that is not really possible, smart cards are a good idea as long as they are carefully designed to actually be secure (ex. the RSA keyfobs that show numbers can just be MITM'd if the attacker can convince you to give your login details to them -- they just have to login immediately to use the information).

Also, if the card has direct contact with the computer, then any spyware running on the computer could use it to log into the user's bank while it is connected. This can be partially worked around by not allowing simultaneous logins (especially from the same unique smart card) (which banks probably already do, but I, naturally, have not tested) and notifying the user of their last login time (which my credit card company does).

How to verify a cert? (0)

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

How do I actually verify the authenticity of a certification. For ex. if I go to mo bank's site I get the SSL enabled and yellow url bar and can look at the details of the cert. Issued by / to etc.. it also has a MD5/SHA1 - can I just go to verisign.com and look up that cert and compare the MD5/SHA1? The only thing I came up with on their site is a way for webmasters to check their installation but it seems to require Flash - which is a no go.

Re:How to verify a cert? (1)

gujo-odori (473191) | more than 5 years ago | (#26918651)

That's an interesting problem. Your browser can recognize a bogus certificate, or at least one that's signed by a CA for which it doesn't have a root certificate, so barring an exploitable browser vulnerability, it would be necessary for the phisher to steal the signing certificate from the CA, break its passphrase, create a bogus SSL certificate, and place said certificate on the bank's website. Then snarf your info. If they've penetrated that far into the bank's infrastructure, they can probably just snarf your info from that side of the https connection without bothering with all that certificate compromise hokey pokye.

Going back to your original question, if they had gotten far enough inside the CA to steal its signing certificate and compromise the password, you couldn't trust any MD5 sum that site gave you, either. An unbreakable web of trust is hard. Maybe impossible. That's a reason why security organizations symmetric ciphers with keys carried in locked diplomatic bags, and one-time PADs.

Paranoid (1)

indre1 (1422435) | more than 5 years ago | (#26918649)

I'm going back to pen and paper to send mail, then there's no encryption for hackers to break!

Odd choice of words (4, Insightful)

Garse Janacek (554329) | more than 5 years ago | (#26919133)

SSL encryption isn't as secure as online businesses would like us to think.

What? I mean, are online businesses down in their underground lairs, laughing at the misinformation perpetrated on an unsuspecting public? "Hah! They believe that SSL encryption is secure!"....

Maybe it should be "...isn't as secure as online businesses would like it to be." I think that it is in the interests of businesses as well as their customers for SSL transactions to remain secure. We can address incompetently implemented security protocols without treating it like a conspiracy on the part of the sites...

Still a man in the middle attack. (0)

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

This doesn't seem to me to be as serious as it might sound. You don't actually sites with this method, the attack is against the users of a compromised LAN who are trying to connect to the secure sites. That limits the scope of a real attack to networks in which a tool like sslsniff can be run. That means the attack is either from an internal user, or someone who has been able to compromise a box on your network. Home users should be relatively safe, unless you can spoof DNS or trojan their systems.

He makes some good points (2, Interesting)

93 Escort Wagon (326346) | more than 5 years ago | (#26919677)

I remember a few years ago banks (and others) were trying to "educate" people about not forcing https connections to their main pages for login purposes. Their explanation was "our login forms submit to a processing script that runs on https, so there's no problem". Well, one thing Moxie demonstrated is an effective way to attack this exact sort of situation via MITM.

I do take issue with his statement "no one types in https (or http for that matter)". With many people he's correct; but I know I do pay attention to this, and I try to get my family and friends to do so as well. Also (especially nowadays) people need to start paying attention to whether they're in situations where MITM is made much easier, such as on unencrypted wireless networks.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?