symantec trust issue

Chrome and Symantec – the Final “Trust” Solution

chrome symantec trust issue

The Google Chrome team announced in March 2017 that it had a problem with Symantec for violating industry standards related to SSL certificate issuance. This has been discussed cooperatively over the last 4 months by Google, Symantec, and other members of the internet community. On 27th July 2017, Chrome and Symantec announced their final plan to move forward.

If you operate a website that uses a Symantec SSL certificate, please read this post to see if future versions of Chrome will affect your specific certificate and how you can replace that certificate (for free) before anything goes into effect.

Are you affected?

If you are a current user of Symantec certificates or plan to purchase one in 2017, this could affect you.

As a leading Certificate Authority, there are more than an ideal amount of Symantec SSL certificates will be affected.  Note that Symantec operates multiple brands, all of which are affected:

  • Symantec
  • GeoTrust
  • Thawte
  • RapidSSL

Also, note that Mozilla Firefox will be taking a similar course of action, but at this time they have not committed to a final plan.

What changes are expected in Google Chrome

The two stages of Chrome’s distrust, which serve as deadlines, are marked in RED to clearly show the difference between general information and actionable items.

October 24th, 2017
Chrome 62 will display a message in Developer Tools to help identify certificates which will be affected by distrust in Chrome 66. Visit your websites with the Developer Tools panel open – this will allow you to identify which websites will be affected by distrust in Chrome 66.

December 1st, 2017
A partnered Certificate Authority (CA) will begin issuing certificates for Symantec. As an end user, you may notice some small changes in the issuance process. From a technical standpoint, this date is significant because it marks beginning of the “new” Symantec certificates. Certificates issued after this date will be issued from different roots and will not be affected by Chrome’s dis-trust.

April 17, 2018
All Symantec certificates issued before June 1st, 2016, will no longer be trusted by Chrome.
Certificates issued after June 1st, 2016 are not affected at all in this release. Replace any Symantec certificates issued before June 1st 2016 by this date. This can be done by reissuing your certificate for free from your provider and installing the new certificate in place of the old one. If your certificate expires around this time (April-June) you may want to consider renewing it, instead of reissuing, to avoid two replacements within a short time frame.

Oct 28th, 2018
All certificates issued by Symantec with their existing infrastructure will no longer be trusted by Chrome.
Starting in the stable version of Chrome 62, a message will be added to the Developer Tools panel when a certificate that will be distrusted in Chrome 66 is encountered. Developers can use this functionality to ensure they identify certificates on their websites that will be affected.

Our Recommended Plan of Action

To reduce the amount of disruption and effort required, we recommend the following action:

If your certificate expires BEFORE December 2017

We recommend you renew (instead of reissue) your certificates prior to December. This will allow you to have a trusted certificate in place through the holiday season up until Oct 2018 when all certificate files from Symantec’s existing roots will have an issue and need to be replaced on your website. Alternately, switch over to certificates from a different Certifying Authority (CA) such as Comodo to avoid any issues.

If your certificate expires DURING December

Symantec hopes to have their partner CA issuing certificates on December 1st (a Friday). If you can wait to reissue and replace your certificates until after this occurs, you will most-likely never need to replace your certificate files on your website until their natural expiration date.

However, note that delays may occur which require Symantec to miss the December 1st estimate, and there may be an unusually high volume of issuance at that time which could cause technical issues.

If that is the case, if you are close to the expiration of your current certificate you may risk outages. ‘Holiday freezes’ may also prevent you from replacing certificates during this month.

If you do need to replace your certificate before Symantec’s partner CA is ready to issue certificates, you will need to replace the certificate files again before Chrome 70’s release (expected late Oct 2018).

Alternately, you can switch over to certificates from a different CA such as Comodo to avoid any issues.

If your certificate expires AFTER December 31st, 2017

We recommend you wait to replace any of your certificates until Symantec’s partner CA begins issuing certificates (expected December 1st, 2017). After this date you can begin reissuing and replacing certificates as needed. This way you need to replace your certificate files only one time.

Certificates issued by Symantec’s partner CA will not be affected by Chrome’s changes and will not need to be replaced until their natural expiration.

Special Case: If your certificate was issued BEFORE June 1st, 2016 and expires AFTER April 17th, 2018

You fall into a special case. Your certificate must be reissued and files replaced BEFORE the release of Chrome 66, which is expected April 17th, 2018 in order to remain trusted in Chrome.

However, you should wait until after December 1st 2017 to reissue your certificates. On this date, Symantec’s partner CA will begin issuing certificates. By waiting until this date you will only need to replace your certificate one time.

If you reissue before Symantec’s partner CA is available, your certificate will come from one of Symantec’s current root certificates and will need to be replaced against before October 2018.

UPDATE: Mozilla Firefox will follow more or less the same timelines as Google Chrome.

 

COMODO most popular SSL certificate brand amongst top 1mn websites

COMODO most popular SSL brand and comes out a clear winner with a 28% website share. GeoTrust comes in a distant second with a 12% share. GoDaddy is third with 7%. Lets Encrypt comes 5th and powers 5% of these websites.

The top certificate authorities identified are as follows:

comodo most popular ssl certificate

Image courtesy Kenn White via Adam Caudill

700,275 out of the top 1 million websites responded with a SSL / TLS certificate on port 443. The scanner attempted to connect to the domain on port 443, and if that failed, then attempted to connect to the “www” subdomain. 

The scan was run with an eight second timeout. Any server that couldn’t complete a handshake within eight seconds wasn’t counted.

No certificate validation was performed. The scan didn’t attempt any other ports or subdomains.

Banned country list for SSL now includes Zimbabwe

ssl connection not secure

Websites from Zimbabwe are now banned by the Certification Authority Browser forum from receiving Extended Validation (EV), Organization Validation (OV), and Domain Validation (DV) SSL certificates.

Countries are usually banned or restricted when the country is experiencing a period of political unrest and the security of information traveling in and out may be compromised by the government or an outside entity.

The banned country list for SSL certificates comprises of Afghanistan, Cote d’Ivoire, Cuba, Eritrea, Guinea, Iraq, Islamic Republic of Iran, Democratic People’s Republic of Korea, Liberia, Myanmar, Rwanda, Sudan, Sierra Leone, South Sudan, Syrian Arab Republic, and Zimbabwe.

The restrictions do not affect websites that already have SSL certificates, but any websites applying for new certificates are being denied.

 

DROWN logo

DROWN Attack – 33% HTTPS servers at risk

DROWN stands for “Decrypting RSA with Obsolete and Weakened eNcryption”

Websites, mail servers, and other TLS-dependent services are all at risk for this kind of attack, including many popular websites. It allows attackers to break the encryption and read or steal sensitive communications, including passwords, credit card numbers, trade secrets, or financial data.

drown attack scenarios

Next Steps For Server Admins

Learn more and check if your servers are affected.
green secure shield

The “Poodle” SSL Bug

green secure shieldJust a few months after the Heartbleed bug shattered the believed-to-be-secure SSL/TLS encryption layer status quo and put data transfers, emails, instant messages, etc. at risk, a new SSL vulnerability has been brought to light by Google experts.

According to Google researchers, a weakness in the SSL 3.0 protocol could be used to eavesdrop critical data that is transferred over an encrypted connection between web browsers, apps, etc. and servers.

The ‘new’ bug is called POODLE – an acronym for Padding Oracle On Downgraded Legacy Encryption.

The mechanism of the POODLE attack

The newly discovered POODLE exploit poses a great threat to online security, since it affects an old SSL version, which is still widely used by the majority of servers and clients.

It allows hackers to outsmart a web client by telling it that the server does not support the more secure TLS (Transport Layer Security) protocol, so the client is forced to connect via SSL 3.0.

This downgrade maneuver opens the door of abuse and attackers can freely decrypt secure HTTP data and steal the protected information.

Measures taken against POODLE attacks

With the discovery of POODLE, the security specialists at Google instantly recommended measures for dealing with this encryption issue.

First and foremost, the SSL 3.0 protocol needs to be disabled for both participants in the SSL communication – the server and the client, and they need to default to the more secure TLS. This will stop attackers from forcing the communication to go through the exploited SSL 3.0.

Server-side measures:

In response to the Google team’s recommendation, our web hosting servers no longer support SSL 3.0 and older versions of the protocol. Also, our admins have set the minimum SSL requirement to the provenly secure TLS 1.0.

NOTE: As a result, an Internet Explorer browser whose version is 6.0 or older will not be able to access websites hosted on our servers.

Client-side measures:

As far as web clients are concerned, Google specialists recommend that end users immediately disable SSL 3.0 support in their browsers, if such exists.

In response to the issue, Google plans to remove SSL 3.0 support completely from all its products in the upcoming months. Currently, they even offer a Chromium patch, which disables the SSL 3.0 fallback.

Mozilla has also announced plans to turn off SSL 3.0 in Firefox and it will be disabled by default in Firefox 34, which will be released in November. They also offer code for disabling the protocol, which is now available via Nightly. Also, you can use the SSL Version Control add-on for Firefox.

Here you can find details instructions on how to disable the use of SSLv3 for the most common browsers and Operating Systems - https://zmap.io/sslv3/browsers.html

Upcoming actions against POODLE attacks

To further secure our system against future downgrade attacks, our admins are also planning to implement TLS_FALLBACK_SCSV (Transport Layer Security Signalling Cipher Suite Value) on all our servers shortly. We’ll keep you posted.