Home > Blog > HTTPS: the problems
Update 2019-06-20: Just a disclaimer that this is a very rambly post, so don't take it too seriously.
HTTPS is hailed as a robust protection against man-in-the-middle attacks, which are apparently a problem on the World Wide Web (WWW). It encrypts HTTP traffic over Transport Layer Security (TLS), with servers' identities being verified by certificate authorities (CAs). Everyone wants encryption and privacy, but it's important to reiterate the problems people have with this specific system.
In encrypted communication, you must always blindly trust something. For example, in a WhatsApp encrypted chat, you trust your friend to verify their online identity IRL. Given a one-time pad by their government, a spy must trust the pad.
You don't strictly need a pre-trusted channel to communicate with encryption, but you do need one to talk with confidence. To spread pre-trusted info, Internet engineers design infrastructure that lets encryption be used in practice. Today, many plans exist, each with pros and cons.
HTTPS uses a public key infrastructure that is hierarchical, where a site's TLS certificates are signed by CAs who themselves are verified by "higher-up" CAs. They form a chain of trust ending in a self-signed root CA. Root CAs are the pre-trusted channels. The problem is, in theory a WWW surfer can choose which root CAs they want to trust, but on Earth, WWW surfers rarely change the default root CAs that their WWW browser trusts.
Therefore, we should worry that Google Chrome has 60% market share of WWW browsers. Google has power to basically kill root CAs (mostly corporations) at will by auto-updating Chrome to revoke their authority. This is not a wild fear, since they already did this in 2018.
Pretty Good Privacy, a well-known public key infrastructure, avoids this threat by widely publishing keys informally on trusted channels. Tor, the grand-daddy of encrypted private communication protocols, has no authorities for its onion services (secured WWW sites). It simply identifies services using their public key. There are big disadvantages to these solutions, but they sidestep centralized insanity.
Many sites are static text and images. For blogs, essays, articles, and stories, encryption is extraneous. With HTTP, happily the user-level software stack starts empty, and despite growing server costs it's feasible to program a slim and low-cost HTTP server in a weekend. Meanwhile, OpenSSL—the main library used for TLS—is a massive layer of bloat, and sadly the dominant programming culture reprimands any small-brained no-PhD dummy for trying to hand-roll encryption routines (which is very wise, but still unfortunate). Worse yet, Google (again) pushes hard to mislabel HTTP sites as "dangerous", and artificially stunts their page ranking on their Google search engine. It's OK to defend this culture, but we should acknowledge it exists.
Note: PGP isn't really a PKI but it forms a web of trust model, which works like a PKI.