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?

[gilrain]

Maybe as an option, but for god's sake don't force the thing. I, and many others, *do* look for the lock and would prefer to not have some image ruining the look of the page.

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?

[Anonymous Coward]

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?

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?

[asmellysock]

Sometimes individual entry fields can be https without the page on which they are appearing being secure. For example, go to the bankone web site. The login field has a little lock next to it drawn by the site itself (not the browser).

Re:Do people even see the lock?

[Pieroxy]

It might be interesting to have some usability folks do an eye movement analysis

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?

[fodi]

Can somone please explain the implications of using plain text SSL encryption? I'm under the impression that 128bit or above, non-reversible encryption is, in all practise, unbreakable. Also, isn't it common practise to encrypt sensitive data stored in a database with the same level of security? So, if someone does snif an encrypted packet, or access your database, how can they actually make use of the data they steal?

thanx

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?

[snarkh]

Or, worse yet, the guy who has the credit card in his wallet goes out and buys something!

What a disaster!

Re:Do people even see the lock?

[Anonymous Coward]

Why? The problem is not that you can't check whether a page is secure, it's that the average user doesn't bother to do it.

The people who want to know whether a page is secure already have an easy way to do it. All you need to do is look down on the status bar and look for the lock icon. It's the people that don't know that they should be looking for that in the first place that causes a problem.

What makes more sense, IMHO, is to warn users about submitting data through unsecure forms. If they try to do so, pop up a warning telling them that it's not safe... Internet Explorer does exactly that. But then people just check the box that says "Don't show this warning again." and then forget about it. Maybe the dialog should not be so easy to disable.

However... none of this is really the root of the issue. Users' inability to distinguish between trustworthy and non-trustworthy sources asking for their information is the real problem.

Re:Do people even see the lock?

[Anonymous Coward]

Your voice of reason has no power here! Go back to the shadow, flame of Udun!

Re:Do people even see the lock?

[Anonymous Coward]

In Mac OsX Apple already has away of short displays of reminder info that could well be used in safari to make it clearer when secure and not secure.
That little ghost square that pops up for Volume, or eject.
having those for lock and unlocked web sites, nice and obvious and short lived reminder.
it Could even have the same bar scale as volume to indicate security level.

Re:Do people even see the lock?

[Anonymous Coward]

lol

Re:Do people even see the lock?

[colinleroy]

plain text SSL is just to authenticate the site, not to protect the data I suppose... (retarded? maybe..)
As you can see in the article (the what? "article"... what would be that), scammers use plain-text SSL connections just because such connections don't use certificates at all, which is "useful" as it doesn't trigger certificate alerts.

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?

[Felinoid]

Are you listening programmers?
Yes. I understand. Obveously we have to go out of our way to make sure the user can't disable the alarm by compleatly restricting the computer in every way.

What? Did someone say "Make it not obnoxous" No I couldn't have heard that. Nobody would suggest that. Naaah.
*Fingers in ears* Na na na na I can't hear you.

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?

[andy landy]

The whole certificate system is screwy anyway, the "Padlock" only proves that the *connection* is secure, (Prevents "man-in-the-middle" attacks). The host at the other end isn't guaranteed trustworthy.

Do you honestly trust Verisign et al to judge whether a website is trustworthy or not? I certainly don't. SSL certificates prove absolutely jack about the site in question, it's just a way for the CAs to make a quick buck.

Anyway, my rant is over. I'll go have a cup of tea and calm down now. :)

Re:Do people even see the lock?

[essreenim]

Or possibly still even worse yet, the user sees the lock and thinks "hmm, the server is locked, I better try an unlocked one so I can get in".

THe nthey buy on an insecure scam server, content in their ignorance that they have successfully puchased their Bush'04 t-shirt!

Re:Do people even see the lock?

[JacobO]

That would be the site's designer sending you comforting signals about the site. In fact, you're taking it on their word that your data will be submitted via a secure connection (or that "my data is safe"). This same trust is exploited by those who might also use text-only certificates. It's all about the perception of security. If you see the lock, you feel safe; assuming you know what it means, some would give their CC details out on a website without any thought.

It is a good idea to apply psychology in areas like this, I may steal the idea for my next e-commerce site. (Hey, I meant the little lock icon, not the abuse and criminal behaviour!)

Re:Do people even see the lock?

[Anonymous Coward]

Something even scarier;
I once worked at a mass mailing company and one of our clients sent us thier mailing list as an attachment to an unencrypted email. This is standard actually except that along with the address they included the CC# + expiration for every single one of the 250,000 people on the list!
Never mind if it had been intercepted, atleast 10 people had access to this file in our company alone.

BTW... anyone want to buy some CC#'s...?

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?

[zero_offset]

5:50 AM... Shouldn't you be outside waiting for the school bus?

Re:Do people even see the lock?

[Anonymous Coward]

Please, cut the FUD, you can't do SQL injection on PHP anymore since about version 4. Anytime you type a speech mark or backslash in a GET or POST variable, PHP automagically sticks a backslash before it. It does mean that you need to do a stripslashes() anytime you echo back to the form something that was POSTed or GOT from the form. You can turn it off in the configuration file, but the default is to leave it on.

ASP is another matter, but it is only ever used by complete dickheads and any damage to an ASP server should be considered an improvement. If you use any software without reading the source code, you are an idiot. If you accept software gratis without reading the source code, you are an even bigger idiot. If you pay someone good money for software and they won't let you read the source code, your mother should have had an abortion.

By the way, some of the ".asp" pages you see out there are actually PHP, but masquerading as ASP in an attempt to appear more PHB-friendly.

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?

[Anonymous Coward]

Fortunately the ASP + PHP programmers know all about the hot beef injection.

Re:Do people even see the lock?

[T-Ranger]

SSH server key fingerprinting also pervents "man-in-the-middle" attacks. But generaly speaking people dont check the fingerprint on initial connection, and if/when it changes, don't check either.

(As implemented) SSL takes that one step further.. Not only are you sure you are sending data to the same place as last week (the key diddnt change), you are sure that who you are sending it to is who you think you are sending it to (name verified by a "trusted" third party). SSL probes something: that they are who they say they are.

But as for providing a measure of quality, no. And I doubt providing such a measure was even consitered a /potential/ function of CA back when this stuff was being implemented.

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

Re:Do people even see the lock?

[hattig]

There are all good ideas (apart from the flashing page borders, hehe).

Please suggest them to the Mozilla / Firefox team, Konqueror, etc. Use this Slashdot story as motivation.

I'd go for by default a simple padlock image (128x128) at 30% transparency (with both white and black in the image so that it shows up regardless of the background) with text underneath stating the connection attributes. i.e., the browser merely has to injects some CSS+HTML onto every secure page in the display.

A mouse cursor with a padlock is also a neat idea., and turning the text red in the location bar, with a padlock next to the favicon as well. Precede the title with "SECURE: " ...

and have a preference interface where you can disable these if you wish.

Re:Do people even see the lock?

[hattig]

of course, a fake secure page could fake the security padlocked image itself, hence the other two bits are nice to have in addition. Also why you'd want to be able to configure your own security image, or why you must at least be forced to choose from a small selection of images.

Re:Do people even see the lock?

[Cramer]

• But is the web server itself secure?

I can go one step further... does the vendor handle your sensitive data securely beyond the web server? One can expend significant energy in securing the transport and the end-points, but if the web server is, oh say, logging your credit card information to a file and emailing it to a distribution list containing "yahoo" accounts, what the hell's the point? Many years ago (several employers ago), I was alarmed to see CC#'s in the postmaster inbox... One of the customers (a news reader vendor) was doing exactly that. And that information is still on backup tapes to this day (of course, that tape is over a decade old and probablly not readable.)

I tend to stay away from on-line sites that's store my CC#. It's not a big deal for me to enter that number every time I purchase something. I can ensure the security of my use of the card; I cannot say anything about the number in a file at some yahoo store merchant... if they can read it, so can the hackers.

Re:Do people even see the lock?

[gnu-generation-one]

"Since several people have to be able to view all this info, I couldn't figure out a way to realistically keep it all secure.... would your book still apply?"

It's more difficult -- if someone has the ability to view the entire database, then they have the ability to leak or sell the database, that's pretty fundamental, and it's the same problem as DRM.

The book does have a few chapters on people adding data with the public keys of whoever's allowed to read each piece of data, but probably nothing you couldn't work out yourself. It's also got a fair bit on making a database so that you can't look up a particular record unless you already know some information about it, but that's more for people needing a 'view' of database statistics than for someone with the need to view every record.

If the client is on the phone when you need to access their record, then it's much simpler -- you just encrypt records using their name and password as a code, so when they phone and tell you their name and password, you use it to decrypt their record. That means that 'stealing' one password will only get you one record and not the whole database.

Some companies (AOL) have tried to use hardware tokens to help when lots of people need access to parts of a database which needs to be kept confidential. I don't know much about that, but assume that it fails if someone takes the database machine itself (which these other methods are designed to withstand theft of the entire database and it's root password)

I'm not a banker, but if you're even thinking about these questions then you're probably ahead of some famous internet banks as regards database security.

Re:Do people even see the lock?

[OhioJoe]

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

True that. Further, those who know and count on the validity of a security certificate are probably the exact same ones that wouldn't fall for such a scam. Those who would fall for it likely know nothing about secured certificates.

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]

Gah... I submitted this as HTML but slashcode interpreted it as plaintext and messed up the formatting somehow... sorry!

Re:SSL certificates in 2004

[ddent]

Uh, that AC was not me. And I already apologized for the poor formattting... kindly lay off :)

Re:SSL certificates in 2004

[ThisIsFred]

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.

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 doesn't make them competent or trustworthy. There needs to be ethics standards in place for these CAs. SSL encrypted web sites are the preferred way to do business transactions with mail-order companies. If there isn't some kind of trusted organization in place to enforce some ethical standards, it'll end up being like the stock market in the 1980s.

Re:SSL certificates in 2004

[Anonymous Coward]

Umm... non verified SSL certs? And you don't tell us whom?
Not even a http://cutandand paste.com/ur l?

Uh...

This slashdot right?
I am sure there are lots of home servers our there that would love to get a cert w/o having a corporation.

Re:SSL certificates in 2004

[andreMA]

Ever since the "Extrans" and "code" options were added I've found posting with HTML to be hit-or-miss as well. Ah, to be a beta-tester.

Re:SSL certificates in 2004

[ddent]

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 to individuals - instead of corporate documents we ask for personal ones (i.e. passport, driver's license, etc.).

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

Re:SSL certificates in 2004

[bentfork]

Slashdot and other OSDN sites can mess up companies. ( and home based webservers) AFAIK that is why you, myself and everyone else still reads slashdot.

I just like seeing dirty laundry... I cowardly admit it. ;)

I did look at your site... with a NPA of 604... you are good in my books... and $50 in any currency isn't that bad... ( aprox 2 months home internet access for me).

There is some Slanderous content on the page you linked to that helps me know whom you are talking about. ( left as exercise for the reader )

Re:SSL certificates in 2004

[Anonymous Coward]

Click on the lock? That can be beat. Make the bar with the lock a .jpg in a frame, and link the .jpg to another that looks like a real certificate.

Face it, there is no good way for a user to authenticate the bank.

Re:SSL certificates in 2004

[4of12]

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.

To me, this really seems to suggest that certificate issuance should include some more detail about the exact level and kind of trust that is guaranteed.

And, that browsers ought to be able to display that trust arrangement in a way that end users can easily understand.

Something along the lines of:

ezcertificates.com guarantees that this certificate from flybynight.com is valid and has posted a bond in the amount of $10.45 at First Cayman Bank.

Something in a sidebar to show this and maybe other details about the SSL connections would provide users with more of the information that they really ought to be paying attention to.

It looks as if some of this already exists, but you have to dig around and be interested to find it.

Security ought to be as convenient as possible (but no more so).

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)

Re:The short

[Idealius]

Flamebait +1

For fun.

Re:The short

[Anonymous Coward]

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.

Holy fucking marketing pap. Someone must have a machine that grinds this shit out by the ton.

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?

Re:Average Joe

[TwistedGreen]

Never insult religion on Slashdot. You will be modded down for "Troll" no matter how factual your post is.

Does that include Apple? Post anything criticizing anything Apple releases, be it MacOS X or the iPod or their silly one-button mice, and you will be instantly modded down no matter how factual it is.

That is evil..

[Sovern]

Considering the low level of understanding most users have, I think many more will fall for these scemes. We should all switch to the dark side.

Re:That is evil..

[Anonymous Coward]

The low-level users don't know anything about SSL or encryption etc. If these users are going to get duped into entering thier info they are going to wether it is SSL enrypted or not.

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

[Nogami_Saeko]

Ya... yet another reason I couldn't get my DNS entry away from verisign fast enough.

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

[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

Re:It doesn't matter

[smellystudent]

Can you explain that to my bank please?

Bank: This is soandso from Big Corp Bank calling about a personal financial matter, could you please confirm your date of birth and mothers maiden name?
Me: No. You called the contact number you have listed for me, I just answered my phone with my own name, you know who I am. However, I haven't got the foggiest who you are. Is there a number I can call you back on?
Bank: I'm afraid we don't accept incoming calls at this center.
Me: Neither do I *click*

Seriously, this is a bank encouraging their customers to give out their personal info to people who just call them up. Seriously clueless.

Re:It doesn't matter

[JoesRagingBileDuct]

What you shouldn't do is to give out your password on the phone when someone calls you...But if you call them, you know who they are. Who cares if you give out your password over the phone.

You have never read BOFH have you?

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?

[zeruch]

the entire point of any one technology these days seems to be to do something that will be eclipsed and/or circumvented by another technology in roughly realtime. ain't high-tech fun?

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?

[NutscrapeSucks]

Is it possible to disable these plain text certificates?

I just looked through Firefox and IE and don't see any clearly marked as "Plain Text". The only one that looks slightly funky is "NO LIABILITY ACCEPTED, (c)97 VeriSign, Inc."; "VeriSign Time Stamping Service Root"

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?

[jesser]

SSL has an authentication-without-encryption mode but no encryption-without-authentication mode? WTF?

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

Re:Defeats the purpose of SSL?

[Tim C]

I don't know if it's what you're looking for, but in Mozilla, go to Edit -> Preferences -> Security & Privacy -> SSL -> Edit Ciphers. On the "Extra SSL3/TLS" tab, the last two options are for authenitcation-only ciphers (and appear to be disabled by default).

Unfortunately, I can't see an equivalent in FireFox, and I don't know for sure if the Mozilla settings are what you're looking for either...

Re:Defeats the purpose of SSL?

[Tim C]

What's the use of encryption without authentication? You don't want anyone but the recipient to be able to read or change the data, but don't care who the recipient actually is?

The only time I can think that I'd use that would be when I am the intended recipient, eg encrypting data on my harddrive, or before mailing it to myself.

Re:Defeats the purpose of SSL?

[Spy Hunter]

This is a good thing. If you encrypt without authentication, the encryption is questionably useful at best because the connection is always vulnerable to a man-in-the-middle attack. At worst, providing this kind of mode that is known to be attackable could cause big problems if people assume it's secure (it's encrypted, of course it's secure, right? Wrong).

This is why SSH always asks you to verify the host computer's public key the first time you login and stores it for later connections. If it didn't, an attacker could come in at any other time you connect, impersonate the server and get your password. With authentication, the attacker can't impersonate the server and man-in-the-middle fails.

Re:Defeats the purpose of SSL?

[jesser]

Encryption without authentication prevents a weak attacker, who can watch the transaction but not modify it, from seeing your credit card number.

Re:Defeats the purpose of SSL?

[Anonymous Coward]

The only value left in SSL is encryption, the authentication part has been useless ever since browser manufacturers added Verisign as a root CA. Even the f**king mafia is more trustworthy than Verisign, so SSL authentication itself only changes "this server claims to be x" to "the least trustworthy company in the world claims that this server is x".

Useless authentication.

Re:Defeats the purpose of SSL?

[zero_offset]

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?

It breaks the "sandbox" concept we normally expect (or at least, hope for) from browsers, but there isn't anything inherent in "object orientedness" that would necessarily preclude modification of things outside the boundaries of a window frame (I don't think OO really applies to windowing-as-a-UI-experience except in a very superficial sense).

The problem is that the lock icon is doing double-duty, which is an old "no no" across the board in computer programming. It is being used to suggest both encryption of the communications link as well as authentication of the person at the other end. Possibly even triple-duty, as many users further interpret that as some kind of indication that the site at the other end is "safe".

In this case, there is no encryption (that plain-text mode they mentioned), and the authentication is useless -- they may be who they say they are -- but that doesn't really mean you should trust them.

Re:Defeats the purpose of SSL?

[ebrandsberg]

I just did a bit of research, and here is what I found:

Mozilla (at least 1.6) doesn't have the text encryption enabled by default

I can't even find a way to make MSIE 6 do the text encryption.

I forced a webserver to do only the text encryption and I couldn't connect to it with Mozilla or MSIE, so I can't see how many clients people expect to catch with this technique.

Re:Defeats the purpose of SSL?

[Turmio]

No, the entire point of SSL is not to encrypt traffic. Its point is to guarantee secure transactions between servers and clients. And that definitely doesn't equal to encrypted traffic between a server and a client, though this property belongs to the picture, of course. But more important is that you can be sure that you really are doing business with an entity that you believe you're dealing with. That's the whole point of certificates. A 3rd party certificate authority that both client and server trust issues a certificate to a company and by verifying the name and the validity of the offered certificate client can draw her conclusions if her transaction with the company is safe or not. This the ideal world situation, of course. Not many does this because they don't have a clue. And why would they have, this isn't an easy issue to understand and that's why browsers display those nasty warnings for you if there's some problems with the certificate and that's great. But the problem is that it's the makers of the browsers that decide on behalf of the user who's a trusted 3rd party and who isn't (yes you can edit the list of trusted CAs but is Joe Schmoe aware of that?) But the biggest joke is the whole CA system in use. Can I really say the entity behind innocent-looking, accepted-by-browser certificate really is trustworthy? The certificate was aquired from some South African company with hard cash (that eventually can lead to leisure trips to space for the Netscape-and-Microsoft-loving-thanks-for-trusing-u s masterminds behind the certificate business for instance). Does that make the owner of the certificate a good guy? The total security level of a system is the security level of the weakest link belonging to the system. In the current CA model we have four weak links (client, browser, CA and servee). Who do you trust (not)? Arg, rant overflow detected, system halted.

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

[RoundSparrow]

Yha, and domain typo squatters, etc.

Surfing was 'fun', now it has become a nightmare.

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

[platipusrc]

seriously...

And what's the point of SlashHot anyway?

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

[Anonymous Coward]

There's actually very few reasons that ISP tech support should need your password. My theory is that they only ask because they are using barbaric management systems and/or it's just part of their monkey-script. Either way it's bad policy.

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.

Re:Best strategy for fighting this

[pongo000]

Of course, this lead to the occasional luser that wouldn't tell us their password when we needed to ID them

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

[YetAnotherLogin]

And how do you know they weren't tapping your phone line and intercepted any of your calls to 911? You should've checked for that white van across the street before believing the 911 "operator".

</paranoid>

Re:Best strategy for fighting this

[Nogami_Saeko]

Seconded. If users need to be ID'ed, the proper way is either getting them to pick a short "PIN" number, or just use personal info.

Security needs to be tempered with "being reasonable". It is, afterall, an internet account, not access to a missile silo or something...

N.

Re:Best strategy for fighting this

[Anonymous Coward]

just use personal info.

Like, something only they would know?

Like their password?

Re:Best strategy for fighting this

[Anonymous Coward]

Don't be a dork. The admins should never ever ask for the password. If you can't figure out how to identify your customer, you're in the wrong business.

Re:Best strategy for fighting this

[Anonymous Coward]

And how do you know they weren't tapping your phone line and intercepted any of your calls to 911? You should've checked for that white van across the street before believing the 911 "operator".

I'm sure he knew, because he probably knew why he was being arrested and just wanted to mess with the police. I wished they'd just broken his door down. That would server him right. We don't need low life like this wasting taxpayer money for fun.

Re:Best strategy for fighting this

[Anonymous Coward]

So here's the plan then:

- get a list of past offenders who can expect a visit from the police
- wear police costumes, go to their house, handcuff them, put them in a van
- sell each of them to some horny-women camp.

*everyone* has to verify authenticity, even if you expect something to happen. The paypal scam works because a small percent of people expect such an e-mail from paypal.

Re:Best strategy for fighting this

[techno-vampire]

I tell my users never to give their password to anyone *including* me

At the ISP I worked for, customer's passwords were considered a form of ID. We couln't actually see the passwords, but we had a program that would tell us if what we'd typed in matched or not. When people were concerned, I told them, "Don't worry, I've lots of practice in forgetting passwords." A few let me know they'd change them after the call to be safe but most trusted me. The *only* time I would ask for one is when I was on the phone with a customer and then only if I needed it either as ID, or to help with a password error issue; I never asked for one to be emailed. Not only was it good sense, it was company policy.

Re:Best strategy for fighting this

[techno-vampire]

Please do everyone a favor and tell us the name of the ISP so we can avoid doing business with this company.

Only if you'll tell me the name of the company you work for so I can avoid doing business with it.

Passwords for ID are fairly standard at ISPs as far as I can tell. Much safer than a mother's maiden name, as your brother or sister can't fake their way into your account. Yes, there are other safe ways such as credit card numbers and we used them too. Alas, there were times, such as when a member paid by check, that there was nothing else we could use. The important distinction is that when I asked for a password the callers knew they were talking to their ISP because they had called us. We never called or emailed and asked for a password.

Re:Best strategy for fighting this

[vanyel]

I think that's a really bad policy because it trains the users to give out their password to someone they think is the ISP which makes them very vulnerable to social engineering. I can see the ID value, but there needs to be a better way, maybe some sort of challenge response system, though that would be hard to implement in a simple way. And of course, it is totally useless in the most common case where you want to validate that the user is who they say they are: when they've forgotten their password and need it reset (which is one reason why I also strongly recommend that people never save their passwords and let the system remember them).

Re:Best strategy for fighting this

[techno-vampire]

I think that's a really bad policy because it trains the users to give out their password to someone they think is the ISP...

You just don't get it, do you? The customer calls their ISP for tech support. As part of this support, they need to have email removed from their box, their username changed or something like that. How can they not know who they're talking to when they placed the call? And I can assure you with over seven years exerience in this that people calling because they forgot their password and need it reset are not the most common reason for people to ID themselves. People wanting to change their billing method, delete email from the server, change their username or otherwise make changes to the account are far more common. And, without exception, they are the ones that initiate the call. There is no way that some phisher is going to hijack the ISP's (800) number and collect passwords.

Re:Best strategy for fighting this

[techno-vampire]

Let's say you call and claim you're having trouble downloading your email and your box is full. You say you want all the email in your box deleted. Now, as the tech you're talking to can't actually see your password, how do you expect them to do this without your password? (Knowing the password can also be considered proof that you have the right to ask for this.) I can guarentee that no ISP is going to give their techs the use of software that could do this without the user's password, because that's too easy to abuse. Also, if somebody wants to cancel their account, there's no easier way to ID them than the password and, if the cancelation takes place right then, no reason not to give it. However, a good tech won't ever ask for the password unless there's a reason to need it and I'll agree that most issues don't need it.

Re:Best strategy for fighting this

[vanyel]

Calm down now... I do understand the reasons for it, I just think it's just bad training for the users. Yes, they can trust the person when they called the ISP, but what happens when someone calls them and pretends to be the ISP and they're already used to giving their ISP their password? All I'm suggesting is that we need to see if we can come up with a better solution to the problem...

Obviously our experiences are different, and I admit mine is probably the more unusual --- I run a small ISP and most interaction is by email. The only phone calls I get are when email won't work for some reason, usually password problems.

Re:Best strategy for fighting this

[techno-vampire]

I spent over seven years working for one of the majors. I took calls, made call-backs and answered email, although the last was fairly rare. Part of our policy was making sure that callers knew both that it was safe to tell your password to the tech that you called, but not to somebody that calls you. This means that when making a callback we generally couldn't ask for passwords, but that wasn't a problem. Callbacks were made if a tech couldn't solve the member's issues and needed help and if asking for a password would have done the job, there'd be no reason for a callback.

Re:It doesn't matter - but it does

[RoundSparrow]

I don't agree... It does matter. There are those of us who still use email, despite the spam (and phishing that this story is about).

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 password

Fraud and crime sucks no matter what part of your life. Don't just accept it. Yes, things are not what they used to be on the Internet... it is the job of the geek to help educate the masses and to help track down the as*holes.

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

[Anonymous Coward]

Well, I'm a user, and I'm not buying anything from you if you don't have a real certificate.

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

[PacoTaco]

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.

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

[timmarhy]

What and the propitery ssl servers don't suffer from this? give me a break. the fact is ssl certificates from vendors are worthless, it's just revenue raising scam and provides no extra security to users. the POINT of ssl is encrypted data transfer, not these hokey popups

Re:Open SSL contributes to the problem...

[rekt]

What you're describing begins to approximate the Web of Trust. But why approximate and not go all the way?

Why should each CA have the same trustworthiness value to every user? Joe could think that Verisign was the best thing since sliced bread, while Maria might want to give them a low score, and instead might want to trust CAcert.org more highly.

Furthermore, why relegate trust just to official "Certificate Authorities"? If i know that my brother will do a good job verifying identities of organizations that he deals with, why can't i choose to trust him for these tasks as well?

Once you start to distribute the responsibility for certification, you are building a web of trust, in which each entity can both certify and be certified, and the middlemen/brokers/leeches we use today as CAs would be forced to actually do identity validation or become irrelevant and useless.

Of course, this all depends on every user knowing what it means to "trust a certificate authority"...

And it depends on web site admins not just wanting the "least hassle" when it comes to getting their SSL identities signed.

Re:Open SSL contributes to the problem...

[doorbot.com]

End users don't understand PKI, for the most part.

<poor attempt at humor>

Congratulations, you have won the "Understatement of the Week!" award. Note that this being slashdot, your reward may be revoked at any point in time for any reason, and by any poster. This award is non-transferrable, but may be redeemed for Disney Dollars. On the upside, as long as your award is valid, expect to be invited to Fark photoshop contests, among other sought-after perks.

Re:Open SSL contributes to the problem...

[PacoTaco]

Let me clarify my idea a bit. I was thinking of something along the lines of a scale from 1 to 10, where 1 is "untrustworthy," 5 is "trustworthy," and 10 is "extremely trustworthy." All of the trusted root certificates would default to 5 (or whatever), and it would be up to the user or site administrator to adjust the values if they wanted. Most end users probably wouldn't care, but those who did would be able change these settings and receive the appropriate notification via a browser icon. This is a quick and easy modification that could be done without changing the current system.

I agree that the trust web idea is pretty cool. However, there's something to be said for being one step removed from the certificate authority, especially for financial transactions (and regardless of your trust architecture).

Re:Open SSL contributes to the problem...

[Have Blue]

Plus, on most browsers I've seen, there is no "cancel and leave site" button, just "OK" . All the dialog says is that the cert is not from one of the major authorities and some vague instructions about making sure the domain is who it says it is- a task that your average nontechnical user has no idea how to accomplish if he even knows what that message means.

Re:Open SSL contributes to the problem...

[kistel]

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

IMHO the problem is that there is no distinction between the "good" and "bad" CAs (e.g. in the EU: conforms to the EU directive or not). This will be really interesting when you want to use some legal background behind eelctronic signatures.

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

It suffers from one serious drawback though: it has no revocation information. If your key pair is stolen, you are pretty much doomed. There is no infomation on whether your key is still yours, and if not, from what point of time?

Average end users don't care about HOW things are done, they just want a reliable infrastructure. Th problem is that there's no such thing if you don't care about the details...

Re:Open SSL contributes to the problem...

[rekt]

i see what you're saying, and it makes sense. It's currently too difficult (and not granular enough) to indicate your levels of trust in a given certificate authority. Mozilla (for example) will allow you to modify your list of root certificate authorities yourself through the "Privacy and Security|Certificates" pane of the Preferences dialog. But you can only add or remove CAs wholesale (indicating "trust to identify websites"), you can't score their trustworthiness.

To make any such scoring scheme work, you'd need some good way of calculating the "accumulated validity" of a visited site's identity, based on the trustworthiness scores of the signing CAs. And you'd need a good way to report that back to the user.

GPG's implementation of the web of trust is slightly more granular than Mozilla's (but not much!). For each key, you can indicate a level of trust in that user's ability to do adequate identity validation: none, marginal, or full. (you can also choose "unknown").

A key's stated identity is only considered fully valid if enough other keys have signed it (by default, "enough" is defined as 1 fully trusted key or 3 marginally trusted keys); But GPG only counts keys that are within 5 hops from the user (this parameter is also tunable to suit your paranoia). So this is a method of scoring "accumulated validity", since it can also report "marginal validity" (e.g. if only 2 marginally trusted keys have signed it).

So, a system like you describe exists! it's not as fine-grained as you proposed, but it's more fine-grained than the existing X.509 implementations in popular web browsers.

About your last point: why is the "one step removed from the CA" useful when the declared root CAs aren't necessarily trustworthy themselves? It's only a useful metric if you are sure that you really do trust the CAs, which i think most people only do implictly.

And many big sites aren't even "one step removed from the CA". Using mozilla's default CAs, https://www.microsoft.com/ is 3 steps removed (OK, that might be a bad example). But browsers make it fairly inconvenient to see how many levels of signing authority are used, and i've never seen anyone inspect the length of the cert chain before deciding a site was secure.

Re:Open SSL contributes to the problem...

[Anonymous Coward]

Mod parent up!
That is exactly correct, I trust self-signed certs more than I trust the ones from the CA vendors. Many people here don't trust Verisign, I don't see a reason to even use them since they don't provide what they were supposed to - a chain of trust. The distributed, self signing and peer, circle of trust seems more reasonable and useful

And I know it is not relevant here but the article is about the lock is "turned on" without any cert pop up on the client asking if you trust so-and-so. It seems to be a minor part of the overall phishing schemes and I thought I read sometime ago about a method to install non-plain text certs (possibly using javascript?) without generating a pop up when I was research some cert issues for a Java Web Start project I was working on.

People have been using pretty persistent, varied and sophisticated methods to try to spoof the e-gold site for sometime which used turing numbers and explicit warnings to check for the proper URL _and_ the lock before entering your passphrase (which has a good minimum number of characters), etc, etc and what do you know? people still get taken.

Part of the problem is that https combines the cert trust functions with the network encryption functions - there is no reason we couldn't have a connection oriented dynamic encryption standard for http that doesn't use certs.

Re:Open SSL contributes to the problem...

[rekt]

It suffers from one serious drawback though: it has no revocation information. If your key pair is stolen, you are pretty much doomed. There is no infomation on whether your key is still yours, and if not, from what point of time?

You can generate revocation certificates in the web-of-trust model just like you can with X.509, can't you? There's still the issue of how you expect to distribute the revocation cert should you need to, but those can be distributed through any channel (even non-secure ones) since they should be effectively un-forgeable. Is there something more to a CRL that i'm missing?

As far as figuring out whether a signature is valid given a known-revoked cert, the web of trust does require that signatures be timestamped. But a malicious agent with a copy of a compromised key and root privileges somewhere (to reset the clock) could create bogus signatures with bogus timestamps that would look valid.

Doesn't X.509 have the same flaw? It seems that you shouldn't trust any signatures from a given key (no matter what the signature timestamp) if the key is known to have been revoked, under any PKI trust model.

Average end users don't care about HOW things are done, they just want a reliable infrastructure. Th problem is that there's no such thing if you don't care about the details...

All too true, sadly.

Re:Open SSL contributes to the problem...

[Anonymous Coward]

So? The problem is not viewing the site, you can go on view it with no problems. It's only when you enter your credit card info it really matters if you trust the site. So, the message box is not some kind of "are you sure", it's just a warning to NOT enter your cc number unless you trust the site.

Re:Open SSL contributes to the problem...

[kistel]

Is there something more to a CRL that i'm missing?

Not much; you are probably aware of OCSP, but the basic idea is the same there.

As far as figuring out whether a signature is valid given a known-revoked cert, the web of trust does require that signatures be timestamped. But a malicious agent with a copy of a compromised key and root privileges somewhere (to reset the clock) could create bogus signatures with bogus timestamps that would look valid.

I wouldn't call this timestamping, then (as per "using some reliable third party to prove the time of something"). This way it provides no additional security at all.

Doesn't X.509 have the same flaw? It seems that you shouldn't trust any signatures from a given key (no matter what the signature timestamp) if the key is known to have been revoked, under any PKI trust model.

Using the CA model you should. If the signature was created before the revocation (proven by a timestamp), then you could accept it. If there's no timestamp, then you shouldn't, but the decision is really up to you.

Forgive me if I'm offtopic.

Re:Open SSL contributes to the problem...

[PacoTaco]

To make any such scoring scheme work, you'd need some good way of calculating the "accumulated validity" of a visited site's identity, based on the trustworthiness scores of the signing CAs.

Yeah, I hadn't thought that through. I suppose a lot of shady or careless companies get their signing authority from someone else's root certificate.

So, a system like you describe exists!

This happens to me all the time. Apparently I'm good at design but terrible at research. :)

About your last point: why is the "one step removed from the CA" useful

I suppose I should clarify what I meant by that. If you look at the certificate path for a site like E*TRADE, everything is signed by Verisign even if it isn't done directly from their root certificate. I guess I'm saying that some users may not feel as confident about a certificate trusted by a friend of a friend that they've never met compared to a gigantic, "respectable" corporation. I suppose this perception could change if signed/encrypted email really takes off and more people get comfortable with the technology.

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.

Re:Open SSL contributes to the problem...

[rekt]

Using the CA model you should [trust the signature]. If the signature was created before the revocation (proven by a timestamp), then you could accept it. If there's no timestamp, then you shouldn't, but the decision is really up to you.

<veering even further off-topic>

i thought one of the main uses of key revocation is to announce a key compromise.

If the CA's private key was compromised, then what's to stop the attacker from forging signatures with timestamps prior to the revocation date? Is there some ultra-reliable third-party time-granting scheme? Does a parent CA (presumably with a non-compromised key) need to sign off on the cert as well to validate the timestamp? If that were the case, why bother with the intermediate CA at all? And what if there are no parent CAs (such as when the root CA is the one doing the signing in the first place)?

It seems like the same flaw as in the WoT model to me, but i'm probably missing something.

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!

Re:Microsoft Has Got You Covered

[Anonymous Coward]

For those of you who are lost...
New IE Bug Hides Real Site Address
And Microsoft's response:
Microsoft Advises to Type in URLs Rather than Click

Re:Microsoft Has Got You Covered

[Anonymous Coward]

The problem you are describing has been resolved in a patch.

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:an old timer i know

[snarkh]

Yes, and I prefer to stay home as it dramatically decreases the probability of a heavy home appliance falling on my head as I walk under a window.

I also prefer candles as it it decreases the chance of being electrocuted.

Re:an old timer i know

[Anonymous Coward]

Right. Tell him to not use ATMs either, unless he is able to spot the difference between a real and false-fronted IBM 30803 machine.

Re:an old timer i know

[Compuser]

Well, I consider myself more or less clueful but
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's
ATMs whose locations are specified in you bank's
brochure or ATMs located physically inside a bank
and branded by that bank.
Never use your credit card abroad except to withdraw
money from a reputable bank like Citi (for US people).

Re:an old timer i know

[Anonymous Coward]

and you're a fucking moron. the grandparent said nothing about ludditism, you fucking cunt-faced troll

Legislation

[dysprosia]

Why, oh why isn't there legislation to make this sort of thing illegal? Phishing is basically fraud, and if there was a chance that some action could be done, then these phishers would not be tempted to pull such a stunt, since they would know that there would possibly a lawsuit/jailtime behind this...

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

[nacturation]

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

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

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.

Re:Legislation

[TykeClone]

And it should be a capital crime.

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.

Re:Legislation

[techno-vampire]

set up a fake website at http://123.456.789.0/gf.php[1] that mimics their logon screen.

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

[Anonymous Coward]

I mean really there was no need for new murder laws when guns came about.

Not as if that stopped anyone from passing the "Use a gun; go to jail" laws.

Re:Legislation

[Anonymous Coward]

[1] Yes, I know this is an invalid IP address. You're missing the point.

Well, duh. However, I am unable to find either Grand Fenwick or Mordor in my Encarta Encyclopedia.

Re:Legislation

[Tumbleweed]

Indeed It Should!

Re:Legislation

[Anonymous Coward]

1. The Courts
2. The Courts
3. Law Enforcement
4. Law Enforcement ... this is why people pay taxes. This is also why people entrust their governments to enter into treaties with other governments. Banks are not in the business of being Courts or Law Enforcement Agencies.

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

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

[Anonymous Coward]

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.

I can't believe it. You're saying that hotmail's spam filters let a scam message through. I'm shocked.

Re:Meh

[Xenographic]

They sometimes catch ones with broken headers. And spammers aren't that good at writing SMTP engines, either.

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 field that asked for "3rd grade teacher's name" or "pet(s) name(s)" ...

Re:Meh

[TigerNut]

As a regular eBay / PayPal user, I get these emails regularly - the first one had me thinking for a while, but logging into Ebay directly and doing some status queries quickly settled the situation. The later phish emails got way more brazen - they're asking for more personal information than eBay or PayPal ever did.

The basic rule of only supplying personal information when YOU are the originator of a Web transaction still applies, but as you say,

.. not to mention some way to get the average public to read them both.

... it's going to be hard to get everyone to think critically all the time.

Re:Meh

[cortana]

Call the primer something like "WHEN AMERICA'S DUMBEST INTRA WEB CREDIT CARDS ATTACK 3" and they'll lap it up.

Re:Meh

[Anonymous Coward]

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.

I almost hate to be cynical about this, but state attorneys general have been trying to do this for decades. And still, on a regular basis, some little old lady gives up her financial information to some random stranger over the phone.

Re:Meh

[Anonymous Coward]

Very similar to an email scam claiming to be from CitiBank I got a while back. Used the same %00 URL bug, asking me to verify my online account details. Since I don't use their online services, I though this was strange (thought it was strange that the sender IP address was registered in China as well). I called CitiBank about it and they showed some interest in it, so I sent them a copy of the email.

Re:Meh

[protoshoggoth]

I sent off a LART to the hosting provider's abuse email. No response. I don't consider that a good sign.

Letting Paypal know is probably more likely to get you somewhere. I forwarded one of these things to the "imitated" bank once, and got a (not form-letter) reply within an hour. I don't know what, if anything, they actually did about it, but I figure Bank of America is more likely to get JimmyDean ISP's attention than I am.

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?

[Anonymous Coward]

How this got marked interesting, I have no idea. I can generate as many SSL certiciates as I want. "BAD" Cert "providers" (they're really only /signers/ of the key) aren't the problem -- if there's any out there. It's the use of their trick to bypass the browser's message about accepting a key.

By the way, if anyone wants their key signed, I'll sign it for $10 if you think that provides any sort of security for validating the identity of a web site. Also, I have a bridge for sale. It's in New York.

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

[Anonymous Coward]

Actually, it does provider security if the provider will only issue the certificate after checking your identity...

The other thing that signed certificates prevent is man in the middle attacks.

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

[Anonymous Coward]

I tried removing the certificate for the most untrustworthy company on the entire internet, but that didn't help anything, it just gave me a lot more ok-buttons to click. At that point I just gave up on SSL=trustworthy, and to me, SSL or plaintext doesn't really matter anymore. Sure, the data is encrypted in transit, but the net connection is more trustworthy than any proof that the guy in the other end is really who he claims to be.

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

[Anonymous Coward]

Also, I have a bridge for sale. It's in New York.

It better not be the same one you sold to me last week, asshole.

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

[AKnightCowboy]

If so anybody have a list of SSL providers I should be giving a second look at when the site pops up?

Verisign. Their underhanded deceptive practices practically brought the Internet to a stand-still last fall with their Sitefinder "service". I'd recommend deleting them as a trusted CA in all your applications and NEVER visiting sites that have been signed by these slimeballs.

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

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

[Anonymous Coward]

"practically brought the Internet to a stand-still"

Your deffinition of practically doesn't match mine. Why? Because I know that all three locations I use the net from were unaffected by the Sitefinder service. So not only did it not bring them to a stand-still, it didn't make a single difference.

Just because you're a little pissy about the whole thing (I agree with you, btw), doesn't make it okay to make up lies and bullshit to back yourself up with.

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 ?

'splane it to me Lucy

[602]

from the article: 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.

I understood most of the article, but parts of it were like Greek to me, and I'm pretty savvy. I understand encryption and know to look for the SSL lock when I'm entering sensitive information, but visual spoofing worries me. I'll be sure to look at SSL certificates from now on. I hope the browser and backbone programmers can make this more secure.

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.

Re:'splane it to me Lucy

[monkeyfamily]

...visual spoofing worries me. I'll be sure to look at SSL certificates from now on.

In visual spoofing, the fraudster's created a fake statusbar with a lock icon on it. Assuming you're using IE (because an IE statusbar would look awfully fishy at the bottom of a mozilla window), they could just link the lock icon to a popup window that mimics what you'd see in IE when clicking on the lock at a valid SSL site. Monoculture makes things ver-r-r-y convenient for the baddies!

Re:'splane it to me Lucy

[stonetemple]

Since a web server (usually) knows which browser you're using before it sends any data, i'm sure the phishers have a layout for the non-IE browsers as well. Although most people using anything other than IE are probably familiar enough with their browser to notice any sneakyness.

One upside to computer monoculture is that the few in the know can easily avoid the pitfalls faced by the many. For example, I haven't seen a pop-up or distracting ad on the web for years (mozilla kicks ass), but the average user with IE keeps the internet revenue machine humming happily. And as long as joe average user falls for these scams, I can feel secure knowing that there are much easier targets out there.

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:'splane it to me Lucy

[Darren.Moffat]

One easy way to get around this is to use themes, I don't believe Mozilla themes names are ever passed across the wire in HTTP headers. This is even more likely to help you if you use a theme that you designed and you didn't distribute anywhere.

Themes aren't just for eye-candy anymore!

Re:'splane it to me Lucy

[Anonymous Coward]

> 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 (my emphasis) who don't look at the complete URL are going to be victimized.

Yeah, it's always those damn USERS, isn't it? Just because the tech they're using is undependable, misleading and easily abused, it's still their fault! If only they would educate themselves to the level of professional IT folks, then all would be well!

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.

Re:Look for the cute little lock!

[kfg]

. . . six years of math education and he's stumped by our ssl user interface.

I once knew a man who had a dog with only three legs, and yet that man could play the banjo like anything.

KFG

Re:Look for the cute little lock!

[dipipanone]

..that man could play the banjo like anything.

Could he play it like a euphonium? That's something I'd *really* like to see -- a man with a three legged dog, playing the banjo like a euphonium.

Re:Look for the cute little lock!

[kfg]

Could he play it like a euphonium?

Yes, but only if it was a four string banjo.

KFG

Re:Look for the cute little lock!

[fm6]

If you're saying that the lock thing is lame, and that web security is totally FUBARed, I certainly agree with you. I was just pointing out what they are trying to do.

In the case of your Dad, the problem is proper documentation. When the web browser starts babbling about certificates, there's simply no way the ordinary non-techie can follow what's going on. Hey, when I get a certificate message, I have to stop and think about exactly what it means.

But that's kind of a peripheral problem. The whole concept of web security needs to be re-thought. We need some simple way to ID each other, and you should be able to use a standard smart card and plug it into any computer to prove you are who you say you are.

Which would also help with spam!

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:They just want to jam.

[kin_korn_karn]

It IS all Phish's fault. Drugs are bad, m'kay?

Invading SSL can't be good

[superpulpsicle]

This was the last safe territory for me. When I punch info into a https site, I get a sense that it's alot safer.

How the hell I use online banking and do any heavy shopping via https again?!

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:Invading SSL can't be good

[Anonymous Coward]

While having the data encrypted over the wire is a good and comforting thing. I havn't had my data stolen while in transit. I know for a fact that my credit card data was stolen once when someone broke into a vendor's back end SQL Server database.
Packet sniffing is too much work for most people when they can just build a fake web site, or break into the real one.
Not that I'm downplaying the need for encryption on the transfer - I'm just saying that other things are equally or more important in most cases.

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.

Re:you are misinformed

[femto]

The parent has a valid point. But the problem is not with allowing people to create their own certificates.

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 be changed to reflect the fact that it doesn't actually relate to everything being 'okay'?

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

[Anonymous Coward]

Note that view selection source generates source based on the dom, so it isn't the original html page. this isn't really a bad thing, since if the page rewrote the post destination, you'd want to see that...

of course this is also available in seamonkey.

Re:The lock is not important

[a24061]

Holy crap, that's useful -- thanks very much!

surprise, surprise...

[wotevah]

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:surprise, surprise...

[Spetiam]

but the problem here is when he (or other computer illiterates) personally enter the data and have to deal with deceptive spam, popups, etc.

Domain Typos

[ChrisBrown1]

Or evil domain is typo of legitimate one... (Not meant to defame any website) such as www.ebaye.com, www.paypall.com, www.macaffee.com, etc...

Interface issue

[Overly Critical Guy]

The browser should somehow make it more prominent then, without annoying the user. If you really wanted to be safe, have the window give itself a red border around the page, instead of a tiny little lock at the bottom. People would notice a red border, yet it wouldn't be intrusive.

Re:Interface issue

[Anonymous Coward]

If you really wanted to be safe, have the window give itself a red border around the page, instead of a tiny little lock at the bottom.

body { border: thick solid red; }

Moral of the story? Don't give important user feedback in a way that can be spoofed easily by websites.

Re:Interface issue

[Overly Critical Guy]

I mean the browser window itself, not the web page.

IE hides information for your own good

[wotevah]

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. Yeah, okay, let's put the actual error mesage at the bottom of the page so users need to scroll to see it, if they really want to, but why should they anyway. It is irritating, but this by itself probably made jobs for thousands of IT people who could "research" what happened.

Even with certs. IE refuses to work with wildcard certificates (*.domain.com) when the * part needs to match two names like a.b.domain.com. But the error message says "The cert does not match the name of the site", it pops on each SSL connection (i.e. each individual image on the page), and you can't say "OK, accept for this session" like you can when the cert expired.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:View source

[thedillybar]

Ah...

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

[windside]

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

Issue isn't really encryption, but trust.

[Chuck Chunder]

I think it should be fairly simple to update the browsers so they require some encryption by default

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 verifying the identity of the certificate holder before signing.

According to the article there is a form of certificate which does not need to be signed by a trustworthy party to be accepted by user-agents without question.

So the problem here isn't really that user agents should require some encryption by default, but that they should require some indicator of trustworthyness.
(That's not to say they shouldn't require a particular level of encryption. And requiring encryption may have the knock on effect of requiring a signature. I think you understand that. I just wanted anyone else reading to be clear that "encryption" and "trust" are two different roles and that the core issue when talking about "phishing" is trust.)

Re:Issue isn't really encryption, but trust.

[Anonymous Coward]

According to the article there is a form of certificate which does not need to be signed by a trustworthy party to be accepted by user-agents without question.

it says there that with the nonencyrpted SSL, the browser does not ask to verify the cert.

Re:Issue isn't really encryption, but trust.

[Piquan]

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.

Point of order: SSL's second role is not about trust, it's about integrity and authentication.

Integrity means that the data that you see is the data that the sender sent. It has not been modified. For example, if I see that my bank balance is $100, then (if proper integrity checks are taking place) I know that the web server sent the value $100, and that an attacker didn't substitute that value for my actual balance.

Authentication means that the data is from who it says it's from. Nobody else sent that data. If proper authentication checks are in place, then I know that the web page I am seeing was sent by my bank, and not by an attacker.

Most cryptosystems that provide authentication also provide integrity. (The opposite is not true; consider MD5 checksums distributed alongside tarballs.)

These have nothing to do with trust. My bank may be a front for the World Crime League and actually has spent my money on Evil Devices with no intention of letting me have it back. This would mean my bank is untrustworthy.

Re:Issue isn't really encryption, but trust.

[Anonymous Coward]

As for "Plain Text" encryption, you can turn that off. (At least in Netscape 7.1 - Edit|Preferences|Privacy&Security|SSL, Click Edit Ciphers and go to the third tab).
But yes, the main issue is not encryption (or lack of), but one of what does the certificate actually certify.

ATTN OP

[Anonymous Coward]

Please forward any emails like this to spoof@ebay.com.

Thanks.

Re:ATTN OP

[Anonymous Coward]

Err, this was a PayPal scam, not an E-bay one :)

Re:ATTN OP

[Xenographic]

There's a spoof@paypal.com, too (which is the appropriate point of contact).

I have already forwarded it to them.

Re:ATTN OP

[arantius]

Err, this was a PayPal scam, not an E-bay one :)

Who owns PayPal?

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.

Re:Every UI I've seen for SSL, is lame

[Perky_Goth]

let me be a whiner who says he can't figure out certs. where can i see how they work?
and a lot of company's here (portugal) don't even have their certs certified with Verisign and others, they are top level certs...
and they don't even get together to create on for portugal... sigh...

Re:BFC

[Atrax]

Actually, that segment in BFC is a throwback to a segment from The Awful Truth called Corporate Cops - in fact the segment of film is almost identical to the trailer used in the TV show.

Bollocks

[Anonymous Coward]

Absolute rubbish.

Another bullshite, unfounded self-promoting, bunch of codswallup.

SSL isn't flawed (yet), its the implementation of the code in the web server. And to expoit it, a victim has to click on a link that phiz's. Hm, you all seem to think most people are stupid, well, it is generally the case, but in this situation, and the amount of press that banks have given to their customers (have you not seen the junk-mail?), it is still likey that some moron will fall for this trick, but it's not a flaw in SSL, it's a flaw in the code of the http server/client(browser).

Typical unballanced, bollocks.

arggghhhhhhhhhhhhhhh

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

Re:Bollocks

[Anonymous Coward]

Show me one browser that implements a "bilaterally anonymous SSL connection".
You say "that's what the browser vendors have apparently done." Prove it.
Show me any "apparent" evidence of DH_anon ciphersuites in browsers.
You say "It would be nice to provide someway to disable this feature".
Show me that it's enabled. Go on, I dare ya'.
Use IE, Mozilla, Netscape (any version). Or any other browser.
Negotiate any of the SSL3/TLS DH_anon ciphersuites, which are:
CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
Just look at the browser's unencrypted client hello message, which contains
the list of supported ciphersuites, and see for yourself what is supported.
While you're at it, see if they support the NULL encryption ciphesuites, too.
In short, hey users, don't believe every alarming web page you read.

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.

What a scary world we live in

[stonetemple]

The only way to avoid being a victim of this kind of fraud is to understand your computer and the internet. The average user doesn't have the personal connection to their computer that the average slashdot reader has, and they shouldn't have to. What a frightening world to live in--your money can be managed through a completely unfamiliar (and illogical, to the average computer user) medium.

Hopefully the technological divide will dimish before a major financial catastrophe occurs. IMHO, the most perilous psychological response is the urge to continue clicking "yes" or "ok" until a problem disappears. I've done it before, and i'm sure everyone else has done it too.

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

1) type the site | 2) login | 3) it's that simple!

[Anonymous Coward]

It's also common sense that nobody is expected to type 30+ characters into their address bar. It's easy to be a smart aleck and make it look funny but there's no need to be a troll when all you have to do is type "www.ebay.com" or "www.paypal.com" (or whatever site you are after), hit enter, and then login to your account.

I access my accounts at public terminals a lot and don't have the luxury of bookmarks so it amazes me that simple and usable advice (to type in the url instead of clicking a ^sneaky^ scam link) is blown all out of proportion into "OMFGBBQ!! I have to type in a paragraph of a url!" Fortunately for idiots like you, those big companies survive by separating currency from your meaty fists. They usually have short URLs that you can painlessly remember and can type rather easily since you have to mash the keyboard with your neanderthal club.

Roll your own CA has it's uses.

[temojen]

If you're a politician, lawyer or human-rights worker in a country where your opponents may take extra-legal control of a CA to issue faulty certificates, your own CA may be the best option.

Who knows better than you who is a legitimate member of your organization?

Remember, X.509 certificates are used for more than just e-commerce and online banking. They're also used for S/MIME email, Intranet Websites, and VPNs. If I were running an IPSec protected multisite VPN I sure wouldn't trust a commercial CA to decide who can connect.

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

[a24061]

Even if every computer in the world were running free software, the users would be the same. Yes. Those who run as root

Not exactly right: most Windows home OSs actively encourage users to run as root all the time, whereas all Unix-like OSs have separate user accounts by default and you have to choose deliberately to act as root.

and click on every goddamn mail attachment.

But I agree with you here.

controlled net hardware (punishments in the same class as dealing "class A controlled substances") ... a compulsory international e-identity (smartcard/bio authentication; equivalent of a passport) without which you cannot even access the net.

So, no privacy or freedom and compulsory TCPA? Do you work for Microsoft?

Re:Enough is enough

[Anonymous Coward]

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.

Wonderful -- a complete expression of Ashcroft's wettest dream. Make the net bulletproof for business and to hell with anyone with a legitimate need for privacy or anonymity. Yeah, Islamic law for the net. You skunk-fucking dipshit.

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:Enough is enough

[October_30th]

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

There's no contradiction here.

As with any law enforcement, I don't tolerate vigilantism.

Re:Enough is enough

[October_30th]

Wonderful -- a complete expression of Ashcroft's wettest dream. Make the net bulletproof for business and to hell with anyone with a legitimate need for privacy or anonymity. Yeah, Islamic law for the net. You skunk-fucking dipshit.

Thank you for your insightful post.

Then I suppose you want an unsable net. Or do you actually have any real ideas on how to stop the inevitable degeneration of the net?

And speaking of privacy, why aren't you complaining about the necessity of having a passport or even visas when traveling abroad? I'd say freedom to travel is much more important than net access and yet it's heavily controlled.

Re:Enough is enough

[October_30th]

So, no privacy or freedom and compulsory TCPA? Do you work for Microsoft?

Well, I know this will piss people off here, but I believe that once the population (virtual or not) grows numerous enough, there must be limits to individual freedoms. This happened ages ago in the real world, but the net has only recently matured to this stage.

Cars, international travel, movies, guns and drugs are controlled. I don't see the problem with controlling access to the net.

Re:Enough is enough

[meringuoid]

So, if not 'vigilantes' - I think this is inaccurate in SPEWS' case, it's more like the nosey neighbour who gossips about your misdemeanours - who would you suggest we appoint? A US government agency? Microsoft? The UN? How could they enforce their rulings?

Right now, I don't think there's any real authority on the net other than the democratic mandate granted by the goodwill of sysadmins. The net's authorities, whether government-endorsed like ICANN or unofficial like SPEWS, only have real power because the network owners agree to follow their lead.

As long as there is no world government, surely a US government attempting to police the net is just as much a vigilante as Sergei Didorenko from Lake Baikal?

Re:Enough is enough

[a24061]

I see your point about cars and guns, but computing is IMHO too closely tied to freedom of expression to be treated the same way. (I'm not saying there should be no restrictions.)

I'm curious why you're opposed to SPEWS but favour some restrictions that many people would consider draconian.

Re:Enough is enough

[Anonymous Coward]

Imminent death of the Net predicted on Slashdot. Film at 11.

Re:Enough is enough

[October_30th]

I'm curious why you're opposed to SPEWS but favour some restrictions that many people would consider draconian.

After the run-ins I have had with SPEWS ("your ISP supports spam, that's why you can't receive/send mail anymore even if you didn't do anything wrong") I cannot consider them as legitimate civil action anymore. They are a bunch of vigilantes.

If I'm going get shafted by anyone, I'd rather take abuse from the government than from a group of anonymous cowards like SPEWS.

Re:Enough is enough

[October_30th]

As long as there is no world government, surely a US government attempting to police the net

Well, I don't see any problems in policing international travel. I'd use the passport/visa system as a model for the more robust internet authentication.

Re:Enough is enough

[a24061]

I've heard some similar complaints about SPEWS too, as well as SORBS. But the worst they can do is put an IP address on a blacklist which some parties use and some do not. That's nothing compared to the effects of enforcing closed computing (TCPA, DMCA, etc.) throughout a jurisdiction.

Re:Enough is enough

[meringuoid]

Well, I don't see any problems in policing international travel. I'd use the passport/visa system as a model for the more robust internet authentication.

Passports and visas are the product of agreements between independent countries, not of any global government. So, for instance, most countries within the EU will allow movement between them with no passport or visa required. Britain and Ireland require passports. The US requires a visa. The degree of authentication needed depends on how much your destination country trusts the country you just left.

What if you're an Afghan trying to go to the USA? Well, the USA has had a lot of problems with illegal immigrants from that part of the world, some of whom turned out to be terrorists. Even if you're on perfectly legitimate business, you'll have a tough time being allowed entrance. What if you're Cuban? No chance. Cuba is a communist country, and the USA hates those on ideological grounds.

So, an internet governed along the lines of passports and visas would presumably consist of ISPs who trust each other exchanging all data more or less untroubled, while data coming from an ISP that your ISP doesn't trust, or doesn't like, gets dumped. Why might an ISP decide to treat another ISP this way? Maybe because the ISP whose data is being dropped is full of spammers, I suppose. Just like the legitimate Afghan visitor to the USA, the legitimate customer of that dodgy ISP is going to have big problems. Or maybe because your ISP hates that ISP for ideological reasons - they're a major competitor, for instance. Like the Cuban who wants to legitimately start selling cigars in the US, the legitimate customer of the hated ISP will have problems.

So... I'm still having difficulty seeing what your problem is with SPEWS. Sounds like exactly what you're advocating. A system where ISPs block what they want, for whatever reason they choose.

PTFB

[iamacat]

(Patch the Fine Browser). It is responsible to tell users weather the site is secure and who owns the key. There are countless ways to do this, like putting a lock icon next to the standard window title bar controls such as minimize and close. MacOSX Safari does it already, why not others? Then, the page title can be prefixed with site's identity.

You can blaim user stupidity or phishers deviousness, but really it's a simple security bug and it should be fixed.

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)

[Conare]

The only reason that SSL continues to work so well, is that it is still not the weakest link in the security chain. As other posters have pointed out, it is much easier to crack the endpoints of an SSL transaction. There are products out there that will keep information encrypted through to your back end servers, but as long as the credit card companies are limiting liability, there will be no public insistence on using them. Q: Who is doing all the writing off of this theft and who is ultimately paying for it? A: The costs of these thefts are hidden in higher prices for products and insurance of course.

Re:Other limits of current SSL implementation(s)

[execute85]

As of right now, the price of verisign stock is $16.22 putting the market cap at $3.94 billion. Since they have about $700 million in cash, there's no way you'll be starting a leveraged buyout with $15MM. Even if you did want to do a leveraged buyout you'd need the backing of one or more wall street syndicates. There's no way the Russian mob is performing a buyout with the backing of wall street. Please stop spreading inaccurate anectdotes.

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.

Re:Other limits of current SSL implementation(s)

[Anonymous Coward]

If you have a password on your private key, then it usually doesn't matter if the bad guy gets a hold of it.

Does plaintext-ssl provide authentication?

[raboofje]

> Sometimes all you need is authentication.

Certainly - but does plaintext-ssl provide that? If the page is sent over in plain text, it could have been altered in transit, for example.

Or are the pages signed or something? But then we could check the signature, right?...

Re:Does plaintext-ssl provide authentication?

[realdpk]

That's a good point. I guess a signature would need to be calculated by the server and sent with the content. It might net a small increase in speed still, though.

A step in the wrong direction

[iamacat]

Users already have trouble with a single lock icon, do you really want them to think about insecure vs signed vs encrypted? If people pay for the silliness of hardware XML accelerators (rather than using a nice binary protocol), they can pay for hardware SSL accelerators. ISPs should have no problem getting an SSL certificate and signing all users' pages with their username, given a small modification to SSL to support one more level of indirection.

In this way, most pages on the web will be https://, with the exception of some hobby and ultra-high-performance URLs. Those will be prominantly marked by the browser with a red title bar that says "Insecure page!"

Re:A step in the wrong direction

[realdpk]

Yeah, it would be nice if everyone used SSL, but there is some SSL decryption overhead on the client end that could be avoided for many types of files (slashdot's homepage for instance, its all publicly accessable data so why encrypt it?).

ISPs would have to get a different certificate for each of their client's domains, and give out separate IPs for each of their sites unfortunately. SSL would need that shortcoming fixed first.

Re:A step in the wrong direction

[iamacat]

slashdot's homepage for instance, its all publicly accessable data so why encrypt it?

Ah, but you may not want your company or your neighbors to know your slashdot username or your anonymous or regular posts. Think of all the SCO, Real or Microsoft employees who post here.

Yes, we need an SSL change to allow certificate owner to create additional certificates for "child" domains. And some traffic like multicast audio/video steams is not practical for SSL. But most things should be signed and encrypted as soon as technology permits.

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

[Anonymous Coward]

Interesting read, but that is what CC insurance negates. So what if someone takes your details from a receipt - your CC company will be liable. Do as I do, and pay the $7 a month for the insurance :)

Re:Funny but you have a point...

[Ulven]

As far as I'm aware, fraud protection is free over here in the UK.

Re:Funny but you have a point...

[MukiMuki]

There's always those nice, "insta-use, $50 limit, 24-hour-lasting" 'net cards that some CC companies offer.

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:Funny but you have a point...

[Anonymous Coward]

For your safety, post your credit card number here so we can check that you are properly protected.

Re:Funny but you have a point...

[Anonymous Coward]

They swiped the card without even looking at it.

That's nothing, awhile back I word for an internet start up. We needed to purchase a few modems, but there was no corporate credit card, so one of the head guys gave me his card to use. I didn't really feel comfortable doing it, but what was I to say to the guy?

I used it, signed his name, they even compared the signatures allowed the transaction. Granted it was only for $150 or so, but still. I definitely feel better I practiced his signature a few times.

The security of credit cards is absolutely horrible, but what are you to do. Until someone implements a more secure system, there's nothing we can do.

And about sniffing traffic, I wouldl't put it past some people. Sniffing one persons credit card? Not worth it. Sniffing all of Amazon's traffic and getting millions of credit cards? Worth it. Or worse yet someone breaking into amazon and downloading their cc database. I've had my card number stolen this way before TWICE. Now I stick with the big guys hoping they have better security.

Re:Funny but you have a point...

[gid]

I never quite got what those insurance fees were for, except to needlessly charge your more money. As far as I know, credit card companies are responsible for fraud if you have their insurance or not. You can always issue a charge back on the place that charged your cc # in the first place to get your money back. It screws the retailer, but what choice to you have? Note, I've never done a charge back before. Someone please correct me if I'm wrong.

Debit cards are different, then your bank is liable for the fraud and it takes much longer to get your money back, but from what I hear you still get all or most of your money back.

One trick I learned: Maybe every year or so, call your cc company and ask for a new number and issue you a new card. They'll be more than happy to do it, and you have the peace of mind knowing all those retailers in the past year your gave your card to no longer have a valid number on file anymore.

Re:Funny but you have a point...

[radio_babylon]

personally i just use two bank accounts to mitigate my risk... one account has all my money in it, and the other is my spending account... the debit card for my storage account stays locked up at home, and i just keep a few hundred bucks transfered over into my spending account at any given time, then just use the visa debit card on that account for purchases online and off...

this limits how much i could lose if someone stole my card or card info... and on the rare occasions im shelling out more than a few hundred bucks at a pop, i generally know exactly how much ill need and just transfer that much over before paying a payment... it also has the side effect of making it easier to do my accounting, and more obvious when i am spending more than i ought to be :)

and for those occasions where a debit card just wont do... i have exactly ONE credit card, and that card has a $300 limit... so im not going to get too terribly screwed on that either. its pretty funny, every now and then they will raise the limit on the card and i have to call to tell them to put it back...

i guess this wouldnt work for everyone, but if you can reasonably manage to operate debt-free, with enough assets liquid to deal with those occasional big-ticket unexpected expenses (like your car blows up or something), then it can certainly mitigate the risks of using plastic instead of cash, with only the minor added inconvenience of the periodic transfers... but maybe there are other flaws with this that i just havent noticed or thought of yet...

Re:Funny but you have a point...

[DonGar]

Debt cards are different, the banks are NOT liable.

With credit cards the liability is legally limited to $50, but debit cards sit in a limbo not covered by the law, so you are liable, not the bank.

I'm not an expert on this subject, just repeating gossip level knowledge.

Re:Funny but you have a point...

[gid]

What's weird is if say Joe Blow walks into my bank pretending to be me, and withdrawls all my money. The bank would them be liable for giving my money to the wrong person, correct? How is that different than Joe Blow acquired my debit card somehow, and used it to take my money that way.

I've known people that have gotten their bank accounts withdrawn on, and they go their money back. One thru a debit card, and the other thru wire transfers. They both go their money back I believe, but maybe the bank was just being nice, as I don't believe it was all that much money.

If debit cards aren't covered, maybe I should get rid of mine. Something to look into.

Re:Funny but you have a point...

[Eraser_]

Ooo funny story time.

Stupid story was at arby's I had never been asked for ID. Then one day I'm given a card to use and they finally asked. Sucks to be me.

At UC Berkeley they have strict security for the dorms. Whenever a student comes in or out you must first unlock the door, give the desk person your student ID to be swiped (make sure you do live here), then use same key to get the elevator/gain access to stairs. Guests must sign in with photo ID.

Some friends and I went to visit another mutual friend there one weekend. He is wheelchair bound, so doesn't always come to the door to let us in, etc. Instead he has people let us in, sign us in, and give us access to the stair well. Of course, sometimes it can be hard to find friends to let someome in, so he just gives us his ID card and key. That weekend 4 different people handed the desk clerk the UCB PHOTO ID to be swiped, then signed in one or more guests. We bought food, drink, and gained entrance to buildings with this ID, none of us look anything like him.

Re:Funny but you have a point...

[NicksMyName]

I worked in a theme restaurant in SF many years ago. There were so many people who didn't actually sign their credit cards the restaurant had a policy of asking for ID. Many customers actually were upset about this. Many times I was told by customers that they didn't sign their cards because if they lost them "Someone could just copy the signature". It hadn't dawned on them that "the bad guys" could simply sign the card themselves...

If people are this dumb in the physical world we really have to make things security simple in the electronic world. Something tells me we'll never be able to protect these sorts of people though. (one foot note; there were some people who didn't sign their cards but wrote "See drivers license" on their cards. They were forgiven.)

Despicable

[Halloran]

This is absolutely despicable behavior, and the folks doing this should be fined or imprisoned.

That this is even possible seems to suggest that either the "secure" system needs to be re-examined and perhaps re-implemented, or there needs to be strong controls put in place on the technology.

When its your money, or information on the line, sometimes we need regulation to make sure we aren't getting scammed by the next "popup camera" business.

Current poll applies...

[Undefined Parameter]

Just another reason that my favorite permissions setting is 0000.

Nah, who am I kidding? I can barely use the terminal in Mac OS X!

(Though if someone would point me toward a general list or guide to the commands available, I might use it and become an even geekier... geek. ...If that's possible.

~UP

Re:Current poll applies...

[lxs]

I can barely use the terminal in Mac OS X!...(Though if someone would point me toward a general list or guide to the commands available, I might use it

try the linux users guide

yes,it's aimed at linux, but most of the commands they describe are generic to unix and GNU tools.

All my linux experience translated directly to the OSX command line (especially now Panther uses bash by default instead of csh for the CLI)

Re:Current poll applies...

[Undefined Parameter]

Thanks, man! I'll take a long look at it later today! :-)

~UP

Re:1) type the site | 2) login | 3) it's that simp

[Anonymous Coward]

I access my accounts at public terminals a lot and don't have the luxury of bookmarks ....

So why not bury a page or so of the most useful ones in a secure directory at your ISP? That way you have quick access to them from anywhere.

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.

Blacklist phish site @210.93.131.250 read why now!

[iamcf13]

'Re: Do people even see the lock?' Stay sharp!

There is one at the bottom of this fraudulent phish site posing as a part of eBay that got sent to me recently via email.

http://210.93.131.250/my/index.htm

Needless to say, this is *not* a secure connection as far as the browser is concerned.

So I did what I could:

I looked up the abuse department responsible for
210.93.131.250 (the spam email *came* from this IP address) and traced it to a group of DNS servers in Korea. Cross referencing them with rfc-ignorant.org revealed they were *ALL* blacklisted--nobody worth complaining to.

I reported the phish URL to eBay by sending them the url saying in effect 'why wast the bandwith sending you the spam email itself containing the (reported) url'.

I even 'filled' out the form at the phish site, using 'fraud' and 'I reported you to eBay' in the text fields.

The website is still up and running, ready to steal some persons credit card information.

Now with the program CF13(TM) I wrote and use, such phish scam emails are scanned, deemed spam, and sent to the program's 'spamdump'. Should such a message get past CF13(TM), that would mean such a message is (concievably) reportable to the abuse department responsible for hosting the such a site....

Now, I don't have to deal *almost all* forms of email spam and don't have to hide behind an obsfucated email address to do it.

Since it appears impossible to shut down this fraudulent site, the next best thing is to prevent anybody from going there. Thus a perfectly useable IP address has been ruined by scammers....

I got a better one

[essreenim]

A little basic intelligence prerequisite test before credit details. SSL+HTTPS on OpenBSD with Apache Jakarta with J2EE with the highest security options, followed by another test (just to be sure)

Re:I got a better one

[zero_offset]

The test could go something like this:

Which is grammatically correct?
(a) "I have a better idea."
(b) "I got a better idea."
(c) "I am not old enough to have a credit card."

Re:I got a better one

[Anonymous Coward]

Which is grammatically correct?

All of the above!

Well, at least Word thinks they are fine. These are fine too:

I got me a better idea.
I have got me a better idea.
I have better idea got.
I got have a better idea.
Better got have me idea.

However Word doesn't like this:

I has a better idea.

At lest the spelling checker works.

Re:I got a better one

[Anonymous Coward]

We has a better idea, precious!!!

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

ssl is not completely solid

[Anonymous Coward]

the ephemeral key is "weak" in that its randomly generated and sent over the wire using the public key of the other side, instead of a DH key exchange (like ssh does) meaning that an attacker can record ssl traffic and decrypt it later after getting the server.

insurance is stupid

[Anonymous Coward]

legally, you're only liable for $50 of fraud; most companies cover you 100% if you report it in time (in the US).

Re:insurance is stupid

[Anonymous Coward]

legally, you're only liable for $50 of fraud

Only on credit cards. IIRC, debit (or "check") cards do not have this protection.

Re:1) type the site | 2) login | 3) it's that simp

[dreamchaser]

Better yet, carry around a list of links on a mini USB keychain drive. Not to mention notes, addresses, etc.

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.

open for attacks..

[Anonymous Coward]

With the plaintext-encoding causing no errors at all it's rather simple to construct man-in-the-middle attacks on just *any* existing and wellknown server, since no warning is reported to the user.
But with all those keylogging trojans out there, who care's about the men in the middle?

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.

Own experience

[Anonymous Coward]

I've just set an Apache up with NULL encryption and tried to connect. I tried both Mozilla and IE

Mozilla refuses connection (no shared cipher). You have to edit SSL preferences to accept NULL encryption by hand. Then you can connect, but certificate is verified by browser. Lock icon is not the same as a typical SSL connection : it is broken and red enlighten.

IE refuses connection (no shared cipher). I quickly ran into config options but found nothing about NULL encryption

Which means NULL encryption seems to be refused by theses two popular browser using default install.

Number of wards on the key

[Anonymous Coward]

In the early versions of Netscape, the number of wards on the ssl key icon went up with the strength of the key crypto.

But the UI bastards thought that was too confusing, so now in later versions there's the little padlock icon that is only open or closed.

The purpose of language...

[fm6]

...is to communicate, not to satisfy some rule book. "I got" is perfectly clear. Because it breaks "standard" rules, "I got" is not good formal English -- but that's a cultural problem, not a matter of intelligence.

Here's a nice intro to SQL Injection

[joshmccormack]

http://www.securiteam.com/securityreviews/5DP0N1P7 6E.html

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?

Re:How do banks do it?

[DavidDeLux]

I do online banking, and the system my bank uses is more that just using an SSL connection.

1. There is the SSL connection to their site

2. I then have to enter my user ID

3. I then have to eneter my password

4. I then have to give 2 randomly chosen letters out of 16 from a card that they have given m

Now, all this is running inside a Java app, which then sends it down the wire to be verified before I can get at my account and do things like transferring money to pay bills. This is not an uncommon scenario for bank in Europe... I leave it as an exercise for the /. readers as to how good their software actually is :-) No software is perfect, but with carful planning to can stop stupid mistakes that lead to a nice big hole for somebody to exploit.

Comment removed

[account_deleted]

Comment removed based on user account deletion

A radical solution!

[sorbits]

Are you listening programmers?

The problem is that showing a special flag when the page is secure does not remind the user about the problems when a page is not secure.

So we would need to indicate that the page is not secure, but that's 99% of all pages... and so the user will quikckly learn to ignore it.

I think the solution to having people input their credit card details and pincode on a webpage after receiving an E-mail should not be solved by the browser, after all, the E-mail could also have told them to phone in their information...

A radical solution would be to print the wrong info on the credit card, but provide the user with the correct info on request, that way, everybody would be made aware of the problem (about not giving away this info), except those who never request the correct info, but then they won't be doing any harm with it either...