A declaration of war on the HTTP of Shit

It has been known for quite a while now that Google are waging a war
on plain HTTP with their Chrome web browser. They are openly leveraging their browser’s popularity and their political power to force web server owners to provide services exclusively through HTTPS, that is, the HTTP of Shit. This is all nice and well, only, as it happens, I personally don’t care.

Let us be clear about this: HTTPS is not secure. The simple fact that Google claims HTTPS to be secure does not make it so. It does not make it so from a political point of view, since the “secureness” property of HTTPS only extends as far as Google’s own political arm can reach, which arm cannot for example reach this blog. It also does not make it so from a technical point of view, despite the so-called “experts” having you believe it “just works”. No, it doesn’t, and for some very specific reasons.

But before going into technical details, let us define what “security” means in this context. From a purely theoretical point of view, the TLS family of protocols have been designed to give their users three properties: confidentiality (communication over a given medium cannot be easily intercepted), integrity (data cannot be easily tampered with or otherwise corrupted) and authenticity (the source of given data is verifiable). The first property is enforced through encryption; the second is enforced through sealing(which for our purposes is equivalent to encryption); while the third is enforced through signing.

Distributed communication systemsare fraught with many problems, two of them being: the meta-problem of authenticating the instruments of authentication (i.e. the keys, and more importantly, their owners) and the problem of invalidating said instruments (i.e. key revocation). The two problems are unresolvable. Let me explain what I mean by this: “unresolvable” means “not solvable using technical means”, which means that so far science has given us no sound solution, and searching for one is not so different from looking for a solution to the P vs. NP problem or for a device that can reverse entropy.

Having said that, TLS, and thus HTTPS, proceeds to solve this unresolvable problem; and it does this using two of the worst possible approaches.

The first approach is to make the protocol’s implementation a hack, with the purpose of (as much as possible) providing “universal support”: support all the key exchanges algorithms, all the encryption algorithms, the newest, the latest, the greatest (if possible) algorithms. All this bloat and clutter is what has spawned what you may know as Heartbleed; or DROWN; or BEAST; or many, many other attacks on faulty implementations which are anything but maintainable.

The second approach is to base the protocol upon a centralized model of key generation, exchange and revocation, the Public Key Infrastructure model. The model is, granted, attractive to socialists, because it follows from the basic assumption that Alice and Bob are not able to own their keys, so someone needs to own them for them, to distribute them and revoke them in case of incidents. This, like allsocialist systems, has (among others) the problem that it creates single points of failure. This is how you got the DigiNotar compromise, the VeriSign compromise and others.

Thus we can claim that not only TLS, and thus HTTPS, is not secure; we can claim that it is antithetical to security
. To be clear: I don’t claim that they don’t “just work”. They do “just work”, to the degree a shabby hut works: at the first earthquake or thunderstorm wind, it will fall; and when it does, it will fall hard
, à la the “too big to fail” nonsense. And when it does, the first to suffer will not be the gang of idiot programmers, Google engineers or IETF bureaucrats; it will be the “users” of this fragile construction.

This lengthy introduction being laid out, I wish to formally issue a declaration of war on the HTTP of Shit, also known as HTTPS. This entails an open war with Google, The Linux Foundation, Facebook and pretty much every entity listed as a sponsor on the Let’s Encrypt
web site. There isn’t much that this declaration of war entails, as myself and my blog are very small pieces in this puzzle, but I hope for it to serve as an example for all those who share the philosophy described here.

The Tar Pit’s hosting web server will pointedly not use HTTPS for the foreseeable future, which will result in it being marked as “not secure” by browsers such as Chrome in the near future, and all that for arbitrary reasons. Furthermore, in the near futureThe Tar Pit will remove all support for Chrome: the HTML dialect will probably be limited to around version 4, the CSS decorations will go away and the so-called “web fonts” will have to hit the proverbial dirt as well. The interface will perhaps not look so fancy as it does now, but alas,everything costs. I will however make sure that the blog looks and acts decently in lynx, w3m, Dillo and maybe Firefox, which should be more than enough.

As for Google Chrome: let it be the most popular ever, and let it continue being useful for browsing the Internet of Shit, using the HTTP of Shit. Collectivist computingis not needed around here, nor is it useful in any general or particular way.

稿源:The Tar Pit (源链) | 关于 | 阅读提示

本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » 综合编程 » A declaration of war on the HTTP of Shit

喜欢 (0)or分享给?

专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录