Another quick snippet that I figured out this weekend. It’s not hard, but it’s something that I really wanted to do and had to look up where it was, so perhaps it will help you.

Problem statement:

I run a bunch of local services in my network. They aren’t exposed publicly (I use Wireguard to access them when out and about), so I really don’t need HTTPS. But (rightfully) a number of services behave better when they’re behind HTTPS + if there’s ever a service that’s running amuck (Internet of Things devices?) that’s listening, I don’t want them to see anything.

Options

Option 1: Use Nginx Proxy Manager to request certificates for each subdomain. It works quickly and well. Problem: All certificates are published to Certificate Transparency Logs. I don’t immediately mind exposing what I’m running… but I’d still rather now.

Option 2: Set up wildcard certificates. This requires integration with your DNS provider (since wildcards need a DNS challenge, not TCP).

Of course (based on the title), we’re going with option 2. 😄

read more...

TLDR:

# Use 'always' so headers are also set for non-2XX and unset to avoid duplicates
<IfModule headers_module>
	header unset Strict-Transport-Security
	header always set Strict-Transport-Security "max-age=16070400; includeSubDomains;"
</IfModule>

Slightly¹ longer version:

HTTPS everywhere is a worthwhile goal. Even when you have traffic that isn’t super interesting or sensitive by itself, the fact that you’re encrypting it makes traffic that really does need to be encrypted safer against tools that grab all of the encrypted traffic they can to decrypt later if/when possible.

One of the downsides of using HTTPS though is that without certain things in place, many users will still type domain.com in their address bar from time to time, completely missing out on the https://. While you can immediately redirect them, that very first request is a risk, since if a man-in-the-middle attack happens to catch that request, they can downgrade the entire connection.

Enter HTTP Strict Transport Security (HSTS). It’s a HTTP header that you can send on the first HTTPS connection you establish with a compatible client. Once you’ve done that, any further requests (until the header’s TTL expires without being renewed) will be sent to https:// no matter what the user types. Which solves the first request problem for all sessions… but it still doesn’t fix the very first time you have to get the header. So how do you fix that?

read more...

From time to time when doing web development, you need to test something related to HTTPS. In some cases, the application you’re writing already supports HTTPS natively and that’s no problem. But more often (and probably better, in my opinion) is the case when you have another service (be it an AWS ELB or an nginx layer) that will terminate the HTTPS connection for you so your application doesn’t have to know how to speak HTTPS.

In those cases, how can you test functionality that specifically interacts with HTTPS?

Today I will show you autohttps, a thin nginx proxy using Docker and a self signed certificate to automatically create an HTTPS proxy in front of your application.

read more...