Phishing Scams Incorporate SSL Certificates

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

Comments

Do people even see the lock?

[valence]

Based on my experiences helping neophytes do web work, my guess is that 90% of the web-using public doesn't even notice the little key icon, and don't know what a security certificate is even when the dialog to accept one appears. All they usually look at is the web page itself... especially on a browser like Safari where the lock is a small icon in the title bar that escaped me the first time I went looking for it. It might be interesting to have some usability folks do an eye movement analysis to see if the average user's eye ever tracks to the lock icon during normal browsing.

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?

[RoundSparrow]

I agree, most users don't even pay attention to the lock.

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?

[mrseigen]

But is the web server itself secure? Most aren't... most are written by ASP + PHP programmers who have no clue about SQL Injection.

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?

[miracle69]

Would there be a way to have the browser display some sort of image transparency on the secure web page?

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?

[LostCluster]

Or worse yet... the people who have the root passwords to the server walk off with the data with no hacking needed.

Re:Do people even see the lock?

[gilrain]

Or, worse yet, the guy who has the credit card in his wallet goes out and buys something! Oh wait, I guess that was a step too far.

Re:Do people even see the lock?

[Anonymous Coward]

Or, still even worse, the guy with the credit card travels to Soviet Russia where his credit card spends *him*.

Re:Do people even see the lock?

[nacturation]

Would there be a way to have the browser display some sort of image transparency on the secure web page?

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?

[Anaxagor]

What are some good resources for a web developer to read so that they know how to design secure sites that use RDBMS as a backend?

OWASP is a good start.

Re:Do people even see the lock?

[rcpitt]

The biggest problem with "seeing the lock" is that the lock icon itself does not intrude enough and the "You're now viewing a secure site" message is too intrusive.

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?

Re:Do people even see the lock?

[EMN13]

I don't know anything about plain text SSL.

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 the various routers - much harder than on a lan.)

So if I had to choose between authentication and encryption - well; I know what I would choose...

Re:Do people even see the lock?

[pimpin apollo]

The 128 refers to the symmetrical encryption key that's used. SSL technically is a hybrid system, it uses public key, which is RSA, for the initial handshake, but it then uses RC4, AES, 3DES, blowfish, or whatever other symmetrical algorithm, for the rest of the transmission.

Public key involves coprime numbers (and the extreme difficulty in factoring them).

Symmetrical algorithms do not; they only require a key, hence the 128 bit key. Brute forcing a 128 bit key is computationally infeasible (that's an understatement), so you're right about it being in all practice, unbreakable.

SSL's real vulnerability is the public key infrastructure and the often poor implementations of it. The main holdout however is getting your key signed by a certificate authority (verisign, thwate, etc). I don't know any details but the posts would seem to suggest that plain-text isn't checked, or at least there's no popup warning.

This answer's probably longer than you wanted, but in principle ssl is cryptographically solid (to the extent of my understanding). Implementations are the problem.

Re:Do people even see the lock?

[paul_pick1]

I think this puts it rather well:

"[Encrypting transactions on the Internet] is the equivalent of arranging an armored car to deliver credit-card information from someone living in a cardboard box to someone living on a park bench." -- Eugene Spafford (Purdue)

Re:Do people even see the lock?

[gnu-generation-one]

"But if you have asystem where more than one person has to look at all the data, than it can't really be encrypted without saving the password somewhere on the server, since all the people accessing the data won't have the password/unencryption method."

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 during the transaction, and if you even need to keep them in the database, they can be encrypted with the user's password, so that next time they logon, they can use that stored CC number again.

Management stats? No, you can just update the "total x" for each transaction, without having to store x individually per-person.

There's plenty more in the book, but start thinking about which direction each piece of data is going in, and whether that's correct. Does the person's ID need to go into a table of statistics? If not, hash their name and password, so that it produces a unique identifier that can't be related to the customer without knowing their password.

Does some data need to go from the customer to the company at all, or could it just be encrypted with their password? Would it be better to just throw some information away? Start thinking about who needs to know what..

Re:Do people even see the lock?

[PD]

The warning buzzers are there by law. The auto industry lobbied to weaken the law, and the compromise was a 20 second requirement for the buzzer. It wasn't a smart auto industry. Remember, they're the ones who think your door is a jar.

Re:Do people even see the lock?

[Shurhaian]

"However, if the trust is misplaced (as this article suggests) then all this notification is kind of pointless."

Which is the crux of the whole issue.

Even a properly-registered, fully-valid SSL certificate only proves(to a reasonable extent) that the entity is what it claims to be. It's still up to the user to determine that said entity is trustworthy. It's that way in e-mail with PGP/GPG keys, SSL-encrypted web pages are no different.

Browsers should probably be set up to pop up a warning if plaintext is used for SSL, since it violates the very security SSL is supposed to ensure. Also, checking around for a company's reputation is a good idea. Is there a central site that keeps track of reputable dealers versus known scams?

All that said, the only reason internet transactions are any more problematic than those in person is that you don't know exactly where the person on the other end is - which is also a problem for phone payments. Certainly, identifying an encrypted credit card order, much less decrypting it, is not a task for the faint of heart; with so much network traffic, it's next to impossible to pull stuff like that unless you're specifically monitoring on one end or the other, right? Even if you do spot encrypted traffic, it might be a credit card transaction, or it might be account management of some kind, or it might just be someone connecting to a bulletin board that's set up to use SSL.

(As an aside, I suddenly have a renewed urge to get SSL working properly on my FreeBSD box, even though I don't handle anything remotely related to financial data or business secrets. Perhaps it's time to hit O'Reilly again.)

SSL certificates in 2004

[ddent]

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

Re:SSL certificates in 2004

[ddent]

I've actually often thought how our business would be a good one to run if we were identity thieves. Very, very few of our customers have pose any questions about giving us the documents we ask of them. Fortunately, we are not, and we are also very careful with our document retention/storage policies.

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 competent and trustworthy.

But I ask: If you are not going to judge a CA by the procedures they use to issue certificates, then how are you going to judge them (and the certificates they issue, and the holders of those certificates)? I would suggest that there is little else in the way of quantifiable properties that people can go on...

The short

[Idealius]

Here's the kicker (From Article):

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 the market, Comodo markets a range of innovative products and services developed by its dedicated research lab delivering software, hardware, secure messaging and certificate-based security.

Comodo offers its SEEOS(TM) Secure Enterprise Extensible Operating System for integrated network security, together with secure Linux applications delivered via its Trustix(TM) brand, SIDEN(TM) next generation ASIC, Instant SSL Certificates for securing web servers and patented web site verification and identity solutions. For product information please contact US +1 800 772 5185 or Europe +44 (0) 161 874 7070 or visit the Comodo Home Page at www.comodogroup.com .

About Betrusted:
Betrusted is the premier global provider of security and trust services to the world's leading organizations and government agencies. Through its managed security services, Betrusted offers clients a comprehensive package of leading security products coupled with unrivalled expertise to help reduce costs, increase revenues and comply with government and industry regulations. For more information, please visit our website at www.betrusted.com . Betrusted is owned by One Equity Partners, Bank One's private equity group.

(http://www.instantssl.com/ssl-certificate-news/ss l-120104.html)

Average Joe

[LordK3nn3th]

Average Joe doesn't have any idea what encryption is or why it's important. Average Joe just wants to point, click, and buy. Hell, I rarely pay attention to it.

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

[TheDarkener]

What, is this going to trick another 1% of so called "technically adept" people *COUGHmcseCOUGH* into giving their online bank login info over a freakin' website? Who ever ASKS YOU for your login information?! They reset it, and they have you reset it upon login.

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

[PacoTaco]

Who ever ASKS YOU for your login information?

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

[God! Awful 2]

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.

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?

[chrispyman]

Wasn't the entire point of SSL was to be encrypted? Who's bright idea was it to put plain text in SSL in the first place, much less give browsers support for it?

Re:Defeats the purpose of SSL?

[realdpk]

Sometimes all you need is authentication. It would actually be nice if plaintext sites could have plaintext certificates so you'd know you're going to the right place, but still be able to browse without the added encryption overhead with every request.

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?

[chamilto0516]

OK, given what is in this thread, I ask this: In the popular browsers (IE, Netscape, Mozilla, Firefox, Safari) how would I turn off "plain text" SSL. But if I could, would I want to? Would that break SSL authenication without encryptions type things and do a lot of sites do that?

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 cert matches the url that I am pointing to...but I do understand that I'm especially paranoid in a nerdy kinda way.

Re:Defeats the purpose of SSL?

[femto]

Perhaps the problem is a user interface one? Typically, a user will interpret a 'lock' to mean security. Wouldn't the solution be to only display the lock when the link is actually encrypted (plain text doesn't count as encryption)? Alternatively, replace the 'binary' lock with an analog scale indicating an effective key length (in bits) as an indicator of security level. Perhaps have the bar change colour when it passes a level of security strong enough to be considerd as 'encrypted'?

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?

Re:Defeats the purpose of SSL?

[realdpk]

In Mozilla 1.5a at least, in preferences under SSL, in the tab "Extra SSL3/TLS" the only two options that are labeled "No encryption" are deselected for me - I am certain I didn't do this myself, it was probably that way stock.

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

Best strategy for fighting this

[kongjie]

...is probably a low-tech one.

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

[Anonymous Coward]

If you doubt the authenticity of an e-mail from, say, American Express, just visit the site as you usually do, through a bookmark.

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

[techno-vampire]

I did tech support for an ISP until my call center was closed. We used to tell people that we'd never send them an email asking for login or credit card info, and that any message doing so was bogus. Of course, this lead to the occasional luser that wouldn't tell us their password when we needed to ID them because they couldn't see the difference between somebody sending them an email asking for their password and them calling us and our needing to ID them before changing something on their account. Most of the time, just pointing out that they'd called us, so they know who they're talking to rather than an email that they don't know who sent did the trick, but there's always a few people that refused. I never minded because not doing something is much less work and I could go on to the next call faster.

Re:Best strategy for fighting this

[vanyel]

I tell my users never to give their password to anyone *including* me (it's amazing how many just automatically send it). If I need to verify someone, I use caller id. It's not perfect, but it's "good enough" for my environment.

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.

Open SSL contributes to the problem...

[LostCluster]

Unfortunately, the open-source SSL systems contribute to this problem...

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

[devnullify]

You can create self-signed certs just as easily with Microsoft's certificate managment tools.

Users are conditioned to click Yes/OK to *any* dialog box that gets in their way, without reading it.

Re:Open SSL contributes to the problem...

[rekt]

An SSL certificate is just a (hopefully long) bit-string formatted in a certain way. I don't see how the fact that anyone can generate a long bit string to a well-known format contributes to the insecurity of SSL.

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:

Uncomprehending users End users don't understand PKI, for the most part. They don't understand the implications and assumptions which underly the system. By default, the X.509 architecture means that they end up implicitly trusting the root Certificate Authorities installed by their browser provider (which means they are implicitly trusting their browser provider and we know who that usually is...) Untrustworthy Hierarchy in X.509 The hierarchical nature of SSL's PKI means that even for those people who understand how it works, they are still strongly compelled to trust some large CAs. Sadly, many of the large CAs have abandoned their ideal role of actually establishing and verifying identity. They seem to now see themselves as yet another middleman who deserves a cut of any transaction without providing a service. How many times have you seen a CA whose policy for establishing identity amounts to "Please send us a fax on company letterhead" ? Who can't send a fax on "company letterhead" these days?

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

[pacman on prozac]

Fortunately, the open-source SSL systems also provide a solution to this problem.

Look here

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

[FiberOpPraise]

Don't worry, I make sure to type all of my URL's now including onces such as:
http://slashdot.org/comments.pl?sid=99888&threshol d=0&mode=thread&commentsort=0&op=Reply
Sometimes they take a while but it pays off!

an old timer i know

[Spetiam]

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.

Re:Legislation

[pookie_jurd]

Why isn't there a law against going out and killing people? Then these people "would not be tempted to pull such a stunt, since they would know that there would possibly a lawsuit/jaintime behind this..."

Re:It doesn't matter - but it does

[LostCluster]

I think the problem is that the Internet is using all sorts of technologies that allow things to be misrepresented... the basic IP protocol was written in an era where every other host on the Internet could presumed to be somewhat friendly, since everyone was either part of the US Government or an academic who was affiliated with a univeristy. Any abusers of the Internet could be identified and thrown out.

Now, absolutely every weakness is being found and exploited. The Internet just wasn't designed for this...

Re:Legislation

[nacturation]

I think you'd be better off asking why the existing laws against fraud and deceptive trade practicees aren't enforced.

Meh

[Xenographic]

Sad thing is, it's getting harder and harder to be able to give them basic advice.

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:Legislation

[yasth]

It is illegal under current laws (Wire fraud, misrepresentation, etc). The hard part is catching them, also there are jurisdiction issues. I mean really there was no need for new murder laws when guns came about. This is fraud, and oftentimes theft plain vanilla crime, but with a new delivery method. Also to be honest, most DAs would probably rather go after child porn then something so unlikely to get there names in the paper as white collar credit card scams

Anybody got a list of "BAD" Cert providers?

[nlinecomputers]

Ok if the bad guys can get certs from slime certificate houses then I can delete said certificates or mark them untrustworthy. Will I then get warning about the certificate being invalid and that should prompt me to take a closer look.

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?

[Nintendork]

The way it works is this: Your web browser has a list of trusted Certificate Authority (CA) servers. Any certificate that has been signed by them is automatically trusted to be secure and you don't get any prompts. If a certificate has been signed by another CA that your web browser doesn't have listed as a trusted CA, then you get prompted with a warning outlining the problem. What this article is basically saying is that if the encryption method employed by the web server is "Plain text", then your web browser won't warn you if the certificate was signed by one of those CAs that isn't in your list of trusted CAs. Anyone can be their own CA by issuing a self-signed certificate, removing the need for another entity such as "Slime certificate houses."

-Lucas

Re:Anybody got a list of "BAD" Cert providers?

[Nintendork]

Allow me to correct myself. I hadn't read the story yet and other posts led me to believe that phishers were issuing self-signed certificates. In this case, there is no certificate involved. Plain Text is one of the SSL encryption methods and when used, it doesn't use a certificate. The answer here would be for web browsers to warn the user that the connection is not secure or to reject plain text SSL altogether.

-Lucas

thanks scammers!

[BinaryJono]

finally an affordable way to use SSL certificates on our sites without "unsigned certificate" warnings or having to pay Verisign $895/year for each certificate!

Re:thanks scammers!

[ddent]

Please, please dont do that... that is purely evil. You give the impression to your visitors that you are securing their data, and then you don't if you do it that way. Also note that you can get a certificate every bit as good as the ones that VeriSign issue for much less than $895/year these days - look around a bit more.

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

[MajorDick]

"One of the SSL encoding methods is 'plain text'," I could have had my own certs with no browser barking for all this time ? Damm Years ago I tried the "Please install my certificate thing" It worked for a while but stupid customers kept asking questions (I am sorta joking) Now I find out I could have configured my server to avoid many of these authority issues ?

Re:Legislation

[Anonymous Coward]

Oh, it's illegal. The problem isn't whether or not this sort of thing is legal. It's finding, apprehending, and punishing the offendors that's the hard part.

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:

1. How do they know whether that host is a willing or unwitting party to the fraud?
2. How do they prove it, if it's willing?
3. If it's unwilling, how do they track down the perpetrator?
4. Assuming they can track down the perpetrator, how do they take said perp into custody?

It just so happens that the host is my own, and I'm listed as the registrar. Alas, alack, there is no extradition treaty between Mordor and Grand Fenwick, so all they can do is shout threateningly across the ocean at me, whilst I mock their puny and powerless attempts to bring me to justice.

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.

Look for the cute little lock!

[fm6]

And even if they do... SO WHAT -- gee your data is encrypted for the 100ms it travels between your PC and the web server.

That 100ms is long enough for a packet sniffer to grab your credit card number. But that's not why they're playing up that lock icon. They're trying to give people a simple way to distinguish legitimate sites from phishing sites. Not a very good way, of course, but I'm not sure I know a better one.

Re:Look for the cute little lock!

[Frymaster]

They're trying to give people a simple way to distinguish legitimate sites from phishing sites

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.

They just want to jam.

[Jasn]

I for one object to blaming all this on Phish. I'm sure that Mr. Anastasio et al. have no connection to this illegal and extremely harmful activity.

Re:Legislation

[alfredw]

most DAs would probably rather go after child porn then something so unlikely to get there names in the paper as white collar credit card scams

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.

Mozilla has a warning for this...

[Anonymous Coward]

It defaults to poping up a warning that you are using low grade encryption. Plain text qualifies!

Re:Mozilla has a warning for this...

[dmeranda]

Actually the NULL encryption algorithm is by default completely disallowed...it is not considered low-grade encryption, since it is in fact NO encryption.

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.

you are misinformed

[wotevah]

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.

Is there a page with a demo of the technique?

[kasperd]

I'd like to verify if my browser is vulnurable.

EXTREMELY IMPORTANT CRITICAL ACCOUNT UPDATE

[Anonymous Coward]

I think the site you were looking for is here.

The lock is not important

[thedillybar]

Many websites now use an insecure connection (HTTP) to shop, add items to your cart, and process your checkout. Even the final order form page is sent over HTTP, but the form POST is set to use HTTPS.

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

[windside]

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:The lock is not important

[BZ]

> Even the final order form page is sent over HTTP, > but the form POST is set to use HTTPS.

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.

Re:The lock is not important

[James_G]

The "View partial source" functionality is also available as a plugin for IE. Download it here.

Enjoy!

Re:The lock is not important

[James_G]

Oh, and I should note.. it says that the download is only for IE 5.x, but it works fine in IE 6.0 as well. YMMV.

Re:Invading SSL can't be good

[sirReal.83.]

I don't care if you're using 2048-bit encryption to purchase that new GeForce - if SuperDealUpgradeStore so much as leaves the wrong port open on the firewall or uses a simple password and doesn't check logs, you're hosed.

As the saying goes: "Security is a process, NOT a product."

Re:'splane it to me Lucy

[Vegeta99]

Well, these 'phishers' would make up a url.. something like http://www.eonlinebank.com (and then, insert a bunch of spaces)@theirsite.com/

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Tip for Safari users

[Concerned Onlooker]

I couldn't find a way to view the site certificate in Safari when the padlock was showing, but if you have the Debug menu enabled you can go to Debug-->Security and set it to perform strict certificate checks. The default setting was "Allows expired root certificates."

To enable the Debug menu see this tip.

Re:It doesn't matter - but it does

[jadavis]

Interesting post, but I'm glad it wasn't designed to protect people against hostile hosts. If it was, we'd probably not have the internet as we know it today. Somebody would have raised a scare early on, and the government would have heavily regulated it.

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.

Every UI I've seen for SSL, is lame

[Sloppy]

The way most (all) browsers handle SSL is lame. There is no effort to inform the user what is really going on. Ok, maybe that's because the concepts are nontrivial, but the whole "lock icon" thing is beyond dumb, and just creates a false sense of security.

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

[SuperKendall]

The whole text/SSL thing is very disturbing, I thought I knew quite a bit about SSL having generated my own keys and installed certs and done some other things, but I had never found this dark corner.

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.

Enough is enough

[October_30th]

This is not fun anymore.

Spammers and virus writers/blackhats have joined in an unholy alliance and scammers like the ones in this article are running their schemes apparently with impunity.

Existing legislation has failed mainly because it is national and not international like the net itself. Technological means have failed as clearly shown in this article. If encryption/authentication like SSL won't work, then what will.

The dream is gone. The freewheeling internet from the late 80s and early 90s is dead and will never come back. The net can no longer remain both useful and unregulated and I will certainly opt for the usefulness over unregulation.

And no, before someone starts bashing Microsoft, running Linux won't save you. This is not a technological problem. Even if every computer in the world were running free software, the users would be the same. Yes. Those who run as root and click on every goddamn mail attachment. This is a social problem just like ignorance of the general population, scamming and vandalism are in the real world.

So what to do? Well, if the problem is the same as in the real world, use the tools we already have for controlling travel, gun ownership or who gets to drive a car or practise a profession. Age limits for net access, controlled net hardware (punishments in the same class as dealing "class A controlled substances"), tightly controlled licenses for running a business on the net and most of all a compulsory international e-identity (smartcard/bio authentication; equivalent of a passport) without which you cannot even access the net.

Re:Enough is enough

[meringuoid]

So what to do? Well, if the problem is the same as in the real world, use the tools we already have for controlling travel, gun ownership or who gets to drive a car or practise a profession. Age limits for net access, controlled net hardware (punishments in the same class as dealing "class A controlled substances"), tightly controlled licenses for running a business on the net and most of all a compulsory international e-identity (smartcard/bio authentication; equivalent of a passport) without which you cannot even access the net.

Interesting. So, you want really heavy, hardline controls on the internet - draconian regulations about who can do what, in just about every aspect of net existence. And yet...

Pro-SPEWS? Welcome to my foe-list.

You don't like people publishing a list of ISPs that harbour spammers and suggesting that it be used for email blocking.

Does this strike you as inconsistent in any way?

Re:What a scary world we live in

[NerveGas]

Hopefully the technological divide will dimish before a major financial catastrophe occurs

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 switched! That's right, very, very few. Most people just go back to the "comfort zone".

steve

Other limits of current SSL implementation(s)

[Beryllium Sphere(tm)]

You don't have a real PKI (public-key infrastructure) unless you've got some way to revoke compromised certificates.

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)

[scrytch]

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.

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

Better, just change one of the existing CA entries to use the same name and a different server and cert. Even hardcore cypherpunks aren't likely to catch something like that. Ultimately the answer is going to have to be loss mitigation and harm reduction: it'd be nice to see some technology solutions (or at least assistance) applied to the pessimistic assumption that WHEN your data IS compromised at some point, there's some help other than suspending, scrubbing, and possibly having to get a brand new digital identity.

Showing once again why Javascript is a bad idea...

[Ed Avis]

From the article:

A technique called visual spoofing offers another method to present a "lock" to visitors on a Scam phishing site. The technique alters the user interface of the web browser, substituting images for parts of the browser interface that would normally help users detect the fraud. Javascript links launch a new browser window without scrollbars, menubars, toolbars and the status bar - which allows the scam artists to substitute a fake status bar containing the URL for a legitimate site, along with an image of a "lock" indicating a secure SSL site.

The evolving strategies of phishing crews underscore the need for continuing consumer education on detecting deceptive URLs, web sites and now, to discern authentic SSL certificates and relationships as well.

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.

Funny but you have a point...

[WebCowboy]

Cuz if the guy is a slimeball who found your wallet lost on the street and decided to have some fun on you it's all to easy for him to do that. Whenever I use my credit card in person I'm never asked to prove my identity. One time awhile back a boss I had asked me to fill his truck and use his card and to call if they gave me any trouble. They swiped the card without even looking at it.

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

[Johnny Mnemonic]

You might be interested in the one-time use Credit Card that I have. From MBNA, 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:'splane it to me Lucy

[a24061]

And as long as joe average user falls for these scams, I can feel secure knowing that there are much easier targets out there.

It sounds harsh, but that's basically the theory behind preventive security for your house or car.

Re:Bollocks

[bryceh1]

DING! DING! DING! The most secure of systems can be brought down by a simple configuration error. TLS/SSL is certainly not to blame here. Instead it's individuals'/vendors' misunderstanding of the TLS/SSL protocol. First let's set one thing straight, it is not encryption at issue here - it is *authentication*. Plain-text SSL encryption has nothing to do with the vulnerability per se. The real problem is the browser's allowance of a "bilaterally anonymous SSL connection". In other words the spoofer's SSL server requests that an authentication handshake is not necessary during the SSL negotiation protocol. That's certainly an allowable configuration option according to the TLS IETF specification, but just because it is defined does not mean it should be an allowed, especially by default. But guess what, that's what the browser vendors have apparently done. BAD! And so easy to fix (about six words in OpenSSL). But this also demonstrates a flawed manner of thinking about client-server trust in WWW computing. Often people assume that SSL protects your "sensitive data" from being pilfered. True in a sense (of course that data ends up sitting plaintext in a non-secure database somewhere overseas), but you can utilize that very same encryption with in a bi-laterally anonymous SSL connection, or in other words SSL/TLS encryption has almost nothing to do with certificates. The problem being missed is one of trust. SSL/TLS (in good practice) should be used to create an encrypted connection with a *trusted party*. What business does a browser have connecting to an anoymous server with SSL/TLS, it completely defeats the purpose of it? The UI fakeouts aside the one, true way to fix this is to ensure that vendors configure their browsers to always require a valid certificate from a server when utilizing a SSL/TLS connection. It would be nice to provide someway to disable this feature for us more security initiated users but the rest of the community would probably never care nor notice. It would also be genuinely nice if user's were educated by their browser during such security incidents. For instance, when the user is conducting an SSL negotation with a nefarious server that offers up a certificate signed by an unknown or untrusted Certificate Authority the browser should be prompt the user to read very carefully the consequences of accepting the server certificate, and why it's not being trusted in the first place - vague dialogues breed bad user actions/reactions and the user is no wiser having clicked a button to make the annoyance go away. In short, hey vendors, don't allow the browsers to ever make SSL/TLS connections with an untrusted party!!!

The article is incorrect

[jburst]

The article is full of crap.

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

[Gollum]

I tried to duplicate this, with no success using either of the abovementioned browsers.

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

[nagora]

It's good to have the data encrypted but the idea that the companies running the certificate issuing system are trustwrothy is laughable.

TWW

Misuse of Lock icon..

[slashkitty]

In a related note, you can put a lock icon on a web page with out using ssl at all. Take a look at the Chase Bank Homepage. They put a lock in the login box, making users think that the login box is secure, however, it's not completely secure because it's on an unsecured page. While indead, for most people, the login information will go straight to chase secure servers, it is possible to hack the users session. How? Easy, just modify the chase.com homepage before the user gets it. Either through DNS, proxy or xss. Whatever you do, don't login to your bank account from the chase homepage.

Bruce Schneir: Ten Risks of PKI...

[pjkundert]

Bruce Schneier has a very interesting article about the "Scam" that is the Public Key Infrastructure.

Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure

This is probably just the first of many security problems resulting from the fact that these PKI issuing authorities are more interested in Money and Marketing, than in actual security...

Limited cards also available from Citibank

[amyandjake]

This is also available from Citibank, I have one of their cards. It works exactly as you say, great for online transactions.

How do banks do it?

[Kiyooka]

Pretty much all major banks allow for internet transactions, which I'm assuming are virtually 100% secure. I have no idea how they do it, but why can't we implement their type of protocol/security system throughout the entire internet and disallow all other types of transactions? Is it too expensive or slow?