Series: My website is down. Now what?

Panic button imageThis is a multi-part series about how to keep your cool when your website is down and be part of the solution instead of a seething mass of non-helpfulness.

This tutorial assumes the reader has some basic knowledge of how websites function as I believe it is unforgivable to be wholly and wilfully ignorant of the workings of things we buy. However, I maintain a quick primer here on the various moving parts of websites and their ecosystem should you need a quick refresher.

  1. Part 1: Overview
  2. Part 2: DNS Issues
  3. Part 3: Routing
  4. Part 4: Layers (firewalls, etc.)
  5. Part 5: SSL/TLS and HTTPS problems.

The problem with the Internet of Things is the things

CCTV on a wallThe “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.

My website is down. Now what? Part 5 – SSL/HTTPS Issues

This is part of a series on diagnosing your website outage issues. This is part five; links to the other parts are here.

In Part 1 of this series we covered the overview of what could have broken to cause your website to go down. In Part 2, we started working through those possible issues by diagnosing DNS issues. In Part 3 we diagnosed routing issues. In Part 4 we looked at how to diagnose problems with any architectural layers such as firewalls. Now that we know all that is good, we need to look at what is going on with the web host itself. If your site runs over HTTPS, there are a myriad of issues that broken certificates or broken code can cause and that is the subject of this article.

This is not an article on what SSL is or how it works, but some basic terms and knowledge are necessary to understand the content of this article so I will lay them out.

Although secure web sessions are referred to as ‘SSL’ and certificates that provide this security are called ‘SSL Certificates’ the more correct term is TLS. The Transport Layer Security (TLS) standard replaced the Secure Sockets Layer (SSL) standard. But to avoid confusion I will use SSL since it is in more common use even though this guy will kill me.

SSL certificates are the mechanism by which secure Hyper Text Transport Protocol (HTTP) sessions are created. Those secure HTTP sessions are referred to as HTTPS (note the ‘S’ denoting Secure). Therefore, the proper way to think of this is that traffic between your website and your visitor is encrypted when they connect to your web server using https:// links and that encryption is implemented by means of the SSL certificate installed on your host.

Lastly before we jump in, it’s important to understand what SSL certificates actually do. They have two jobs:

  1. Encrypt the traffic between your website visitor and your website so that it cannot be read if it is intercepted by bad guys. Intercepting traffic is easier than you probably think but if the requests are encrypted, bad guy only gets a bunch of encrypted blobs.
  2. Provide non-repudiation to your browser meaning that it assures your browser that it is connecting to the website it asked for. Imagine if you told your browser to connect to your bank, but it connected to some other bad site and you entered your username and password into that bad site. SSL non-repudiation prevents that. I wrote an article on the others things SSL certificates do for the Sucuri blog here if you’d like more information on that.

So, knowing the two main jobs SSL does, what can go wrong on your SSL-enabled site? Here are some of the most common:

Continue reading “My website is down. Now what? Part 5 – SSL/HTTPS Issues”

My website is down. Now what? Part 4 – Layers

This is part of a series on diagnosing your website outage issues. This is part four; links to the other parts are here.

In Part 1 of this series we covered the overview of what could have broken to cause your website to go down. In Part 2, we started working through those possible issues by diagnosing DNS issues. In Part 3 we diagnosed routing issues. Now that we know your domain’s DNS is good, the routes are good, we’re going to start looking at any layers you may have in your architecture.

Image showing a turnstile inside a door but there is so much room around the turnstile that you can just walk through it without using it.The term “layers’ refers to things like firewalls or Content Distribution Networks (CDN) that may be present in your architecture. If you don’t use these things, you can skip to the next section which I will link to here when it is ready.

A typical website architecture looks like this:

website visitor -> web hosting server

There are no layers involved in this architecture. Your visitor simply hits your website directly. That works just fine and represents probably 80% of the use cases out there, but an increasing number of website owners are starting to employ firewalls and CDNs to secure and speed up their sites. If you employ a firewall such as The Mighty Sucuri CloudProxy, your architecture changes to look like this:

website visitor -> Sucuri CloudProxy -> web hosting server

If you harken back to Part 2 where we discussed routing, then you will recognize that this change in architecture introduces another point of failure for your website. How do you test those parts to ensure they are functioning? There are a few options.

Continue reading “My website is down. Now what? Part 4 – Layers”

My website is down. Now what? Part 3 – Routing

This is part of a series on diagnosing your website outage issues. This is part three; links to the other parts are here.

In Part 1 of this series we covered the overview of what could have broken to cause your website to go down. In Part 2, we started working through those possible issues by diagnosing DNS issues. Now that we know your domain’s DNS is good, we’re going to start looking at the routing. In other words, now that we know where your domain is (DNS), are there any roads to get there (routing)?

Many people misunderstand how the web works. I blame the media and well-meaning explainers for suggesting and continuing to propagate the notion that we “log on” or “visit” websites. The problem with these terms is that they naturally call to mind the concept of “going” to a website which is the exact opposite of how web surfing works. Instead of your browser being some sort of vehicle that goes to websites, it is a static piece of software that sits on your computer and issues demands for websites to come to it. Websites come to you, you do not go to them.

Internet routing imageWhen you click a link or type in a domain name, your browser issues a request across the Internet to that domain’s web server and says “give me that page”. Well behaved web hosts comply and the content your browser requested is downloaded to your computer and your web browser then renders it nicely so you can see and interact with it. In order for this to happen, there has to be a pathway on the Internet that can transfer your web browser’s request to the web server and transfer the response (content) from the web server back to your web browser. Those pathways are called routes and a big part of website troubleshooting involves diagnosing routing issues.

Continue reading “My website is down. Now what? Part 3 – Routing”