A recent Google announcement stated that all publicly trusted SSL/TLS certificates issued in October 2017 or later will be expected to comply with Chrome’s Certificate Transparency (CT) policy or be untrusted by the browser.
On June 2, 2015, Facebook announced that it would stop supporting Facebook-connected apps that were signed with SHA-1, as of October 1, 2015.
“These changes are part of a broader shift in how browsers and web sites encrypt traffic to protect the contents of online communications. Typically, web browsers use a hash function to create a unique fingerprint for a chunk of data or a message. This fingerprint is then digitally signed to prove that a message has not been altered or tampered with when passing through the various servers and systems between your computer and Facebook’s servers.” [https://developers.facebook.com/blog/post/2015/06/02/SHA-2-Updates-Needed/]
Since we last wrote about SSL/TLS performance, there has been a lot of activity in the IETF HTTP Working Group, resulting in the February announcement that the next version of HTTP has been approved. This is big news because it means that major SSL/TLS performance improvements are on the way.
Background
When your browser connects to a website today, it most likely uses the HTTP/1.1 protocol that was defined in 1999 in RFC 2616. Over the past 15 years, HTTP/1.1 has served us well and many tweaks have been discovered to make the most of it. However, in that time the web has transformed into a platform for interactive content and applications. Today, browsers load much more data from many more sources to build the typical web page.
UPDATED September 23, 2014: The following blog post has been updated with action taken in recent weeks, as well as to reflect helpful user comments left on our August 28 blog post on this topic.
On August 19, Google announced a new policy that accelerates the deprecation of SHA-1 certificates, potentially causing websites using SHA-1 certificates to display warnings in the near future. While keeping with an earlier Microsoft announcement to accept SHA-1 certificates with an expiration date before Jan. 1, 2017, the Google policy will provide new “untrusted” warnings in regards to such certificates as early as this November.
Google’s announcement that it will give priority ranking to SSL enabled sites is a key milestone for increased use of SSL on the Internet.
Google announced a change to its ranking algorithm to include use of SSL on the site as a “very lightweight [positive] signal”. Although, this might not have an immediate impact to website owners/operators that are not currently using SSL, this is still an important signal indicating everyone should be prepared to encrypt all their websites if they want to remain relevant.
With the announcement of the Heartbleed bug and the resulting need to revoke large numbers of SSL certificates, the topic of certificate revocation has, once again, come to the fore.
There have been many issues with how revocation information is provided to the browsers. First let’s review how SSL certificate status may currently be obtained:
How
| How | Definition | Pros | Cons |
| signed list of the serial numbers of all revoked certificates that were signed by the CA’s certificate. | A single point of reference for the status of all certificates issued by the CA’s certificate. | Over time, CRLs might become very large, resulting in unacceptable latency. An attacker may be in a position to block the CRL delivery. |
| Online Certificate Status Protocol (OCSP) | A signed response containing the status of one certificate. | An OCSP response is small and does not grow. As such, there is no latency due to size. | Browsers have to obtain an OCSP response for each certificate in the Web server’s certificate chain, requiring it to open additional connections, thereby impacting page load time. Privacy issues may be a concern as the CA can determine which websites a user is visiting. An attacker may be in a position to block the OCSP delivery. |
| OCSP Stapling | A signed response, fetched by the Web server, with the status of its certificate. The OCSP response is then provided by the Web server to the browser. | No privacy issues, as the CA does not know which user has asked for the OCSP response. | Need Web servers and browsers that support OCSP Stapling. An attacker may be in a position to block the OCSP delivery. |
| Blacklist (for example, CTLs or CRLSets) | A list of certificates that should not be trusted (whether or not they were revoked), distributed by the browser supplier. | The blacklist is distributed by the browser supplier as part of the browser executable. | Any certificate on the blacklist can be rejected without any additional checks. | For practical reasons, the list is incomplete. |
After the CASC’s previous letter addressing ICANN’s proposal to delegate nearly 2000 new gTLDs for use on the public Internet, ICANN identified and initiated an extensive study on two significant securityissues. Now, based on the conclusions of the studies, ICANN is moving forward quickly with the delegation process, delegating more than 30 in the last two months alone. With ICANN ramping up the delegation process, nearly all 2000 will be delegated under the new rules, with only .corp and .home reserved as high risk gTLDs. This post serves as an advisory for interested network administrator on how the newest ICANN decisions may affect their networks and certificates.
Today marks an important day for internet security and future SSL enhancements, as the world’s seven largest publicly trusted Certificate Authorities are announcing the formation of the Certificate Authority Security Council.
While leading CAs have worked together for years to address security challenges and meet them with evolving and increasingly strict standards and best practices through the CA/Browser Forum and other industry venues, we’ve lacked a union where we can come together and speak with a unified CA voice.
Participate in our community discussions and/or join the consortium
