Quick trusted overview.

We now live in a work of free ssl certificate for everyone [startssl, let’s encrypt]. This is awesome not only for security, as in you encrypt your in-transit data, but also for authenticity, that is, you prove (by proxy) to everyone that the data stream originated from your server. This is done by trusting the certificate, or more precise: the certificate path.

A certificate path starts from the certificate authority, the company or entity you gives you your certificate. Most of the time your certificate is signed not directly by your certificate authority (CA) but by/through an intermediate certificate authority. Your browser (Firefox, Opera, Iexplore, Safari et all) comes with a list of trusted ‘root certificates’. All certificates signed by any of those trusted root-CAs are automatically trusted as long as the chain of trust is complete. So your browser trusts, for example, startssl root-CA. StartSSL created and signed an intermediate-CA so that is trusted, too. This one, in turn, issued your server CA. As your browser trusts the entire chain you should not see any security warnings when you visit your site.

The problem.

So what is the issue here? Your browser already trusts all the certificates issued by any trusted root-CA. There you have it. The problem. You trust any issued certificate. So when an obscure Chinese root-CA issues valid certificates for your domain, that certificate is automatically trusted by anyone. A man in the middle or imposer attack was never this easy. Think this is a theoretical problem? It’s not. There are many cases out there.

(more…)

The Issue

If you are using WordPress then you undoubtedly have noticed an ever increasing number of login attempts on wp-admin.php. There are botnets out there that do nothing else but try to login to (any) WordPress Backend site. The reason is simple and not what you think; they are not going to defacing your site but rather looking for mailservers in good standing.  Once “hacked” into your wp-admin, they most commonly infect a theme and call that theme to send tens of thousands of Spam mails to the point where your server can no longer send email due to the fact that it’s blocked on most rbl’s out here. This is in fact so common, that removing malware from WordPress themes is a (near)fixed task at work.

But even if you have chosen a good, strong password combined with a non-standard username there is still the matter of exploiting bugs and glitches which might even bypass authorization altogether.

A Solution

The solution is simple, place a htaccess-protection in front of it. A htaccess protection is plain stupid from a technical point of view – not much can break, not much can be bypassed. By adding another layer of authentication you effectively protect your wp-admin and all current and future bugs and exploits.

But this would mean having to log in twice. Yuck.

And don’t think about using the same username and password combination for both locks.

A better solution

How I am doing it and how I recommend it: Run nginx (it does work with apache, too!) and always serve tls pages which is a best practice and good for your seo on google. I am assuming you already have a working nginx setup and your site is already being served out of nginx. So edit your nginx configuration add add these lines to enable tls:

(more…)

Yes, Sir!

If you are reading this blog, odds are you are an System Administrator or at very least someone with technical skill and Linux knowledge. Following this train of thought, giving our connected world, leads us to the fact that you have used ssh at some point. And chances are you seen this prompt:

The authenticity of host 'mx1.alpha-labs.net (46.229.47.141)' can't be established.
RSA key fingerprint is 50:88:9e:56:e9:2a:2f:d7:7f:e7:a9:3d:0f:23:9e:52.
Are you sure you want to continue connecting (yes/no)?

Be honest: Did you ever really read this passage? I wager you typed “yes” to get on with the job at hand. This however, is a major security concern. You see, encryption is only awesome if you talk to the right person. What use is the most sophisticated encryption if you encrypt with your enemy?

You need to be sure you talk to the right guy, or in this case the right server. The fingerprint printed above should be checked against a trusted source, be it written, given in person or phone call. No one does this, period. So everyone is just typing yes — or even worse: Disabling this check altogether (please don’t).

Do you know DNSSEC? With a fully trusted path coming from the root name servers “.” across the tld registries (.net) all the way down to the local system administrator on fqdn level (alpha-labs.net) or even lower (mx1.alpha-labs.net).

(more…)