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.

CA Security Council (CASC) 2019 Predictions: The Good, the Bad, and the Ugly
December 6, 2018 by Bruce Morton (Entrust), Chris Bailey (Entrust), Jay Schiavo (Entrust) Apple Attack CASC Chrome DV Encryption EV Firefox Google Identity IETF Malware Microsoft Phishing SSL/TLS TLS 1.0 TLS 1.2 TLS 1.3

As the legendary coach of the NY Yankees Yogi Berra allegedly said, “It’s difficult to make predictions, especially about the future.”  But we’re going to try.

Here are the CA Security Council (CASC) 2019 Predictions: The Good, the Bad, and the Ugly.

The Good

Prediction: By the end of 2019, over 90% of the world’s http traffic will be secured over SSL/TLS

TLS 1.3 Includes Improvements to Security and Performance
April 10, 2018 by Tim Shirley Forward Secrecy IETF SSL/TLS TLS 1.2 TLS 1.3 Vulnerability

Last month saw the final adoption, after 4 years of work, of TLS version 1.3 by the Internet Engineering Task Force (IETF). This latest iteration of the protocol for secure communications on the internet boasts several noteworthy improvements to both security and performance:

Security

All cipher suites that do not provide forward secrecy have been eliminated from TLS 1.3. This is a very important security property, because without forward secrecy, if a server’s private key is compromised today, any previously-recorded conversations with that server dating back as long as the key was in use could be decrypted. While it is possible (and highly recommended) to configure a server with TLS 1.2 to prefer (or only support) cipher suites that provide forward secrecy, under TLS 1.3 these are the only option. Other cryptographic modernizations in TLS 1.3 include the elimination of DSA, custom DHE groups, and compression.

2016 – Looking Back, Moving Forward
December 14, 2015 by Bruce Morton (Entrust) Attack CA/Browser Forum CAA Chrome Code Signing DH Encryption Firefox Google Hash Function IETF Microsoft MITM OpenSSL Policy RC4 Revocation RSA SSL/TLS TLS 1.2 TLS 1.3 Vulnerability

Looking Back at 2015

A number of new tactics proved 2015 was no exception to an active year defending against ever increasing security issues. Vendors found new and creative ways to provide vulnerabilities including the now popular man-in-the-middle (MitM) attacks.  MitM as well as a host of other new vulnerabilities caused browsers to rethink their security requirements.  This article gives a flashback of the exploits and industry changes from 2015 and looks ahead at the latest security requirements and how it impacts IT security teams.

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.

Perfect Forward Secrecy
April 11, 2014 by Bruce Morton (Entrust), Rick Andrews 3DES DH ECC ECDH Forward Secrecy OpenSSL RC4 RSA SSL/TLS TLS 1.2

Recent revelations from Edward Snowden about pervasive government surveillance have led to many questions about the safety of communications using the SSL/TLS protocol. Such communications are generally safe from eavesdroppers, as long as certain precautions are observed. For example, configuring your web server to avoid using SSL2 and SSL3, favoring newer versions of TLS like TLS 1.2, selecting strong ciphersuites, etc.

But even if your server is configured properly, you still must secure the private key associated with your SSL certificate. In nearly all cases, the web site owner generates their key pair and sends only the public key to their Certification Authority (CA). The CA (and any eavesdropper) sees only the public key, and the private key cannot be derived from that. So the CA cannot reveal a web site owner’s private key to the government or an attacker, even if coerced to do so.

2014 – Looking Back, Moving Forward
January 6, 2014 by Bruce Morton (Entrust) Attack BEAST CA/Browser Forum CAA Code Signing ECC Encryption Forward Secrecy HSTS ICANN IETF Microsoft MITM Mozilla PKI Policy RC4 RSA SHA1 SSL/TLS TLS 1.2

Looking Back at 2013

Protocol Attacks

The year started with a couple of SSL/TLS protocol attacks: Lucky Thirteen and RC4 attack. Lucky Thirteen allows the decryption of sensitive information, such as passwords and cookies, when using the CBC-mode cipher suite. Lucky Thirteen can be mitigated by implementing software patches or preferring the cipher suite RC4.

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.

Getting the Most Out of SSL Part 2: Configuration
June 29, 2013 by Ryan Hurst Attack CASC DH Forward Secrecy OpenSSL PKI RC4 RSA SSL/TLS TLS 1.0 TLS 1.2 Vulnerability

They say the most complicated skill is to be simple; despite SSL and HTTPS having been around for a long time, they still are not as simple as they could be.

One of the reasons for this is that the security industry is constantly learning more about how to design and build secure systems; as a result, the protocols and software used to secure online services need to continuously evolve to keep up with the latest risks.

RSA Recap – Securing Your Site
March 8, 2013 by Ben Wilson BEAST CASC Encryption Firefox Hash Function HSTS OpenSSL Policy RSA SSL/TLS TLS 1.1 TLS 1.2 Vulnerability

At RSA last week a few of us participated in panel discussions that focused on SSL/TLS. During the panel that I moderated on Friday, one theme we addressed was secure server configuration. One of CASC’s goals is to help harden existing SSL/TLS implementations against vulnerabilities—because most SSL/TLS exploits arise from suboptimal website configurations. These vulnerabilities and attacks can be mitigated or even eliminated with proper server configuration and good website design.