300Mbs down, 50Mbs up – that’s pretty darn ludicrous

After nearly 6 months with Zen Internet, I’ve decided to upgrade to their fastest package – Ultimate Fibre 4 – which should give me a top speed of 300Mbs download and 50Mbs upload. And it only costs an extra £8 per month.

It ties me into a new 12-month contract, but I’ve been very happy with Zen’s performance over the past few months. And I’m still extremely happy with the Amplifi kit I purchased too – especially as I’ve seen some really decent Wi-Fi performance gains through firmware updates, and the latest firmware release gives me the ability to VPN back into my home network via the Teleport app.

As I work from home at least one day a week, it’ll get to the point where my home broadband will (vaguely) match that of the work connection – so using a VPN will ensure that any file transfers will remain fast.

I’ll report back when the connection goes live.

The past year has seen an influx of new smartphones flooding the market – all Android, and almost all of them touting at least three rear cameras.

The Huawei P30 Pro has perhaps shown the most promise – until the U.S. government came along and started their trade war with China – as well as the whole Huawei trustworthiness affair. This resulted in Google allegedly cutting Huawei’s access to Android updates at one point. Even with the recent thawing, it’s enough to have put me off considering Huawei smartphones.

I’ve used Google’s Pixel XL and Pixel 2 XL for a while, but even with a frequently updated OS, there have been substantial problems with the phone that have put me off going back to Android at all. I’ve read all the problems with the Pixel 3/3 XL and have been counting my chickens that I didn’t switch.

I am an iOS man, and I’m not likely to ever switch. Here are some statistics as to why that is the case:

  • 1,642 albums (15,648 songs) totalling 108.95Gb, or 37.5 days worth of music stored in Apple Music
  • 361 purchased iTunes films totalling 1.4Tb in total (if I were to download them all in HD), or 30 days worth of viewing back to back in one sitting
  • 38 purchased iTunes TV programmes totalling 947Gb in total (if I were to download them all in HD), or 24 days worth of viewing back to back in one sitting
  • 10,108 photos, 453 videos totalling around 97Gb (APFS) which are stored both on the Mac, iPad Pro and iPhone XS Max as well as the iCloud Photo Library

Switching between Apple Music and something like Spotify is possible with third party programs, but it’s a substantial pain-in-the-arse process and the music catalogues vary between the services which mean that I’d lose quite a few albums/tracks along the way. I know I’d definitely lose all the Studio Ghibli soundtracks if I were to switch to Spotify.

Moving my movies and TV shows to another service is near impossible unless I break the digital rights management of each title. This is illegal in the UK (even for the purposes of backup). The state of the streaming and physical disc union is a massive pile of poop at this point, but iTunes has almost always been the best experience. And the Apple TV 4K has been the best streamer. Newer TVs from the likes of Samsung and Sony are getting the Apple TV app, so content from iTunes is becoming more widely available across other devices. It’s still not ideal, but it’s something that consumers are having to live with if they want to rewatch their favourite films or TV shows.

I’ve also struggled with Android to try and replicate the sheer ease of use and simplicity of Apple’s Photos app. Google Photos has come very close, but it is substantially behind in some RAW camera formats (particularly earlier Sony RX100 models) and limitations in MP4 sizes has meant that I cannot upload my whole library to Google’s servers. I do use Google Photos to upload what I can, however, and my Google Nest Home Hub shows a series of photos from my travels – a bit like a digital photo frame – when I’m in the kitchen.

Then there is iOS itself. We get a major free version every year, and it’s generally very well supported for around 3-4 (and even in some cases 5) years during the lifetime of a device. And it’s regularly updated by Apple to fix major security flaws whenever they occur. When looking at my work’s policies for BOYD phones, we have had to pretty much rule out most Android phones because of the delay in which the device manufacturer roles out security updates. It’s really only Google’s Pixel phones that pass the grade and that kind of rules out the whole purpose of Android IMHO.

Finally, I have an Apple Watch (series 4) which still requires pairing with an iPhone for many functions. However, with the next release of WatchOS, the watch is going to start to gain a bit more independence from the phone. But it will still take a few more iterations before the Apple Watch is a truly standalone product.

So, this leads me to the iPhone 11. We should find out soon when Apple intends to announce this year’s new line-up. It’s not long to go – they usually announce them sometime in September. Rumours suggest that the current XS and XS Max line-up will be renamed “Pro”.

Rumours also suggest that there will be fairly modest upgrades this year, with the bulk of the good stuff coming in 2020. We’re unlikely to see 5G modems this year, and we’re likely to follow the trend of other smartphone manufacturers by having a third camera on the back of the phone – probably an ultra-wide lens.

My plan with EE should allow me to upgrade sometime at the end of September. Whether I will or not really depends on what Apple’s offering with the iPhone 11. I’d REALLY like to see is USB-C connectivity like the iPad Pro. Given the Macs, I work with all have USB-C ports, and I have multiple USB-C chargers, cutting down on Lightning connectors would be a real bonus. There are some sketchy rumours abound that the Pro range of iPhones will feature Apple Pencil support. Useful, but not essential to me (but I can imagine a trillion uses in my line of work).

As for cameras, I’ve been really happy with the iPhone XS Max. It is by far the best camera that Apple has rolled out in a phone. Some recent images that I took:

And I still have a significant amount of storage left for more films, TV shows, music and photos:

So I’d be perfectly happy to continue using the iPhone XS Max for another year if necessary. If I did upgrade, I’d still be on an upgrade anytime plan, but I’d effectively renew my contract for another 2 years – whereas next year I’d be free to leave EE if necessary. But so far I’ve had no reason whatsoever to do so – they’ve been brilliant.

And ditch insecure and weak TLS ciphers or risk attack

SSL, or TLS as it should be called these days, is THE de rigueur of modern web site hosting. Well, not so much de rigueur, but more of a necessity. It’s not just about security (encryption between your web browser and the webserver), but SEO (search engine optimisation) requires an SSL/TLS certificate as search engines such as Google are prioritising SSL/TLS protected sites above non-secure sites (see http://www.bafta.org, an example of a web site which could – and indeed should – be using an encryption connection throughout, but doesn’t).

And it’s not just all about encryption. With the HTTP/2 protocol – assuming your web server supports it – can provide a number of improvements that can significantly boost the performance of your site as well.

SSL/TLS certificates used to cost a fortune and were difficult to manage. Every year or so, you’d have to create a new certificate signing request (and private key, if necessary) and then submit the CSR to an SSL vendor. You’d then have to verify you own the domain either by placing a text file on your website, or an entry in DNS. And you’d be paying a pretty penny in the process. And that’s just to protect one URL (or, in the case of most SSL vendors – actually two – one for a subdomain (such as ‘www’), and the other for the bare domain (such as ‘drake.org.uk’). If you wanted to protect a whole bunch of subdomains, you could buy a wildcard SSL certificate. These are even more expensive (though the cheapest I found was $45 per year), but can be deployed across multiple servers and hostnames under the same domain.

Then came along Let’s Encrypt. It’s a free certificate authority that issues free single hostname and wildcard SSL certificates. It’s easily automated and requires very little effort. Wildcard SSL certificates are relatively new – and most people end up issuing single domain certificates through the “certbot” utility.

But it’s just as easy to get a wildcard cert which can be renewed automatically. Usually, like me, you’d run certbot with the –nginx command which sorts out your nginx configuration for you. But if you wanted a wildcard certificate instead, it requires a bit extra work:

certbot-auto certonly --manual --preferred-challenges=dns \
--email [email protected] \
--server https://acme-v02.api.letsencrypt.org/directory \
--agree-tos -d *.wombats-are-cool.com

You’ll then be prompted by certbot to add a DNS entry to your domain (in this example, wombats-are-cool.com) and then it’ll go off and verify it exists and issue the certificate. Keep your DNS TTL record for a quick resolution.

Once issued, you’d just alter your nginx server block with:

ssl_certificate /etc/letsencrypt/live/wombats-are-cool.com/fullchain.pem; # managed by Certbot

ssl_certificate_key /etc/letsencrypt/live/wombats-are-cool.com/privkey.pem; # managed by Certbot

Then shove the following in /etc/crontab:

0 0,12 * * * root python -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/local/bin/certbot-auto renew

(add > /dev/null 2>&1 to taste)

A free wildcard SSL certificate which will automatically renew itself. An alternative to Let’s Encrypt is to use a WAF or CDN such as Cloudflare or Sucuri – both will offer to install a certificate at the edge (e.g. their servers – all traffic will go through their datacentres before being passed to your origin server). This requires a bit more set-up, especially if you want to the WAF/CDN to connect over HTTPS to the origin server. There are a number of approaches to this – including, ironically, using Let’s Encrypt.

Now, don’t forget to disable SSLv3, TLS v1.0 and v1.1 and use strong ciphers. Don’t do what many web site owners do, and accept any old nonsense.

In the following example (from a well known UK multi-media facility), the highlighted protocols are terribly insecure and will fail you in any vulnerability scan, and a temptation for intruders and automated bots. TLS v1.1 isn’t worth keeping around – I’ve been looking at the stats of a very high volume e-commerce web site shows that barely anybody uses it. I’ve configured many web sites to use TLS v1.2 at a minimum and it has had absolutely no impact on browser compatibility.

PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
|
SSLv3:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: client
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
| CBC-mode cipher in SSLv3 (CVE-2014-3566)
|
TLSv1.0:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: client
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
|
TLSv1.1:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: client
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: client
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
|_ least strength: C

Or a more visual representation of the above:

Exposing the versions of your server’s web server, OpenSSL and PHP is also a Bad Thing(tm). Which of course, our poor saps absolutely do:

Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.6.30

Don’t do what these people do. Pay attention to your SSL/TLS settings as well as your certificate.

Meanwhile, I’m happy with this:

Apple is a strange company. It has come up with some rather lovely designs during its history. The Apple Magic Mouse 2 isn’t one of them. It’s a mish-mash of superb usability and horrible ergonomics combined with very decent battery life. I’ve been using them pretty much ever since I’ve had a Macintosh.

The Space Grey version of the Apple Magic Mouse 2 is very shiny!

I have been tempted by other Bluetooth mice before, and indeed earlier this year I bought a couple of Logitech MX Master 2S wireless mice. They’re ergonomic, chunky and feel great in the hand. My only complaint has been the scroll wheel has always felt either too loose in quiet mode, or when the ratchet mode is on, too noisy. Whereas the Apple Magic Mouse 2 has a surface area which acts like a touchpad which makes scrolling pretty much flawless. Plus the Apple mouse can scroll sideways much more easily.

The Logitech MX Master 2S – which can be used when charging

The MX Master 2S can also be charged whilst it’s being used, whereas with the Apple mouse you’ll need to turn it upside down in order to plug in the Lightning cable – thus it’s incapacitated whilst it is charging. This is made up, however, by a much better battery in the Magic Mouse. The Logitech MX Master 2S only seems to last 2 days before the battery runs out whereas the Magic Mouse lasts several weeks. Well, I’d say that my home MX Master 2S only lasts a couple of days – my work MX Master 2S does tend to last a couple of weeks, and both tend to get the same kind of use.

But I’ve had to go back to using a Magic Mouse 2 again because Apple do NOT make it easy if you ever need to reset your Mac’s PRAM, or go into recovery mode with non-standard Apple kit. The following image demonstrates:

Cables, dongles and non-Apple kit – oh my!

I wanted to reset my work 2018 Mac Mini’s PRAM as the USB-C (acting as a DisplayPort cable) to HDMI connected monitors tend to play Russian Roulette every time I switch the Mac on. Sometimes the Mac remembers the right order, and other days it doesn’t. Or sometimes the Mac doesn’t send the signal to the right monitor, necessitating cable fiddling. A PRAM reset might fix that, I thought.

First of all, the Magic Keyboard 2 wasn’t able to get the bloody Mac into PRAM reset mode wirelessly – not without physically attaching the keyboard to the machine via a Lightning to USB-A cable (thankfully the Mac Mini has two USB-A ports). That seemed to work. Then I needed to go into recovery mode to sort out something, but the MX Master 2S mouse wouldn’t work. As you can see above, the Mac’s firmware wanted me to connect an Apple wireless mouse. Any Bluetooth mouse that’s Bluetooth capable (and not an Apple mouse) and has been paired with the Mac beforehand will not work in recovery mode. I had to hook up the MX Master via a micro-USB cable to USB-A to get anything done.

So it’s a mix of battery life, being able to scroll properly on a Magic Mouse 2, and being able to move the mouse pointer effortlessly in Mac’s firmware/recovery mode that’s brought me back to the Magic Mouse.

In the I.T. world, the acronym “SSL” means “Secure Sockets Layer” which refers to a protocol that’s used to encrypt content between two endpoints (typically a web browser and a server).

Along comes Amazon Prime Video and this appears (along with many other warnings) relating to their superheroes-gone-bad series, The Boys (which is really rather good, though the critics aren’t as keen as regular folk):

As the Internet has progressed, we now tend to refer to SSL as TLS (“Transport Layer Security”). I reckon it’s only a matter of time before Amazon comes up with their own acronym to describe their content:

TLS – Tender Loving Sex