PKI Consortium blog

The CA Security Council Looks Ahead to 2020 and Beyond
January 9, 2020 by Patrick Nohe (GlobalSign), Doug Beattie (GlobalSign) Apple CA/Browser Forum Chrome Edge Encryption EV Firefox Forward Secrecy GDPR Google Identity Microsoft Mozilla PKI Policy Qualified SSL 3.0 SSL/TLS TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 Web PKI

A whirlwind of activity will cause dramatic shifts across the PKI world in the year ahead

Suffice it to say that 2019 was filled with challenges and contentiousness as Certificate Authorities and Browsers began to watch their shared visions diverge. The debate around Extended Validation continued as CAs pushed for a range of reforms and browsers pushed to strip its visual indicators. And a ballot to shorten maximum certificate validity periods exposed fault-lines at the CAB Forum.

2017 – Looking Back, Moving Forward
January 13, 2017 by Bruce Morton (Entrust) 3DES Apple Attack CA/Browser Forum CAA Chrome Code Signing Encryption Firefox Google Identity Malware MITM Policy Revocation RSA SSL 3.0 SSL/TLS TLS 1.3 TSA Vulnerability

Looking Back at 2016

Fortunately, 2016 was not a year full of SSL/TLS vulnerabilities. Although some researchers did prove old cryptography algorithms should be put out to pasture. The year showed the end of public-trusted SHA-1 SSL/TLS certificates. It also showed more transparency should be considered due to issues discovered with a few certification authorities (CAs). The great news is HTTPS is no longer the minority — after 20 years, connections using HTTPS has surpassed HTTP.

SSL 2.0 and DROWN
April 4, 2016 by Bruce Morton (Entrust) Attack IETF OpenSSL SSL 3.0 SSL/TLS Vulnerability

A team of researchers has announced a vulnerability with SSL 2.0 called Decrypting RSA with Obsolete and Weakened eNcryption; otherwise known as DROWN.

SSL 2.0 is a version of the SSL/TLS security protocols. It was released in February 1995, but due to security flaws was superseded by SSL 3.0 in 1996.

DROWN is a cross-protocol attack where the bugs in SSL 2.0 can be used to attack the security of connections that use TLS. The vulnerability applies to servers:

2015 – Looking Back, Moving Forward
January 6, 2015 by Bruce Morton (Entrust) Apple Attack CA/Browser Forum CAA Chrome Code Signing EV Firefox Forward Secrecy Google IETF Malware Microsoft MITM Mozilla OpenSSL PKI Policy RSA SHA1 SSL 3.0 SSL/TLS TLS 1.0 TLS 1.2 TLS 1.3 Vulnerability

Looking Back at 2014

End of 1024-Bit Security

In 2014, the SSL industry moved to issuing a minimum security of 2048-bit RSA certificates. Keys smaller than 2048 are no longer allowed in server certificates. In addition, Microsoft and Mozilla started to remove 1024-bit roots from their certificate stores. Hopefully, the key size change will support users through to 2030.

POODLE for TLS
December 16, 2014 by Bruce Morton (Entrust) Attack SSL 3.0 SSL/TLS Vulnerability

The POODLE attack on SSL 3.0 has now been extended to some implementations of TLS. POODLE for TLS can be tracked through CVE-2014-8730.

POODLE is not a flaw with the certificate authority (CA), SSL certificates or certificate management system. POODLE is a TLS implementation bug.

Adam Langley states that “TLS’s padding is a subset of SSLv3’s padding so, technically, you could use an SSLv3 decoding function with TLS and it would still work fine. It wouldn’t check the padding bytes but that wouldn’t cause any problems in normal operation. However, if an SSLv3 decoding function was used with TLS, then the POODLE attack would work, even against TLS connections.”

A Follow-up on POODLE and SSL 3.0
November 21, 2014 by Bruce Morton (Entrust) Attack Encryption Google IETF Mozilla OpenSSL SSL 3.0 SSL/TLS TLS 1.0 TLS 1.1 TLS 1.3 Vulnerability

In October 2014, Google announced POODLE, an SSL 3.0 protocol attack.

To bring you up to speed, the SSL/TLS protocol is the most important and popular security protocol on the Internet. The Secure Sockets Layer (SSL) protocol was developed by Netscape. They quickly moved from SSL 1.0 to 2.0 and finalized with SSL 3.0 in 1996.

This protocol was then picked up by the IETF, who released it under the name of Transport Layer Security (TLS). The IETF released TLS 1.0, 1.1 and 1.2. They are currently working on TLS 1.3.

It’s Time for TLS 1.2
September 19, 2013 by Wayne Thayer Attack BEAST Chrome Firefox OCSP RC4 SHA2 SSL 3.0 SSL/TLS TLS 1.0 TLS 1.1 TLS 1.2 Vulnerability

In a previous post titled Getting the Most Out of SSL Part 2, we touched on the recommendation that Web servers be configured to prefer Transport Layer Security (TLS) version 1.2. With the planned release of Firefox 24 and recent release of Chrome 29 adding support for TLS 1.2, now is a great time for website administrators to make the switch.

Transport Layer Security was formerly called Secure Sockets Layer (SSL) and is the protocol that enables secure “https://” connections to websites. TLS 1.2 was defined 5 years ago in RFC 5246, and TLS 1.1 dates all the way back to RFC 4346 in 2006. Both of these versions are updates to the original standard that fix bugs and problems including vulnerability to cipher block chaining (CBC) such as the BEAST attack that made news in 2011. The authors also added newer cipher suites including a replacement for RC4, a popular cipher that has been shown to be susceptible to attack. In short, enabling TLS 1.2 is like a Windows software update – it fixes potential problems and makes your website more secure.