Opportunistic encryption is now turned on by default

As you probably (do not) know, today is a national holiday in Cyprus. How can we enjoy our holidays, when Mozilla came out with their newest version of their Firefox browser, version 37, yesterday? :-) At the time of writing, the updates are still rolling out, so if you are rushing to check if we are telling the truth or not, rest assured we are.

Why should you care:

This version of Firefox, enables client side support for opportunistic encryption. Among other things. We are specifically interested in that, since opportunistic encryption allows plain websites to enjoy a limited degree of security, enough for everyday people to enjoy their privacy. There's nothing you need to do, sit back, grab your drink of choice and read on.

How does it work?

The server responds with a specially stamped response to your browser, giving it instructions on how it can upgrade its connection to an encrypted connection to prevent eavesdropping.

Getting somewhere...

This process might sound familiar, but it's NOT how encrypted websites work. TLS (SSL) certificates have their details checked for validity, before your browser accepts them. This is NOT the case with opportunistic encryption. The browser simply sees the certificate, skipping the validation, but uses it as is. It can not tell if the certificate is valid or not, but the certificate can still be used for encryption.

Headache coming up...

You might start thinking that it sounds like a "too much fuzz, too little gain" scenario. Follow this scenario: You visit your favorite restaurant, sit down and eat the best food you ever had, and decide to write something about it on your blog. You power up your laptop, and proceed to login to your blog and start typing. Little did you know that the restaurant owner does a little "personal info" collection as a side job. Since your blog was not protected with a TLS certificate (not encrypted) the owner can perform a network sniffing session (copy the network's traffic for later analysis), hoovering up your password (trivial to do on unprotected networks, take our word for it). He then sells it on the black market. Since you were lazy, that password is also the password to your online banking. Not so far fetched as you might think. These incidents are daily occurrences in the IT industry.

Here's where opportunistic encryption comes in: When you visited your blog to log in, our server says "hey, wanna go over this on an encrypted channel? follow me". Your browser follows the server's directions, establishing an encrypted connection behind the scenes, then proceeding to use that as its primary connection to your blog. The owner sniffing the network (get rid of that mental image,"sniffing the network" is a technical term) now has a copy full of gibberish (scrambled traffic), and your password is not visible. Can stop trivial sniffing attacks, since they are (mostly) passive in nature: they get a copy of the data, and don't interfere in any way with the actual connection. If all they get is scrambled text, they have nothing of value.

Sounds great! Can I stop paying the €15/year for a TLS certificate now?

Nope. We still want your money muahahahaha....no really: remember when we said above that opportunistic encryption does not validate the certificate? (if not, you probably fell asleep). If it cannot validate the certificate, an attacker can perform an attack known as MiTM (Man in The Middle). Stop running, get back here. Simple explanation: The attacker convinces your computer that the blog you want to visit is on his computer, and he then forwards your connection to the actual destination, and vice versa. Hence "in the middle". He can then see inside the connection, if the connection is not encrypted. He can do more than that. He can interfere with the traffic, injecting malicious traffic to your computer, while you happily think your are visiting your blog. A properly validated certificate protects against this kind of attack. An improperly validated certificate (as is the case with opportunistic encryption) does NOT protect against this particular kind of attack. You can imagine that for an eshop (for example), this kind of protection is not adequate. The attacker would otherwise interfere with the regular traffic as well, since there is no protection mechanism there.

Where does that leave us?

A couple days ago, there was the usual FUD (fear-uncertainty-doubt) spread by the usual people (in this case the head of a large law enforcement agency, that shall go unnamed), that enabling encryption by default will "ZOMG!!!oneeleven!! think-of-the-children/cyber/terrorism (not necessarily in that order)" (if you didn't get the reference, don't worry ;-)) and will hurt "them" in their "pursue of justice", so encryption should have built in backdoors (side attack channels). What's next? Removing the locks from our doors? What happened to the good old "get a warrant" days? The traffic is unencrypted on the server, since it needs to see it to actually understand it and process it. No need to put backdoors in encryption protocols, which WILL be misused in the future (see past couple of decades). When a door has a lock, nobody stops a random stranger from picklocking it. The mentality of "I own the key to that lock, therefore only I can access it" is just plain wrong and needs to stop.

deZillium strongly believes in everyone's right to privacy: This is why we are currently rolling out server side support for opportunistic encryption, and it will be enabled by default on all "normal" websites we host, effective immediately. Don't like it? Sue us. Opportunistic encryption provides the next step up in privacy of your otherwise wide open online habits, and should be enabled by all.