Using RSA and ECDSA on Apache with CentOS / RedHat

Previously I described a relatively modern set of TLS settings that would give an A+ score on SSLtest. This was based purely on an RSA certificate. There exist another type of certificate, based on Elliptical Curve cryptography. You may see this referenced as ECC or, for web sites, ECDSA. An ECDSA certificate is smaller than an RSA cert (eg a 256bit ECDSA cert is roughly the equivalent of a 3072bit RSA one).

More modern TLS settings

Back in 2016 I documented how to get an A+ TLS score. With minor changes this still works. But times have changed. In particular older versions of TLS aren’t good; at a very least you must support nothing less than TLS1.2. Consequences of limiting to TLS 1.2 or better If you set your server to deny anything less than TLS 1.2 then sites like SSLlab tell us that older clients can no longer connect.

Introduction to web SSL certificates

Last year I wrote about how I used Letsencrypt to handle the SSL certificates for this site. In this entry I’m going to take a step back and discuss the basics of what an SSL certificate is and the steps involved in managing them. There’s a lot of jargon involved, which can make this seem more complicated than it already is. Note that in this post I’m likely to use the words “SSL” and “TLS” interchangeably.

Phishing and Certificate Transparency

Many people are at a large risk of a phishing attack. In this scenario the person may receive an email that looks like it came from a legitimate source (e.g. their bank) and encourages them to click a link that presents them with their bank login page. The user then attempts to login… Except that site isn’t their banking site. It’s a mockup that looks like the real one. And they’ve now told their banking password to the attacker.

Using Letsencrypt for TLS

In previous posts I pointed out why TLS is important, how to configure Apache to score an A+ and how to tune HTTP headers. All this is dependent on getting an SSL cert. Some jargon explained Before we delve into a “how to”, some basic jargon should be explained: SSL/TLS TLS (“Transport Layer Security”) is the successor to SSL (“Secure Socket Layer”). SSL was created by Netscape in the mid 90s (I remember installing “Netscape Commerce Server” in 1996).

Scoring an A+ for SSL/TLS

(Side note: in this post I’m going to use TLS and SSL interchangably. To all intents and purposes you can think of TLS as the successor to SSL; most libraries do both). You can think of security as a stack. Each layer of the stack needs to be secure in order for the whole thing to be secure. Or, alternatively, you can think of it as a chain; the whole thing is only as strong as the weakest link.

Why use SSL/TLS on websites?

Building a secure web application has multiple layers to it. In previous posts I’ve spoken about some design concepts relating to building a secure container for your app, and hinted that some of the same concepts could be used for building VMs as well. You also need to build secure apps. OWASP is a great way to help get started on that. I’m not going to spend much time on this blog talking about application builds beyond some generics because I’m not really a webdev.