Sunday, 20 September 2015

to HTTPS or to HTTP?

I have to say that HTTPS makes sense in environment where there is a need to protect and HIDE the information inside the communications channel. Examples for this being banking or financial transactions as well as passwords.And even here I'll make a claim that I not utterly convinced beyond all doubt that HTTPS is the best option method to protect those data...

But does it make sense to encrypt EVERYTHING? like what https://letsencrypt.org/ is trying to achieve? (Okay, I'm all FOR the cheap/free SSL certificates, but... but ... it won't solve it all)

No it doesn't. Let me give you an example where encryption is not only a pain in the back, but counter productive: Package distribution.

Firstly I'm typically in situations where I need to reload/reinstall packages to test reliable recreation of systems. However, I'm also limited to costly internet connections, so I want to cache the packages, simply setup something like squid ro apt-cacher-ng, and I'm set.... except for those that does https:// <ARGH!!>

Let me explain, the first problem you'll hit is that apt-cacher-ng doesn't do the CONNECT statement for proxies, and why should it? it should cache the data, not bluntly allow a tunnel. I'm not even going to explain, but you'll see it in various ways and means, and I don't believe it's the right thing, as simply put it this way: I could still capture (ala cloudflare.com's SSL) your connection (since you are behind *my* firewall and proxy) and I could abuse some CA issues and then I'll be able to make you think you are connecting to the right place. But besides that, what are we actually hidding in that transaction? It boggles my mind, but let's continue.

The main concern with regards to package distribution, is the reliability of the package downloaded, and that that downloaded package haven't been tampered with. You know that this problem have been solved and used for the past 20 (twenty) odd years now? Simply sign the package with your GnuPG key, and distribute your public key, and then everybody can check that the file recieved, is the actual file that you've signed. This is as secure, if not better, than trying to trust CAs out there in the wild to confirm that your HTTPS connection was the right HTTPS connection you've said it was.... and then I'm still not sure if the file on my disk haven't been tampered with while it was busy downloaded...

Thus, THINK BEFORE ENCRYPTING

Yours loving encryption himself



No comments: