Tag Archives: HTTPS

Beware: Changes to HTTPS Certificate Requirements

This is a follow up to yesterday’s newsletter alert and sorry, it is a bit technical, but I will try to make it as untechnical as possible.

Up to a few years ago, if you ran a website, you could buy an HTTPS (also known as a TLS or SSL) certificate that didn’t expire for 10 years. The problem is that if something happened, a malicious actor could continue to use that certificate and masquerade as a legitimate website owner, possibly for an additional 9 and half years.

There was a certificate revocation process to stop compromised certificates from being used any more, but it never really worked.

As a result, a few years ago, the board that oversees the browser makers (called the CA/Browser Forum) and the certificate authorities that issue certificates reduced the allowed lifetime for a certificate to three years. This was a lot better than 10 years, but still a malicious actor could use a compromised certificate for several years.

As the CA/Browser Forum continued to wrestle with how to deal with compromised certificates, they invented something called OCSP or the Online Certificate Status Protocol. The idea is that the user’s browser could look inside the certificate to find the OCSP web site that the certificate creator runs and a browser can use that webiste to see if a certificate is still good. The problem is that this process doubles the number of requests that is required in order to load a web page. For example, as I write this, the home page of Fox news requires 84 separate calls just to load that one page. Some might be an image or a video or it could be some code. If you have to check to see if the certificate for each of these loads is valid, now you have to make 168 calls, significantly increasing the time to display the results to the user.

And, what do if that web site is down, overloaded or takes too long to respond? Do you not display the page?

During this time the CA/Browser forum reduced the allowed lifetime of a certificate to just two years. Still a bad actor can do damage for a year or more, but each time, we reduce the window for malicious activity.

Then they came up with yet another standard called OCSP Stapling. With stapling, the website owner is responsible for checking to see if the certificate is still valid. A website will get an OCSP certificate from the certificate authority say every few hours. That is then “stapled”, securely, to the HTTPS certificate that is sent to the user’s browser. When there is, say, an hour left in the life of the OCSP certificate, the website owner orders a new one. It has an hour, say, to get it and that is an eternity in browser time. For a while not all browsers understood stapling but now they do.

BUT, there is nothing to force a web site to support either OCSP or STAPLING and many do not support either.

Sometime along this time, came Let’s Encrypt. Let’s Encrypt offers a lower security (but okay for many users) certificate, but it is free and it only lasts 90 days before it expires. Now we have really reduced the bad actor’s window of opportunity.

But Let’s Encrypt came with a new standard called ACME (this has nothing to do with the Road Runner ūüôā ). With ACME, once you get Let’s encrypt installed on your server, it AUTOMATICALLY renewed itself every 90 days. This completely eliminated the work for administrators to manage and Let’s Encrypt has now issued a BILLION certificates.

Of course the certificate authorities aren’t thrilled with someone giving away their product for free, even if it is a slightly lower security product.

There was an effort in February to reduce the lifetime of certificates to one year, but it failed to get approved at the CA/Browser Forum meeting. Administrators and certificate authorities complained about the workload, but if everyone implemented ACME or something like it, that problem goes away.

OK, so now you are up to date. Fast forward to 2020.

Like Google, Microsoft and others, Apple has a lot of clout. After the move to reduce the certificate life to one year failed earlier this year, Apple said you guys can do whatever you want, but we are not going to display any web page that has a certificate (and this is important) THAT WAS ISSUED AFTER SEPTEMBER 1, 2020 AND HAS A LIFETIME OF MORE THAN A YEAR PLUS A MONTH GRACE PERIOD.

This means that if you have a new certificate that has a two year life and someone visits your website from an iPhone, iPad or Mac after September 1, they will get an error message.

So basically, Apple forced the issue.

Once this was a done deal, Google Dogpiled.

This means that if you get a new certificate with a two year life after September one, about 80% of the world’s users will no longer be able to get to your website.

THIS is why the change is kind of important.

Got questions? Contact us. Credit: ZDNet

Security News for the Week Ending July 19, 2019

FTC Approves $5 Billion Fine for Facebook

The FTC commissioners reportedly approved an approximately $5 billion fine of Facebook for violating the 2011 consent decree in conjunction with the Cambridge Analytica mess.

To put that in perspective, Facebook’s revenue just for 4th quarter of last year was $16.9 billion and their profit for that quarter was $6.9 billion, so the fine represents a little less than one quarter’s profit.¬†¬† Still this is two orders of magnitude greater than the FTC fine of Google a few years ago.¬† The Justice Department has to approve the settlement and is typically a rubber stamp, but given this President’s relationship with social media, you never know.¬† Source: NY Times.

 

Why do they Want to Hack ME?

The Trickbot malware has compromised 250 million email addresses according to Techcrunch.  Besides using your email account to send spam, it does lots of other nifty stuff as it evolves.  Nice piece of work РNOT!

Why?  So that they can use your email to send spam.  After you, you are kind of a trusted person, so that if someone gets an email from you as opposed to a spammer, they are more likely to click on the link inside or open the attachment and voila, they are owned.

And, of course, you are blamed, which is even better for the spammer.  Source: Techcrunch.

 

Firefox Following Chrome – Marking HTTP web sites with “NOT SECURE” Label

Firefox is following in the footsteps of Google’s Chrome.¬† Starting this fall Firefox will also mark all HTTP pages (as opposed to HTTPS) as NOT SECURE as Google already does.¬† Hopefully this will encourage web site operators to install security certificates.¬† It used to be expensive, but now there are free options.¬† Source: ZDNet.

 

AMCA Breach Adds Another 2 Million + Victims

Even though American Medical Collection Agency was forced into bankruptcy as a result of the already 20 million+ victims, the hits keep coming for AMCA.¬† Another one of their customers, Clinical Pathology Labs, said that more than 2 million of their customers were affected by the breach.¬† They claim that they didn’t get enough information from AMCA to figure out what happened.

It is going to be interesting to see where the lawsuits go, who’s name(s) show up on the HIPAA wall of shame and who Health and Human Services goes after.¬† Given that AMCA filed for bankruptcy, it is very likely that Quest, CPL and AMCA’s other customers will wind up being sued.¬† Actually, Quest, Labcorp and the others are who should be sued because they selected AMCA as a vendor and obviously did not perform adequate due diligence.¬† Source: Techcrunch.

 

Another Day, Another Cryptocurrency Hack/Breach

This time it is the cryptocurrency exchange Bitpoint and they say that half of their 110,000 customers lost (virtual) money as a result of a hack last week.¬† The hack cost Bitpoint $28 million and they say that they plan the refund their customer’s money. One more time the hackers compromised the software, not the encryption,¬† Source: The Next Web.

Security News Bites For Friday July 6, 2018

NSA Deleting All Call Detail Records (CDRs) Acquired Since 2015

While the NSA is not providing a lot of details about what went wrong, the NSA is saying that it is deleting all CDRs acquired since 2015 because of technical irregularities that resulted in it receiving data that, likely, would be illegal under the current law.  They have been accused of breaking the law many times, but this is one of the few times I can remember that they admitted to breaking the law.

Because, they say, it is infeasible to sort out the legal data from the illegal data, they are deleting lots of data.

Gizmodo, in a bit of editorializing, asked if the “technical irregularities” were related to the “programming errors” the FBI said caused it to wildly inflate the number of encrypted phones that they could not access in various criminal cases.

While admitting that they screwed up is important, what would be better would be to get it right as they hoover up all of this data.  (Source:Gizomodo)

3 Weeks Until NOT SECURE Starts Showing Up In Your Browser

I wrote about this a few months ago, but now it is going to happen, so it is worth a reminder.

For all of those web sites that said that HTTPS was not important or a hassle or costs money, as of July 23, 2018, Google is going to flag your site as NOT SECURE in the address bar, every time someone visits your site.

While some visitors will ignore the warning, others will get freaked, especially if your site is not one that they visit often.

Now is the time – like in the next 21 days – to set up an HTTPS certificate for your web site.

By the way, in typical Google fashion, in a few months they will start presenting a pop up box that visitors will have to click through to say, yes, I know this site is not secure, but I want to go there anyway.  Not a great way to attract new visitors.  (Source: The Register)

Bank of England (BoE) Tells British Banks to be on a War Footing

Bank regulators in the UK have told financial service firms to come up with a detailed plan to restore services after a disruption and to invest in the staff and technology to do so.  Bank Boards and senior management should ASSUME that systems and processes that support the business will be disrupted and focus on backup plans, responses and recovery.

Lyndon Nelson, deputy chief executive of the BoE’s regulator said that firms need to be on a “WAR footing: withstand, absorb, recover.”¬† This is something the Brits understand from World War II, but which the United States hasn’t quite figured out.

In addition to cyber attacks, the BoE said that firms should be ready for disruptions caused by failed outsourcing and tech breakdowns.

As the U.S. relaxes it’s stress tests, the BoE said that it will stress test banks with “severe, but plausible” scenarios.¬† The BoE will set a time limit for recovery.

It looks like the UK regulators are way ahead of US regulators, but maybe we can learn from them.  (Source: Bloomberg)

US Firms Hit Another Hurdle in GDPR Compliance

Some people say – and no one has proved the contrary – that GDPR was designed to go after big U.S. firms, while dragging along all the little ones with it.

This week, in honor of July 4th (not really), the European Parliament voted in favor of a resolution that says that if the U.S. does not fulfill it’s obligations under Safe Harbor by September 1 of this year, Europe should suspend the deal.¬† This is in addition to the attacks on Safe Harbor that are currently going on in the EU court system.

Taken together, U.S. firms doing business AND who transfer data between the E.U. and the U.S. should be rightfully worried.

Some of the obligations that the U.S. is behind on include filling vacant posts on the Privacy and Civil Liberties Oversight Board, which has been basically dormant under the current administration,¬† the lack of a permanent ombudsman, the impact of the President’s executive orders on immigration, the re-authorization of Section 702 of the FISA act and a number of others.

The current relationship between our president and the EU doesn’t help things.

This could turn into a standoff, or, in the worst case scenario, the E.U. could shut off the data spigot for U.S. companies to legally move data from the E.U. to the U.S. for processing, storage and analysis.  While large companies may (repeat MAY) be able to deal with this, smaller companies will be greatly challenged and some may have to abandon the European market to E.U. based businesses, something that would make a lot of E.U. businesses very happy.

Stay tuned!  (Source: The Register)

 

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.

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.

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:

not-secure-2

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.

 

[TAG:TIP]