Category Archives: Security

Let’sEncrypt on Ubuntu Bionic

So I’ve been getting emails from Let’sEncrypt telling me that my certs are coming in through the old ACME v1 protocol and that if I wish to continue receiving certificates, I need to update my certbot.

I figured this was just because the Ubuntu version I had been running was a little on the old side and was no longer receiving non-security updates, prompting me to update to Bionic (v18).

But the emails kept coming, and it became apparent that the version of certbot I had was woefully out of date (0.31 vs 1.3.0).

Turns out, the certbot team doesn’t have anyone with expertise in packaging for Debian systems – so this has fallen by the wayside (even for their own PPA).

And yet… the EFF’s website containing guidance for getting certbot up and running on various systems still provides a guide for installing using the PPA. There is a justification for doing so, but as of June 2020, the software installed via PPA will be useless, so I’m not entirely sure why it’s still the recommended method 2 months out.

At any rate, here’s what I did to update mine in order to continue working with my hosting software:

wget https://dl.eff.org/certbot-auto
sudo mv certbot-auto /usr/local/bin/certbot-auto
sudo chown root /usr/local/bin/certbot-auto
sudo chmod 0755 /usr/local/bin/certbot-auto
/usr/local/bin/certbot-auto --help

(as per instructions from https://certbot.eff.org/docs/install.html#certbot-auto)

That ain’t all though. This worked fine on my main server, but the secondary server threw an error:

/usr/local/bin/certbot-auto --help
Requesting to rerun /usr/local/bin/certbot-auto with root privileges...
Creating virtual environment...
Traceback (most recent call last):
  File "<stdin>", line 27, in <module>
  File "<stdin>", line 19, in create_venv
  File "/usr/lib/python2.7/subprocess.py", line 185, in check_call
    retcode = call(*popenargs, **kwargs)
  File "/usr/lib/python2.7/subprocess.py", line 172, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.7/subprocess.py", line 394, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1047, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

Turns out, that “no such file or directory” came from the fact I’d never used virtual environments on the secondary server.

Quickly fixed by installing the package:

sudo apt install virtualenv

I’m informed that on RedHat-based systems, you need the python3-virtualenv package, but that didn’t do anything for me.

And then, to maintain compatibility with calls for the old certbot and letsencrypt commands:

cd /usr/bin/
sudo ln -s /usr/local/bin/certbot-auto letsencrypt
sudo ln -s /usr/local/bin/certbot-auto certbot

Running certbot with the –version arg should then show you a current version.

I’m surprised at how little support the deb based systems are getting from the certbot crew – I’ve been otherwise impressed with Let’sEncrypt’s work thus far.

SSH & HTTPS on the same port: Surprisingly easy

If you’re stuck behind a school or university firewall, you’ll often find that they’re unreasonably restrictive (as a user – as an administrator, well actually, most of the admins probably think it’s a bit over the top too, given it really doesn’t stop much untoward behaviour for the inconvenience caused).

As long as you want web traffic to sites that haven’t been blacklisted or have restricted keywords in the URL (sigh), you’ll be fine. But if, for example, you need SSH access to a *nix server offsite, you’re stuck using various web based SSH console solutions.

As always, there are a variety of ways around it: some more complex than others. But a good place to start is the fact that most corporate firewalls are not only unreasonably restrictive – they’re also lazy.

Port 443 is used for secure web traffic, and the firewall can’t really do much to inspect the back-and-forth through that port (you know, by design), so in many cases, they just let traffic through without even bothering to check that it’s actually HTTPS.

I mean, really. If someone is trying to get access through port 22, they can probably figure out how to achieve the same end through 443 (this post, case-in-point).

Enter the demultiplexers – software tools to simply listen on 443 and direct SSH traffic to sshd and HTTPS traffic to httpd (the two kinds of traffic are trivially and flawlessly distinguishable).

Continue Reading…

Stay Classy, Cert Companies

Let’s Encrypt has been a welcome addition to the security landscape – if only because it’s nice to do business with someone who actually gives a damn.

The trouble with HTTPS has always been more of a “business model” thing than a technical thing – anyone can set up strong encryption on their server and send/receive encrypted traffic to their users, but the initial connection needs to also confirm to the user that the site is who it says it is, and therein lies the rub.

The solution for the past 2 decades or so has been to have big corporations (called certificate authorities) who are trusted by browsers (the software, not the people) issue the certificates and keys needed for encryption. When a browser connects, it can identify whether or not one of the certificate authorities vouches for your website. If it does, the browser knows to trust that it is, indeed, connecting to the correct site.

This is a crucial step, as otherwise another site, posing as, say jonathan.ihle.in might manage to trick a browser into connecting to it. The connection itself would be perfectly encrypted, but the encryption would be for nought – as the user would be sending all their private data to the wrong party.

The problem with this arrangement is twofold – it forces site operators to decide whether or not a site is worth spending money to encrypt and it puts the issuing of certificates and keys into for-profit organisations who have varying demands for determining site identification. The end result: many sites remain without encryption.

Let’s Encrypt was created to resolve this specific issue. Continue Reading…

The backdoor in the iPhone *is* Apple

So recently, the FBI has obtained an order to have an iPhone compromised for an investigation.

The issue is thus:

  1. The iPhone is locked with a 4 digit passcode and the FBI doesn’t know what that passcode is.
  2. The iPhone’s data is encrypted – so they can’t just yank out the flash memory and attempt to read the contents. The passcode is required, through the operating system on the iPhone to decrypt that data.
  3. Because 4 digit codes aren’t really very secure (only 10,000 possible combinations), iOS will gradually force longer and longer delays between failed attempts to unlock the phone. (Edit: As Kieran points out below, codes in recent versions of iOS allow up to 6 digits, or 100,000 combinations)
  4. As an added layer of security, a user can set their iPhone to wipe its data after 10 consecutive failed attempts.

 

The FBI wants the data on that phone. But the process of brute forcing an unlock might wipe that data out and even if not, will still take a long time with the lockout delays and manual passcode entry. So a US federal magistrate has ordered Apple to do whatever is necessary to work around these safeguards so the FBI can access the data quickly and safely.

Apple is refusing.

They’re refusing on the grounds that (among other things) this will create a “backdoor” that will compromise all iPhones ever.

This is not true. iPhones are already all compromised. The backdoor is Apple. Continue Reading…

Your Security Policy Sucks

I’m talking to you, enterprisey organisation.

Your ITS people just got back from a seminar and they’re all fired up to enforce password changes every 3 months and allow your users to “take control of their accounts” by using “security questions” to reset passwords.

Well that’s dumb. Don’t do either of those things.

People are bad with passwords. They don’t understand security in general. Forcing them to change their mediocre passwords every 90 days instead of never is only going to exacerbate the problem.

Let’s take a look at my university’s policy:

crap_pw_policy

  • “A maximum of 16 characters” – Don’t do this. Don’t be this dumb. Once your password is salted and hashed, it doesn’t matter if it’s 16 characters or 216 characters. This isn’t 1988 and we’re not storing plain text passwords in a non 3NF database using COBOL. Stop putting low (very low) upper limits on password length.
  • “A minimum of 1 upper/lower/number/special” – great, you’ve just narrowed things down for the guy trying to brute force a password (not that that’s how people break in these days anyway). How many of your people are going to put more than the minima you just set in their 8-16 characters? A negligible few.
  • “The password can’t contain… spaces” – Don’t. Just… don’t. Do. This. Combined with the 16 character maximum above, this completely rules out using a passphrase (longer, easier to remember). There’s no backend reason to disallow spaces, which means you either have this rule because you heard it was the right thing to do (it’s not) or because you have a badly designed front end which breaks on spaces.
  • Challenge questions

 

“Challenge questions” or “security questions” or “secret questions” or “giving out personal details to everybody for no good reason” were a kludge invented for a bygone era and are no longer useful or necessary.

In fact, they’ve been badly implemented since their inception, and were worse than useless even 7 years ago.

You might have seen in the news lately that a number of celebrities have had their iCloud accounts broken into and private photos stolen and distributed.

Why did this happen?

Well yes, because some people are complete assholes. But how it happened, dollars to doughnuts, is that many of these celebrities used questions to which the answers are not difficult to divine. It’s not their fault – they’re not the experts. You, enterprisey organisation, are. And if your security policy is only good against people who don’t actually know you, then it sucks.

See also, this blog post from iiNet.

Your password should be a minimum of 9 characters

Why 9? Is this a “You don’t have to be able to outrun the bear, just the slowest person in your camp” situation?

No white space

One character is just as good as literally any other. The only vaguely plausible argument I’ve seen to justify this is that passphrases will often have lower entropy than passwords – since people write predictable sentences as much as predictable words and sentences usually consist of fewer components (words vs characters).
Except, people who use passphrases don’t make them up. They have them randomly generated.
They’re also rare, so not worth trying to tackle.

Why is it silly to ask your users to choose meaningless strings of characters, especially in light of the fact they’ll have to change the damn thing in 3 months anyway?

Because your users can’t remember them. Many of your users don’t log in every day or even every month – the next time they log in might be to change the damn thing because 90 days are up.

So they tack a 1 to the end of their last password. Or if you forbid minor modifications (which you shouldn’t even be able to check, by the way!), then they write them down. Or both. Which defeats the purpose of your security policy, or in many cases is worse than just letting them keep the same damn thing for 8 years.

What’s the solution?

Use proper two factor authentication (no, security questions are not 2FA – at best, they’re half factor authentication).

If you’re a company, issue dongles to your users. You can even re-sync them every 90 days if you like.

If you’re not, issue a key generation app for smart phones (or any phone that runs Java) or use an existing one.

Failing (or in addition to) that, you can SMS codes to your users’ phones. Even banks manage that much, and they’re basically the gold standard in doing this stuff badly.

You can also issue security certificates for your users to combine with their passwords. Issue a new one every 90 days or monthly or whatever makes you happy – it’s nothing new for them to remember, so they won’t care.

And fire the guy who does your ITS seminars.