Phishing Scams Incorporate SSL Certificates 316
dettifoss writes "Netcraft reports:
`Internet "phishing" scams are incorporating the use of SSL certificates in their efforts to trick users into divulging sensitive login information for financial accounts.'
Perhaps more disturbingly: `Scammers can also configure their web server so that deceptive SSL certificates won't trigger an alert in the user's browser. "One of the SSL encoding methods is 'plain text'," Neal Krawetz from Secure Science Corporation noted in the SANS post on the issue. "Most SSL servers have this disabled by default, but most browsers support it. When plain text is used, no central certificate authority is consulted and the user never sees a message
asking if a certificate should be accepted.'"
Do people even see the lock? (Score:5, Interesting)
Of course, this does make it more likely for people who hit that nasty stage of knowing just enough about online security to be dangerous to get caught...
Re:Do people even see the lock? (Score:4, Insightful)
And even if they do... SO WHAT -- gee your data is encrypted for the 100ms it travels between your PC and the web server.
But is the web server itself secure? Most aren't... most are written by ASP + PHP programmers who have no clue about SQL Injection.
Re:Do people even see the lock? (Score:5, Insightful)
Excellent point, you have to consider the pinheads who are keeping your credit card data on file as well. Somebody comes by, cracks a few passwords and they walk off with all this data. That's a lot less work than busting SSL.
Re:Do people even see the lock? (Score:3, Insightful)
Re:Do people even see the lock? (Score:4, Funny)
Re:Do people even see the lock? (Score:3, Funny)
Funny but you have a point... (Score:4, Insightful)
Hell, even if it's you using your own card...people are really careless and only seem to have concerns about using their card on the 'net. Too may people out there verbally broadcast their credit card info to strangers over the phone who solicit them for donations to feed the starving Africans, or hand their cards to the attendant at the full-service station when they fill their vehicles, or willingly give it to the waitress when they have lunch at Denny's, or whatever else.
I dated a diner waitress once, and know the types of losers who ended up as permanent pump jockeys from summer jobs as a teenager. I have personally witnessed those environments. In both situations many (if not most in some cases) of those employees are poorly educated, poorly paid, perennially broke, dopey chronic potheads. Also, some call centres are also pretty lax and will hire anyone who will stay long enough to learn how to use the predictive dialer system. AND WE TRUST THESE PEOPLE WITH OUR CREDIT CARDS!
Because of that I NEVER buy anything, book a room or hire a car over the phone...I go online so my credit card number is at least encrypted (and I hope that the computer jockeys are at least a bit more trustworthy than a call centre operator). I NEVER give my credit card to a waitress or a pump jockey--if I use my card at all I go to the cashier and have them swipe it electronically. Authorisation is instant and the receipt they retain doesn't show the whole number anymore (I also NEVER use the old "click-clack" impression machines either).
Sounds paranoid? Well, it's far easier to exploit those common real-world events than to set up an internet phishing expedition. C.C. fraud on the INTERNET? Even if your number was sent in the clear it's typically in transit for less than a second, and could only be aniffed out by people with access to special equipment. Sure you have to be careful about encryption and authentication but (for now) online transactions are still mostly safe. Much less bother for criminals to pursue other opportunities.
Re:Funny but you have a point... (Score:5, Informative)
You might be interested in the one-time use Credit Card that I have. From MBNA [mbnanetaccess.com], it requires that you get one of their cards, and then sign up for an online account; afterwards, you sign back in to the online page, and then can set limits + expiration dates on any given purchase. I use it whenever a physical card isn't required by the vendor, which includes over the phone transactions etc. Works with my Mac OS X and Safari.
Re:Do people even see the lock? (Score:5, Informative)
OWASP [owasp.org] is a good start.
Re: (Score:3, Interesting)
Re:Do people even see the lock? (Score:3, Interesting)
However... Just authenticating a site is really important! It's more likely that you'll be fooled by a hoaxed web site than that someone manages to sniff your packets or man-in-the-middle you. I don't know about most of you; but I'm on a reasonably trusted network (i.e. I know there aren't any sniffers on the LAN and once the connection's being routed you'ld have to sniff all kinds of gunk and manage to somehow, transparently get into that connection between th
Re:Do people even see the lock? (Score:3, Interesting)
The book you want is called "translucent databases"
Think again about your assumption that one person may want to look at a whole load of data on different people, and consider what fields this actually applies to.
Credit-card numbers? No, they get sent dur
Look for the cute little lock! (Score:3, Interesting)
Re:Look for the cute little lock! (Score:5, Interesting)
like that works! my dad called me about a year or so ago. he'd only been on the 'net a couple of weeks and ran into a site that asked him to accept a certificate. he was concerned because his bank's site never asked him for acceptance... he assumed that if the site didn't ask for acceptance it wasn't a legit ssl connection. yep, exactly the opposite of how it's supposed to work.
now, you can say he didn't read the full message (and it's true, he didn't) but, really, who here actually reads all that stuff your computer throws at you? i mean, we all skip down the man page to the examples section (if there is one) don't we? and my dad's a chemical engineer - six years of math education and he's stumped by our ssl user interface.
oh dear.
Re:Do people even see the lock? (Score:5, Interesting)
If the user was forced to pick a unique picture/bitmap/watermark that would be displayed on secure webpages by the browser, it could help with security. I.E. Design the browser so no ssl pages work until the user selects a unique bmp/jpeg that would be displayed as a unique overlay somewhere on the web page that allows them to verify that the page is secured.
Re:Do people even see the lock? (Score:5, Insightful)
Given that the problem can be clearly stated and this is software we're talking about, yes -- such a method could easily be implemented. Alternate solutions could be changing the colors for the titlebar/statusbar, unique secure text/mouse cursor icons, flashing page borders, etc. However, if the trust is misplaced (as this article suggests) then all this notification is kind of pointless. User education on top of security-conscious software is still the best way to deal with security concerns.
Re:Do people even see the lock? (Score:2)
Well, since https is flawed in its mere design (As the story says) I'd say save the trouble of doing an analysis and just forget about the whole thing.
Re:Do people even see the lock? (Score:5, Insightful)
The auto industry went through this when they put warning bells/buzzers on their cars telling drivers/passengers that their belt was not done up. The warning was persistent and loud - and got disabled (read ignored for the lock symbol and turned off for the message) ASAP.
They (the auto industry) learned though - they put the buzzer/bell on for only a few seconds at the beginning of the trip - reminding those who cared and not pissing off the rest enough to result in turning off the warning permanently (and thereby removing the warning from others who might drive the car/run the browser)
The lesson is "If you are going to issue a warning message - do it for a few seconds and then get rid of it so the idiot driving doesn't use wire cutters to remove it altogether"
Are you listening programmers?
SSL certificates in 2004 (Score:5, Informative)
(Disclaimer: I am probably biased, since we issue
SSL certificates
on our website.)
This article is a good example of yet another reason why the old advice of
"make sure the site you are dealing with has an ssl certificate, and you
should be fine" is no longer entirely true.
To be more confident you are dealing with a reputable/accountable merchant/site, you
should not only make sure that they have an SSL certificate, but you
should also actually click on the lock (or however it is done in the browser
you use) and look at the certificate.
The reason the advice used to be valid, is that traditionally, to get an SSL
certificate, you had to provide documents to prove you are who you say you
are, i.e. DUNS #, articles of incorporation, business license, DBA, bank statement,
passport, driver's license, whatever. That is still true for most of the
certificate authorities, but it isn't always true. Some of the new certificate
authorities don't actually ask to see documents before issuing the
certificate, instead, they merely make sure that you have control of the
domain by sending an email to the listed contacts. In some cases, they also
place a phone call to a number you provide them (I fail to see how this does
anything, but..). Certificate authorities that do this will issue the
certificate to "Domain control validated, organization not validated" as the
organization (or similar text to that effect) rather than to the actual name
of the company the certificate is for. These certificates are
perfectly fine for making sure things
are encrypted, however, they make the certificate useless for getting an idea
about the legitimacy of who you are dealing with. They also don't tend to
carry the warranties that other ones do (and for good reason, who would
underwrite that procedure?).
Anybody got a list of "BAD" Cert providers? (Score:5, Interesting)
If so anybody have a list of SSL providers I should be giving a second look at when the site pops up?
Re:Anybody got a list of "BAD" Cert providers? (Score:3, Informative)
Re:Anybody got a list of "BAD" Cert providers? (Score:3, Informative)
-Lucas
Re:SSL certificates in 2004 (Score:2)
That doesn't make me feel any wiser or safer. Asking for all of that information isn't the litmus test for the legitimacy of a CA. Heck, that'd be a great front for an identity thief. I'm no more trusting of big tech companies offering certificates. Just because they charge a wad of dough do
Re:SSL certificates in 2004 (Score:3, Informative)
I agree ethics in business is important.. witness Worldcom and Enron if you want something more recent than the 1980s.
We don't charge the wads of do some companies do, but I would like to think we are both
Other limits of current SSL implementation(s) (Score:5, Interesting)
Suppose your server gets rooted and a bad guy gets your private key. You have to tell everyone who might go to your web site that the old certificate is no longer valid.
The good news is that there are certificate revocation lists out there. The bad news is that Internet Explorer, as of the last version I looked at, doesn't check them by default.
Next, think about the level of understanding of PKI out there, think about the usability studies that have been done on public-key software(specifically PGP), and estimate how likely it is that most organizations could resist a social engineering attack on the secret part of their SSL cert.
The indispensable Bruce Schneier has pointed out a couple of other vulnerabilities. How does your browser know what signers make a certificate valid? It ships with a list of trusted signers. How secure is this list? It isn't. Schneier has pointed out in his newsletter that a virus could silently add an evil CA to the trusted list.
His other good point was, how much would it cost to compromise the Verisign root signing key? He talked to Verisign's CEO and they decided that for $15 million you could make a down payment on a leveraged buyout of the company. So that's an upper bound. Could you make $15 million illegally with bogus Verisign-signed certs? Could the Russian mafia raise $15 million?
I've been kind of surprised that SSL has worked as well as it has for as long as it has.
Re:Other limits of current SSL implementation(s) (Score:3, Interesting)
The good news is that there are certificate revocation lists out there. The bad news is that Internet Explorer, as of the last version I looked at, doesn't check them by default.
Both IE and Mozilla both support OCSP. Mozilla does not have it turned on out of the box either.
The indispensable Bruce Schneier has pointed out a couple of ot
Re:SSL certificates in 2004 (Score:2)
Re:SSL certificates in 2004 (Score:2)
The reason I am not mentioning any URLs or names is that I don't want to be seen as badmouthing competitors, as that isn't the point of my post. I'm against the practice, not the people doing it.
Re: Getting a certificate without a corporation, you don't need one. We are happy to issue SSL certificates [omegasphere.net] to individuals - instead of corporate documents we ask for personal ones (i.e. passport, driver's license, etc.).
The short (Score:2, Informative)
Netcraft has developed a service to help banks and other financial organizations identify sites which may be trying to construct frauds, identity theft and phishing attacks by pretending to be the bank, or are implying that the site has a relationship with the bank when in fact there is none.
Here's the competition (From Google):
About Comodo:
Comodo is the leading WebTrust-compliant enterprise solutions provider for E-commerce Security Solutions. Firmly established in t
Average Joe (Score:5, Insightful)
Isn't it more likely that people were suckered in not because of the SSL trick but rather simply from "scam" or mimic pages instead?
It doesn't matter (Score:4, Insightful)
Ooooh... Wait a minute. That could be a NEW strain of e-mails... Just takes a little more HTML craftmanship to code a fake E-Mail with a "reset" password, you log into the evil website with it, and enter in your "new" (which would most likely be your old one again, for most people) info. Scary!
Re:It doesn't matter - but it does (Score:2)
And when I get a legit looking letter that looks like a real notice from a domain registrar, web site I have account with (PayPal, eBay, eSnipe, Mwave, NewEgg, etc.) - then I want to respond.
Business is about relationship with customer and company... you SHOULD read your notices that your account is past due, that your account was hacked and you need to change your passwo
Re:It doesn't matter - but it does (Score:3, Interesting)
Now, absolutely every weakness is being found and exploited. The Internet just wasn't designed for thi
Re:It doesn't matter - but it does (Score:4, Insightful)
Now, after the fact, engineers can design useful protocols to work on top of or in conjunction with the internet to help solve the problem of hostile hosts. IPsec, SSL, PGP, firewalls, ssh, and fancy switches/routers all help to protect people from abuse.
And now, we have a high degree of internet freedom. We can pretty much do what we want with our bandwidth. People will get mad and hunt you down if you crack systems, violate copyrights or send spam, but aside from that, it's pretty much free. And even with all this freedom, it just requires a little persistance to prevent your machine from getting hacked.
Re:It doesn't matter (Score:5, Informative)
Verisign does. After failing to get an account migration problem fixed via email, I finally resorted to calling them. The rep asked for my username and password to verify my identity and couldn't understand why I refused to give out my password over the phone. I asked him if the passwords were stored in their database in plaintext or if he was going to check it by logging on, but he wouldn't tell me.
Re:It doesn't matter (Score:2)
Moved it to register.com, who have provided nearly flawless service. It's not the cheapest out there, but it's reliable.
N.
Re:It doesn't matter (Score:5, Informative)
So am I, actually. What you shouldn't do is to give out your password on the phone when someone calls you. That's how they trick you. "Hi, this is so-and-so calling from Verisign. Can I have your date of birth and mother's maiden name?" But if you call them, you know who they are. Who cares if you give out your password over the phone.
One time at work, I got locked out of my account for typing in my password 3 times (actually it happened quite frequently due to their lame-brain "user must change password every 6 months" policy). I called the help desk to have them reset my password, but they refused to give me the temporary password over the phone.
I was impressed. After all, they had no confirmation of who I was other than the fact that I was calling from the phone on my desk. So instead they sent me a voice-mail and I had to type in my voice-mail password. But my new found faith in MIS was quashed when I listened to the message: "Your new password is 'password'. That's p-a-s-s-w-o-r-d."
-a
Defeats the purpose of SSL? (Score:5, Insightful)
Re:Defeats the purpose of SSL? (Score:5, Informative)
There would, of course, need to be a way to easily differentiate between encrypted and non-encrypted sites just like now.
Re:Defeats the purpose of SSL? (Score:2, Interesting)
For the record, I do look for the lock icon but because of that, I do turn off the "you are connecting to a secure site/you are leaving a secure site." 9 times out of 10, I do click on the lock and verify that the URL in the ce
Re:Defeats the purpose of SSL? (Score:3, Informative)
I do not see anything in IE's config to disallow this, except perhaps disabling SSL3 all together. That seems excessive. I hope someone can post a correction to this.
Re:Defeats the purpose of SSL? (Score:2)
Re:Defeats the purpose of SSL? (Score:5, Interesting)
I presume the second half of the problem in that MS Internet Explorer allows (is this fixed?) a site to misrepresent its address in the address bar? That way the user cannot be sure that the address displayed matches that in the certificate.
Personally, I've never understood the mentality of allowing a web page to modify ANYTHING outside the boundaries of its frame. Doesn't this break the whole 'object orientedness' of a windowing display?
Best strategy for fighting this (Score:5, Insightful)
If I understand correctly, phishing comes into play when users are sent an e-mail with a bogus link. Probably something like "we've detected fraudulent use of your account, please follow this link to verify your information" etc. etc.
There is no reason to follow links in e-mail to get to a site that you regularly use. If you doubt the authenticity of an e-mail from, say, American Express, just visit the site as you usually do, through a bookmark. After logging in you should be able to access the necessary info.
Re:Best strategy for fighting this (Score:5, Funny)
This applies to real life too. The other day, two guys wearing official-looking "police" uniforms came to arrest me. I didn't open the door, I called 911 and told them that some jokers wearing police costumes were trying to arrest me. I turns out they were the real police, but it's always best to double check.
Re:Best strategy for fighting this (Score:5, Interesting)
Re:Best strategy for fighting this (Score:4, Insightful)
I've always told users to never click on a link in email --- *always* go to the known URL manually to login. If there's something important for you, they'll tell you when you login.
Re:Best strategy for fighting this (Score:2)
Please do everyone a favor and tell us the name of the ISP so we can avoid doing business with this company. Who in their right mind would *ever* ask a user for their password as a means of identification? It's business practices like this that leads to confusion amongst the non-tech masses.
Re:Best strategy for fighting this (Score:2)
Security needs to be tempered with "being reasonable". It is, afterall, an internet account, not access to a missile silo or something...
N.
Open SSL contributes to the problem... (Score:2, Troll)
Most of them let you do a functionally okay SSL certificate without having to pay a root certificate authority. However, that means you're going to get the "sorta okay" certificate message poping up, with the user being told that the certificate is valid but there's no certifying authority behind it. As a result, the user is trained to click "Yes" to that box, and is conditioned to ignore such errors...
Re:Open SSL contributes to the problem... (Score:4, Insightful)
Users are conditioned to click Yes/OK to *any* dialog box that gets in their way, without reading it.
you are misinformed (Score:4, Informative)
RTFA or quit trolling. The problem is not the SSL certificates or who creates them, but the browsers accepting a "plain" encryption scheme when setting up the secure channel. I haven't actually seen this but it's entirely within reason that a "plain text" encryption was available in the SSL libraries for debugging communications in SSL apps.
I think it should be fairly simple to update the browsers so they require some encryption by default. Voila. Problem solved and we don't have to kill OpenSSL or "pay a root certificate authority" for the privilege of having encryption.
Re:you are misinformed (Score:2)
When you inspect a certicicate with MS Internet Explorer, it says the certificate is 'okay'. Most users would interpret this to mean 'everything is 'hunky dorey', and continue on with their transaction.
In reality, 'okay', in the context it is used, means that the certificate is internally consistent. It doesn't say anything about whether the user is being scammed. Shouldn't the message wording
IE hides information for your own good (Score:2)
Someone at Microsoft decided that it's better to not scare users with too much technical information, and give them just bits of it (literally - it works/ it didn't work). IE is not exactly known for its informative error messages.
"Page cannot be displayed". Could it be because the site fell off the face of the planet, the file is missing on the server or your office network is down ? doesn't matter to IE so long as you can feel warm and fuzzy inside that it tried and it's definitely not your fault. Yea
Issue isn't really encryption, but trust. (Score:2)
The issue here isn't really encryption, it's trust.
SSL (in terms of how it is useful to someone browsing the web) has two roles. One is to "ensure" that data is securely transmitted between two endpoints. The other is to "ensure" that the endpoint(s) is trustworthy.
Encryption really only relates to the former. The latter relys on certificates being signed by someone trustworthy who has taken due care in v
Re:Open SSL contributes to the problem... (Score:4, Informative)
If a protocol can be weakened by someone generating a long bit-string, then that protocol isn't worth much in the first place.
Public knowledge of SSL (incarnated in the openSSL source) is not the problem. Rather, the problem is twofold:
I would be willing to pay a good CA for actual verification, even as a client, if i could be sure that they were actually verifying the folks they issued certificates to. But it would need to be big enough to be able to certify a large number of sites to be worthwhile...
The non-hierarchical nature of the web of trust [gnupg.org] model of PKI is so much better than X.509, so it would fix the untrustworthy hierarchy issue above. But, even more than X.509, it expects all the end users to understand the basic ideas of PKI, not just "look for the little lock and click those dialogs as soon as they come up". sigh...
Re:Open SSL contributes to the problem... (Score:2)
A cool idea would be to assign a "trustworthiness value" to each trusted root certificate. Then browsers could do something with the lock icon and/or use a tooltip to notify the user. CAs that don't care much about verification or that support fraud would be at the bottom of the scale.
Re:Open SSL contributes to the problem... (Score:2)
Re:Open SSL contributes to the problem... (Score:3, Insightful)
Look here [openssl.org]
Tells you how to install your self-signed certificate into your clients browsers.
For anyone with too many clients to do this practically... well if you have that many clients you should be making enough money to buy a certificate from a trusted authority.
Microsoft Has Got You Covered (Score:5, Funny)
http://slashdot.org/comments.pl?sid=99888&thresho
Sometimes they take a while but it pays off!
an old timer i know (Score:5, Interesting)
solves all this by never entering any financial data anywhere on the internet. he's not a knowledgeable computer user, and he knows it. in his case, and in the case of many non technically-minded individuals, it seems much easier to simply avoid all online financial transactions.
i think his simple approach to avoiding online financial risks makes a lot of sense. many of my non-tech friends/family members might be taken in by a scam like this, and given how painful it is to explain computer things to them, from now on i'll just tell them never, under any circumstances, to enter financial data on the web.surprise, surprise... (Score:2)
I doubt that completely removes the risks. I bet most processors now use the 'net to submit data to their central database when they get it either by phone or on paper. It's the obvious thing to do, not many want to develop their own modem-based secure networks when this cheap Internet is already here.
Re:an old timer i know (Score:2)
I also prefer candles as it it decreases the chance of being electrocuted.
Re:an old timer i know (Score:2)
how am I supposed to know if that Yahoo store is
legit. So my strategy is to only buy from places
with long history and well-established reps and
their own domains like Newegg, amazon, holiday inn
etc.
Also, always pay with money order on auction sites
like e-bay and only buy from high-ranked sellers
(though it doesn't save you from some frauds).
Basically, try to whitelist who you deal with
financially over the internet.
And like someone pointed out, use only your bank
Meh (Score:5, Insightful)
At the rate things are going, you pretty well have to know all the same tricks the spammers/scammers do...
I mean, just the other day, I got a message from PayPal about my account. Oops, I don't have one... Okay, so that would've been my first clue, but it was faked well enough to pass Hotmail's spam filter, and it looked official, like I really had had an account suspended.
So I check the email source, because I know better. Sure enough, it's using the %00 bug to catch IE users. Assuming they would know to look for where the link actually pointed, instead of where it claimed to.
In the mean time, I went to the page. Sure enough, it wants every bit of information imagineable. All the other links off it link to actual PayPal pages... the status bar at the bottom is left blank via JavaScript. So the inobservant and gullible would be hosed...
Naturally, I feed it totally fake information (might as well give them more false data... shouldn't harm anyone, should only help get them caught, I hope), just to see what it does. Sure enough, redirects you to another actual part of the PayPal site. I sent off a LART to the hosting provider's abuse email. No response. I don't consider that a good sign.
Note that no SSL was required here. Just official-looking pages. Granted, I didn't fall for it, but I know more about these exploits than Joe Average. Joe Average probably wouldn't know what was wrong with %00 in a URL if he saw it.
This is sad, too. I've taught classes on this, and I try to teach the class as much as they are capable of understanding. Even so, it's getting to the point where I feel like they need to know at least as much as I do just to avoid these stupid scams. There's a new one made up every day, it seems, and I spend a lot of time just keeping up with what the lowlifes are doing...
So the point of all this? We practically need a "scam report" type of newspaper for the general public. Not to mention a primer detailing the older tricks in the book... not to mention some way to get the average public to read them both.
Re:Meh (Score:2)
That said, yeah, it's not like it's that hard for them to pass the spam filters. Even so, it's just another thing that might help it seem more legitimate to a potential victim.
Then again, I would hope that a reasonable person would know better than to give them every possible password, address, SSN and bit of personal information they could possibly want...
I mean, hell, I was waiting for the
thanks scammers! (Score:4, Funny)
Re:thanks scammers! (Score:4, Interesting)
You do raise a very interesting point though. The fact that browsers don't pop up a warning for plain-text SSL could actually potentially be used to perform a man-in-the-middle attack with no-one the wiser (unless they check the issuer of the certificate manually, as they should)! That is rather scary to me, and it is serious enough that patches should be issued (not that most people apply them, but that is an entirely different story).
Damm I wish I knew (Score:4, Funny)
They just want to jam. (Score:5, Funny)
Invading SSL can't be good (Score:2)
How the hell I use online banking and do any heavy shopping via https again?!
Re:Invading SSL can't be good (Score:4, Insightful)
As the saying goes: "Security is a process, NOT a product."
Mozilla has a warning for this... (Score:4, Informative)
Re:Mozilla has a warning for this... (Score:4, Informative)
In Mozilla go to Preferences -> Privacy & Security -> SSL -> Edit Ciphers -> Extra SSL3/TLS.... Then you'll see the two modes of NULL encryption,
No encryption with RSA authentication and a SHA1 MAC
No encryption with RSA authentication and a MD5 MAC
If you click on the cipher details button, you'll see that the effective key size is 0 bits.
You should also consider disabling SSLv2, since it is cryptographically broken (unless you have to use a site which doesn't support the newer TLS).
Note that this TLS/SSL non-encryption mode potentially applies to all TLS/SSL-enabled applications, not just web servers/browsers. You could argue that in some of those (such as email SMTP+STARTSSL), that using these modes almost makes sense if all you want is authentication.
Is there a page with a demo of the technique? (Score:3, Interesting)
EXTREMELY IMPORTANT CRITICAL ACCOUNT UPDATE (Score:2, Funny)
I think the site you were looking for is here [cockeyed.com].
The lock is not important (Score:5, Insightful)
This is fine by me. Everything up to that point doesn't need to be encrypted. However, the only way to verify that the form (i.e. credit card #) will be sent over HTTPS is to View Source and look for the POST line. And this makes verifying certificates and encryption methods even harder.
Would it make sense for a tooltip over the Submit button to show the destination of the POST? Or at least whether it's secure? How about some useful items on the right-click menu?
While I'm on the topic...When I right-click and hit View Source, why can't the browser open an editor and scroll to the line of code that I right-clicked on? I know Firefox & IE don't, maybe something else does already..
Re:The lock is not important (Score:5, Interesting)
While I'm on the topic...When I right-click and hit View Source, why can't the browser open an editor and scroll to the line of code that I right-clicked on? I know Firefox & IE don't, maybe something else does already..
In Firefox, if you highlight part of the HTML document and then right click the highlighted text and select "View Selection Source", the program attempts to load the source and go to the appropriate line(s). I've found the functionality is kind of hit-and-miss, but it's definitely what you're after.
Re:View source (Score:2)
This is absolutely beautiful. Where do I send the check for the number of hours you're going to save me over the next 50 years?
THANKS!
Re:View source (Score:2)
Heh... no problem! I think I actually found that feature by accident. I'll call it even if you can tell me how to change the key binding for "open page in new tab" from Alt+Enter to Ctrl+Enter ;)
Re:The lock is not important (Score:3, Informative)
Enjoy!
Re:The lock is not important (Score:2, Informative)
Re:The lock is not important (Score:5, Informative)
Unfortuantely, you have no clue where the form is going to be submitted to.... Just looking at the source is not enough -- there can be an onsubmit handler defined in one of the dozen scripts linked into that page that rewrites the action URI to a (HTTPS, sure) URI pointing at some other server. Like the server of the guy who just performed a man-in-the-middle attack on the unencrypted data channel you and the store were using...
The only way to prevent this is to serve the page the uset types the credit card number in as https and have the user check that _that_ page is actually what it's claiming to be.
All this apart from the fact that if you type any text into a web page that web page can immediately phone the text home (using toys like XMLHttpRequest, SOAP, etc). So don't EVER type a credit card number in a page whose origin is not guaranteed.
Tip for Safari users (Score:5, Informative)
To enable the Debug menu see this tip [macosxhints.com].
Every UI I've seen for SSL, is lame (Score:5, Interesting)
I bet 99% people don't even know what the lock icon means. I bet 90%+ of Slashdotters don't really know what the lock icon means and how to interpret the meaning of the cert. What does that tell you about the quality of the user interface?
The UI is oversimplified to the point of danger. So some company that you don't know, but the guy who made your browser might know declares that the cert really belongs to who it claims to belong to. Where's the accountability? Do you know any of these signers? Do you know anything at all about their security procedures? And if you did know something about them, could you adjust how much you trust them, and have your browser use other authorities to double-check them?
That's why the cert system sucks, especially with only one signature per key. I can think of ways it might be useful, but Internet Commerce isn't one of them.
Fortunately, many many years ago, before the web even existed, someone came up with a much better way of dealing with these issues. That someone was the underrated hero Phil Zimmermann, and that something is called PGP.
Now with PGP, the user has to actually think about who they trust and deal with the concept of degrees of trust, and grandma doesn't want to have to think about crypto stuff. Boo hoo. That's too bad, because if you want accuracy, and even the capacity to be able to trust what your tools are telling you, then you have to. But some people don't care. Fine, then trust some central authority just like you do with SSL certs, and your situation is no better or no worse than it currently is now.
But at least if PGP were used, then, the applications (e.g. web browsers) would be designed with the idea in mind, that certs are of varying degrees of trustworthiness, and they would have been forced into coming up with ways of presenting this information to users. (Because just because grandma doesn't care, that doesn't mean all your users don't care. So you have to deal with the issue.) That means that problems like the one in this story, wouldn't happen, because the UI would be designed, not to tell the user if an connection were SSL, but instead to inform the user about the other side's identity and the degree of certainty of that identity. A plaintext SSL connection would say something like "0% certainty" instead of a stupid lock icon.
Now, time for a plug: the GNU TLS library. [gnu.org] These dudes made an SSL library that can use PGP certs. It's a step in the right direction. Kick ass.
Another idea for browser security - data detect (Score:4, Interesting)
Anyway, I had an idea that might be easer for users to use - instead of indicating a page is secured or not, instead let the user indicate that certain kinds of data should never be sent out over an unsecured, unverified link - any attempt to post data would result in a warning message about the information transmitted not really being protected. That would eliminate mistaken posting of data of insecure lines if people are not really paying attention to the lock (I have left up on all my browsers the warning about entering/leaving a secure page so I pretty much always know [or thought I did], but that's too annoying for most people).
You wouldn't even have to give the exact number - you could have pre-defined things like "anything that's a credit card number" or "anything with 9 digits ending with these four" or "my address". Then the browser would watch form fields and if the user tried a page submit - up would go the warning.
Showing once again why Javascript is a bad idea... (Score:4, Insightful)
No it doesn't. It underscores the need to make browsers that aren't quite so bloody stupid, and do things like always displaying the real URL (gasp!) and not allowing Javascript to open new windows without the normal user interface security features (or a big yellow border saying 'Javascript window'). In fact, it might be a good idea to always have a grey border of a few pixels between the contents of a page and the user interface widgets surrounding it.
They may have a point on the SSL certificates, but the whole PKI thing seems a complete crock anyway... Verisign, Thawte and the like are not exactly the world's most trusted institutions. Maybe in the case of banks and other high-security sites it should be possible to pick up a free CD from your local branch or from your country's financial regulator containing the public keys. Then there would need to be a simple and foolproof way to import this key into your browser.
The article is incorrect (Score:3, Interesting)
Yes, SSLv3/TLSv1 does have a NULL cipher suite, which is authentication only, and there is also support for Anonymous Diffie-Hellman key exchange (which doesn't require authentication). (See RFC 2246 [ietf.org]) But browsers don't use it. No browser, even going back to Netscape 2.0 supported NULL or ADH by default. If you wanted these cipher suites, you have to explicitly turn them on.
Go ahead, try it. Take a test Apache/mod_ssl server and change the SSLCipherSuite config line to:
SSLCipherSuite ADH:NULL
and restart the server. Now try to connect to it.
In IE, you'll get the generic "The page cannot be displayed" error. In Mozilla/Firefox, you'll get "Firefox and cannot communicate securely because they have no common encryption algorithms."
I welcome a real-world example of this "attack" that will actually work on a default-configured web browser.
Doesn't work in Firefox 0.8 or IE 5.50.4807 (Score:4, Informative)
I tried using
openssl s_server -nocert -ciphers eNULL:aNULL:NULL -www
as well as
openssl s_server -cert mycert.crt -ciphers eNULL:aNULL:NULL -www
In both cases, both browsers refused to connect, saying that there were no shared algorithms (Firefox), or simply giving a error page (IE).
In all cases, openssl gave me messages similar to
332:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c
Perhaps this does not qualify as "most browsers", but I'm sceptical of this report.
SSL Certificates are worthless anyway (Score:3, Insightful)
TWW
Misuse of Lock icon.. (Score:4, Informative)
Re:Legislation (Score:2, Troll)
Re:Legislation (Score:5, Insightful)
Re:Legislation (Score:4, Insightful)
Re:Legislation (Score:3, Funny)
Reminds me of Bowling for Columbine. Michael Moore had the brilliant idea of treating white collar criminals just like the rest... Chase them through the street, tackle 'em in the street, and bump them a few times on the hood of the cruiser. Would make for entertaining TV, and every "Average Joe" would love to see his/her boss go down.
Re:Legislation (Score:5, Insightful)
Let me give you an example. Suppose you're in the nation of Grand Fenwick, and bank with the National Grand Fenwick Bank. I, who live in Mordor, decide to target customers of the National Grand Fenwick Bank, and set up a fake website at http://123.456.789.0/gf.php[1] that mimics their logon screen. I then send out millions of emails to lure customers of NGFB to my website.
Within minutes of these emails being sent, the Powers That Be at NGFB know about the fraud that's being committed in their name. They know what host is hosting the scam. They know (or can easily find out) where the host is located physically. BUT:
There are too many levels of proof needed to bring a conviction, and even if they're all satisfied, if the perpetrator is in a country such as Russia, all hope goes out the window. In fact, all it takes is one layer -- me hiring a Russian to obtain these details -- to protect me (as long as I'm careful about how I use those details).
The police and fraud departments are aware of these issues, and they're trying to resolve them. Unfortunately, political problems get between the problem and the solution. Things aren't helped when it takes me a half hour to alert the bank and/or police of a currently active fraudulent site...
[1] Yes, I know this is an invalid IP address. You're missing the point.
Re:Legislation (Score:2)
This IP range is controlled by Freedonia, and President Rufus T. Firefly has let it be known that hijacking their limited IP addresses would be a causus belli. Prepare for war!
Re:'splane it to me Lucy (Score:4, Informative)
Their site would be an exact replica meant to steal your information. So, firms would beat into their customers to look for the 'lock' or the https:// before a URL to make sure that it was the right site.
With plain text encoding on an https site, you still get the comfort factor of the lock (i think), and the https://, so once again, the morons who don't look at the complete URL are going to be victimized.
IE had a bug where a certian control code would make the second part of the url (the @and everything after it) completely invisible. This has been fixed.
Re:What a scary world we live in (Score:3, Insightful)
Not a chance. Until something big happens several times, there simply won't be enough of a drive to make anything better.
So many people are so content with the crap that Redmond pumps out, it's just disgusting. They're also afraid of the effort to learn anything new. Every time someone complains about popup ads, I tell them that there are other browsers they can use which will block them. Guess how many have swi
Re:Enough is enough (Score:3, Insightful)