Tag: ssl

Drop DES Ciphers
My (former) coworker read my recent post about the forward secrecy and noted the following:

@p0pr0ck5: you really ought to get rid of the DES ciphers too.

As it happened I was looking into that!

What Is DES?

DES stands for Data Encryption Standard. It’s a symmetric-key algorithm using 56-bit keys, which means it applies its magic to a block of data at once, rather than one bit at a time.

Back in the 1970s, The National Bureau of Standards (in the US) created DES because it occurred to them that secure data was a good idea. A bunch of brains were invited to meet their proposal for a standard, and of them IBM (yes, that IBM) came up with a winner.

What’s the Problem?

It’s 2017, not 1971, and data is bigger and more complex. First off, 56-bit keys are too small. AES, the current standard, uses 128-bit and 256-bit keys. But perhaps more importantly, we don’t do symmetric encryption anymore. Sending the keys over the same channel you’re going to encrypt is dangerous and easy to snipe.

Back in the late 1990s, a big machine could break a DES key in 22 hours. Today, using a cloud network on Amazon, it could be done in seconds, and be worth it.

Oh and if you’ve heard of 3DES and are wondering if that’s better, it’s not. Remember the massive Target hack in late 2013? A bunch of credit cards were stolen and it turned out Target stored their PINs in 3DES. So no. Not safe at all.

Why Did You Have It?

Because Windows XP is a sack of shit and up until last year, I had to support it.

Seriously, that was it. Now that everyone I know who use some XP (and NT) are on modern OS’s (or blocked from the server… or dead) I don’t have to worry so much.

How Do We Ditch It?

Remember, these are the default chiphers:
```
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
```
In there you have the following: ECDHE-ECDSA-DES-CBC3-SHA, ECDHE-RSA-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, and DES-CBC3-SHA

While I already have !DES in my cipher suite (as I posted a few days ago), I should remove it fully. But that also means in the Pre Main Include section, I need to change my value for SSLCipherSuite to match!

When I tested, I noticed that I was still pulling a TLS suite with 3DES: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

To fix that, I changed HIGH to +HIGH:+MEDIUM:-LOW and that gave me the following:
```
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:+HIGH:+MEDIUM:-LOW:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4:!DSS
```
The -LOW is the magic sauce to say “Don’t use anonymous insecure ciphers.” when you’re on cPanel, you see.
13 February, 2017
SSL Security: Forward Secrecy
Forward secrecy is actually what it sounds like. It forwards on secrecy. This means that the secret keys you have won’t be compromised even if the server’s key gets hacked. The way it works is by constantly changing things. Basically it’s rotating its encryption forever.

“You’re constantly generating new keys for new messages,” says Nadim Kobeissi, the creator of Cryptocat, one instant messaging app that was early adopter of perfect forward secrecy. That means if a user’s device is stolen or hacked and eavesdroppers steal a decryption key, it doesn’t matter. “The latest message gets compromised, but any message prior to that message or after it can’t be decrypted,” Kobeissi says.

This is a good thing to have on your own server, as it means if a secure transaction (like an ebook sale) is compromised, only that one instance is impacted. No one else gets hacked. No other part of the sale is affected. You minimize damage considerably.

Let’s do this thing!

On Monday we killed off RC4 by going to WHM Home » Service Configuration » Apache Configuration » Global Configuration and changing the cipher suite to this: ALL:!ADH:!RC4:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP:!kEDH

In order to properly handle perfect forward security, we have to reorder things. Instead of using ALL, which calls everything, we need to put the ciphers in a preference and omit the ones we don’t want. That gives us this:
```
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4
```
Awesome. Once we set that, and restart Apache, we go to Service Configuration » Apache Configuration » Include Editor » “Pre Main Include” and pick ‘All Versions’ from the drop down. I’ve edited this section before, when adding HSTS support. But then I edited pre_virtualhost_global.conf (“Pre VirtualHost Include”). This is just a different section.

In the Pre Main Include section, put this:
```
SSLProtocol all -SSLv3 -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4
```
This forces the SSL protocol to v3 and then v2, but then it demands the order of the ciphers be honored.

Restart Apache and you’re done.

Testing it

If you want to test, go to ssllabs.com/ssltest and you should see something that says A or A+. If you don’t have it right, you’ll max out at an A-.

This site? It’s currently an A+, however that target is always moving. Keep safe out there.
1 February, 2017
SSL Security: Killing RC4

In the middle of debugging what turned out to be an unrelated problem, my friend James pointed out that my server was throwing a warning about the RC4 cipher.

Ciphers?

When you want to transmit secure data, you use a cipher to encrypt the data. RC4 is a (hah) cipher. It generates a stream of random bits and bytes (they’re not really random) and combine them with plain text using a pattern to make an encrypted message. The secure connection unravels the bits because it knows the cipher too.

Ciphers only work if no one knows how to crack them. That isn’t the case with RC4 anymore and it was hacked. Sad news. Time to disable it!

Disable it!

Why was it enabled at all? As it happens, it was enabled on my servers for browsers that can only use it. Old browsers. The funny part is that those old browsers can’t support SNI (which is what lets me have multiple certificates and multiple https sites on one IP address), so the domains were broken anyway.

To disable, I went to WHM Home » Service Configuration » Apache Configuration » Global Configuration and changed my cipher suite to ALL:!ADH:!RC4:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP:!kEDH

The !RC4 is the part that says “Not this one!”

Restart Apache and you’re safe to go!

30 January, 2017
Let’s Encrypt cPanel
On August 10th, cPanel announced provisional support for Let’s Encrypt via AutoSSL.

For hosts like DreamHost to be able to implement Let’s Encrypt is a lot easier than a behemoth like cPanel. See, DreamHost only had to make sure it worked on their own servers. They have a homegrown panel that they have 100% full control over. Adding in how to install the code on all servers and how to integrate it requires less testing than cPanel, who has to make sure everyone who uses cPanel can use this.

As of version 58 of cPanel, everyone can. And it works.

Installation

Log in via SSH and run this as root:
```
$ /scripts/install_lets_encrypt_autossl_provider
```
That installs everything you need. Keep in mind, this only adds LE to the AutoSSL feature. It’s AutoSSL that whips up SSL certificates for cPanel accounts. Doing this install does not install certs on your domains. We have to configure it for that.

Configuration

Once you’ve installed the code, go to WHM: Home » SSL/TLS » Manage AutoSSL and set it to Let’s Encrypt:

If it’s your first time, yes, check Create a new registration with the provider. because you’re new. You only need to mess with that if you’re new or have to reset registration for some reason.

By default, AutoSSL is set to run based on your “Feature List Setting” (under Home » Packages » Feature Manager » Edit Feature List). Mine has it checked, which means it will automatically run.

Adding Existing Domains

This worked great except I had a bunch of domains using StartSSL. First off, I adore StartSSL, and the recent changes to their website make it so much easier to use. But I was using it for external free certificates where I didn’t want to pay for them, on domains that never see money. Some of them (most of them) I wanted to convert to LE.

For that, I deleted the StartSSL certificates in WHM and cPanel for the domains/account in question. Then I went to AutoSSL, clicked on the tab “Manage Users,” and clicked “Check USERNAME.” I did not pick check all users (which is at the top of the page) because I don’t want to check all users.

Adding New Domains

I love this part.

Do nothing.

No, really. Add the new domain, wait twelve hours, boom. New certificate. If you have to have it right now, go into WHM and click check for that user. But it’s automatic. Hence ‘Auto’ SSL you see.

Caveats!

This is something only controlled by the server admin. Per-site cPanel doesn’t get an option, however if they delete the LE cert and add their own, that will override it.

There’s a limit to how many times you can make certificates and how many you can make. As the warning says:

Certificates that Let’s Encrypt provides through AutoSSL can secure a maximum of 100 domains per virtual host.
Let’s Encrypt will issue a maximum of 20 certificates per week that contain a domain or its subdomains. If you include subdomains of a domain on more than 20 certificates, Let’s Encrypt will issue those during the next window, up to the limit for that week.

If you’re using a wildcard subdomain (*.ipstenu.org for example) in order to make things easier with Multisite, this won’t work. You’ll see a ton of errors in your logs. Not to mention it won’t make SSL certs for all the virtual subdomains. That’s because they’re too virtual. You’ll have to make an actual add-on subdomain or use a domain alias for LE to pick that up.

You can’t revoke a certificate either, which can be a problem should there be a security issue along the lines of Heartbleed. When that happened, we all had to reset our SSL certs as well as patch our servers. Lots of fun. Should that happen again, cPanel users will have a big problem.

It’s because of that I don’t want to use Let’s Encrypt on everything. I’ll use it on this domain, and my other normal ones, but my WMH domain and my stores use a Comodo Certificate.
19 August, 2016
Mailbag: SNI Incompatibility?

Kim asks:

You wrote an article which does a great job of explaining a number of things. My only question (comments appear to be closed so I could not post there) is the SNI – do you find that there are many people using browsers that are old enough that the SNI creates a problem? I have looked over the list of incompatibles and it does not seem to be that much of a risk, but I thought you might have more concrete information since you’ve been using the setup.

This relates to how I set up my SSL certificates, which is to use Server Name Indications and have multiple certs on one server with one IP. And the question is “Do we care about the old browsers?”

Let me quote my coworker.

IE8 is EOL, XP is EOL. We can’t support things forever.

XP makes up most of the sites that have issue with SNI so I’ve only found 0.006% of my visitors impacted.

Yes, I did that math properly. I checked it a couple times.

No. I’m not worried about SNI and I don’t care. We can’t support old things forever.

27 March, 2015
CloudFlare’s SSL
CloudFlare’s been pushing SSL for a while as a new feature. We all know that SSL is a great idea, that any time you have someone logging in, it should be secure. If you’re handling money, it should be secure. If you’re taking any personal information, for god’s sack (sic), make it secure!

A major problem with this has often been the cost overhead. You can self-sign your certificates, but that pops up with other errors for people. Really what we want is a simple, non-super-expensive, way to have security where and when we need it. Until Let’s Encrypt gets its kick off later this year (and probably for another year after that), it’s complicated and expensive to set up shared hosts with certificates, even if you use SNI.

Enter CloudFlare and their bold proclamation that they’re going to provide free One-Click SSL for everyone, even their free-plan users. This is great! Except that it doesn’t work quite right.

First off, if you use the flexible SSL plan, the one that doesn’t change your URL to HTTPS, then you need to use a plugin line CloudFlare Flexible SSL. Or you can just toss this into your wp-config.php:
```
#SSL
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
	$_SERVER['HTTPS']='on';
} else {
	$_SERVER['HTTPS'] = false;
}
```
Secondly, if you’re not actually changing the URL to SSL, you’ve got a problem. I don’t want my users to hit https all the time, not for all my sites. And all the reasons we don’t use https everywhere aside, it’s something to keep my running costs down.

My rule is that SSL should be used anywhere where you are transmitting information that should not be public, and this suddenly was an issue when I looked at the levels of security. The one I’d want would be Full SSL, as it “Encrypts the connection between your site visitors and CloudFlare, and from CloudFlare to your server.”

And there are two types of Full SSL, one of which is ‘Strict’ and requires you to have your own SSL cert, be it purchased or self-signed.

The obvious implications here, however, are that everyone would see HTTPS in the URL, and I don’t really want that. Of course, that’s not what they meant. What they mean is that IF you use https in the domain, then CloudFlare double encrypts. Otherwise it remains http for the domain.

So basically normal SSL. And this is what I want, because I do have a purchased SSL cert for the domain in question and I do want to be secure all down the line. If I was using a self-signed certificate, I’d use the Full SSL (not strict) and that would work as well.

One important thing to keep in mind is that if you chose to use the Flexible SSL, you’re not giving yourself login protection! As they point out, this gives you an encrypted connection between your site visitors and CloudFlare, but not from CloudFlare to your server. This greatly reduces the possibility of being sniped or sniffed, but the content from CF to use isn’t secured, which means if you use Flexible SSL for your store, you’re a moron.

With that in mind, what good is it? Well you can be promised security throughput for your domain, and that, if you’re using CloudFlare, is a great thing.
25 March, 2015