Why?

Lots of good reasons as of July 2018 posted here by Troy Hunt, including that the National Cyber Security Centre (part of GCHQ) says so here – the title of that blog post is ‘serve websites over HTTPS (always)’.

As we state in our HTTPS guidance, all websites should use HTTPS, even if they don’t include private content, sign-in pages, or credit card details.

When we’ve had recent Home Secretaries state that encryption aids terrorists, if the Security Services are saying .. use encryption .. well, seems rude not to.

Mostly, it’s an excuse to play with Cloudflare.

Background

I’ve recently stood up this blog on wordpress.com. I’m paying for the base package, and as part of that I can use an existing domain, sort of.

wordpress.com cannot take over the main website subdomains; ie:  ‘www.thewatertower.org’ and ‘thewatertower.org’

So, I set it up on https://blog.thewatertower.org

There’s a CNAME that forwards it on, and wordpress.com handles providing a certificate for the ‘blog’ subdomain, so it’s https if you go direct.

Box ticked: blog.thewatertower.org meets the requirement: a 3 month Lets Encrypt certificate. Nice.

What I now want to do is intercept web traffic to my domain’s website, and securely forward them on to the blog. As it stands, my website is a small amount of HTML and a JPEG hosted (on port 80) by my domain provider.

DNS Steps

I started by watching Troy’s videos at https://httpsiseasy.com/

So, first steps were:

• set up an account
• enable 2FA (via ‘my profile’)

I didn’t want to move my DNS to cloudflare, because I use it heavily for email.  My website isn’t that important if anything goes wrong with it.  But it’s either move DNS, or use their CNAMEs support, which won’t handle the root domain.

Cloudflare detected

• A wild card A record, which Cloudflare will only replicate in DNS on the free service.
• A records for ‘thewatertower.org’ and ‘www’ which are the ones I need.
• CNAMEs for autoconfig, ftp, imap, pop3 which Cloudflare proposes maintaining in DNS and not proxying.
• CNAME for blog.thewatertower.org, which Cloudflare wants to proxy. I changed this so Cloudflare would only handle DNS, not proxying.
• MX, SRV, and TXT records which Cloudflare will replicate in DNS.

Next steps:

• I documented all the records, including sufficient information to re-enter the SRV and MX records via my domain provider’s admin interface.  Just in case.
• I changed the DNS settings for the domain, and confirmed the update via my domain supplier’s WHOIS tool.

Crypto

• I changed SSL from ‘full’ to ‘flexible’ as the current sites do not serve HTTPS. Once it’s all live, I should be able to test my current holding page and find it running https. Once redirects are working, I should be able to set this to either full or strict.
• ‘always use HTTPS’ changed from off to on.
• I changed Minimum TLS from 1.0 to 1.2
• TLS1.3 was enabled by default
• Automatic HTTPS rewrites enabled.

To do this, the DNS records for the parts of my domain running through Cloudflare need to change.  I assume they would do anyway, as ‘thewatertower.org’ and ‘www.thewatertower.org’ were identified by the Cloudflare onboarding tool / DNS dashboard as DNS plus proxying.

First hour; DNS TTL

Within about 30 minutes of changing DNS on my domain, Cloudflare detected the change and updated the dashboard. The first four requests were from Vietnam, within the first hour. Who’d have thought my domain landing page was so popular. Anywhere.

The following queries continued to return the original IP address.

dig www.thewatertower.org A
dig thewatertower.org A

Time to live was showing as just under 24 hours, and this query showed the authoritative servers as my original ones ..

dig +short NS thewatertower.org

not cloudflares; eg:

$ dig +short NS httpsiseasy.com
leah.ns.cloudflare.com.
rob.ns.cloudflare.com.

So, it would seem that the TTL happened to reset during my DNS changes, which makes the queries from Vietnam a bit of an anomaly. Perhaps that’s where Cloudflare detected the name server change from.

Next day

I checked all the DNS records were returning as expected.

The DNS changes had propagated, to me anyway, within 14 hours.  Traffic stats suggest I’m not alone. No more interest from Vietnam, peak interest is currently from China.

I now see DNS results that don’t map to the old IP, as expected:

;; ANSWER SECTION:
thewatertower.org.	300	IN	A	104.18.50.27
thewatertower.org.	300	IN	A	104.18.51.27

(There’s AAAA records as well)

Shift-reload of my site loads the old content with TLS; a one year Cloudflare issued certificate with the following Subject Alternative Name entries;  the common name being the Cloudflare one.

DNS Name: *.thewatertower.org
DNS Name: thewatertower.org
DNS Name: sni.cloudflaressl.com

Page rules

The free service comes with three page rules.

I set up two shortly after making the DNS change and then flicked the rules ‘off’ (I could also have done this, reading the docs, using ‘save as draft’.)  Ready to then test them when DNS sorts itself out.

www.thewatertower.org/*
Type: Fowarding URL. 
Status code: 301 permanent redirect, URL: https://blog.thewatertower.org

thewatertower.org/*
Type: Fowarding URL. 
Status code: 301 permanent redirect, URL: https://blog.thewatertower.org

Reading the documentation

• Specifying http/https on the URL to match is optional. I didn’t specify so it’ll match both.
• Specifying the port is optional;  if not specified, all ports are matched.

Initially, I didn’t specify the trailing “/*”, ie:

source: thewatertower.org
destination https://blog.thewatertower.org

My logic was that I wanted to hoover up the traffic, not translate the original content, such as:

source: thewatertower.org/*
destination https://blog.thewatertower.org/old/$1

That worked fine for basic requests for the site, but requesting specific resources like the image still resulted in the original content being served. So, I fixed that.

SSL Labs

I then checked out the site using Qualsys SSL server test, and it got an ‘A’ – which will do me. It also shows the redirect. That’s basically what I wanted: a permanent redirect, issued securely over HTTPS.

HTTP status code	301
HTTP forwarding	https://blog.thewatertower.org
HTTP server signature	cloudflare

I’m not concerned about HSTS and preload for this. As an aside, my target site hosted by wordpress.com is also an ‘A’ and

• Supports TLS 1.0 and 1.1.
• Has some weak cyphers.
• Does specify HSTS.
• Has a fun message in the HTTP headers.