Posted on

A reminder for Symantec certificate users

icon security lowUsing Chrome or Chromium?  Browse to PayPal, right-click while on the page, select Inspect, and click on the Console tab. Bit of an exercise, but it’ll let you see the following notice:

The SSL certificate used to load resources from https://www.paypal.com will be distrusted in M70.
Once distrusted, users will be prevented from loading these resources.
See https://g.co/chrome/symantecpkicerts for more information.

Google hasn’t really been hiding this, they have been publicly talking about it since last year.

“Symantec’s PKI business, which operates a series of Certificate Authorities under various brand names, including Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL, had issued numerous certificates that did not comply with the industry-developed CA/Browser Forum Baseline Requirements.”

The M70 release of Chrome will be in beta from September, and GA in October 2018.  Yes, that’s quite soon!

All of this would be fine, if sites and companies would get a move on and deploy new certificates that don’t originate from this problematic source.  One would expect PayPal to have done this months ago, but apparently not.  It’s important to be aware of this, because come October it’ll be much more than a little inconvenience particularly for e-commerce sites: online payments via PayPal will start failing – unless and until PayPal and others update their certificates.

Posted on
Posted on

SSL certificates – not optional

We made a stuff-up over the weekend.  Historically we have different SSL certificates for different services in our realm, and last Saturday the certificate for the main website expired.  Of course we noticed at that point, but we should have had an internal notification earlier and somehow that had failed.  Fixed, but it would have been much better if the front-end hadn’t been temporarily inaccessible.  It was, because of HTTPS Strict Transport Security (HSTS). Any browser that had previously talked with our website (rightfully) refuses to talk to it if it doesn’t see a valid certificate.  Going back to non-HTTPS is not an option either, for this reason as well as others mentioned below. However, we do have different certificates for different services, so it was only our frontend website that was affected (bad enough), the various other services for our clients fortunately were unaffected.

Let's Encrypt logoGoing forward though, keeping up-to-date with the certificates and automatically renewing them is much easier now than it used to be. Let’s Encrypt® has been around for a while, but a few months ago they started supporting wildcard certificates.  With non-wildcard, one of the ways Let’s Encrypt can verify that you own the site is by doing a challenge/response on port 443 of the website address; Certbot will temporarily listen there and give the appropriate answers.  For a wildcard, that doesn’t work, because you can have an infinite number of subdomains and Let’s Encrypt needs to be certain that you actually control these.  So in v2 of the API there’s support for DNS based validation.  Through special TXT records for which Let’s Encrypt provides the token on every domain request, you can prove that you are in control of the DNS servers for the domain. That’s pretty slick!

There are integrations for many hosting providers as well as Cloudflare, which through a secure mechanism allow Let’s Encrypt to update those records in your DNS, and then validate. As Let’s Encrypt certificates are only valid for 3 months, this is important for the automation.  If you run your own DNS servers, you can still automate the DNS based verification process by setting up RFC-2136 remote updates in your DNS server (Bind9 can do it, it’s been around for many years – that said, being an older system, it can be rather finicky to set up).

Let’s Encrypt’s Certbot can take care of the entire updating process, including reloading your webserver’s or reverse proxy’s config.  Do make sure you use a recent Certbot, as all the appropriate support is quite recent. We had to grab Certbot from Github the first time as the Debian release hadn’t updated quite far enough yet – it has now.

We think that the EFF has done brilliantly with setting up Let’s Encrypt, and helping everyone move towards a fully encrypted web.  Particularly with the cost-factor removed, there’s no reason to not offer HTTPS to users – whether for a website, or an API.  Respecting one’s users and their online privacy is really a must-do.  Companies that don’t, increasingly look bad.  See it this way: going fully HTTPS is an opportunity to make a good first impression.  And did you know it also affects your ranking in search engines?  Now there’s a good incentive for the PHB

Do you need an EV certificate?  Probably not, as they actually have very little meaning – and even less so with various CAs having distinctly flawed verification processes.

Do you need a site seal from your CA (Certificate Authority)?  Really not.  It just advertises the CA, and actually enables them to track your users – if you get the seal served from the CA’s URL, that’s every single user. Not cool. So just don’t.

Final hint: if you do get a wildcard certificate from Let’s Encrypt, make sure you include both the wildcard and non-wildcard in the certificate domain names, otherwise it won’t work. So, *.example.com as well as example.com. You may not have noticed that your wildcard certificate always contains these, as many CAs automatically include the appropriate extra item.  Certbot just does exactly what you tell it to, so it’s something to be aware of.

Posted on
Posted on

SSL and trust

We can all agree on this: security is important, as is trust.

Does a pretty seal from an SSL certificate provider create trust? Doubtful. The provider’s own claims aside, it’s marketing fluff.
Oh, it used to provide them with some extra Google juice (one more link to them) but Google’s algorithms doesn’t care for that any more. Good!

What Google (and others) do care about is security, all sites should use SSL. For everything.
Expensive? Not really. Let’s Encrypt is free, and updates can be fully automated (scripted). Quite shiny really.

Let’s Encrypt only does domain validation, so a user sees the green lock and a “Secure” indicator. If you want company validation, you need to use another provider and pay their fees. Do you need that? That’s up to you. We reckon that in many (if not most) cases, you don’t really. It might depend on whether your clients are informed enough to care for SSL, and then whether they know (and care) enough to discern which indicators actually have real security meaning and which are just fluff. Tech geeks aside, few people do. We’re not saying that is brilliant, but it is reality. Do people care for pretty seals, and do we want to feed that realm of misinformation and false security? We hope you don’t go that path, because if we really care for security, this just distracts without solving the real issues. Doing things you technically don’t believe in won’t create real trust, as it’s not genuine. And whatever marketing/sales types tell you, you can’t fake genuine. Increasingly, people see right through it. Which is awesome! If your users know enough and care to ensure that your site is really owned by your company, then yes, a certificate with company validation makes sense.

Actionable task

If your publicly facing web or API servers aren’t using SSL for everything yet, you’ll want to spend some time to fix this. Real security aside, it affects your search engine ranking. If web pages pull in logos, javascript or even stylesheets from third parties, make sure those too use https as otherwise browsers produce “mixed content” warnings.

References

Posted on
Posted on

Web Security: SHA1 SSL Deprecated

You may not be aware that the mechanism used to fingerprint the SSL certificates that  keep your access to websites encrypted and secure is changing. The old method, known as SHA1 is being deprecated – meaning it will no longer be supported. As per January 2016 various vendors will no longer support creating certificates with SHA1, and browsers show warnings when they encounter an old SHA1 certificate. Per January 2017 browsers will reject old certificates.

The new signing method, known as SHA2, has been available for some time. Users have had a choice of signing methods up until now, but there are still many sites using old certificates out there. You may want to check the security on any SSL websites you own or run!

To ensure your users’ security and privacy, force https across your entire website, not just e-commerce or other sections. You may have noticed this move on major websites over the last few years.

For more information on the change from SHA1 to SHA2 you can read:

To test if your website is using a SHA1 or SHA2 certificate you can use one of the following tools:

Open Query also offers a Security Review package, in which we check on a broad range of issues in your system’s front-end and back-end and provide you with an assessment and recommendations. This is most useful if you are looking at a form of security certification.

Posted on
Posted on 1 Comment

Understanding SHOW VARIABLES: DISABLED and NO values

When you use SHOW VARIABLES LIKE “have_%” to see whether a particular feature is enabled, you will note the value of NO for some, and DISABLED for others. These values are not intrinsically clear for the casual onlooker, and often cause confusion. Typically, this happens with SSL and InnoDB. So, here is a quick clarification!

  • NO means that the feature was not enabled (or was actively disabled) in the build. This means the code and any required libraries are not present in the binary.
  • DISABLED means that the feature is built in and capable of working in the binary, but is disabled due to relevant my.cnf settings.
  • YES means the feature is available, and configured in my.cnf.

SSL tends to show up as DISABLED, until you configure the appropriate settings to use it in my.cnf (SHOW VARIABLES LIKE “ssl_%”). From then on it will show up as YES.

Depending on your MySQL version and distro build, InnoDB can be disabled via the “skip-innodb” option. Obviously that’s not recommended as InnoDB should generally be your primary engine of choice!

However, InnoDB can also show up as DISABLED if the plugin fails to load due to configuration or other errors on startup. When this happens, review the error log (often redirected to syslog/messages) to identify the problem.

If InnoDB is configured as the default storage engine, failed initialisation of the plugin should now result in mysqld not starting, rather than starting with InnoDB disabled, as obviously InnoDB is required in that case.

Posted on 1 Comment