Menu
Index

Contact
Atom Feed
Comments Atom Feed

Similar Articles

2013-06-23 18:30
Linux Mint 13 Maya (also Ubuntu Precise 12.04) Migration to LUKS+LVM

Recent Articles

2019-07-28 16:35
git http with Nginx via Flask wsgi application (git4nginx)
2018-05-15 16:48
Raspberry Pi Camera, IR Lights and more
2017-04-23 14:21
Raspberry Pi SD Card Test
2017-04-07 10:54
DNS Firewall (blackhole malicious, like Pi-hole) with bind9
2017-03-28 13:07
Kubernetes to learn Part 4

Glen Pitt-Pladdy :: Blog

Going SSL

This site has just been switched to SSL. These are some thoughts and experiences with doing this.

Why?

Other Content

While the public see this site, there's a lot more served up by my webserver like webmail/calendar, site statistics, MythTV, Blog editing, and much more.

Until now these have all been served up on an SSL site so I can safely access them remotely, but the question I had to ask myself was why a separate site?

Since the SSL site already exists and is public, why not just consolidate everything onto one site? That's been a lot of my motivation here - it's much less time consuming when everything is in one place.

User Safety

Among the content on this site is executable code that will be executed with the highest privilege on servers containing sensitive data (eg. monitoring scripts). Taking executable code from anywhere is a risk, but a random, unverified site on the web is asking for trouble.

By using SSL users can have a high level of confidence that what they download actually came from me and was not tampered with. Essentially - the level of trust is much higher.

Encrypt (or secure) everything philosophy

Nearly 20 years ago I came across this concept. Much of the security we put in place relies on a simple economic concept: making the resources required to overcome the security mechanism far beyond any gains possible and better yet if you can make it far beyond any practical means available.

We (should) use "complex" passwords which computationally expensive dictionary attacks would take excessively long times to find, and the computational power required to do a key search on any decent cryptography should be way beyond anything viable. By salting password hashes it ensures that even with the hash the computational time is maximized. That's the same concept.

While "security though obscurity" isn't actually security at all, information that allows an attacker to narrow down the options does weaken security. For example, it's common to enforce certain password strength rules, but, if you know how many characters are in a password, how many of them are numbers, letters and punctuation, the number of possible combinations collapses and may well come into scope of a brute force attack, especially when human nature is taken into account. The effective approach is to require a high entropy (low predictability) password not a (predictable) pattern.

The same applies with encryption. If you create a pattern (eg. by only encrypting sensitive data), you effectively tell attackers what to focus their efforts on. By encrypting everything you flood attackers with noise. Behind encryption the data is not know until it can be decrypted, and it's an awful lot of work going through all the mundane stuff like photos of your cat etc. to find the tiny bit of information that would be of use to someone with malicious intent.

At the same time, we often don't know what is useful information to an attacker beforehand. It may well be that knowing something seemingly mundane might be useful to trick someone into trusting for a social engineering attack. This is how a lot of identity fraud and other scams work. And before anyone chirps up that they won't fall for it - it's not falling for it yourself you need to worry about: the more serious social engineering attacks rely on multiple people which is why they are so effective since people tend to trust those they already know around them without knowing the full picture.

I often hear the argument "I don't have anything to hide"... well actually everyone has stuff to hide from fraudsters and other people who use it for malicious intentions, and if you "hide" everything it makes their lives so much harder.

Encrypting everything is easier than being selective, minimizes risks human error leaving data vulnerable, and helpful to make anyone with malicious intent have to work as hard as possible.

I've also just had an SSD totally fail so I can't erase it - technically almost everything is probably still in the flash, but the controller has it's self in a twist and won't let me access anything. If I had encrypted it from the start then not being able to erase it would be no problem.

Costs

There is a misconception that SSL is something exotic that only massive corporations and governments can afford. While 10 years ago costs may have been discouraging for individuals and small companies to deploy SSL, many domain registrars now have deals to get entry level SSL certificates for beer money.

It's become more a case of not being able to afford not to take advantage of.

Technical Barriers

Deploying SSL is actually rather easy. With Apache it's something in the region of 6 lines of config depending your exact setup, and half of those are just telling it were the key and certificate files are located. Other than that it's one command with openssl to generate a CSR and you are ready to let the Certificate Authority do their job.

IIS pretty much steps you through a wizard and does most the config for you behind the scenes.

It's really quite simple.

What is more difficult is securing a system, and that applies SSL or not. Many systems are configured in a very poor, inconsistent and sloppy way. This simply means that there are often vulnerabilities outside of SSL which may prove to undermine any benefits.

It's always worth doing your homework and fully understanding the system, how things work in detail and ensuring a tidy and consistent configuration that's easy to review and manage.

Making the switch

Google recommends setting up a Permanent Redirect (HTTP 301) and that's what I've done. Anything hitting the non-ssl site gets redirected to the same path on the SSL site.

It's trivial, and it makes sure that everyone finds their way to the right place on the new address.

Experience so far

One interesting effect is that it appears to have clobbered many malicious crawlers. Referrer spammers are notably not managing to get onto the SSL site. This will probably change in long term since it's trivial to use an HTTP agent library that supports SSL rather than one that doesn't (I'm guessing that's why this is happening), but for now it's an unexpected bonus.

Legitimate bots (Google, MSN, Yandex etc.) seem to be visiting the site, happy as usual.

Otherwise all other traffic is happily just working with redirects from the non-SSL site to the matching SSL URL.

Traffic is marginally down so far, but not significantly enough to be outside normal month-to-month variability. This may just be from the removal of fake traffic that can't do SSL.