Phishing Scams Incorporate SSL Certificates 316
dettifoss writes "Netcraft reports:
`Internet "phishing" scams are incorporating the use of SSL certificates in their efforts to trick users into divulging sensitive login information for financial accounts.'
Perhaps more disturbingly: `Scammers can also configure their web server so that deceptive SSL certificates won't trigger an alert in the user's browser. "One of the SSL encoding methods is 'plain text'," Neal Krawetz from Secure Science Corporation noted in the SANS post on the issue. "Most SSL servers have this disabled by default, but most browsers support it. When plain text is used, no central certificate authority is consulted and the user never sees a message
asking if a certificate should be accepted.'"
SSL certificates in 2004 (Score:5, Informative)
(Disclaimer: I am probably biased, since we issue
SSL certificates
on our website.)
This article is a good example of yet another reason why the old advice of
"make sure the site you are dealing with has an ssl certificate, and you
should be fine" is no longer entirely true.
To be more confident you are dealing with a reputable/accountable merchant/site, you
should not only make sure that they have an SSL certificate, but you
should also actually click on the lock (or however it is done in the browser
you use) and look at the certificate.
The reason the advice used to be valid, is that traditionally, to get an SSL
certificate, you had to provide documents to prove you are who you say you
are, i.e. DUNS #, articles of incorporation, business license, DBA, bank statement,
passport, driver's license, whatever. That is still true for most of the
certificate authorities, but it isn't always true. Some of the new certificate
authorities don't actually ask to see documents before issuing the
certificate, instead, they merely make sure that you have control of the
domain by sending an email to the listed contacts. In some cases, they also
place a phone call to a number you provide them (I fail to see how this does
anything, but..). Certificate authorities that do this will issue the
certificate to "Domain control validated, organization not validated" as the
organization (or similar text to that effect) rather than to the actual name
of the company the certificate is for. These certificates are
perfectly fine for making sure things
are encrypted, however, they make the certificate useless for getting an idea
about the legitimacy of who you are dealing with. They also don't tend to
carry the warranties that other ones do (and for good reason, who would
underwrite that procedure?).
The short (Score:2, Informative)
Netcraft has developed a service to help banks and other financial organizations identify sites which may be trying to construct frauds, identity theft and phishing attacks by pretending to be the bank, or are implying that the site has a relationship with the bank when in fact there is none.
Here's the competition (From Google):
About Comodo:
Comodo is the leading WebTrust-compliant enterprise solutions provider for E-commerce Security Solutions. Firmly established in 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/s
Re:SSL certificates in 2004 (Score:1, Informative)
Re:Defeats the purpose of SSL? (Score:5, Informative)
There would, of course, need to be a way to easily differentiate between encrypted and non-encrypted sites just like now.
Mozilla has a warning for this... (Score:4, Informative)
you are misinformed (Score:4, Informative)
RTFA or quit trolling. The problem is not the SSL certificates or who creates them, but the browsers accepting a "plain" encryption scheme when setting up the secure channel. I haven't actually seen this but it's entirely within reason that a "plain text" encryption was available in the SSL libraries for debugging communications in SSL apps.
I think it should be fairly simple to update the browsers so they require some encryption by default. Voila. Problem solved and we don't have to kill OpenSSL or "pay a root certificate authority" for the privilege of having encryption.
Re:Do people even see the lock? (Score:5, Informative)
OWASP [owasp.org] is a good start.
Re:Open SSL contributes to the problem... (Score:4, Informative)
If a protocol can be weakened by someone generating a long bit-string, then that protocol isn't worth much in the first place.
Public knowledge of SSL (incarnated in the openSSL source) is not the problem. Rather, the problem is twofold:
- 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 [gnupg.org] model of PKI is so much better than X.509, so it would fix the untrustworthy hierarchy issue above. But, even more than X.509, it expects all the end users to understand the basic ideas of PKI, not just "look for the little lock and click those dialogs as soon as they come up". sigh...
Re:It doesn't matter (Score:5, Informative)
Verisign does. After failing to get an account migration problem fixed via email, I finally resorted to calling them. The rep asked for my username and password to verify my identity and couldn't understand why I refused to give out my password over the phone. I asked him if the passwords were stored in their database in plaintext or if he was going to check it by logging on, but he wouldn't tell me.
Re:'splane it to me Lucy (Score:4, Informative)
Their site would be an exact replica meant to steal your information. So, firms would beat into their customers to look for the 'lock' or the https:// before a URL to make sure that it was the right site.
With plain text encoding on an https site, you still get the comfort factor of the lock (i think), and the https://, so once again, the morons who don't look at the complete URL are going to be victimized.
IE had a bug where a certian control code would make the second part of the url (the @and everything after it) completely invisible. This has been fixed.
Re:Defeats the purpose of SSL? (Score:3, Informative)
I do not see anything in IE's config to disallow this, except perhaps disabling SSL3 all together. That seems excessive. I hope someone can post a correction to this.
Re:SSL certificates in 2004 (Score:3, Informative)
I agree ethics in business is important.. witness Worldcom and Enron if you want something more recent than the 1980s.
We don't charge the wads of do some companies do, but I would like to think we are both 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...
Tip for Safari users (Score:5, Informative)
To enable the Debug menu see this tip [macosxhints.com].
Re:The lock is not important (Score:5, Informative)
Unfortuantely, you have no clue where the form is going to be submitted to.... Just looking at the source is not enough -- there can be an onsubmit handler defined in one of the dozen scripts linked into that page that rewrites the action URI to a (HTTPS, sure) URI pointing at some other server. Like the server of the guy who just performed a man-in-the-middle attack on the unencrypted data channel you and the store were using...
The only way to prevent this is to serve the page the uset types the credit card number in as https and have the user check that _that_ page is actually what it's claiming to be.
All this apart from the fact that if you type any text into a web page that web page can immediately phone the text home (using toys like XMLHttpRequest, SOAP, etc). So don't EVER type a credit card number in a page whose origin is not guaranteed.
Re:The lock is not important (Score:3, Informative)
Enjoy!
Re:The lock is not important (Score:2, Informative)
Re:Bollocks (Score:2, Informative)
Re:Mozilla has a warning for this... (Score:4, Informative)
In Mozilla go to Preferences -> Privacy & Security -> SSL -> Edit Ciphers -> Extra SSL3/TLS.... Then you'll see the two modes of NULL encryption,
No encryption with RSA authentication and a SHA1 MAC
No encryption with RSA authentication and a MD5 MAC
If you click on the cipher details button, you'll see that the effective key size is 0 bits.
You should also consider disabling SSLv2, since it is cryptographically broken (unless you have to use a site which doesn't support the newer TLS).
Note that this TLS/SSL non-encryption mode potentially applies to all TLS/SSL-enabled applications, not just web servers/browsers. You could argue that in some of those (such as email SMTP+STARTSSL), that using these modes almost makes sense if all you want is authentication.
Doesn't work in Firefox 0.8 or IE 5.50.4807 (Score:4, Informative)
I tried using
openssl s_server -nocert -ciphers eNULL:aNULL:NULL -www
as well as
openssl s_server -cert mycert.crt -ciphers eNULL:aNULL:NULL -www
In both cases, both browsers refused to connect, saying that there were no shared algorithms (Firefox), or simply giving a error page (IE).
In all cases, openssl gave me messages similar to
332:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c
Perhaps this does not qualify as "most browsers", but I'm sceptical of this report.
Re:It doesn't matter (Score:5, Informative)
So am I, actually. What you shouldn't do is to give out your password on the phone when someone calls you. That's how they trick you. "Hi, this is so-and-so calling from Verisign. Can I have your date of birth and mother's maiden name?" But if you call them, you know who they are. Who cares if you give out your password over the phone.
One time at work, I got locked out of my account for typing in my password 3 times (actually it happened quite frequently due to their lame-brain "user must change password every 6 months" policy). I called the help desk to have them reset my password, but they refused to give me the temporary password over the phone.
I was impressed. After all, they had no confirmation of who I was other than the fact that I was calling from the phone on my desk. So instead they sent me a voice-mail and I had to type in my voice-mail password. But my new found faith in MIS was quashed when I listened to the message: "Your new password is 'password'. That's p-a-s-s-w-o-r-d."
-a
Re:Funny but you have a point... (Score:1, Informative)
Re:Funny but you have a point... (Score:5, Informative)
You might be interested in the one-time use Credit Card that I have. From MBNA [mbnanetaccess.com], it requires that you get one of their cards, and then sign up for an online account; afterwards, you sign back in to the online page, and then can set limits + expiration dates on any given purchase. I use it whenever a physical card isn't required by the vendor, which includes over the phone transactions etc. Works with my Mac OS X and Safari.
Misuse of Lock icon.. (Score:4, Informative)
Bruce Schneir: Ten Risks of PKI... (Score:2, Informative)
Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure [schneier.com]
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...
Re:Anybody got a list of "BAD" Cert providers? (Score:3, Informative)
-Lucas
Re:Anybody got a list of "BAD" Cert providers? (Score:3, Informative)
-Lucas