What does Facebook have against Christmas?


This turned into a bit of a rant! My apologies!

If you were on Facebook during Christmas time, you probably noticed something was lacking from the ‘Trending’ part of the site, which is usually on the right-hand side. Christmas.
I don’t think this can be attributed from lack of user activity, because at least in my circle of friends, and my partner’s circle of friends, there were many Christmas messages and photos being passed about.
And it’s trending on Twitter, still, as of Boxing Day.

So, what does Facebook have against Christmas? And is this a thing that is exclusive to the company? Or is it a bigger problem in Silicon Valley and attack on Christianity?
Why was Facebook happy to add Eid and Ramadan onto that list, but not Christmas?

I’ll start by expressing my opinion that there is a global attack on Christianity. I’m not even Christian myself, but my kindest friends in life have been Christians. The majority of modern Christians I’ve met have a ‘live and let live’ attitude to life, and it’s hard to compare other world religions to it. The closest parallels I can probably draw are to Buddhism. Both religions share the same level of passiveness and kindness, with very little doctrine-based hate crime or attacks coming from either.

Of course though, to the Buzzfeed and Tumblrite public, Christianity is seen as an oppressive and evil religion. Why? Because they see Christians as running all the current existing power structures.
Well, is that even true? Not really. But you wouldn’t get elected as president of the U.S. or a senate-grade position without saying you are.

When a Christian does deviate from what is politically correct, the media is quick to jump on them and call them every name under the sun. When we see similar behavior from “less-quiet” religions like Islam, we see them portrayed as the victim or the media simply ignoring it, if there is no way to make them appear victimized.

Every year, we see that Christian holidays consistently eroded.
Well, we shouldn’t celebrate Christmas should we, that’s a bit racist? What about religious group X? Well, it’s just consumerism isn’t it?
To the point, of course, that it’s becoming politically incorrect to say Merry Christmas, and instead we say Seasons Greetings or something similar.
The leader of the Labour Party, Jeremy Corbyn, didn’t even issue a Christmas message or broadcast this year, didn’t say squat about it. But he issued such a message for Eid.

So really, Facebook censoring Christmas from their trending topics entirely is just the next progressive step.
Will Google do the same next year?

Two-factor SSH authentication with U2F hardware security key


I’m shocked at the lack of documentation on using a U2F security key for two-factor SSH authentication. Luckily, it isn’t too difficult, thanks to the fact that Yubico has done a lot of the hard work for us.

A prerequisite for this guide is compiling and installing the pam_u2f.so module. Luckily, there is a fair amount of documentation online on how to do this. You’ll also need a system that can run the u2f-host command. Instructions for getting set with these are here and here, respectively. You will need both of these for both the server andclient.

If you are working with a remote system which you do not have physical access to, I recommend making sure you have a backup SSH session open at all times, as failings in the SSHd or the PAM configuration can cause you to be locked out. You are warned.

First, come up with a unique name for the system you wish to SSH in to. This doesn’t have to be wholly unique, just make sure it doesn’t collide with anything else on the key, really.
For this example, we’ll use backupserver.
You’ll also need to know which account you wish to secure. For this example, we’ll use root.
For this tutorial, I used a MacOS X system to generate the key and responses, and secured a CentOS 7 system. Instructions should be easily adaptable to other operating systems.

Registering the key
We now need to register a new key with your U2F device. In order to do this, we’ll use pamu2fcfg.

On the system with the U2F device connected, run the following command:
pamu2cfg -o pam://backupserver -i pam://backupserver -u root
Make sure to change ‘backupserver’ and ‘root’ to what you decided earlier.
Your U2F device should then start flashing. Touch it to continue.
After you’ve touched the device, you’ll be left with something similar to this on the command line:
This is the U2F key definition. The first part is the username the key is for, and the second part contains both the key handle and the user key. These are seperated by commas.

Configuring the U2F definition
Now login to the server you are wanting to protect, and execute the following command, making sure to replace the data with the output you got from the above command (in quotes). Example:
echo 'root:cCaQUJyqmU68z6KVAdpyk2871wuRVtgDbXCKq5A8zqBj577vdUhdLKeOQG4l9yG-t7Ze8wgtsdF7l0GEjO0g-A,04f32cb3dd0b0b1ac20517050ab1dd2700f410f638675c7ebe18b9607459171c8b82de6d1a1d5d25429157db43943033b741c0c376c375ce460628bd7464677fb4' > /etc/u2f_mappings

This will create a file which we’ll use to tell the PAM module to find your key information.

Configuring SSH
Next, let’s prepare the SSHd configuration. We have to ensure to turn on ChallengeResponseAuthentication and we must make sure SSHd is set to use PAM.
Open up /etc/ssh/sshd_config using your favourite editor.
Make sure to set the following:

ChallengeResponseAuthentication yes

It is probably already defined, so search for it and set it to Yes, or uncomment it.
And also make sure UsePAM is set to Yes.

UsePAM Yes

Now reload SSHd:

systemctl reload sshd

Configuring PAM
Next we need to modify the PAM SSH configuration. Open up /etc/pam.d/sshd. It should look a bit like this:

auth required pam_sepermit.so
auth substack password-auth
auth include postlogin
account required pam_nologin.so
account include password-auth
password include password-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session required pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session required pam_selinux.so open env_params
session optional pam_keyinit.so force revoke
session include password-auth
session include postlogin


auth substack password-auth

Add the following, replacing backupserver with the name you chose above:

auth required pam_u2f.so origin=pam://backupserver appid=pam://backupserver authfile=/etc/u2f_mappings manual

This configuration will ensure that the security key challenge-response is done after the password authentication.

Testing and Logging In
Now, it’s time to test this configuration. Log in to the server in a new session to test if it works.
After you supply your password, you should be met with the following prompt.

Now please copy-paste the below challenge(s) to 'u2f-host -aauthenticate -o pam://backupserver'
{ "keyHandle": "Rr3ZPpbO6fuCF1_w1RgxY2Ft6FpZ3CtABHgeySshQpH470dbVlZCbFIjUEzut3JxQrCoUWJfo4YKjAxJxL2MwA", "version": "U2F_V2", "challenge": "zwkjaDcNdfjMSqOKIq84ZsF9MlS8M0P3rmHCB7PSuKo", "appId": "pam:\/\/backupserver" }
Now, please enter the response(s) below, one per line.

On your system, run the following — replacing the u2f-host command and challenge with what you are asked for:

echo '{ "keyHandle": "Rr3ZPpbO6fuCF1_w1RgxY2Ft6FpZ3CtABHgeySshQpH470dbVlZCbFIjUEzut3JxQrCoUWJfo4YKjAxJxL2MwA", "version": "U2F_V2", "challenge": "zwkjaDcNdfjMSqOKIq84ZsF9MlS8M0P3rmHCB7PSuKo", "appId": "pam:\/\/backupserver" }' | u2f-host -aauthenticate -o pam://backupserver

You should get a response like this:

{ "signatureData": "AQAAADwwRQIhANLPROgaGa5NYrTBY8qK8bCuy3Vc_LI6wZdrFhquyt0lAiA4ppzdGv277g853EW1TKJMC788TwxWV4SOPUPltDGyYA==", "clientData": "eyAiY2hhbGxlbmdlIjogIm1DTDBxel9aV1NvR1pHcElSZk1GYm5WSkcyNHBGMG1tTjR4Z2s4Z3VIU3MiLCAib3JpZ2luIjogInBhbTpcL1wvYmFja3Vwc2VydmVyIiwgInR5cCI6ICJuYXZpZ2F0b3IuaWQuZ2V0QXNzZXJ0aW9uIiB9", "keyHandle": "Rr3ZPpbO6fuCF1_w1RgxY2Ft6FpZ3CtABHgeySshQpH470dbVlZCbFIjUEzut3JxQrCoUWJfo4YKjAxJxL2MwA" }

Paste that into your SSH session, and press Enter. Provided you supplied a correct password and challenge response, you should be logged in.

The problem with CloudFlare Free SSL


CloudFlare recently introduced a ‘Free SSL’ service. Straight off the bat, this sounds great for website owners. It’s basically the service that they’ve been offering to their pro users for a while. A chance for organisations and websites to use SSL without knowing the slightest about security.

It is fundamentally flawed and shows the problem with the centralized authority system we have right now. However, we’ve never had a system where it is incredibly easy to serve HTTPS sites before. Yes, we’ve had “free” certificate authorties like Startcom, but they are known for doing a lot of manual verification and validate WHOIS details. CloudFlare Free SSL is the final bullet in this ridculous system.

Phishing. Fraudsters and phishers love the new service. It means they can setup a fraudulent website very quickly, and without any verification apart from that they can change the DNS records of the domain, instantly getting that padlock that we’ve been telling people is great for years.

False sense of security. One of the major reasons more and more organisations and website owners are flocking to SSL is because it protects against interception. Flexible SSL is a CloudFlare solution which works by adding security between the user and CloudFlare, but not between CloudFlare and the server. Anyone who is on any hop between CloudFlare and the origin server can listen in, and you bet that probably includes your buddies the NSA/GCHQ.
The very annoying part of this is you’ve got absolutely no idea if a website you are connecting to is using this Flexible SSL, so you’ve got absolutely no way of trusting that padlock anymore.

Hacking. If someone discovers your CloudFlare username and password, they can change the origin server to somewhere else. They could change the origin server to a reverse proxy server that logs everything and then passes it on to the real server. You as a user would see absolutely nothing. The site owner might not even figure it out, as it looks like everything is fine and well. Without CloudFlare, an attacker would at the very least have to get a new certificate issued, or hack the server and steal the private key. Now, they don’t have to.

What could CloudFlare do? There are a few things CloudFlare could do to make their Free SSL service not suck as much.
I would recommend getting rid of Flexible SSL, or at least add a warning to the user that your traffic could still be intercepted.
They could do more manual verification of new accounts, and domains that look suspicious should not be issued a certificate.
I’ll admit, there’s not much they can do about the hacking aspect, although I’d personally require users to use two factor authentication to activate their SSL options.

It should be noted I use SSL as it’s the industry standard term. Nowadays, it mostly refers to newer TLS technology.