Slashdot Mirror
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.'"
(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?).
SSL Certificate
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.
It defaults to poping up a warning that you are using low grade encryption. Plain text qualifies!
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.
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...
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.
To enable the Debug menu see this tip.
http://www.rootstrikers.org/
> 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.
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.
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
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.
--
$tar -xvf