Skip to main content

Encrypt All The Things

I love to study new technology as it comes out, but today's blog post is about a very old technology finally being handled in an intelligent way.  Let's start with the old technology.

It's all https

Security on the internet is hard to explain, but in general it just--sucks.  The truth is that when you log into you bank's website, the data to handle that is (usually) encrypted.  That is to say that the data your'e sending to the bank is gibberish that the bank's servers know how to translate back into your username and password, among other things

Encryption is complicated, but the important thing to understand about all of this is that your computer has to know how to translate your username and password into gibberish, and the bank's computer has to know how to translate that gibberish back into your username and password.  For this to happen, those computers have to start by sharing the translator with each other, we call this the handshake.  Usually, it goes something like this (yes, with this many steps, Yay TCP!).

Your Computer - "Hey bank, I'd like to see your login page"
Bank Computer - "Sure thing, here it is"
Your Computer - "What is this gibberish?  Must be encrypted.  Hey bank, I'd like to see your encrypted login page."
Bank Computer - "Sure thing, here's the encrypted login page and translation instructions."

It's all a sham

SSL/TLS encryption is the fancy term to refer to this method of security today.  The problem is subtle--or more specifically, subtlety.  The problem is this:

You see, the only way to know if a website is secure today is for you, the user, to see that green little https lock icon.  There's no check to ensure that you don't accidentally log in on a page that looks like this:

The difference between the former and the latter from your perspective is whether or not you were paying close enough attention, which even many security experts fail to do.  The difference in terms of security, however, is everything.

Modern browsers don't manage this for you at all.  In fact, security experts got caught recently by a fake google site, and the only difference was the above text.  And of course, the other side can be true too. is not safe, but so is because users can bring you to sites with the wrong URL just as easily as one that isn't secure.

The problem is sharing

Programmers attempted to build security around https into browsers to let you know when a website was unsafe, but there's no way to know which websites should be using encryption and which shouldn't, so instead they chose to check if the encryption of the website did indeed come from that website--which they only do when there is any encryption at all in place.

This is where you get gigantic warning pages about websites:

The way they know that should be red and should be green is called a Certificate Authority, often called a CA.  Because the programmers who wrote your browser can't possibly know every website that should have https, they rely on the website to tell your computer, as in the above dialogue (handshake).  When you get back those translation instructions (called the certificate) from the website, the browser then goes to a CA it knows and trusts to see if that really is the correct instructions for that website, because if it's not, you're just encrypting the data to send it to someone who's pretending to be the website, which would defeat the purpose.

If the CA hasn't heard of the certificate, the browser gives the gigantic warning page above, which makes you feel very safe.  But remember, that if they don't even bother to encrypt the page, there's no warning at all, even if it's a page that's usually encrypted.  Because CAs are the only accepted authority on what sites should have what certificates, they have to be right, every time.  For this reason, and the costs associated with that, CAs have always charged a decent amount of money (hundreds of dollars per year on the low end) to grant your website a certificate that they will tell the browser is safe.

You can create your own certificates (translations) for your websites, called self-signed certificates, but your users will get this gigantic warning page every time they try to go to your site unless they do some manual configuration to accept the certificate on their computer.  This is why most websites don't even bother to encrypt.  It costs too much, and if you do it yourself, browsers actually make the experience worse for your users than if you didn't do anything at all.

Enter Let's Encrypt

The world of CAs is going a little nuts right now, as a newcomer to the market has decided to issue certificates for free, and completely automate the process.  What's unusual is that, the newcomer is actually being accepted by all major browsers.  This is incredible.  Now, people who make websites can encrypt them just for fun!  There's no longer any reason not to see that beautiful green https at the top of your browser.  It doesn't cost anything!

Now, I may not sound like it, but I'm usually quite skeptical of new technology.  I like to use it and study it, but I don't usually trust it in production until it's more tried and true.  Let's Encrypt still acts like new technology.  It's unwieldy and hard to use, but it works, and because I care about security it's worth it to me.  From the perspective of someone who doesn't like it when things are hard, however, here's a StackOverflow post I wrote about issues with setting it up.  It's not everything, but it has some links that should help you along the way.

What's great about Let's Encrypt being free is that everyone should be doing it now.  If you make websites, encrypt them.  I don't care if it's just a blog about baking cookies, or a picture page with no logins.  Encrypt it!  You see, since programmers never could figure out a good way to identify whether a website should have a certificate, we can create an internet for them where they don't have to.  If every legitimate website is encrypted, then they can tell the browsers to throw ugly scary warning pages when there is no encryption, and take that onus off of the user.

This means a lot to me, as a programmer who understands how important your personal information is.  The internet is dangerous, and this is one way that we can make it just a little bit safer.

Encrypt all the things!


Popular posts from this blog

Teams and Complexity

Let's pretend you're a car mechanic (I don't know, maybe you are).  But you don't work at some shop in town, you work at a bigtime auto-maker onsite at the factory.  You help build cars from scratch.  You work with a lot of other car mechanics, and various engineers of different levels.  If we were looking at the 1910s, you might be working for Henry Ford on one of the first ever assembly lines.  Either way, you have a specific part of the car you're responsible for.  Your skills probably extend beyond that, and you might work on a different part of the car each day as your manager moves you around to keep the factory efficient.

One of your coworkers, Bob, is a superb engineer.  He is very good at building cars, far better than you, and he does it faster than everyone else.  Your boss really likes him.  You often get stuck after him in the assembly line, so you know exactly what sorts of things he does.  He's not sloppy, but he likes to do things his way.  He w…

Managing Programmers

Working with other programmers is tricky.  That said, it's nothing compared to the job of managing programmers.  One of my favorite quotes about Perl is that (paraphrased) "a Perl developer is like a rockstar.  Now imaging having a bunch of rockstars in one room together and you will understand why you don't want an entire team of Perl developers."  It's not about Perl here though. What's important to understand is that any developer worth his salt is going to be like a rockstar.  And yes, there are a lot of professional developers out there who aren't worth their salt, but that's for another post another day.  Rockstar may not be the right term here, but think of it this way.  These guys are smart.  They may not be geniuses, but there's going to be things that they know that you don't and probably never will.

I've seen it more than once and it's not going to make some Product Managers happy, but I'm going to state a fact, an eleph…

How to identify a skilled programmer during an interview

How does one identify a skilled programmer?  No company that has interviewed me could tell the difference between myself and other programmers they'd interview.  The interview process is truly a game of luck in this industry--on both sides.  Both the programmer and the company are basing their actions entirely on luck.

Companies have come up with numerous methods to attempt to discern a good programmer from a bad one.  The best tricks they have include a series of math problems, algorithms, problem solving technique tests, and even obscure programming questions, some without definitive answers.  As an example: Is there an authoritative source of information on the core principles that define object oriented programming?  I've heard everywhere from 3 to 7.  In a field of research about a synthetic concept, an authoritative answer is almost impossible to obtain.

Programmers were then forced to study to the interview.  Careercup is one of my favorite sites for this.  This almost …