Garten Eden

#linux #programming #android #online #stuff

Why not to use TLS?

TLS, formerly known as SSL, really isn’t new (SSL since 1994; the current version of TLS 1.2 was introduced back in 2008 and is now supported by all up-to-date browsers). Nevertheless, many websites are not encrypted on their way to the visitors. Why is that?

A plea for more encryption on the web — Yes, I am talking to you, Admin!

Pros

Let us start with the advantages why one should enable encrypted connections. The short but profound answer is: Edward Snowden. You do not have to be paranoid in order to understand that everyone with more or less talent and/or effort can read all kind of communication. Some may say that the NSA can handle encrypted connections, as well. True, but we can increase NSA’s effort/costs exponentially as soon as more cryptography is used on the web and we can even suppress capturing altogether for non-NSA-like people. Setup properly, TLS is specified secure.

But wait: CPU/Memory-intensive!

Things that are bad for servers are also bad for their visitors. Anyone who encrypts mails or data knows that encryption put load on CPUs and increases loading time. But is this also the case for web servers? Where are we stand today concerning optimizations in this field? If you ask Google, Facebook and other big players, one may reckon that, after activating TLS with its various optimization technologies, an increase of max. 1% CPU load, +10 KB memory per connection and +2% overhead are quite realistic. For example, one of the parameters we have to address is the possibility to decrease the calculation need for recurrent visitors. This, along other technologies, leads to an enormous win for the TLS connection negotiation.
Let’s state: Wrong.

But wait: It’s a lot slower!

Again: wrong. At least mostly. True is, that a handshake has to take place between the communication partners which leads to an agreement upon the used cipher and a challenge etc. In the best case you have to figure one roundtrip (one package to the server, one back) for that. But what is the best case? Server and client both have to support the technologies, namely and most importantly TLS sessions, TLS False Start, OCSP stapling, forward secrecy and SPDY.
Talking about clients, there is no cause for concern as all up-to-date browsers—yes, mobile ones, too—do support these. On the server side many do so, as well, e.g. your Apache, nginx and even IIS (mostly). They are waiting being activated.

But wait: That’s work!

Also known as I’m lazy. Well, maybe I wouldn’t cheer either if I had to tinker with my running configuration. But isn’t it worth the work? Think of the myriads of tutorials for all kind of servers. Twelve simple lines in my nginx SSL file suffice.

But wait: Certificate? Costs?

Not a penny. One word: StartSSL. And seems like Mozilla & Co. are moving towards such, too.
What is the plan?! sudo apt-get install lets-encrypt && lets-encrypt example.com? Absolutely great. I’ll keep track on that.
Worth mentioning is also that all major browsers do not alert on such certificates. And they are really free of charge, year in and year out.

There is no but!

The bottom line is that most caveats concerning secure connections are outdated and can be targeted rather simple.
In my opinion, being an administrator, a website owner or a blogger, we are in charge of such things due to the responsibility we have for our visitors.

Okay, let me consider that…

An excellent introduction is given by Ilya Grigorik, well known for researching on security and Internet performance at Google Inc., on his project site istlsfastyet.com. For more details about server compatibility I refer to his presentation about this and similar topics. The linked video is a must-watch for everyone interested in networks. Plus, it is fascinating and light flare.

As you can see, there is almost no reason not to use encryption.
So, admin, do your homework.

Comments

Your comment:






So far...

...no comments

en

Wait a sec, loading...

Email (not published)

Homepage (optional)

Comment... (code tag allowed)