GlobalSign Blog

What You Missed in Q3 – GlobalSign’s SSL Certificate Update

What You Missed in Q3 – GlobalSign’s SSL Certificate Update

Another three month’s has passed and the world of infosec is rife with new regulations, new types of attack to mitigate and new user experiences to get their heads around. If there’s any industry that changes more regularly I would like to hear about it!

If you’ve been as busy as I expect you have been, then this post should help give a top level overview of anything you may have missed or jog your memory on things you have already been made aware of.

If you think I’ve missed anything, feel free to let me know in the comments or on Twitter.

PCI DSS Update

Companies who require PCI compliance must now support only TLS 1.1 or later in order to meet the PCI Data Security Standard for ensuring the security of payment data. TLS 1.0 and any versions of SSL are not permitted to meet PCI Data Security Standard for ensuring the security of payment card data.

GlobalSign advised in May 2018, that everyone makes the switch but if you haven’t already, I’d suggest reading this article about why it’s time to disable TLS 1.0.

The PCI DSS deadline for disabling SSL and early TLS was 30th June 2018. TLS 1.2 is strongly encouraged and GlobalSign have updated all systems now to ensure we are using a minimum of TLS 1.2. All browsers will be ending support for TLS 1.2 by 2020 but more news will probably follow in the next quarterly announcement. 

Mozilla Has Enabled DNS over HTTPS

Domain Name Service (DNS), the old age internet phone book, has long been under fire for privacy and safety. Firefox has been working to change that by “encrypting DNS queries”.

Every time you click a link, send an email or enter an address into the address bar, your computer takes the domain name and looks up the corresponding IP address. Once it find the address, the DNS resolver sends this information to your browser so that it can start requesting the files. This all happens in milliseconds and can happen a number of times on a single page if there are several links embedded. Even if the wonderful HTTPS protocol encrypts everything on the page, it doesn’t encrypt the DNS lookup and that means, your browsing history can be tracked.

Some ISP providers sell this information for targeted advertising, which is why Firefox are working to encrypt DNS, calling it: "DNS over HTTPS" or "DoH protocol". DoH has already been added to Firefox 62. A great explanation of DoH can be found here.

Chromium News

Chrome 68 – HTTP is now “Not Secure”

It’s official. The day we have been shouting about for more than a year is here. The day of reckoning perhaps? As far as we can tell, the internet is well and truly intact.

Here’s a reminder from the old chromium blog:

Treatment of HTTP pages

This news is followed by the release of Chrome 70 in October which will show a red  “Not Secure” warning when you enter data on a HTTP page.

Symantec Root Distrust Schedule for Chrome Is Complete

symantec legacy error

Chrome 70 is also the release of the final stage of Chrome’s distrust for Symantec root certificates. The date of complete removal is set to 16th October and 23rd October for Firefox although it has now been confirmed that the date will be moved back due to the number of domains still using Symantec root. While Chrome 70 comes with the distrust logic, it’s important to note that this will be phased over time and so not all users will see distrust at the same time.

percentage of symantec regressions

Source.

Domain owners have a lot to look out for this time of year so we suggest the information security experts take responsibility and start sharing and spreading the news.

A study from Netcraft concluded that 254,000 certificates were still using the Symantec root and approximately 8,000 of these sites are considered “high-profile”. Examples such as learningnetwork.cisco.com and okex.com, the popular digital currency exchange site are included in this research.

your connection is not private error

Chrome Tries to Remove the ‘WWW’

In an interesting move by Chrome, the 68 update decided to strip the ‘www’ from domains. If you didn’t already hear the news, they quickly had to take this feature away since their user community complained about it so much on the Chromium blog. I’m highlighting a few of my favorite comments here.

Comment 2 by earl.thu...@gmail.com, Sep 6

This is a dumb change. No part of a domain should be considered "trivial". As an ISP, we often have to go to great lengths to teach users that "www.domain.com" and "domain.com" are two different domains, and that they may not necessarily go to the same destination. The marketing world has done a lot of damage convincing people that "www" is both ubiquitous and non-essential, when in fact, for some domains, the use or lack of it can be quite important to getting to the correct location.

Comment 40 by fer...@gmail.com, Sep 6

Here's another example where it goes very wrong. The site "www.m.www.m.example.com" should not show up as "example.com".

Very disappointed with this change.

Comment 32 by alf...@nurd.nu, Sep 6

I believe this Wired article gives some perspective to this change: https://www.wired.com/story/google-wants-to-kill-the-url

They use altruistic arguments, but of course we can all see their business objectives as a search engine to get rid of the URL. This is probably just a first small step to reduce the importance/trust of the URLs.

Global Governments Go Secure

It looks like the United States Department of Defence (DoD) have recently committed to using HTTPS and HSTS on public facing websites as well as STARTTLS and DMARC for all its email servers. At the time of Netcraft’s analysis, the DoD had mostly been using internal CA certificates which were not publicly trusted and visiting the domains would have caused errors. In the August Netcraft survey, it was found that 3,137 .gov websites have valid and trusted certificates including whitehouse.gov and 51 .mil websites also have valid trusted certificates.

TLS 1.3 Fully Released

As we’ve mentioned in a previous update post, the IEFT released a draft version of TLS 1.3 on 29th June. The final version was released on 10th August officially and is defined in RFC 8446.

As Cloudflare explain in their blog, TLS 1.3 was designed to improve on past protocols by:

  • reducing handshake latency,
  • encrypting more of the handshake,
  • improving resiliency to cross-protocol attacks and
  • removing legacy features.

Adoption of TLS 1.3 is still in the works, many cryptographic libraries have caught up but only a few, like OpenSSL and NSS are currently supporting the final version. One interesting library is Facebook’s new open source TLS 1.3 library known as Fizz. They recently released this to the world but have been using it in mobile apps to improve performance for quite some time.

As for major browsers, Chrome and Mozilla are the only browsers who are supporting TLS 1.3 by default at the moment. Edge, Safari and Opera support is still in development.

Just before they published TLS 1.3, in July, IEFT published a draft proposal on the deprecation of TLS 1.0 and 1.1.

In Other News

Apple Announce Certificate Transparency

Any publicly trusted certificates issued after 15th October 2018 will require certificate transparency to be trusted in the Apple root store. Certificates that fail to comply will be met with a ‘failed TLS connection’ error which will break app connections to the internet.

Microsoft Edge

Microsoft Edge became the last of the big three browsers to implement the Update-Insecure-Requests Content Security Policy which forces the browser to fetch the more secure https:// if someone searches for http://. The recommended approach is to do this in the response header. Check out Troy Hunt investigating Edge’s response header in his blog.

Cloudflare Deploy Encrypted SNI

On the 24th September 2018, Cloudflare announced its support for encrypted SNI. This is huge news in the cryptography world because once and for all, the first part of the server handshake is finally being encrypted. Before this, any observer (say ISP, firewall or Wi-Fi owner) could intercept your plaintext ClientHello message and determine which website your client is trying to connect to. This could have resulted in a man-in-the-middle attack or just an annoying array of targeted advertisements later.

encrypted SNI

A Safer Internet?

It’s becoming clear that 2018 is the year where the security community has come together to plug some major holes in internet security. Whether all these ideas are a step forward is arguable that’s for sure. But what is clear is that public key infrastructure is getting a makeover and we’re moving towards more secure protocols and an even more secure handshake thanks to Cloudflare. Look forward to the last three months of the year.

Share this Post

Related Blogs