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.
So in my previous blog post I said I was going to try and build a web app to find someone’s location using their smartphone’s location services. The first step in this is choosing a language and/or framework to build it in. I’ve decided to use Go, which a former collegue of mine tells me makes me a hipster.
So I have been hearing lately about What3Words and how the emergency services in the UK are using it to locate people. This, and other information I have read about recently has got me thinking. What3Words is a proprietary service, that the emergency services will be paying to use. Now a number of mountain rescue teams in the UK use a service developed by one of their volunteers called SARLOC which appears to have a similar set of requirements, but from what I have read appears much more useful for the mountain rescue teams that use it. Now what I have been thinking, these services both rely on the person that needs to be located to have a smartphone, with location services, and an internet connection. They both require the person to receive a link, and allow the opened web page to see their location. So with these assumptions, how hard is it to build a service that allows an operator to send a personalised link to someone, have that use the smartphone’s location services to get a current location for the user, and share that automatically with the operator?