In my last post I wrote about StartCom’s new StartEncrypt service and its misleading advertisement email. In it I mentioned that they were not using the ACME protocol that Let’s Encrypt is using, but their own StartAPI protocol, for which documentation is behind a login. Their client was also not open source.
It didn’t take long for the first security issues to be found. Computest found multiple vulnerabilities in the StartEncrypt API and client, the most critical of which allowed the user to fetch certificates for domains outside their control. Domains like google.com, facebook.com etc. The following quotes speak volumes about the security of StartEncrypt:
A malicious client can specify a path to any file on the server for which a certificate is requested. This means that, for example, anyone can obtain a certificate for sites like dropbox.com and github.com where users can upload their own files.
[…]
The client doesn’t check the server’s certificate for validity when connecting to the API, which is pretty ironic for an SSL tool.
As Computest points out, when a certificate authority publishes a service which such problems, they are undermining the thing they are paid for – the trustworthiness of their certificates. Personally, after the latest events with StartEncrypt, I would no longer recommend StartCom to anyone, for neither paid nor free certificates.
Before Let’s Encrypt existed, I – like many others – used to use StartSSL, which offered free domain validated TLS sertificates. It was a useful service, but not without its flaws, for example the user interface was very clumsy to use. When Let’s Encrypt arrived, the automation made me jump ship immediately. But a couple of days ago I got an email from StartCom, the company behind StartSSL, that piqued my interest.
This is a project that I’ve been working on for a month or so on my free time (of which there really isn’t too much). I started it on my company’s 12 hour hackfest, where I didn’t get anything worth showing done (it was all backend stuff), but now it’s ready to be published. *drumroll* So, it’s time for the reveal:
Honestly, some days it feels like web development is the art of building a self-aware network of node.js packages that sort of
does what you need it to do… until someone on the other side of the planet inserts a breaking change in a patch version and
the abomination you have created decides to set your house on fire instead.
‘Conqueror’ is about a world that is kind of falling apart around you, and you’re looking for a conqueror to save you. But you’re looking for the conqueror in someone else, which I think is something you should not do. You should find the conqueror in yourself first, and be your own hero. If you stand strong, then you will stand for a bit longer.
NOTE 2016-09-21: It seems whatsapp-purple has been abandoned by its maintainer. So the things in this guide may stop working over time, and your mileage may vary. This guide is left here for posterity.
Perceptive readers may know that I use a Jolla as my phone. This places quite a few restrictions on what programs can be used on it. For WhatsApp I used to use a native application called Mitäkuuluu by coderus. Unfortunately at some point the program was discontinued, the official Android® version did not run well on the phone and the whole thing was a hassle. So I searched for an alternative way of using WhatsApp, since it has some people I would have trouble contacting otherwise. Since my IRC client is always running (on my server) and is something I check often, I looked into what BitlBee had to offer. I got a setup working and decided to document it for others.
Let’s Encrypt is the new free, automated and open certificate authority, that
I talked about in a previous post. The part that I’m focusing on in this post is
automated. Let’s Encrypt is all about automating the certificate request and renewal process, and they encourage this
to the users by offering a good client – and by only giving out certificates with a maximum of a 3 month validity.
I’m not good at remembering things months down the line, especially if I have to deal with multiple different
subdomains. That’s why I wanted to automate my certificate renewal process.
Just noticed someone has forked Mebe into their own version. Haven’t
looked at it more thoroughly, but looking at the feature list they have added lots of useful stuff and removed stuff
that Mebe still has that is specific to my own blog (I’m working on removing them piece by piece). If interested, you
should totally check it out on Github: https://github.com/nmqanh/geekpress.
This is the first project I have that has been forked by someone, makes me feel all warm and fuzzy inside. 😊 Though
also a bit embarrassed of all the things they have had to fix in the engine… Anyway, such a great motivator to see
someone use something you have created.
You may remember that earlier this fall I found out just how much faster a
2048-bit HTTPS certificate is for the server to handle. Now that I
got one from Let’s Encrypt, I decided to redo the performance tests with the new certificate
all set up. Since I ran out of credits on my blitz.io free account, I did the new tests with
loader.io’s free tier instead. That’s why the graphs are a bit different this time.
Before I go into the HTTPS results, I will bring some context. You might remember that last time I got about 730
requests per second served over HTTPS with a 2048-bit key, and about 1380 requests per second for plain HTTP. Quoting
myself from that time: “So fast… 🚀”. Turns out I spoke too soon. By disabling some extraneous console logging,
I was able to more than double the performance. Let’s see the latest results.
For reference: The server is an online.net Dedibox XC with an
8-core Intel Atom C2750 processor and 8 GB of DDR3 RAM.
The identity of this website has been verified by Let’s Encrypt Authority X1.
That’s right! Let’s Encrypt, the new free, automated and open certificate authority, has moved to public beta
and their client has improved enough that I was able to request a certificate for this blog! In the end it was criminally easy,
basically a matter of running one command (after fiddling around a bit to find the correct command…):
This uses the Let’s Encrypt program to automatically validate my domain and request a certificate for it (with the
default value being a 2048-bit one). The way it does the validation is by adding some files to the path I specified and
then making an HTTP request for the domain, checking that the files are accessible. When the domain has been validated,
it requests the certificate and saves it. The cool thing about it is that it creates a directory
/etc/letsencrypt/live/blog.nytsoi.net/ that contains symlinks to the files required for using the certificate, such as
the full chained certificate file and the private key. When I want to renew the certificate, I can run the Let’s
Encrypt program with the same arguments again and it will update the symlinks. That means automating it is very easy
(and indeed required since their certificates currently only last for 90 days). The program also contains plugins for
Apache and nginx, but the nginx plugin is very experimental so I settled for the webroot method.
I’m really excited for Let’s Encrypt’s launch. I hope this will encourage more and more people to adopt HTTPS for their
websites, especially those that deal with user logins or other sensitive data. There’s really no reason to not do it
anymore. Encryption for everyone!