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 sealing1 (which for our purposes is equivalent to encryption); while the third is enforced through signing.
Distributed communication systems2 are 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 revocation3). 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 entropy4.
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"5: 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 incidents6. This, like all socialist 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 future7 The 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 computing8 is not needed around here, nor is it useful in any general or particular way.
-
See Nick Szabo's The Playdough Protocols for further details on sealing. ↩
-
Not necessarily computing systems, but distributed communication systems in general. For example a system comprising Alice, Bob and a messenger pigeon is in principle -- which is to say, qualitatively -- equivalent to a system comprising the same Alice and Bob communicating over the Internet.
This is a more serious matter than a first glance would reveal: while the Internet is significantly faster, which gives it clear quantitative as well as qualitative advantages over other communication media, it is per its definition qualitatively equivalent to so-called "lesser" forms of communication. This is by and large a good thing, as it tells us that were the Internet to collapse, reality would not fall apart. ↩
-
Revocation is more related to the property of authorization than it is to authenticity, but there is a certain point, namely the philosophical realm of identity, where the two converge. Let's explain this.
Let's say that Alice owns a key
Kand gives it to Bob and some other parties. At some point in the future, Alice may not want to useKto communicate anymore, for which purpose she wants to have a way to markKas invalid, which is equivalent to uttering loudly "Kis not mine anymore, so if you use it to communicate with me in the future, you do so at your own risk". This is a problem of authentication/identity, and its solution may lead to a weak form of forward secrecy.At the same time, upon uttering this, Alice revokes herself the authorization to use
K: we assume she cannot change her mind in the future (which may be disastrous). This particular point is very important to our discussion, because as we see, in the framework of TLS and PKI, Alice does not own her key, but in fact some higher power does. ↩ -
This might seem like an exaggeration, but it's not. The discussion exceeds the current subject by far, but let's take a very brief example to illustrate the problem.
Alice and Bob, having not known each other before, meet in person to exchange keys, which as far as I know is the most secure form of authentication in existence. Bob gives to Alice a piece of paper and says "here, this piece of paper contains my public key", and Alice does the same to Bob.
And now comes the problem: are Alice and Bob supposed to trust each other? And if so, what protocol dictates this? And if not, why not? Can you grasp the problem at hand? How can we define trust without a pre-existing context?
For our amusement, let us also define some contexts. Let's say Alice and Bob have a common friend who recommends each to each other: this reduces to the Web of Trust model, but what formal guarantees does this context give? Or let's say Alice and Bob's keys are generated by the Department of Key Generation in the Socialist United State: this reduces to PKI, which reduces Alice and Bob to cattle, but what formal guarantees does this particular context give? Humour me.
Or let's step this up a bit, and assume that Alice and Bob are lovers who have known each other for thirty years, and spouses and whatnot. What formal guarantees do we have that Bob isn't gonna leak Alice's private key to his housemaid who gives him better fucks? What, you haven't seen marriages fail after thirty years? I have.
Which problem reduces to that of trust, which in turn reduces to entropy: what formal guarantees do (or can!) you have that, given enough time, your cells aren't going to fall apart? ↩
-
This "universality" snake oil is not new in the world of technology. See for example Popescu's article on Unicode. ↩
-
Yes, PKI is a form of communism. I'll restate this in bold: PKI is a communist concoction. Now go and whine to your boss about how Lucian is gratuitously mean and all, while zhe, I don't know... fucks you in the ass or something. ↩
-
Meaning, as soon as possible. What, if Google, that is, the owner of a number of servers on the Internet, is allowed to state vague timeframes, why would I, the owner of a number of servers on the Internet, not be? ↩
-
As opposed to the personal kind. This is yet another philosophical and ideological discussion which needs an essay of its own, but until such an essay comes into existence, you can read the statement of No Such lAbs, my posts on cloud software (part one and part two) and many others. ↩
Meanwhile, in other lulz...
Meanwhile, it looks like even the big actors on the web start seeing HTTPS for what it is: a tool for levelling the playing field in a way that now allows even scammers to get the green padlock. What it doesn't do however -- and one can only wonder why it took them so much to place this problem under scrutiny -- is defend the web server from malicious clients, such as, say, DDoSers and spammers. Pretty sure machines are going to outperform humans in solving captchas, if they haven't already.
So now everyone is sorta kinda filling the "tech space" with this discussion on attestation, meaning, in short, that in order to access Google or Apple or some other big fish, your browser should no longer be yours. In other words, it should perform an incantation based on some inputs that are controlled by the vendor and which attest that said software comes from a "trusted source". In practice, this means that the browser will have to rely on some chain of trust originating in the hardware, much like DRM does for example.
On one hand: boss, didn't you have like, client-side certificates for that?
On the other hand: do you see how this is a shoddy reimplementation of the WoT, with Google and Apple as top nodes?
On yet another, third, alien hand: do you see how this creates a system of agreements between these corporations, a la "I'll suck yours if you suck mine", since now everyone is going to keep a whitelist of vendors they like, which will come from Inca itself. For example, good luck using a Huawei phone in the US if or when this is implemented.
I guess the bottom line is, let 'em have their HTTPS and their attestation and whatnot. We can do well without them wonders of modern technology, with our retrograde HTTP implementations from times now gone, and with our other various super sikrit tools.
[...] things that it does NOT intend to support include Unicode and SSL. Notable missing features it ought to have, quoting the manual, [...]
[...] the Key Management front, the fast food model of weak passwords over insecure protocols falls away as operators come to understand secure key [...]
[...] despite a claimed focus on security, its package management tool was written in C and "secured" by HTTPS. Next I tried the experimental "Gentoo hardened musl" project, using its "stage3" binary as a base [...]
[...] version and gotta choose the proper one, and because the remote end of this PIP thing requires HTTPS to work, and well, add one or two more items to this pile of bring-up work and I easily get close [...]
[...] them so far. I can't help but notice that the author doesn't even mention the wreckage wrought by HTTPS and I'm willing to bet that his web0 should also come with TLS and PKI preloaded, because that's [...]