Debian have released the next stable version code named “BookWorm”, and so it is time to look at upgrading some of my servers. Now I have form here for things going smoothly. So I started with the server that I use to host a nextcloud instance. I mean what’s the worst that could happen? I’ve only set that server to hold my contacts, my calendar, to sync important files, to automatically backup any photos I take with my phone. It’s not like there is anything important I couldn’t afford to lose.
I’m a Linux systems administrator. This means I am not as skilled at supporting and maintaining windows based systems as I am Linux systems. As such my personal laptop has Debian installed, and I have a number of Debian servers (some hosted at a VPS provider, some at home). I also have a Desktop that I built myself, using high spec components (at the time). As the desktop was intended to be used for gaming I bought a Windows license for it. At the time the intent was to install Debian, and then create a KVM virtual machine to run Windows in. However out of impatience, laziness, and hubris (I could always fix it later right?) I installed windows directly onto the system drive. And now the hinge on my laptop lid is broken. As my blog is split across two git repositories (one private, and one public) and publishing new posts involves a workflow that requires me to use a number of linux based systems this is a sub-optimal state of affairs.
I always intended to give the app an open-source license. Now that it’s in a state that I feel is functional I asked my employer who sponsored about 10% of the code if they would allow me to apply an open source license, and as the code is unrelated to my job, or their core business, they said yes. So I’ve applied an MIT license. The code is available here.
Since my last post about the location sharing app I was building I stopped working on it. But I came back to it this week to get it working with Azure AD, the protocol is OpenID Connect, and Microsoft’s documentation is very good. I had already got LDAP authentication working, but I didn’t deploy that version of the app as I didn’t want to have to install an LDAP service on a web facing server. But as I don’t have to support Azure AD I could deploy the version with that working, but before I could I do that I needed to allow for disabling LDAP authentication. So having sorted that out I have deployed the current version, with LDAP authentication disabled. It’s also configured to only allow consumer Microsoft accounts to authenticate against it, because this is a demo, not a commercial service. It is once again available at https://location.craig-james-stewart.co.uk/.
It’s been a couple of months since I posted anything, and honestly that’s more down to me being lazy and having nothing worth posting to talk about. But Qualys have updated their SSL Labs to make the use of TLS 1.1 and TLS 1.0 cap the score to a B. This has lead me to once again look at the TLS settings for the various servers that I run. Apache HTTPD is the easiest of server applications that I run to update for this so that’s where I decided to start. Rather than just updating to TLS version 1.2 only it would be nice to use TLS 1.3 as well. However I was mostly running Debian Stretch and out of the box the version of Apache HTTPD included in this release doesn’t support TLS 1.3. Fortunately for me Debian Buster has been out a while, and I have always found Debian upgrades to go smoothly so I decided to run a dist-upgrade, and update the TLS settings on Apache HTTPD.
It’s been a while, and honestly I haven’t really done much work on this since my last post. I’d like to claim I’ve had too much on, but honestly I just haven’t had the motivation. My employer does “Learning and Development” days, and my manager allowed me to work on my location app as part of this. So the progress since my last blog post is thanks to this.
So in my last post I mentioned random numbers, and talked about needing to trade off between security, speed, and the randomness of the source of random numbers. I stand by the considerations that need to be made, but it was brought to my attention that I was looking at math/rand in go where they also have crypto/rand which makes using /dev/urandom much simpler. The trade offs are the same in practice, but the work was much easier to implement that way, so thank you Liam
I'd try crypto/rand. There seems to be a debate about having to create the seed for math/rand but apparently that's not something they are planning on fixing as it's not meant for true randomness.— liam sorsby (@liamsorsby) September 2, 2019
I have nothing to show on the location app I’ve been building, but I’ve hit a hurdle that I felt warrants some discussion. I want to use two random strings that are unrelated to each other in order to make the app more secure. An ID for each location shared, and a key to prevent someone simply trying to enumerate all the ID’s. Because the key is a security device it is important that it is not derived from the ID, or from the same deterministic source as the ID. With this in mind I have been reading about the random number generator available in Go.
So I have been making improvements to the location app I blogged about recently. The first cut of the app wasn’t really all that much of an achievement as I could have done the same with a file and a webserver, without needing an app written in go. Now in my last blog post I stated that I would build an API, and I have done so. I have also moved the default page, and created a new one. If you choose to look at the code you will notice a function for checking an id and key (which are both currently hard coded to “test”) this is to allow multiple locations to be shared (via a randomly generated ID) and also make it harder to enumerate the location ID’s that the system knows about by pairing that with a randomly generated key. The creation of these ID’s and keys is going to be what I work on next, as well as some optimisations to the code.
I have a basic app, as per my last blog post. Now I need to host it somewhere. I have changed the app to only listen on local host, I have iptables on my servers to hopefully prevent me exposing ports I don’t want to expose, but better to not push my luck. I’m using a server running apache and using systemd as the init system. So for SSL termination we’ll use apache as the revers proxy. For this we need a vhost with mod_proxy enabled and the following config in a vhost
ProxyPass / http://localhost:8080/ ProxyPassReverse / http://localhost:8080/
We then need to create a user to run the app, we want an unprivileged user
sudo adduser --system\ --shell /bin/false\ --gecos 'Location Finder App'\ --group\ --disabled-password\ --home /opt/location location
With that we need to create a systemd system file (I’ve added an example systemd file to the app repo) and to move a built copy of the binary onto the system, along with the HTML template file. And that is what I have done.