I’ve switched to a new SSL certificate on my blog website. Most of the time, this is just an uninteresting routine maintenance. Certificates expire, and they need to get renewed. It’s not the usual thing this time though. I’ve taken the opportunity to move to ECDSA-based certificates. It replaces the more customary RSA certificates used by most others.
I made the switch at about 8am this morning. If you’re reading this now, then of course you have no trouble with the new ECDSA-based SSL certificate. But if you do have some difficulties accessing this website using some other browser, operating system, or device, drop me a note somewhere.
My blog website still uses SSL like it has before. The SSL part has not changed. The bit that has changed is the use of ECDSA-based SSL certificates to identify the website. ECDSA and ECDSA-based SSL certificates are not new, but they just aren’t very often used. The more regular type of SSL certificates uses RSA keys. ECDSA-based certificates use Elliptical Curve Cryptography (ECC) keys.
ECC keys offer several important advantages over RSA keys:
- Small ECC keys have the equivalent strength of much larger RSA keys. A 256-bit ECC key is equivalent to a 3072-bit RSA key. This website now uses a 384-bit ECC key.
- The smaller keys means smaller certificate sizes. The PEM-encoded size of my old certificate is 2390 bytes, while the new ECDSA-based certificate is just 1391 bytes.
- The HTTPS connection uses up lesser bytes, because the certificates are smaller. Fetching the main homepage, with all the graphics, stylesheets and ancillary files, take 352 kB with the new ECDSA-based SSL certificates, whereas 372 kB is used with the old certificate.
In general, the ECDSA-based SSL certificates are faster and more scalable.
Websites have been slow to adopt ECDSA-based SSL certificates because they want to maintain compatibility and support for older browsers. ECDSA support, however, has been around for a long time, and today it’s quite safe to say that all modern browsers can support ECDSA-based SSL certificates.
My new ECDSA-based SSL certificate is Comodo’s PositiveSSL certificate product. They support issuing of ECDSA-based SSL certificates. Not all certificate authorities support issuing of ECDSA-based SSL certificates, so this is something you should take note of if you’re looking for a certification authority for your next SSL certificate. I’ll write more in another post.
In the meanwhile, if by some very slim chance you couldn’t access my website today, it may be due to the new ECDSA-based SSL certificate.
Eww, the NIST P-384 curve. You should really watch your P’s and Q’s (literally) as the NIST curves are potentially NSA-backdoored. Perhaps you should consider switching to ChaCha20-Poly1305 stream ciphers instead. They run very efficiently in software, even on mobile devices. Google has enabled this in their cipher suite on their own servers. I believe most of the popular TLS libraries (i.e. OpenSSL, NSS, etc.) have already been patched to support this, as well. Even Cloudflare, bane of all Tor users, enabled it. At this point, I don’t think you have to worry about browser compatibility.
Actually, I was somewhat amiss in my statements. This construction only covers the symmetric part of the equation. You’d still need something like Curve25519 to establish a usable TLS link. Thankfully, that’s also being hashed out as we speak. It’s coming to Chrome 50 and should be part of the TLS 1.3 spec Any Day Now(TM).