Viewing posts with tag security.

StartEncrypt Vulnerabilities

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, 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 and 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.

Misleading StartCom Advertisement

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.

Read more…

Automating Let's Encrypt with simp_le

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.

Read more…

Let's Encrypt!

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…):

letsencrypt-auto certonly --webroot -w /path/to/blog -d

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/ 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!

HTTPS Performance, 2048-bit vs 4096-bit

UPDATE: I wrote a new post with newer and faster benchmarks.

After the Snowden revelations, I personally started looking more into encrypting my online activities and making sure sites that ran on my server were (relatively) secure. Eventually I put this blog behind HTTPS as well, not really for any security benefit, since I’m not talking government secrets and the blog has no admin panel, but rather for learning about TLS and how to set it up properly. Problem was, it seems I did not read about things properly. This blog post describes one result of that ignorance.

Read more…

New Server!

So I went and ordered myself a new server. My old one was a VPS from Linode with 1 core, 1 GB of RAM and a 24 GB disk. The new one is a dedicated server from with 8 cores, 8 GB of RAM and 1 TB of hard disk space. At the same time it is only slightly more expensive so I jumped at the opportunity. How reliable it actually is will only be shown with time, but I like living on the bleeding edge. So I thought I would write a blog post about all the stuff I run into when setting up the new server. Note: This post is meant for reference only, not as a guide. Be sure look for recommendations from people wiser than myself regarding any security settings.

Read more…

Facebook Auto-Sharing Spam Pages

Whatever you think of Internet scammers, they sure are inventive. They keep figuring out new ways to scam people for clicks, money, or whatever it is they want. Today I noticed a new type of auto-sharing spam page that was unwittingly shared by a Facebook friend of mine. It takes form as a regular looking clickbait page that lures you in with its title, but when you go to the page, it fools the user into sharing it on their own page.

Read more…

SuperFish – Race to the Bottom

Earlier this morning it was reported that Lenovo is installing adware to their new laptops. This piece of adware is called SuperFish, and it basically MITM’s your connections — including secure ones — and inserts ads into webpages you visit. This in itself should be alarming and is an extremely scummy thing to do, but now things have taken a turn for the worse. Yes, it can get even worse.

Since Lenovo has installed a root CA of their own on the computer, they can basically make your browser trust any site they want by using the CA to create certificates for them. But now everyone can. A couple of people have already extracted the private key from the adware app and bruteforced the terrible, inexcusably bad password. A password of only 7 characters in length, consisting of nothing but lowercase a–z characters. komodia. Really, that’s it right there.

So now anyone can create certificates that new Lenovo machines automatically trust. Shame on you, Lenovo.

And yes, I know Lenovo is not directly responsible because they didn’t make the adware, but they shouldn’t have added some in the first place. At the very least they should have had oversight, because this is complete buffoonery. Hopefully some heads will roll as a result. This race to the bottom where laptops are preinstalled with bloat in ever increasing crappiness must stop.

In case you are using a Lenovo computer and want to check if you are vulnerable, try going here. If you get a security warning from your browser, you are safe. If not, douse your computer in some holy water and go make an angry call to Lenovo support.


I just literally opened this site about an hour ago and I’m already getting scanned for vulnerabilities.

blog: - - [01/Feb/2015:20:25:10 +0200] "GET /vtigercrm/test/upload/vtigercrm.txt HTTP/1.1" 404 162 "-" "curl/7.29.0"

Isn’t the Internet amazing?