Last year we rolled out one-click HTTPS hosting for our hosting accounts using free Let’s Encrypt certificates. We’ve been making some further improvements to our control panel so that once you have enabled and tested HTTPS hosting, it’s also easy to redirect all HTTP traffic to your HTTPS site.
We’ve also added an option to enable HTTP Strict Transport Security (HSTS). This allows you to use HTTPS on your website and commit that you’re not going to stop using it any time soon (we use 14 days by default). Once a user has visited your site their browser will cache the redirect from HTTP to HTTPS and will automatically redirect any future requests without even visiting the HTTP version of your site.
HSTS makes it harder for an attacker to impersonate your site as even if they can intercept your traffic, they won’t be able to present an non-HTTPS version of your site to any user that has visited your site within the last 14 days.
HTTPS and HSTS control panel settings
We believe that the web should be secure by default, and hope that these latest changes will make it that little bit easier to secure your website. These features are available on all of our web and email hosting accounts. We’ll also happily enable this as part of the service for customer of our managed server hosting.
Our beta program has been very successful, lots of domains now have DNSSEC and we’ve seen very few issues. We thought that we should do some wider testing with a larger number of users than our own website, so we asked some friends of ours with a busy website if they felt brave enough to give it a go
Eben Upton> I think this would be worth doing.
Ben Nuttall> I'll go ahead and click the green button for each domain.
-- time passes --
Ben Nuttall> Done - for all that use HTTPS.
So now we have this lovely graph that indicates we’ve secured DNS all the way down the chain for every request. Mail servers know for definite they have the correct address to deliver mail to, Web requests know they’re at the correct webserver.
The only remaining task is to remove the beta label in our control panel.
Raspberry Pi DNSSEC visualisation, click for interactive version
One of the much requested features for Let’s Encrypt free SSL certificates is support for IPv6-only hosts. Whilst this is promised in the very near future we’re happy to say that IPv6-only hosts behind our NAT64 & Proxy services work out of the box with Let’s Encrypt.
To test it we took the traditional dogfood approach, this website is run on an IPv6-only VM and we’ve just enabled Lets Enrypt SSL support on our own blog. As soon as Let’s Encrypt offer SSL certificates for IPV6-only hosts with no proxy and no NAT64 we’ll give that a try too.
DNS-based domain validation (dns-01)
An alternative approach would be to use dns-01 validation using our DNS API. Our API speaks native v6, so that should work just fine on a truly single-stack IPv6 host.
Here at Mythic Beasts, we’ve been busily undermining sales of our SSL certificates by rolling out support for free certificates from Let’s Encrypt, partly because we think that the internet should be secure by default, but mostly because we’re lazy and Let’s Encrypt makes it easy to fully automate certificate issue and deployment.
Domain validated certificates
The majority of SSL certificates in use today are “Domain Validated” certificates. These are issued automatically by a certificate authority once you have completed some action that proves that you are in control of the domain for which the certificate is being requested. This can include responding to an email send to an address at your domain, or posting a file to a specific location on your website.
Let’s Encrypt DNS challenge
One of the options for validation offered by Let’s Encrypt is a DNS challenge (known as “dns-01”), whereby you prove ownership of your domain by adding a specific entry to its DNS zone. This option is quite interesting, as it allows you to avoid meddling in any way with your web server configuration and, if your DNS is hosted with Mythic Beasts, you can automate the addition of the necessary records using our DNS API.
It’s been a long time coming, but we’re now pleased to announce that we’ve got DNSSEC support in public beta, and you can enable it for your domain at the click of a button.
What is DNSSEC?
DNSSEC is a set of extensions to the DNS protocol that ensures that you can trust the IP addresses that you get back from the DNS system. For example, if you visit www.yourbank.com, the first thing that happens is that your browser uses a DNS server to find out the IP address of your bank’s web server. But how do you know that you can trust the address that you get back? Your request will probably get bounced through multiple DNS servers, such as your home router, your ISPs servers, and finally the authoritative server for the domain. If any one of those gets compromised (and let’s face it, home routers have a terrible security record) it could easily insert a different IP address and direct your request to an entirely different server.
DNSSEC means that all responses are signed with encryption keys that have been lodged with the registry, so you can’t inject bogus responses just by compromising an intermediate server. Of course, the system only works if the systems making the requests check the signatures of the responses that they receive, something which certainly doesn’t happen everywhere yet.
Yes it is, particularly as it is recommended that the encryption keys that you use are changed (or “rotated”) regularly. Fortunately, we’ve now automated all the hard stuff, and if you’ve got your domain registration and DNS hosting with Mythic Beasts, you can make DNSSEC go just by hitting a big green button. We’ll take care of the rest:
Unlike some people, we believe that the internet should be a safe place to do business by default, so this service is, and will continue to be, provided at no extra cost.
If you want to try it out, simply visit our control panel, find the domain under “My Domains” and follow the “DNSSEC” link.
Customers with hosting accounts on either yali or onza can now get free SSL certificates for websites, allowing you to have an https version of your website. We’re using the Let’s Encrypt certificate authority to provide the certificates.
To get a certificate and enable https hosting for your site, simply press the button in the control panel, and within 5 minutes you should have a working https site. You can find the option under “Web and Email Hosting“.
Free SSL at the press of a button
Let’s Encrypt certificates have a short expiry period, but we will take care of automatically renewing them for you.
Why use HTTPS/SSL?
Using SSL on your website means that traffic between our server and your user’s computers is encrypted and can’t be intercepted (despite David Cameron’s desires). It allows browsers to guarantee that they are indeed talking to the website shown in the address bar, even if they are using an untrusted network connection. Even if you don’t view the security aspects as a benefit, Google have previously announced that they will boost the page ranking of SSL-enabled sites.
Unfortunately, this service is not yet available to customers on our sphinx server. We are working on that, and will have it enabled in the near future.
SSL certificates use hashing functions to provide security. The Secure Hash Algorithm 1 (SHA-1), was published by the NSA in 1995 as the standard for secure authentication. The first theoretical attacks were shown in 2005 leading to a recommendation in 2010 that we abandon SHA-1 and move to SHA-256. In 2014 Google put a sunset date for SHA-1 of December 2016 – if your website trusts an SHA-1 certificate past this date Chrome refuses to regard your site as secure.
With iOS9, Apple pulled the date at which everyday software stops working with SHA-1 forward. If your website or application is secured with a SHA-1 certificate, iOS9 gives warnings and errors. The fix is easy, we can provide or re-issue your existing certificate with an iOS9 compatible – and more importantly more secure – SHA-256 certificate.
We will be reviewing the details as soon as the vulnerability is released, and will be patching the affected servers shortly after the updated packages are released, if necessary we will be contacting customer to reissue keys as we did after the now infamous Heartbleed vulnerability.
If you have any questions, or would like to upgrade to a manged service so we catch these kinds of issues for you, you can contact us at email@example.com.
SSL Certificates do two things. They encrypt the traffic between the end user and the website, and they provide authentication that confirms the website is who they say they are. As we previously wrote about at present the authentication step is done using a piece of maths called SHA-1.
What the SHA-1 function does, is to provide a signature that says ‘The Certificate Authority confirms that the public key for Mythic Beasts is ….’. It’s extremely important that nobody else can forge this signature, otherwise anybody could present their public key instead of the Mythic Beasts public key and intercept all of the data.
Now SHA-1 has been subject to a lot of analysis by people attempting to forge keys, and slowly progress has been made. SHA-1 has not been “broken”, but thanks to improvements in mathematics and computing, the estimated cost of forging a certificate has steadily fallen from more-money-than-exists to a-large-country-could-do-it and in the next 5 years is likely to reach script-kiddy-with-a-botnet-could-do-it.
So Google, Firefox and others now refuse to accept SHA-1 based certificates that will last into 2017. Whilst you can’t forge them now, in two years time it’s likely that well funded organizations may be able to do so. As a result, the Internet has had to migrate to SHA-2, a new function that achieves the same as SHA-1 for proving authenticity but has no known attacks: forging a SHA-2 signature is currently believed to be entirely infeasible. Google’s announcement of their intention to deprecate SHA-1 was greeted with dismay and anger, but in the end had the desired effect. The certification authorities moved quite quickly to make SHA-2 the default.
At Mythic Beasts this week, we replaced our SSL certificate for all our servers. As expected, the new certificate we were issued was SHA-2 based. Deployment of the new certificate went smoothly, sufficiently smoothly that not a single customer noticed. A short time later we realised that we now didn’t seem to receive any support mail at all.
Our ticket tracking system runs on top of mono, an open source reimplementation of .NET. The older version of mono it uses doesn’t have support for SHA-2 certificates, so our tracker was seeing the secure connection, failing to authenticate and refusing to send or receive email. Briefly we worked around this by turning encryption off for the support system – as the traffic is entirely within our network we aren’t so worried about it being intercepted.
However, we know that our end-users use a wide variety of different clients for email, some of which are quite old and obscure. So we thought it was rather likely that we were breaking email functionality for existing customers with the SHA-2 certificate. We decided the sensible thing to do would be to use the new SHA-2 certificate just for websites, and obtain a new SHA-1 certificate for mail applications.
We will face the same issue again in 12 months. (Except we don’t even know if the certification authority will still offer the choice of getting a SHA-1 certificate then.) We’re hoping that a year will force a number of updates to mail clients and system libraries such that next year we can deploy SHA-2 everywhere. Eventually, we will have to draw a line, and say that if our customers’ clients don’t support SHA-2, they will have to upgrade them, or use unencrypted access.
In a little known fact, here are two old men singing about SSL security beginning with a limited understanding of SHA hashes. It delightfully uses the metaphor of a journey to meet their loved one to show how the process of security is a continuous process that can never be fully achieved.
We’re please to announced that we can now set DS records for any domains registered with us. At present, only UK domains can be configured through the control panel. For any other domains, please email support and we’ll put the records in place for you.
Control panel integration and other DNSSEC improvements will be coming soon.