The Road to HTTPS
While I have considered the use of HTTPS in the past and even got close to implementing it, there were a few problems which stopped me from doing so. The first reason was simply because everything worked just fine – why make a change that might risk breaking something? After all, most of the articles are reference in nature and users aren’t signing up for accounts and handing over gobs of personal information – it is a personal hobby site after all. The only real benefit of HTTPS would be to protect against “injections” man-in-the-middle style by evil ISPs.
The first real push came once Google started to down-rank HTTP websites over HTTPS counterparts. This gave me some impetus to upgrade, as I’d still want the site to remain visible for those who might need the information. At the time, I explored my options, which included buying a certificate from my hosting company but the cost was rather unreasonable for such a hobby site that’s being hosted as cheaply as possible. I did explore a no-cost option, namely that of Lets Encrypt, but the downside was the frequent certificate expiry which requires an automated renewal process to be run. This was something that didn’t look reliable or achievable from my shared hosting, so I had to abandon this.
Another push came when Google Chrome decided that it would begin marking HTTP websites as “not secure”. While ideologically, I don’t agree with this marking, it could needlessly scare away visitors who don’t understand exactly what it meant. I decided that I might need to go SSL sooner or later, so I tried to implement CloudFlare Flexible SSL.
While CloudFlare Flexible SSL isn’t as secure as a full SSL solution, it’s still a much easier option to deploy without having the cost of getting a dedicated HTTPS certificate or moving away from shared hosting. It still provides encryption and secures the link between the CloudFlare CDNs to the end user, which should provide man-in-the-middle protection, at the cost of a potential slow-down of the website and increased CPU usage due to the need to decrypt the data. The other downside is that the site may become unreachable from older browsers which don’t support the SNI feature of the certificate, but I suppose this is an acceptable compromise for the benefits which include being able to locally cache content and use of HTTP/2 and Brotli Compression to speed up content delivery. At the moment, they are willing to serve sites for free, but I’m not sure how long it might last.
Unfortunately, the first few times I tried it, the site misbehaved. The main reason involved links that were hard-coded to HTTP resources resulting in mixed-content errors. While I could redefine my site URL to HTTPS, as my web host is not actually offering HTTPS, this would make it impossible to access my site if I ever removed CloudFlare from the chain. I also didn’t want to author and upload through CloudFlare either, so short of taking down the site for extended times for migration, I turned the option back off and scratched my head.
With this final push, I decided to give it another shot today – this time, determined to set it up right. Without a back-up staging area, I had to make my modifications to the live site (so sorry if things went a bit funny this morning). Ultimately, I had to update a number of script elements and set up a number of rewrite rules to make things work the way I wanted. The result of this was the reward of HTTPS with a green padlock icon:
I spent quite a bit of time tweaking earlier today, so hopefully everything is operating correctly. Inevitably, some things could break as a result of this change, so do let me know if you spot something strange, but hopefully we’ll be running HTTPS from now on so everyone can be happy.
But it did make me consider – while I do rely on ad revenue as a way to fund the web hosting, it might not be worth it given the cost to the privacy of the visitors. While I enjoy having some figures about viewership and devices, the fact that Google collects this information and might use it for broader tracking makes me think of whether it was worth continuing to run these services. As much as I had trusted Google in the past, it seems that they are increasingly showing their evil side. As a result, there is a distinct possibility that I may distance myself from their services in the future.
For those who are concerned, I completely understand and I have no objection to your use of tracking/advertising blocking third-party add-ons or via Google Opt-Out.
Other (Random) Stuff
I couldn’t help myself – I just had to know what runs the TP-Link TL-SG1008 8-port Gigabit Switch …
… it’s a Realtek RTL8370N. At least my guess was accurate. This chip is actually capable of managed operation, but the unit isn’t configured to do so. The small EEPROM contains two-byte values stored in little-endian mode with a length value (12-bit) followed by register address and value. Based on the two efforts I found to hack these switches, it seems that it isn’t exactly a trivial operation. To run a full managed firmware will require a large Flash chip and changes to the strapping resistors to set the 8051 to enabled and run the code on the chip. To modify the operation without that, either you can modify the register address and value pairs on the EEPROM or you can use the SMI bus to change the configuration. The difficulty is that there are a bucketload of registers and the documentation of values and their functions are only vaguely described due to a lack of full datasheet (as that is under NDA). Just attempting to understand what the existing EEPROM’s code does was a bit surprising, as some registers were being repeatedly overwritten and a number of addresses used are not documented at all.
In the meantime, I’ve been building myself a few cables after my connectors from element14 arrived. Those who use barrel jacks will be familiar with the annoyance the two 5.5mm outer-diameter types have, as their centre pin can be either 2.1mm or 2.5mm. Connected the wrong way, either they will fit but make poor intermittent contact, or not fit at all. As a result, I built myself some adapter leads – 2.1mm to 2.5mm and 2.5mm to 2.1mm. Problem solved.
Another issue is that I have oodles and oodles of power-boards but I can never seem to get enough space to fit all my wall warts. But a lot of equipment doesn’t actually use the adapter to even 20% of its current rating! This even applies to things like Ethernet switches and passive PoE based equipment. I can understand the motivation – lower loading means less heat and longer lifetimes, as well as keeping only one model of power adapter in stock keeps costs low. However, lightly loaded switchmode supplies are vastly less efficient. As a result, there’s a lot that can be done to save on wall wart madness – one way is to buy a cheap open-frame power supply (I have a 5V/8A unit for $20) and build yourself the wires necessary to hook it up to the devices. Another is just to build simple “multi-way” adapters for the DC-side to break one connection into three – top version for 2.5mm pins and bottom for 2.1mm pins. Unfortunately, in-line barrel jacks are not that easily available, so I had to go for PCB mounted sockets instead with copious amounts of heatshrink.
So far, this has let me run two switches, two VoIP ATAs and several USB-powered devices (including two Raspberry Pis and the Fingbox) from a single 5V/8A open frame supply. Lots of plugs saved (replacing seven with just one) – especially when considering that warts sometimes can’t sit next to one another.
Another thing I thought I’d mention – in the past week, the site has had a few periods of unavailability. Unfortunately, it seems that people online don’t have much better to do than to subject my poor site to 40 to 100 requests per second for one to two hours at a time causing resource exhaustion. Despite a certain level of protection, there will always be a few that “get through” and might need some manual intervention to encourage them to move on. Sadly, there’s not much I can do about this, as if I buy more resources, that’s only going to be soaked up by these attacks and sit idle otherwise …
In the interim, I managed to finally work out what powers the TL-SG1008 and get myself thoroughly confused about what the EEPROM data is actually configuring. Unfortunately, it didn’t seem fruitful to modify it owing to a lack of documentation even though the chip is definitely capable.
I also managed to reduce my wall wart adapter hell by building a number of barrel-jack splitters and reduce my headaches by building an adapter to go between 2.5mm and 2.1mm plugs.
Hopefully, I’ll have some time to put some more content up soon :).