Verisign Wimpy Warnings

I was visiting some phishing sites (as you do) and came across this one. These things have short lifetimes; it may not be there when you check. It is/was an eBay spoof page, spam-advertised, which had a spiffy-looking Verisign Site Seal in the bottom corner, which was actually linked to the correct URL at Verisign! Perhaps this is a result of them just saving the eBay page to disk and whacking it up on the webserver. Anyway, I know no-one ever clicks on these things, but I thought I’d try it, to make sure I got a scary message from Verisign.

In fact, what I got was this:

Unable to validate this seal

We are unable to verify the status of this seal at this time. Please try again later.

Click here to learn more about SSL Certificates.

Wow, that has me scared. I’ll be sure not to type my eBay credentials into the site now…

5 thoughts on “Verisign Wimpy Warnings

  1. jmdesp: Indeed; it uses the referrer to check, I believe.

    EV may well become a target; but getting an EV cert as a phisher is no easy feat. Read the spec. If you find flaws in it, let us know. :-)

    bugging: It seems no-one has yet submitted this site to the appropriate phishing lists.

  2. I do not honestly believe that SSL-certificate verification effectively serves any useful purpose for the overwhelming majority of users. Things like DNS spoofing simply do not occur to ordinary people. If typing http://www.example.com into the browser’s address bar brings them to the site, then the site is http://www.example.com by definition. If further verification is needed, you maybe retype the address and see if it still brings you to the same site.

    Frankly, just getting most people to realize that the From: field in an email message can be spoofed is an uphill battle.

    I’m not saying that sites shouldn’t have SSL certificates, but I don’t think that the exact wording of the unverified-cert error message is going to matter all that much in practice. It should probably be better, yeah, but nonetheless, either way, people who understand what it means for a certificate to not belong to the site that is presenting it are going to understand what might be going on, and people who don’t aren’t.

    The number of false alarms also does not help. The overwhelming majority of certificate mismatches are because a server has more than one FQDN and doesn’t have a separate cert for each one. Personally I think one cert ought to be able to cover multiple FQDNs for the same server, which might help with that somewhat, though people would still add more domains, especially subdomains, after the issuance. Maybe there could even be a wildcard provision (so that a cert could be good for example.com, *.example.com, example.net, *.example.net, example.org, and *.example.org), but that creates problems of its own. (citibank.example.com is good enough for at least 10% of users to think it’s a Citibank website, for instance — although, example.com had to pay money to get that cert, and it can presumably be revoked, probably without refund, if they abuse it in that manner. Still, it’s an important consideration.)

    Also, the overwhelming majority of expired-cert warnings are because the user’s computer clock is off by n years due to a dead RTC battery on an old motherboard. If the browser is going to be checking dated items for expieration, shouldn’t it check to see what the time *really* is? (Granted, how to check that in a manner that can’t be subverted is perhaps a non-trivial problem.)

    Even without the false alarms, though, you can still only effectively alert people to problems that they’re willing to consider as a possibility.