Tag Archives: HTTPS

The Challenge of Keeping Users Safe Online

We have trained users to look for a padlock next to a website’s address like it means that you are safe.

Unfortunately, as we all know, it hasn’t quite worked out very well. At least not for us.

Expecting the average user to understand what the padlock means – and doesn’t mean – is unreasonable.  In fact, it is doomed to fail.

For example, if a user is presented with a login screen for Netfilx.com, complete with a Netflix logo and a green padlock, are they likely to realize that netfILx is not netfLIx?  Not likely.

What the padlock actually represents is the fact that the conversation is private, not that it is secure.  When SSL (what is behind HTTPS)  was invented, the object was to convince a skeptical public that providing their credit card to buy something online was safe.  The people who created that did not have a crystal ball to help them see what scam artists would do in the future.

While that HTTPS conversation may be private, you may be talking to Satan.

Are we all doomed?

Actually not, but we are dependent on our technology providers to do more than they have done.

As Google’s Emily Schechter says in the article quoted above.

Google has already started to do more and they plan to continue doing more.

Rather than, for example, putting a padlock next to a website name saying it is secure when it is not, how about putting the message NOT SECURE next to its name.  After all, no one is going to try and con you into falsely thinking their website is not secure, hence you are playing the hacker’s game against them.  Google has already started doing this and as long as you and I understand what all that means, it will likely work better.

Another example of giving users a negative indicator of trust is when when you go to a website and get a message that says YOUR CONNECTION IS NOT PRIVATE.  No one would lie and say that.

How about if you try to visit a website and instead you got a bright red screen with a message that says DECEPTIVE SITE AHEAD?  You are probably going to think more carefully about visiting that site than if you don’t see a little green padlock.

Even the extended Validation, or EV, HTTPS certificate is far from perfect.  We saw this recently with Stripe.  As a test, a researcher got an EV certificate for a fake Stripe website because while the real Stripe was incorporated in Delaware, the fake Stripe, did exist, but was incorporated in a different state.  Would a hacker have to spend more money, take more time and be more committed to pull this off than some?  Yes.  But it is far from impossible.

On the other hand, a bright red screen with squawking ducks telling you to, err, DUCK!, is much more likely to get your attention, unlikely to be faked and much less likely for the average user to get fatigued about.  Or fall for the bad guy.

Google Chrome, the majority browser, is already working on these things.  They don’t think this is simple, but they have admitted what we all know  – that what we are doing now is not working.  The bad guys are winning.

So look for more negative indicators of trust and heed their warning.

Information for this post came from Troy Hunt.

Facebooktwitterredditlinkedinmailby feather

Google Wants All Web Sites To Use HTTPS:

While I have whined that HTTPS:// is not super secure, it is certainly way more secure then not using HTTPS.  Technically known as SSL or more correctly TLS, when you type HTTPS://, it signals the web browser to work with the web site to encrypt all of your information.

For the last year or two, Google has been waging a quiet war to encourage web site owners to use TLS on every page of every web site.

The way they are doing this is by changing how Google’s Chrome browser and Google’s search results handle non HTTPS-protected web sites.  Since Chrome is now the majority browser out there, having a more than 50% share and Google itself  is and has been the predominant search engine forever, how Google treats non HTTPS-protected web sites is important.

So what, exactly, is Google doing?  There are a couple of things they have already done and more to come.

First, and pretty important for folks that depend on customers finding them through Google search results, if your website does not support HTTPS, Google will lower where you show up in the search results.  That’s right,  If you don’t support HTTPS, you will show up farther down the list.  For people who depend on search results, even if you buy ad words, you are going to show  up lower on the list if you do not support HTTPS.

Next thing they have already done is to pop up a red warning in the address bar that says NOT SECURE, if your web site asks for a userid and password and it doesn’t do that over an HTTPS connection.  That probably makes sense – after all everyone wants their userid and password to be protected,  but there are still many web sites that don’t use HTTPS to protect your login.

Come this October, Google is going to label all web pages that request ANY INPUT AT ALL as not secure if it is not done over HTTPS.  That means that if all you have is a brochure web site and you have a search box on your web page, Google will flash up that red NOT SECURE warning in the address line.

Finally, the last announced phase of this effort is to label ALL WEB PAGES that are not using HTTPS as NOT SECURE.  This is the exact opposite of what they were doing a few years ago when they labelled those pages that did use HTTPS as secure by displaying the padlock icon.

The plan here is to sort of shame web site owners into using HTTPS and I think it is a plan that is working.  We are seeing many more web sites using HTTPS than ever before.

And, what Google’s Chrome does is usually done by Firefox sooner or later, in some cases, at the same time.  Microsoft’s browsers typically lag way behind, but between Chrome and Firefox, you cover the vast majority of the user base.

Sooooooooo, if you do not currently support HTTPS, now is the time to start handling that.  It really is not that hard to do, is not very expensive and sends the right message to your customers and visitors.  After all, who wants their web site visitors to be greeted by NOT SECURE?

One last thing, there are two types of HTTPS, domain validation (DV) and extended validation (EV).  With DV, which is, by far, the predominant type of HTTPS in use, your traffic is encrypted, but you have no assurance that who you think is the owner of a web site is, in fact the owner.  With EV, you get an extra level of assurance that you are really talking to your bank and not someone masquerading as your bank.  But, EV certificates are more expensive than DV certificates, so most sites just use DV.  More about this in a future post.

If you have questions about setting up HTTPS on your web site, please contact us.

Information for this post came from ZDNet.

Facebooktwitterredditlinkedinmailby feather

The End of the Road for HTTP://

Google has decided to lead the way on web, as it often has.  In this case, Google has announced that as of January 1, 2017, web pages that transmit credit cards or ask for passwords over HTTP (vs. HTTPS) will be marked with this flag in the address bar:


Some of will say that this is as it should be, and I will be the first to agree with you. Any web site that asks for your userid and password over an unsecure connection needs to be flogged appropriately.  Likewise if a web site asks for credit card information in clear text, it is, at the very minimum, in violation of the merchant agreement that the company signed with its bank.  It too needs to mend its ways.

My guess is that there are way too many sites that will get scooped up in this NOT SECURE net come January 1.  It likely will be like the changeover to chip based credit cards.  When last September came, people said “crap” – or some to that effect – they aren’t kidding;  they really are going to leave this deadline in place and companies started doing what they should have been doing a year prior to that. However, they discovered that fixing this problem was harder than they thought.  As a result, almost a year past this deadline, there are still hundreds of thousands of businesses that have not converted.  I do predict that almost every single major site will have this handled well in advance.  No doubt Google is already talking to major web properties privately.

In this case, people may think that Google will blink.  While no one knows for sure, I would not bet on that outcome.

But this is not where it ends.  It ends with, in Google’s view, the death of HTTP.

The next step is to label all pages that are loaded without encryption when the user is in incognito mode as NOT SECURE.

Finally, the last step is to label all pages loaded with HTTP as NOT SECURE.  They have not provided a date for this, but it may well be during 2017.

Of course, this only affects users who use a Google browser on their computer or phone, but according to W3Schools, this is over 72% right now – and growing.  Last August, that percentage was only 64% (see stats here).

Since most businesses do not want their customers to see that message when going to their web site, they will finally, reluctantly, migrate all traffic to HTTPS.

And to be clear, this does not mean optionally HTTPS;  this means mandatory HTTPS.

The biggest challenge will be for companies that have hundreds or thousands of web sites.  They will need to touch each one of them.  They may need to order an SSL certificate for each one.  It will require some work.

My recommendation is to start now and avoid the New Year’s Eve rush.


Information for this post came from Google’s security blog.



Facebooktwitterredditlinkedinmailby feather

Yet Another Reason Why HTTPS is a FAIL!

Merchants want you to believe that HTTPS equals secure.  I keep saying that it doesn’t.  Here is another story for my side of the argument.

First, a little background.  If a web site want to support HTTPS (also known as SSL or TLS), they need to have a certificate.  The certificate is used as part of the process of generating an encryption key for each session.  The owner of the web site buys (or gets one for free) a certificate and depending on the type of certificate, the buyer has to prove, more or less, that they own the domain that they want a certificate for.

Why do they have to prove they own the domain?  Because if they didn’t have to prove they own it, anyone who wanted to could buy a certificate and install it and launch a bogus web site that pretends to be Facebook or Amazon or whoever.

Using the standard methods that certificates use, any certificate authority – and there are hundreds of them – can issue a certificate for your web site.  As long as that certificate authority is trusted by your browser, you will have no clue that the web site that you think is owned by Amazon or Google or whoever is not legit.  You will see the padlock and everything.

To make things worse, under these circumstances, an attacker can even create a bogus Google.Com or Amazon.Com, fool your browser into going to that site (using DNS spoofing or other techniques) and you now think you are at the real Google or Amazon.

Under the way things normally work with certificates, any certificate authority anywhere in the world can issue a certificate for your domain.

On some operating systems/browsers, you can disable which of the hundreds of certificate authorities you want to trust.  That doesn’t solve the problem of a hacker imitating your web site and someone believing it, but it does solve the problem of you trusting sites certified by authorities in say China.

Curiously, it is pretty easy to disable, say, a certificate authority in China on Android but it is literally impossible for you to do this on an iPhone.  This is because Apple’s philosophy is that Apple knows best.  For details on how to do this (it is  pretty geeky) on different environments, check the link below.

SO, now what is the new problem.  The problem is that a Chinese certificate authority, WoSign, had a bug in their software that allowed people to get a certificate for a domain, say Google, if they could show that they could control a sub-domain, say mitch.google.com.  A researcher tested this by using this bug to get a certificate for the popular web site GitHub and also for a Florida University.  When they explained the problem to WoSign, they did revoke the certificate to GitHub, but did not revoke the one to the university.  This is leading some people to speculate that they do not know what certificates they issued.

But remember that your browser trusts WoSign, so even though they are issuing bogus security certificates, your browser will trust them.  If  you are not using an iPhone, at least if you are motivated, you can decide that YOU are not going to trust WoSign, but I doubt very many people will go to that trouble.

Remember I said that WoSign revoked the bogus certificate to GitHub.  Well that is nice, but it turns out, for a variety of reasons, certificate revocation doesn’t actually work.  So while that GitHub certificate is revoked in theory, it may still work in practice.

While I don’t have a better answer for HTTPS, I can say with some confidence it is seriously broken.  There are some possibilities like DNSSEC+DANE or certificate pinning, but very few web sites, in the grand scheme of things, have the ability to do this.

Which is why I keep saying that SSL is broken.  We are giving people the delusion that things are secure, when they are not really very secure.

We really ought to do something about this before some hacker comes up with a really creative way to steal a lot of money.

Information for this post came from The Hacker News.

Information on how to remove the trust for certain certificate authorities can be found at CertSimple’s blog.

Facebooktwitterredditlinkedinmailby feather