Black Hat Presentation Highlights SSL Encryption Flaws 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."
Oh god (Score:4, Funny)
Someone fix the summary before my brain melts.
Re: (Score:2, Offtopic)
God forbid... (Score:3, Insightful)
...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... (Score:5, Insightful)
Re: (Score:3, Funny)
Re: (Score:2)
Re: (Score:3, Insightful)
Part time job as an accountant. Volunteer work with Deaf people the rest of the time. Live in a one bedroom apartment with my wife. Nope, not important.
A hacking program designed to find exploits in your computer, at your ISP, or any of the internet infra-structure between you and doesn't really care how "important" you are. It only cares about the logic with which it was written.
Your internet connection is only the most easy thing to steal. If an automated program (you can call it a "virus" or "worm" if
Re: (Score:2)
I'm not very exposed to risk online. My bank account and credit cards shut down and lock up tight if they suffer a breach, and I tend to carry enough cash to get back home, so I'm not worried about that. If an odd charge shows up on my bank statement I go to the bank and they reverse it without any question (it's good to be old friends with m
Re:God forbid... (Score:5, Insightful)
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: (Score:3, Interesting)
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
Re: (Score:2)
Re: (Score:2)
I think he's saying he's probably smarter then the average program.
An attitude that can get you in a lot of trouble. Richard Feynman once said "I'm smart enough to know that I'm dumb." In other words, don't think you're so smart you can't be fooled.
What you present is a low-hanging fruit argument.
There's some of that to be sure. But anyone can get hacked, even by an automated program. Do _YOU_ check the security link every time you login to your bank website? The biggest problem with ALL of this damn s
Re: (Score:2)
I do. And I certainly don't mean to suggest being smart == impervious, in fact I believe it's more likely that an educated user will avoid many of the low-hanging fruit scenarios precisely because of their increase in vigilance.
Re: (Score:2)
Thankfully I'm not important enough to be a target.
Bullshit. You don't get attacked for being important, you get attacked because you're there.
Re: (Score:2)
Re: (Score:2)
Spelling mistakes... hmm... he's a hacker! GET 'IM!
Re: (Score:1, Offtopic)
Re:Oh god (Score:5, Funny)
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 (Score:4, Informative)
OK: "Some implementations of SSL encryption are flawed. These can be fixed. SSL encryption itself is not flawed."
Re: (Score:2)
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 (Score:4, Insightful)
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.
Re: (Score:2, Interesting)
Firefox even has everything needed to defeat this already built in - it's just not enabled by default. By setting browser.identity.ssl_domain_display to 1 in about:config, it displays a blue strip left of the URL with the last two parts of the domain name, similar to the green strip with the registrant's name for EV certs.
They should enable this by default, and whoops, the iiijk.cn attack described in the PDF is instantly obvious.
Re: (Score:2)
To put it bluntly: if you ignore a warning saying that you might be being scammed when visiting your banking site, the flaw is in your brains, not in SSL. Altought I sup
Re: (Score:2)
And to be precise, there is nothing wrong with certificate validation itself, just with the particular combination of (a) certificate authorities which erroneously issue certs which permit signing, and (b) broken implementations which don't check the X.509v3 constraints while traversing the certificate chain.
Mind hacked! (Score:1)
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: (Score:2)
Re: (Score:2)
How do you know Mr. T didn't hack in and create a Knight F Mowawk class ?
Hacking (Score:3, Insightful)
It's always about getting the fool.
Hacking isn't attacking the encryption. (Score:2)
(Well, okay, sometimes they're using WEP or ROT13 or memfrob, but in general...)
Sounds like OSI level 8 error (Score:5, Insightful)
Re: (Score:2)
Worse than that, it seems to be about the vulnerabilities of not using SSL, not anything inherent in SSL itself.
Unless I'm mistaken, the only vulnerability in redirecting all HTTP traffic to HTTPS is that users might type paypal.com, end up on https://paypals.com/ [paypals.com] and not notice.
Sensationalist, as usual.
Granted, most sites are still quite a bit worse off than that -- forms served over HTTP that send your password over HTTPS -- but as usual, there are simple workarounds. For example, bookmark https://mail.go [google.com]
No problem at all (Score:1)
Maybe the bad guys are busy elsewhere... wait...
It's not a problem with SSL /per se/ (Score:5, Interesting)
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: (Score:2, Interesting)
Re:It's not a problem with SSL /per se/ (Score:5, Insightful)
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: (Score:2)
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'.
Most people don't actually type that "http://", as all browsers I've seen add it automatically. Including Lynx.
It doesn't help that a lot of ads these days don't bother to include "http://" in the URLs they display, either.
Re: (Score:2)
I have only one thing to say: When my spouse was frustrated with OOo because of lack of understanding in how to manipulate headers/footers in OOo, I asked "Do you know how to handle this in MS Word?" When the inevitable reply of "no" came, I asked why blame OOo then?... end of argument. And to you I say that MS Windows and MS products are no easier to learn than anything else. They carry the same complexity as F/OSS software/systems. To argue otherwise is missing the forest for the trees.
Re: (Score:2)
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/ (Score:5, Insightful)
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: (Score:2)
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: (Score:2)
Exactly. Of course, if you use the Petname Toolbar [mozilla.org], none of these attacks work.
Here are some solutions (Score:5, Insightful)
My biggest gripe about these black hat papers is that they aren't as useful to non-black hats; there are no proposed solutions or workarounds.
I think the most important trick in the paper is that first one you mentioned, of MITM translating server-side SSL to client-side plain-text and assuming the reader won't notice (or care). The easiest workaround is to get Firefox to return the yellow background [cnet.com]. You still have to train users to mentally require it, but it's a step in the right direction.
On to the second hack you noted. The article specifically mentions that .com and several other top level domains (TLDs) are purposefully punycoded (see page 90). However, the logic is still sound and the actual TLD doesn't matter. The example Moxie used was *.ijjk.cn.
A solution proposal (from the top of my head): In the specific case of IDN-valid characters that approximate slash and question-mark, the simple solution is to propose a feature in firefox that recognizes them. Specifically, anything that appears to be forging a protected TLD, so punycoding IDN domains matching a regex like \w\W+(com|net|org)\W (and perhaps additionally a search for any of the proposed confusing characters), would cover a lot of ground. In the meanwhile, you could put the domain up in firefox's blue SSL box [cnet.com].
The final vulnerability discussed in the paper (the first one in the paper's ordering) was that of standard certificates acting as intermediate certificates in the chain. This has an obvious solution and the paper even implies (but doesn't verify ... freaking black hats) that Firefox already has it implemented.
Re: (Score:3, Insightful)
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: (Score:3)
"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: (Score:2)
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: (Score:2)
Taht's a good point. When depleted life savings end in suicide, that is indeed a disaster.
Re: (Score:2)
Yes, it was management's fault, but it was still an engineering disaster. When a disaster happens because you don't listen to the engineers, it's still an engineering disaster.
Re: (Score:3, Interesting)
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
Re: (Score:2)
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 w
Re: (Score:2)
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: (Score:2)
Funny thing..
There really is not much an attacker can do with a bank user/pass.
Email accounts are significantly shittier to lose. Pretty much no matter what you do on the internet, your email ties into everything. From just the email account, they can get into any social networks, hosted servers, code repositories, domain management, paypal, amazon, online games, etc.
It's made even worse when so many of the free email providers (especially google) seem to be allergic to HTTPS, and firefox is more than hap
Re: (Score:3, Interesting)
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 wou
DNS? (Score:2)
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: (Score:3, Informative)
Alternatively, he might redirect from https://secure.example.com/ [example.com] to https://secure.example.com/.ijj.cn [example.com], except that the slash
Re: (Score:2)
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, an
OK, so don't implement the security. (Score:5, Insightful)
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: (Score:2)
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: (Score:1)
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: (Score:1)
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: (Score:2)
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: (Score:2)
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 th
Re: (Score:2)
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 (Score:4, Interesting)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
You've got it wrong again. UAC annoyed people every time they did things they were supposed to do. That's not the same thing. People aren't supposed to send passwords in plain text. People don't actually mind getting alerted when they do something they are not supposed to do... example: lights/gates at railroad crossings.
You are essentially arguing that there is no point to having SSL at all, because nobody cares who has access to their credit cards and passwords. That's incorrect.
Re: (Score:2)
Re: (Score:2)
People don't type https:// (Score:5, Interesting)
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: (Score:3, Interesting)
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 (Score:2)
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: (Score:2)
To some extent that's true, but at least in theory proper SSL could warn the user that something's wrong, because the cert the attackers have wouldn't be valid.
Re: (Score:2)
Well, right, but I think that's an orthogonal problem to the one that an SSL-only DNS option would solve.
The same guy. (Score:2, Informative)
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 (Score:5, Insightful)
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: (Score:2)
Impossible for performance reasons, keyword: caching. A balance has been found.
The problem is with the trusting user, and can be (Score:1)
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 b
Re: (Score:2)
If it still has to be transfered it doesn't matter what peripheral created the signal.
Re: (Score:2, Insightful)
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: (Score:2)
But where do you use your smart card? I don't think i've ever seen an actual reader in person.
Re: (Score:2)
Re: (Score:2)
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
Paranoid (Score:1)
Odd choice of words (Score:5, Insightful)
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...
Re:Odd choice of words (Score:4, Informative)
It's not a conspiracy theory. It appears that a lot of businesses have concluded that occasionally eating the loss on a fraudulent transaction is cheaper than fixing problems.
Maybe it should be "...isn't as secure as online businesses would like it to be."
If they "would like it to be" secure all they would have to do is spend more money on their infrastructure to encrypt everything. So, while it's not a "conspiracy", users who trust sites like paypal or their bank should be upset that these businesses have decided that security is too expensive. Users should be upset that big sites that handle money have decided that it is cheaper to wait for you to notice that money is missing, contact them, and then credit your account (maybe). And if you don't notice, well... it's not their responsibility.
I think that it is in the interests of businesses as well as their customers for SSL transactions to remain secure.
I would think so, too. However, people who run these companies' IT appear to have come to a different conclusion: Spend a certain amount of money on a somewhat secure system, and then put the responsibility on the customer to notice fraud. If noticed, credit the customer's account. Since the problems with mixing secure and non-secure elements have been known and exploited for years, we can conclude that these companies have done their cost-benefit analysis on the current way of doing things and found it to be acceptable.
Re: (Score:2)
Wrong. User types "paypal.com" into their URL bar. Browser sends a request for http://paypal.com/ [paypal.com]. PayPal might automatically redirect to HTTPS (in fact it does, when I try it), but by then it's too late. A MITM can have already served up the fake page as HTTP, and few users will notice the difference.
Replying with a 302 to an http request or responding to an "https link click" is not encrypting everything.
But paypal.com does not have to reply with a 302 to the http request. Or better yet, we could all just strongly discourage using a redirect from http to https under any circumstances, and utterly ban https clickys in http (like the wachovia site). The latter concern is totally unforgivable. The user has to take it on faith that the POST is secure.
The .secure TLD doesn't sound like a terrible idea, but
Re: (Score:2)
So you're requiring users to remember which sites they access are secure or not? Users will just use a different browser if they have to click an extra button every blasted time they want to go to Gmail or whatever (but not 95% of the other sites they use!). That much annoyance to users is probably just not worth the slight gain in security, in the same way that a highway speed limit of 30 MPH is not worth the lives it would save. Any good solution needs to add no noticeable burden to users' normal web browsing.
Funny... Even accepting the analogy I still disagree (ie, 0 crash deaths, less pollution, and trains would be pretty great actually). YMMV.
One thing this presentation showed is that security can not be incremental in this arena. There is no "slight gain in security"; there is secure and there is totally exploitable.
Yes, I think it should be very very obvious to the browser user when they are using tls. The drive to "add no noticeable burden to users' normal web browsing" is part of the problem, imho. And ye
He makes some good points (Score:3, Interesting)
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.
This is an X.509 problem (Score:2, Informative)
Telcos and SSL. (Score:2)
Mobile phone companies are looking to do exactly this to HTTPS traffic transiting the GPRS network:
http://blog.masabi.com/2009/01/how-do-transcoders-affect-https.html [masabi.com]
It won't be long before ISPs that provide dial-up connections do the same with their "web accelerator" products.
Oh, and Opera Mini does this as a matter of course.
Re:Disgusting grammar. (Score:5, Funny)
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. (Score:5, Funny)
If YOU are going to. criticize someone else's. Grammar. Don't use sentence fragments to do. It.
Re:Disgusting grammar. (Score:5, Funny)
Shatner, is that you?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I think he just invoked Muphry's Law [wikipedia.org]
Re: (Score:1, Funny)
Re: (Score:2)
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.
Re: (Score:2)
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