PKI Consortium blog

Stricter Standards for SSL Server Test Coming in 2017
December 13, 2016 by Bruce Morton (Entrust) 3DES CASC Forward Secrecy RC4 SSL/TLS TLS 1.3 Vulnerability

This is a good time to offer a reminder that the CASC has a great tool for secure server testing, the SSL Server Test. The tool grades your server installation and reviews the: certificate, protocol support, key exchange and cipher strength for security against standards and known vulnerabilities.

The grading tool also provides feedback on handshake simulations with various versions of browsers and operating systems. This lets the server administrator know which implementations are supported. The test also checks the server mitigation for known vulnerabilities such as: DROWN, BEAST, POODLE and Heartbleed.

How a SWEET32 Birthday Attack is Deployed and How to Prevent It
September 7, 2016 by Bruce Morton (Entrust) 3DES Attack Encryption RC4 SSH SSL/TLS TLS 1.0

Details surrounding the SWEET32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN can be found in the paper released by Karthikeyan Bhargavan and Gaëtan Leurent from INRIA in France. The paper shows that cipher suites using 64-bit block length ciphers are vulnerable to plaintext recovery attacks. As such, Triple-DES (3DES) and Blowfish are vulnerable. Here’s an overview.

Vulnerabilities to a SWEET32 Birthday Attack

Certain scenarios are pre-disposed to a SWEET32 Birthday attack. For HTTPS, most susceptible are websites that support the 3DES algorithm and sustain long lived connections.

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.

My Website’s SSL Certificate is Fine; Why Do Browsers Downgrade the Security Indicators For My Site?
April 1, 2015 by Rick Andrews Attack Chrome Encryption EV IETF RC4 SSL/TLS

All the major browsers provide “security user interface”, meaning visual elements to inform the user of the security of their connection to the web page they’re visiting. Up until now, those interface elements were tied to the use of SSL/TLS certificates served by the web site. For example, if you went to http://www.example.com, no special elements would be displayed, but if you visited https://www.example.com, you would see a lock icon indicating the presence of a trusted SSL/TLS certificate. You would also see in the address bar the name of the company responsible for the web site, if the web site used an EV certificate. Most browsers change user interface indicators for mixed content (when a secure page loaded scripts, images or other content from a non-secure site).

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.

Reducing the Impact of Government Spying
April 4, 2014 by Jeremy Rowley CASC Encryption Forward Secrecy Malware PKI RC4 RSA SHA2 SSL/TLS TLS 1.1 Vulnerability

Last year, Edward Snowden, an American computer-specialist working as a contractor for the National Security Agency (“NSA”), shocked web-users around the world by publicizing documents showing that the NSA was gathering intelligence on Internet users. The realization that the US government was gathering sensitive information has led to a worldwide demand for better protection of online communication and data and a general worry about the effectiveness of existing infrastructures. Specifically, some entities have asked whether PKI is still a robust way to protect online information.

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.

All You Need to Know About the RC4 Encryption Scheme
March 14, 2013 by Rick Andrews Attack CASC Encryption RC4 RSA SSL/TLS Vulnerability

The latest published attacks target specific algorithms used within SSL/TLS. Those algorithms are used when a client connects to a server via SSL/TLS; they’re not used when a Certificate Authority signs a certificate. The attacks demonstrate potential weaknesses in the use of the algorithms.

While interesting, the attacks don’t represent an immediate practical threat to users of SSL/TLS (including online banking, e-commerce, social networking, etc.). Such attacks require an attacker to run malicious software on a user’s computer which would connect to a particular web site and send the same message over and over again many times. In fact, if the attacker’s software could send the same message over and over 10 times per second, it would still take more than 3 years for the attack to succeed.