My Blog - page 2

In my last post I said I wanted to add solar power to my shed. Well I made a start on that. This post is about what I’ve done so far.

So my wife wanted a new shed (for good reason, the old one was literally falling apart), and I wanted a new project, one that was less computer related. So I ordered a prefabricated shed from B&Q. That was back at the tail end of March. Well that shed arrived about a week ago. And we now have a shed. I have plans for this shed, I intend to set it up with lighting, and power, but without the need to connect it to my domestic electricity supply, it’s at the bottom of the garden after all, and a mains cable running the length of the garden is dangerous. So I intend to build a small off grid solar power system for the shed. But that is for another time, this post is about building the shed.

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/.

So, I’ve been thinking about the nature of “truth” recently, and that led to me thinking about the scientific method, and how it enables to learn more about what the truth is. And that got me thinking about what science is in a more general sense. This led me to the conclusion that for most people modern science has more in common with religion than the scientific method. Now I’m aware that some would argue the scientific method means that science isn’t a religion, but actually that just makes it a bad religion. Now science as a religion isn’t an original idea, but I’m going to go through my thinking on this anyway.

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.