The problem with the Internet of Things is the things

1The “Internet of Things”, or IoT, refers to the ever expanding offerings of traditionally non-Internet connected things that can now be connected to the Internet. The array of things you can connect to your home wifi network is staggering and, to be honest, pretty dumb. Internet connected toasters, light bulbs and even hot tubs are all available to lurk on your home network and send god only knows what data about you to god only knows where.

Your home network should be a safe place where only trusted devices have access. Traditionally, this has meant your own computers, your own smartphones and perhaps a few other devices such as gaming consoles. The problem with attaching a new device to your trusted network is two-fold: does it make attacking my network easier and what is it doing with the data it collects?

The attack vectors

Any device attached to your network can see all the other devices and, potentially, have access to them. If you’re sharing your budget and medical documents with your wife’s computer that’s fine. But is it possible to really keep track of a large number of often innocuous Internet connected devices that you’ve introduced to your network over time?

Additionally, each device connected to your network that talks to the outside world introduces a new attack vector and heightens the vulnerability of your safe network to some degree. Most of us run anti-virus, ad-blockers, and possibly ever firewalls on our PCs to keep bad guys out, but what does that toaster come with? Does it have any security software installed to prevent itself from becoming the weakest link in your network?

IoT devices are built by device manufacturers. This may seem like a self-evident statement and perhaps it is, but the point is that light bulb people build light bulbs and hot tub people build hot tubs. Their area of expertise is in the thing, not in the Internet which means their ability to build and maintain the Internet part of their device is a secondary concern. Internet connected CCTV networks, printers, and even cars have been hacked over the Internet largely because manufacturers do not have the Internet mindset that is born and flourishes under a healthy paranoia level 11.

Continue reading “The problem with the Internet of Things is the things”

Troubleshooting SSL certificates with openssl

Picture of an unlocked padlockA big chunk of the problems I tackle every day surround SSL connections. I’ve written a few articles on SSL that cover off its main tasks which are encryption and non-repudiation and some ways to determine if your SSL certificate is non-functioning. The tool I use 99% of the time to diagnose SSL problems is openssl so that is the topic of this post.

I am a Linux guy, if you’re using Windows you may find a binary here you can use.

An SSL connection needs two things: a private key which you likely won’t have for websites you don’t own and a public certificate which is necessarily available to the whole world. It’s the certificate we’re interested in and here’s how to get it:

This spits out a lot of info and you can pipe the output into openssl again to extract specific data like the valid date range:

Or the name the certificate is made out for:

Or both!

Most of your SSL problems will fall into two categories: the subject name of the certificate does not match the domain name or the certificate is expired.

Note in my output above that it looks like I asked for the certificate for slumpedoverkeyboarddead.com but I ended up with the certificate for .sucuri.net. This is kind of misleading. I didn’t *ask for the slumpedoverkeyboarddead.com certificate, rather I told openssl to connect to slumpedoverkeyboarddead.com. It did and since I did not supply a domain name, the server responded with its default certificate. This will happen on any server that is configured to serve more than one domain which includes things like my firewall or any shared hosting server. To get a specific certificate you must supply the servername directive:

If your domain name does not resolve directly to your web host as is the case with slumpedoverkeyboarddead.com, you can specify the real hosting IP address in the connect directive to get the certificate from that host, instead of the intermediate proxy or firewall:

Note that I have used the same IP address that slumpedoverkeyboarddead.com resolves to instead of my real hosting IP because I don’t want to divulge that. But, it works the same way.

This is usually enough to diagnose SSL connection issue and resolving them should be obvious. Either renew it if the certificate is expired, or replace it with a valid certificate if the domain name does not match.