ssl

Optimize AES and ChaCha20 usage with BoringSSL

BoringSSL is a Google fork of OpenSSL. It includes various interesting patches, including an implementation of the ChaCha20 cipher. In addition, BoringSSL allows you to group cipher suites of equal preference:

Equal preference cipher groups. This change implements equal-preference groups of cipher suites. This allows, for example, a server to prefer one of AES-GCM or ChaCha20 ciphers, but to allow the client to pick which one. When coupled with clients that will boost AES-GCM in their preferences when AES-NI is present, this allows us to use AES-GCM when the hardware exists and ChaCha20 otherwise.

Source

In this article I show you how you can tweak your nginx configuration to take advantage of this feature.

Continue reading →

Despite Heartbleed bug: certification revocation refused (Updated)

Note: [04/14/14] Today I was contacted by GlobalSign representative Gregory who stumbled over this blog post, and he was so kind to revoke the affected certs free of charge. He also added, in response to my summary below, that there is an option in the Chrome settings to enable revocation checking, and that beginning April 1, 2015, GlobalSign will restrict the maximum validity of then-issued certs to 39 months.

So the Heartbleed bug (CVE-2014-0160) is out, and every administrator using SSL to protect his infrastructure has been wondering the same thing: should I absolutely, positively, without a doubt, replace all certificates and associates keys?

The only reasonable answer is: yes – if you used certificates on a vulnerable machine. Even those in disbelief were quickly proven wrong.

The first thing I did was to patch all impacted OpenSSL instances and restart the services that depend on the OpenSSL library (that includes not only HTTP but also MTA and IMAP, among others). That was the easy part.

What followed was a major pain with my certificate authority and one of its partners.

Heartbleed

Continue reading →