There are some security-related updates coming to Google’s Chrome browser this year, including new requirements around HTTPS and new rules for SSL Certificates. Read up on the upcoming changes to ensure that you're on Google's good side in 2018.
1. HTTPS Requirements for Google Chrome
There was a time when HTTPS was considered "nice to have." That time has long since passed, and you really should be using HTTPS already. As of July 2018, Google Chrome (the world's most popular browser) will begin to flag HTTP connections as "not secure."
Here's an illustration of the change from Google:
In contrast, here's what a secure, encrypted connection (over HTTPS) looks like to users:
That nice green padlock tells users that the connection between their browser and your website is encrypted. If your site uses an unencrypted connection (HTTP), threats can intercept website data as it moves between your server and the browser. From there, it's possible to scrape personal information and credit card numbers, and even alter your website before users see it.
This leaves your website and your users highly vulnerable. As we've seen in recent years, that can lead to serious legal and financial liabilities for you and your organization.
Now, Google will further penalize sites that only communicate over HTTP by adding a "Not Secure" warning on the address bar. This will undoubtedly affect both traffic and conversions for the sites affected.
The steps to enable HTTPS vary depending on your website and hosting provider, but you'll need a Secure Sockets Layer (SSL) Certificate. SSL Certificates verify the owner of a domain and enable the HTTPS connection between a server and client. You can pay for SSL Certificates from a Certificate Authority like Comodo or Digicert, or create one for free using Let's Encrypt. If your web services are hosted on Amazon Web Services (AWS), Amazon Certificate Manager is a great option as well.
2. Certificate Transparency Requirements in 2018
In addition to the new penalties against HTTP-only websites, Google is introducing new guidelines around SSL Certificates themselves. Starting April 2018, Chrome will reject SSL Certificates from websites whose certificates are not entered into a known "Certificate Transparency" Log. Let's explain what that means by breaking down the different moving parts of Certificate Transparency.
What is Certificate Transparency and Why is it Needed?
Certificate Transparency adds a layer of verification to SSL, and also increases the speed at which Certificate Authorities can mitigate security problems with SSL Certificates. Certificate Transparency also helps domain owners know when certificates have been maliciously requested or provisioned for their domains.
Why is this new layer of security necessary? While SSL has improved the overall security of the web by a great deal, there are still a few flaws in the system:
- Illegitimate or "rogue" Certificate Authorities can offer fraudulent SSL Certificates
- Even trusted Certificate Authorities can make mistakes or be subject to hacks
- Online threats are getting better at using stolen or illegally created SSL Certificates
- The frequency of these attacks has increased in the past years
These problems can be avoided by a standardized protocol for logging and monitoring trusted SSL Certificates in real-time, and that's exactly what Certificate Transparency is designed to achieve.
How Does Certificate Transparency Work?
Certificate Transparency provides a framework of "checks and balances" that ensures malicious or mistakenly issued SSL Certificates are discovered and invalidated as quickly as possible. It involves a three-pronged system for validating SSL Certificates that ensures that new certificates are continually being monitored for potential abuse.
The Certificate Transparency trifecta consists of:
- Certificate Logs
- Certificate Monitors
- Certificate Auditors
Certificate Logs are publically accessible, append-only (meaning that new logs can only be added, not removed or altered), and cryptographically secured records of trusted SSL Certificates. Certificate Logs use "Merkle Tree Hashes" to verify their integrity. New logs can be created by anyone, but will largely be maintained by ISPs and Certificate Authorities. The result is an open-source, decentralized database of trusted SSL Certificates.
Certificate Monitors are servers set up to watch Certificate Logs closely to identify malicious or "bad behavior" certificates. They automatically and continuously scan Certificate Logs and contain carbon copies of all the logs they monitor. If a monitor finds a bad Certificate Log, or one that has been altered, it will flag it as invalid. Log Monitors can also act as a backup for offline or inaccessible Certificate Logs.
Certificate Auditors are software tools that verify the integrity of Certificate Logs using "Log Proofs." Auditors compare Log Proofs between Certificate Logs and Certificate Monitors. By verifying these proofs against multiple sources, auditors can determine if a certificate is being used maliciously.
This three-pronged approach ensures that if any part of the "trust chain" is found to be compromised, the certificate in question will not be trusted by Chrome. It creates three unique tests which a certificate must pass before a browser will accept an HTTPS connection to its corresponding URL.
Enabling Certificate Transparency
The methods for enabling Certificate Transparency can vary depending on which Certificate Authority you bought your SSL Certificate from. Most popular Certificate Authorities have enabled Certificate Transparency by default in light of this new development, so there's a good chance no action is needed.
If you're unsure as to whether your domain has Certificate Transparency enabled, you can use the Certificate Transparency checker tool from Google.
Here's what the report for https://cuttlesoft.com looks like:
As you can see, there are three different Certificate Log entries for our domain's SSL Certificate. Since that certificate was provisioned by us through our Certificate Authority, we know that our domain is safe.
If you see logs for your domain's certificate created by your Certificate Authority, great! Your SSL Certificate has transparency enabled. If not, you may want to contact your certificate provider.
If you see certificates logged that you didn't create yourself, or that look suspicious, you might have a serious problem. Contact your Certificate Authority and/or your domain provider as soon as possible to find out if something's amiss.
Here are some of the major Certificate Authority's responses to the upcoming Certificate Transparency mandate:
"DigiCert supports CT. Earlier detection of misissued certificates is important for server operators and users. As such, CT is a significant improvement for the industry and highlights CAs using good certificate issuance practices. We will always follow the highest standards for verifying identities and issuing high-assurance digital certificates."
"Entrust deployed Certificate Transparency in December 2014. Since then, all new EV SSL certificates include the signed certificate timestamp (SCT) and are recorded in a public log. All existing, non-expired EV SSL certificates have been submitted to Google for inclusion in a public log. All certificates are logged with complete contents."
"At GlobalSign, we’ve been working hard behind the scenes to equip all of our certificates with CT – Extended Validation (EV) since 2015, Domain Validated (DV) since August 2016 and Organization Validated (OV) is coming in October 2017 - so our customers will be ready for Google’s deadline next year."
"Certificate Transparency (CT) helps you monitor certificates issued for your domains by making the certificate information available in a public log. All certificates issued after June 1, 2016 include CT."
"We are dedicated to transparency in our operations and in the certificates we issue. We submit all certificates to Certificate Transparency logs as we issue them."
"Symantec is pleased to extend support for Certificate Transparency (CT) for our Organization Validation (OV) products, a key certificate management capability for all SSL/TLS certificate types and customer channels. This is just the next step in empowering organizations with the ability to detect and mitigate security concerns for domains they own."
While a fully-secure web is still a distant dream, this adder layer of protection to the SSL framework and Chrome's decision to penalize HTTP connections is big a step in the right direction. For further reading see https://www.certificate-transparency.org/.
Was this blog post helpful? Still having problems with HTTPS or SSL Certificate Transparency? Feel free to leave a comment below, or contact us for more help.