Tag Archives: extended validation

An Equifax Lesson For Everyone To Learn

One of the MANY lessons to be learned from the Equifax breach is how not to handle a breach.  Here is just one of those lessons and it is a lesson for BOTH users and webmasters.


When the breach finally became public – months after it happened – they created a web site for victims to go to in order to find out about the breach.  That web site, equifaxsecurity2017.com, looks like this:

You will notice that it has the Equifax logo on it and that it has the little green padlock indicating that it is encrypted, but, of course, anyone can steal the Equifax logo and put it anywhere they want – like right here, for example:

But that doesn’t mean that the site belongs to Equifax.

You will notice that the web site URL includes the name Equifax, but so does www.equifaxsucks.com (yup, a real site.  Totally benign, but real – see below).  So, just because the word Equifax is in the web site name does not mean that it is owned by Equifax.

In this case, since the word Equifax is probably a trademark, they can, eventually, get this site taken down if they want.   But, Equifaxx is not a trademark (note that there are two xxs and not one).  That site is real (see below) and curiously, it seems to belong to EXPERIAN, their biggest competitor.  Why they didn’t buy up similar sounding web sites for $10 a year each is beyond me and a lesson to learn from this.  Here is Equifaxx.com.

But that is not the worst failure.

Why wouldn’t they send you to a site that you KNOW is theirs. Send people to BREACH.equifax.com or Equifax.con/BREACH or something like that?  At least people know that they are going to a site owned by the company that they are looking for.  In fact, this site was hastily set up and initially, if you looked, it wasn’t even owned by Equifax, it was owned by an Equifax vendor.

Still, that is not the worst failure.

Here is the worst failure and the lesson for everyone – users and webmasters both.

While they secured the site with HTTPS – what we geeks call an SSL (or more correctly a TLS) certificate protected site, they used the cheapest, least secure certificate they could find.  What is called a DOMAIN VALIDATION certificate.  All that certificate proves is that the person who requested it – you, me, my kid, whoever – had sufficient access to the web site to store a file on it.  If the site had been hacked, a hacker could buy that kind of certificate.


Now lets look at Apple’s website for a minute (see below).

Note that the address bar is different from the address bar on Equifax’s breach web site.  This has the name Apple, Inc [US] in green in front of the URL.  This is an EXTENDED VALIDATION certificate.  In order for Apple (or Equifax) to get this, they had to prove they were Apple and not Mitch.  This is a higher level of verification and a more expensive certificate.

It is designed to give the user a higher level of confidence that they really have landed on an Apple – or Equifax – web site.

Why is this important.

One more time, Equifax is the poster child for how to screw up.

Equifax’s offical Twitter account tweeted not once, not twice but three times, an incorrect web site for people to go to.

Instead of sending people to EquifaxSecurity2017.com, they instead sent people to SecurityEquifax2017.com.

Now it turns out that this alter ego site was set up by a security researcher, so even when Equifax’s crisis communications team sent people to the wrong site, it didn’t infect their computer.  But if it was a hacker’s web site, it certainly could have.  Or asked for and stolen even more information.  Here is a look at the wrong web site.  This site proved it’s point so it has been taken down, but the Internet never forgets, so here is a copy from the Wayback machine, the Internet Archive.

Notice that this web site ALSO had a green padlock and was accessed using HTTPS.

Which is why, as users, we need to look for the company name in the address bar and why, as webmasters, we need to pay a little bit more for an extended validation or EV certificate.

In this case, if, say, there was a phishing campaign and it got people to click on the link and it sent people to a bogus web site, the extended validation certificate is much harder to forge.

Be a smart Internet user.  Look for the extended validation certificate.

Now that you are aware, as you surf the web, notice what companies have extended validation certificates.  And which ones do not.

Information for this post came from The Verge.


Time to UP the Ante on SSL

As I have been writing about lately, the browser makers, Google and Firefox – and to a much lesser extent Microsoft, are pushing the envelope to get web site operators to switch to always on SSL (AKA HTTPS).  Well, that is a good start, but certainly not the end game.

Why do they care?  Because it is much harder to eavesdrop on HTTPS traffic than it is to eavesdrop on HTTP traffic.  Remember, eavesdropping is a bit of a loose term.  Not only can someone listen in on what you are sending, but they can also fake the RESPONSE back from a web site.  In that case, you THINK that what you are getting back in your browser is coming from a web site you trust, but in reality, you are seeing what the hacker wants you to see.  Sometimes that means changing something here or there, but other times it could mean a wholesale replacement of the web page.

While not impossible to do this under HTTPS (also called SSL or TLS – while there are subtle differences between these, for the purpose of this conversation, they are the same), it is way more difficult for a hacker to do.

But there are a lot of subtleties when it comes to how a web site implements HTTPS.  Most of the time web site operators choose the easiest one;  on rare occasion, they choose the best options.  I will briefly talk about some of the options, but for the most part, it is geek-speak. There is one option that will be the focus of the rest of this post that is important for an end user to understand.

First the geeky part –

There are a number of things that the web site operator should do to enhance security; here are just a couple.  These are out of the user’s control, but we can help the web site operator get closer to the best option instead of the easiest option.

The web site should enable HSTS or HTTP strict transport security.  This ensures that even if YOU don’t enter the S in HTTPS, the browser will do it for you.

HTTP Public Key Pinning – when this is enabled it ensures that an attacker cannot use an SSL certificate obtained illegally from another certificate authority to pretend that they are the site you intend to visit.

Secure cookies – setting secure option helps to protect your information from being stolen by other web sites.

Now here is the part that the user can easily see.

There are two kinds of SSL certificates; one is called domain validation (DV) and the other is called extended validation (EV).

While we talk about the HTTPS encrypting the traffic so that no one can eavesdrop on it, there is another feature of the SSL certificate and that is to ensure that the owner of the web site is, to a much higher level of assurance, who you think it is.

DV certificates ONLY encrypt the traffic to prevent eavesdropping.  Extended validation certificates provide a level of assurance that you are talking to who you think you are talking to.

First, an example.

Here is a screen shot of Vectra Bank’s home page:

Click for a larger view

Notice in the address bar, on the left side, you have the padlock and the word secure.

Here is a screen shot of J.P. Morgan Chase Bank’s home page:

Click for a larger view

Notice to the right of the padlock and the left of the address it says JP Morgan Chase and Co. [US] .

Vectra is using a domain validation certificate and Chase is using an extended validation certificate.

What this means is that you have a higher level of assurance that, when you visit the Chase web site, that it is really owned by JP Morgan Chase and Co.  That is the value of EV certificates.

OK, so that is a theoretical conversation, let’s bring it down to the practical.

Guess how many web sites have an SSL certificate that includes the name PAYPAL?  When you visit Paypal and enter your credit card, you would like to know that it really is The real Paypal.

Maybe 10?  How about 20?  Some of you probably said 1.

The real answer is 15,270.  And that is just from one certificate authority, Let’s Encrypt.  Of those 15,000 plus domains,  over 14,000 were for phishing web sites.

If you are a user and you see the SSL padlock (which is all you get with a DV certificate), you have no way of knowing whether you are visiting a legitimate web site.

Unfortunately, many of the biggies haven’t figured out this is a problem.  Facebook.  Linkedin.  Amazon.  They all use DV certificates.  That could be OK as long as you know what the domain address is and you type it in manually, but for many of these sites, they have related domain names that contain the company’s name but are different from the company’s main web site.

If we use that Paypal example, probably some of those 15,000 plus domains are actually owned by Paypal, but which ones?

The moral of the story is, as a consumer, look for the extended validation and ask questions if you don’t find it.

Information for this post came from Bleeping Computer.