Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×

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.'"
This discussion has been archived. No new comments can be posted.

Phishing Scams Incorporate SSL Certificates

Comments Filter:
  • by valence ( 164639 ) * on Wednesday March 10, 2004 @12:55AM (#8518061)
    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...

    • by RoundSparrow ( 341175 ) on Wednesday March 10, 2004 @12:57AM (#8518081)
      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.
      • by mrseigen ( 518390 ) on Wednesday March 10, 2004 @12:59AM (#8518094) Homepage Journal
        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.
        • Or worse yet... the people who have the root passwords to the server walk off with the data with no hacking needed.
          • by gilrain ( 638808 ) <gilrainNO@SPAMlunarpolicy.net> on Wednesday March 10, 2004 @01:16AM (#8518181) Homepage
            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.
            • by Anonymous Coward
              Or, still even worse, the guy with the credit card travels to Soviet Russia where his credit card spends *him*.
            • by WebCowboy ( 196209 ) on Wednesday March 10, 2004 @04:57AM (#8519131)
              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.
      • 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.
        • by Frymaster ( 171343 ) on Wednesday March 10, 2004 @02:51AM (#8518646) Homepage Journal
          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.

    • by miracle69 ( 34841 ) on Wednesday March 10, 2004 @01:00AM (#8518095)
      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.
      • by nacturation ( 646836 ) <nacturation AT gmail DOT com> on Wednesday March 10, 2004 @01:32AM (#8518276) Journal
        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.
    • 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.
    • by rcpitt ( 711863 ) * on Wednesday March 10, 2004 @02:12AM (#8518495) Homepage Journal
      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?

  • by ddent ( 166525 ) * on Wednesday March 10, 2004 @12:58AM (#8518082) Homepage

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


    • by nlinecomputers ( 602059 ) on Wednesday March 10, 2004 @01:27AM (#8518240)
      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?
      • 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
        • 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

    • 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 do
      • 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
    • by Beryllium Sphere(tm) ( 193358 ) on Wednesday March 10, 2004 @04:51AM (#8519104) Journal
      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.
      • 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 ot
  • The short (Score:2, Informative)

    by Idealius ( 688975 ) *
    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 t
  • Average Joe (Score:5, Insightful)

    by LordK3nn3th ( 715352 ) on Wednesday March 10, 2004 @01:00AM (#8518097)
    Average Joe doesn't have any idea what encryption is or why it's important. Average Joe just wants to point, click, and buy. Hell, I rarely pay attention to it.

    Isn't it more likely that people were suckered in not because of the SSL trick but rather simply from "scam" or mimic pages instead?
  • It doesn't matter (Score:4, Insightful)

    by TheDarkener ( 198348 ) on Wednesday March 10, 2004 @01:02AM (#8518103) Homepage
    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!
    • 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 passwo
      • 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 thi
        • by jadavis ( 473492 ) on Wednesday March 10, 2004 @03:25AM (#8518767)
          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.
    • Re:It doesn't matter (Score:5, Informative)

      by PacoTaco ( 577292 ) on Wednesday March 10, 2004 @02:08AM (#8518472)
      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.

      • 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 (Score:5, Informative)

        by God! Awful 2 ( 631283 ) on Wednesday March 10, 2004 @06:12AM (#8519400) Journal
        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
  • by chrispyman ( 710460 ) on Wednesday March 10, 2004 @01:06AM (#8518121)
    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?
    • by realdpk ( 116490 ) on Wednesday March 10, 2004 @01:28AM (#8518251) Homepage Journal
      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.
      • 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 ce

        • 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. :)
      • SSL has an authentication-without-encryption mode but no encryption-without-authentication mode? WTF?
    • by femto ( 459605 ) on Wednesday March 10, 2004 @01:51AM (#8518384) Homepage
      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?

  • by kongjie ( 639414 ) <(moc.cam) (ta) (eijgnok)> on Wednesday March 10, 2004 @01:06AM (#8518123)
    ...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.

    • by Anonymous Coward on Wednesday March 10, 2004 @01:42AM (#8518331)
      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.
    • by techno-vampire ( 666512 ) on Wednesday March 10, 2004 @01:54AM (#8518408) Homepage
      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.
      • by vanyel ( 28049 ) * on Wednesday March 10, 2004 @02:21AM (#8518532) Journal
        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.
      • 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.
        • 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.
  • 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...
    • by devnullify ( 561782 ) <[ac.toortog] [ta] [smitk]> on Wednesday March 10, 2004 @01:21AM (#8518214) Homepage
      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.
    • you are misinformed (Score:4, Informative)

      by wotevah ( 620758 ) on Wednesday March 10, 2004 @01:49AM (#8518369) Journal

      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.

      • 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

        • Someone at Microsoft decided that it's better to not scare users with too much technical information, and give them just bits of it (literally - it works/ it didn't work). IE is not exactly known for its informative error messages.

          "Page cannot be displayed". Could it be because the site fell off the face of the planet, the file is missing on the server or your office network is down ? doesn't matter to IE so long as you can feel warm and fuzzy inside that it tried and it's definitely not your fault. Yea

      • 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 v

    • by rekt ( 760792 ) on Wednesday March 10, 2004 @02:04AM (#8518456)
      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 [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...

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

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

      Look here [openssl.org]

      Tells you how to install your self-signed certificate into your clients browsers.

      For anyone with too many clients to do this practically... well if you have that many clients you should be making enough money to buy a certificate from a trusted authority.
  • by FiberOpPraise ( 607416 ) on Wednesday March 10, 2004 @01:10AM (#8518147) Homepage
    Don't worry, I make sure to type all of my URL's now including onces such as:
    http://slashdot.org/comments.pl?sid=99888&threshol d=0&mode=thread&commentsort=0&op=Reply
    Sometimes they take a while but it pays off!
  • an old timer i know (Score:5, Interesting)

    by Spetiam ( 671180 ) on Wednesday March 10, 2004 @01:14AM (#8518165) Journal

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

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

    • 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
  • Meh (Score:5, Insightful)

    by Xenographic ( 557057 ) on Wednesday March 10, 2004 @01:23AM (#8518227) Journal
    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.
  • by BinaryJono ( 546830 ) on Wednesday March 10, 2004 @01:29AM (#8518255)
    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! (Score:4, Interesting)

      by ddent ( 166525 ) * on Wednesday March 10, 2004 @01:50AM (#8518371) Homepage
      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).
  • by MajorDick ( 735308 ) on Wednesday March 10, 2004 @01:30AM (#8518262)
    "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 ?
  • by Jasn ( 106824 ) on Wednesday March 10, 2004 @01:43AM (#8518338)
    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.
  • 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?!

  • by Anonymous Coward on Wednesday March 10, 2004 @01:48AM (#8518364)
    It defaults to poping up a warning that you are using low grade encryption. Plain text qualifies!
    • by dmeranda ( 120061 ) on Wednesday March 10, 2004 @05:31AM (#8519265) Homepage
      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.
  • by kasperd ( 592156 ) on Wednesday March 10, 2004 @01:50AM (#8518370) Homepage Journal
    I'd like to verify if my browser is vulnurable.
  • by Anonymous Coward

    I think the site you were looking for is here [cockeyed.com].

  • by thedillybar ( 677116 ) on Wednesday March 10, 2004 @01:58AM (#8518429)
    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..

    • by windside ( 112784 ) <pmjboyleNO@SPAMgmail.com> on Wednesday March 10, 2004 @02:09AM (#8518483)

      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.

    • by BZ ( 40346 ) on Wednesday March 10, 2004 @03:21AM (#8518750)
      > 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.
  • Tip for Safari users (Score:5, Informative)

    by Concerned Onlooker ( 473481 ) on Wednesday March 10, 2004 @03:19AM (#8518744) Homepage Journal
    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 [macosxhints.com].

  • by Sloppy ( 14984 ) * on Wednesday March 10, 2004 @03:26AM (#8518770) Homepage Journal
    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. [gnu.org] These dudes made an SSL library that can use PGP certs. It's a step in the right direction. Kick ass.

  • by SuperKendall ( 25149 ) * on Wednesday March 10, 2004 @04:00AM (#8518883)
    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.
  • by Ed Avis ( 5917 ) <ed@membled.com> on Wednesday March 10, 2004 @04:55AM (#8519124) Homepage
    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.

  • by jburst ( 50329 ) on Wednesday March 10, 2004 @05:27AM (#8519249)
    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 [ietf.org]) But browsers don't use it. No browser, even going back to Netscape 2.0 supported NULL or ADH by default. If you wanted these cipher suites, you have to explicitly turn them on.

    Go ahead, try it. Take a test Apache/mod_ssl server and change the SSLCipherSuite config line to:

    SSLCipherSuite ADH:NULL

    and restart the server. Now try to connect to it.

    In IE, you'll get the generic "The page cannot be displayed" error. In Mozilla/Firefox, you'll get "Firefox and cannot communicate securely because they have no common encryption algorithms."

    I welcome a real-world example of this "attack" that will actually work on a default-configured web browser.

  • by Gollum ( 35049 ) on Wednesday March 10, 2004 @05:45AM (#8519321)
    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.
  • by nagora ( 177841 ) on Wednesday March 10, 2004 @07:08AM (#8519553)
    It's good to have the data encrypted but the idea that the companies running the certificate issuing system are trustwrothy is laughable.

    TWW

  • by slashkitty ( 21637 ) on Wednesday March 10, 2004 @11:17AM (#8521087) Homepage
    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 [chase.com]. 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.

E = MC ** 2 +- 3db

Working...