The guys at ISPConfig do good work – although it can sometimes get in the way of my own server configuration, the vast majority of the time it saves a huge amount of effort on what would otherwise be mundane and routine tasks.
With FOSS solutions like this though, “must-have” features don’t always come quickly – CPanel implemented Let’s Encrypt functionality very early on, but ISPConfig users had to wait 6 months (which is pretty fast considering the circumstances).
I needed a solution immediately though, which is why I rolled this (reasonably awful) automation to integrate.
The solution has worked well enough for the past 12 months or so (although implementation on slave servers wasn’t easy or pretty), but I figured it was time to upgrade to ISPConfig 3.1 – with built-in Let’s Encrypt support.
It’s almost always best to stick with the native solution rather than a third party one (particularly when the third party one is developed by a time-poor hacker), and that rule largely applies here. Continue Reading…
I never learned to code with Python; my first forays into development were with batch files (I kid you not) and then Visual Basic (which taught me many things I spent years unlearning).
Python is, in many respects, a great language for learners (which I’m not going to discuss today).
There is however, a great deal of… less than intuitive show-off code that can be, nay is encouraged to be, written using the language. Solutions are deemed to be “Pythonic”, a term as nebulous as “elegant” and often resulting in code just as unreadable to the casual observer or Python learner.
In some respects, this is about reducing the number of lines written – something fraught with peril for someone new to coding.
But there is a seductive element to Pythonic solutions – they don’t require you to twist yourself up in lines of boilerplate just to overcome a (often commonly encountered) problem.
The “with” keyword is not especially unique to Python, but is actively encouraged, and with good reason. This is one case where fewer lines is definitely better. Continue Reading…
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…
Age groups used: Year 10s (~15 years)
I’ve been using the most excellent CS Unplugged activities for some of my classes this year – they are predominantly targeted to primary school classes, but they adapt very well to my high school students (either we roll through the activities faster or at a higher level).
It is now nearly two decades since the CS Unplugged activities were published and I think it’s important to note that they are still generally extremely relevant and useful to modern curriculum. Technology is used, implemented and reimagined all the time – but the underlying principles (generally) remain the same.
As a relatively fresh high school teacher, learning how best to position, prime and implement these activities has been a challenge this year – I’d like to reflect and report on how some of these have played out. Continue Reading…
A Very Sensible policy, enforced by default in Exchange Server is to ignore rules automatically forwarding mail to external domains.
It’s fairly easy to see why this is, in fact, Very Sensible:
Your organisation assigned email addresses to people who have agreed to be bound by its policies (right?) – allowing auto-forwarding to any address outside that domain risks you being responsible for a breach of confidence.
I’m all for having the “secure” option be the default and for discouraging or preventing users from breaking that security in the name of convenience.
But there are times when other, less sensible policies are in place that I feel the users should have recourse to implement workarounds. One such policy might be (for example), having an email quota set to (purely hypothetically), 100MB.
This is ample space for email in 1997. This is hilariously limited space in 2016. Continue Reading…
Just a quick one:
I’ve had issues with Google Now’s reminders since I first owned a Nexus 4 (a few years back) and the issue persists with my Nexus 5X. The trouble is in having reminders trigger at a particular location, rather than a particular time.
For example, if I know I need to pick something up next time I visit my in-laws, but don’t know when I’ll next be at their house, I can set a reminder and select “place” instead of time. In theory, entering their address is all that is needed to make it work.
This image was stolen wholesale from this article: http://www.makeuseof.com/tag/8-amazing-life-improving-uses-google-now-reminders/
In practice… nothing. Just… nothing. Continue Reading…
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…
As of this month (May, 2016), Copy is no more.
(I’m sure one day soon that link will be a dead end or be sold to someone not relevant)
Copy was a cloud storage service much like Dropbox or Google Drive – you had an amount of storage space to fill up with your junk, a web interface to access it, some local applications for your computers and mobile devices and it handled syncronisation.
Sticker from Chris Watterston – click the image to visit his store thingy
Lately, new sites I’ve created using my ISPConfig automation and letsencrypt.sh have been received inconsistently on various browsers – the issue appears to be particularly prevalent on OSX.
Doing some digging revealed a possible incomplete chain issue to be the cause.
Sure enough, modifying my Apache conf to incorporate a direct link to the intermediate chain fixed the issue.
My LE-ISPConfig Apache conf now looks like this:
Alias "/.well-known/acme-challenge/" /var/le-ispconfig/
Require all granted
Header set Content-Type "text/plain"
That little line at the bottom was what made the difference; chain.pem (a symlink to my primary domain’s intermediate cert chain) will be updated as and when keys and site certs are updated via cron. Continue Reading…
So recently, the FBI has obtained an order to have an iPhone compromised for an investigation.
The issue is thus:
- The iPhone is locked with a 4 digit passcode and the FBI doesn’t know what that passcode is.
- 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.
- 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)
- 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…