January 23, 2016

Money, Trust, and the Wild Wild Web (A socioeconomic history of SSL, or that green lock symbol in your browser)

Filed under: history, software development — Benjamin Vulpes @ 12:00 a.m.
Money, Trust, and the Wild Wild Web (A socioeconomic history of SSL, or that green lock symbol in your browser)

In the beginning, there was the web. Tim Berners-Lee did smile upon it, for it was good. And he rested, or something.

The web in those days was a simpler thing: HTTP servers responded with simple documents of text nominally structured in such a way as to lend semantic meaning to the content embedded within them. Email servers relayed missives signed and unsigned from all parts of the net to all other parts of the net, from alt.tasteless to comp.lang.lisp. Simply having a home connection in the mid-eighties was a rare thing – much like jeans might have been for my Soviet Union counterparts.

Among the dreams of early "Netizens" grew one that would distract them, and by and large derail an entire cycle of the cool kids. The idea of a self- and mutually-semantically describing-and-linking documents captured all of their imaginations, and so XML ate an entire generation, including the self-immolating Erik Naggum (and many other nameless grinders-on-of-the Semantic Web).

One cannot, however, set meat so delicious as the Internet out in the sun without attracting parasites. The curious plebes and eager kids alike wanted online, and (entirely predictably) AOL and similar companies built their own turbines to loft into the flow of the everyone who wanted onto the 'net, seeking what Joules could be pulled from the stream of derps rushing by.

And so the glorious paradise of intellectuals and smug Lisp weenies was lost to the Eternal September. This piece, however, is not about them. Instead, I write today of the socio-economic drivers behind of TLS/SSL: how the world arrived where it is today, and how (come now, are you yet surprised by the relentless slant around here still) Bitcoin will render the whole damn thing moot.

After Berners-Lee and Phriendz had their fun, the late nineties Venture Capitalists showed up. Paul Graham built Viaweb, an early ecommerce website development tool that ran…via the web…because there were enough non-technical folks derping around to constitute a market of people who wanted to run stores online without understanding how they worked. Predictably, Graham's customers' customers would need to pay for things online, the only option for which (give or take an annoyingly slow ACH or three) turned out to be credit and debit cards.

Unfortunately for the world, there are fundamental problems with using credit cards on the internet. These problems are actually fundamental problems with the previous generation's transaction-processing system that remained more-or-less papered over until Bitcoin came along and kneecapped the whole ancient shebang; interbank wires, ACH, and the credit-card system included. The USG is currently desperately trying to adapt to the new world, but its attachments to the old world will prevent anything they try from working.

The basic problem with using credit cards, debit cards, and generally the entire banking system online is that everyone who does so runs the risk of permanent loss of capital. To better understand what systemic flaws SSL's authors claim to address, let's look at how paying for things online with a credit card would have worked in the good old days before the USG shat up OpenSSL.

Some of the web's original payment-handling weaknesses, narrated and enumerated

Should your girlfriend have gotten a hair up her bum to buy shoes on Nordstrom back in the day (I have no idea when Nordies actually launched their first website), she'd have typed into the browser. The browser'd have looked up in the DNS resolution tables accessible to it, which map the human-legible string "" into an IP address (, at this point in time), opened up a socket to that IP address, asked for a specific file (/shoes.html, perhaps), and then rendered that. After much more clicking around, perhaps adding the desired shoes to the cart, the girl'd decide to check out (requesting /checkout.html, for example), put her magic credit card digits into the form Nordstrom sent back down the wire, and send it back to them.

A visual:


This unprotected flow has several flaws that are worth enumerating so that we're all on the same page when I go to discuss what SSL does to mitigate them.

  • DNS
    • you cannot know that the DNS server is trustworthy and will give you the right IP for Nordstrom's servers
  • IP routing
    • the packets to the internet are inspectable by any re-routing party
    • as such, any server that passes along a request for can decide instead to respond as
    • because the packets are transmitted in the clear, anyone in between your girlfriend and her shoes can read her credit card numbers out of them

The fundamental flaw in the {credit,debit}-card system is that in order for money to move from one database row to another, the purchasing party must hand over information enabling the selling party to transfer arbitrary amounts of money out of the purchasing party's account–up to and including everything in the account–anywhere in the world. The processing networks originally mitigated against this flaw in their system by strictly controlling who could accept those magic numbers, and imposed strict rules (see: PCI compliance for a modern example) on how to handle the numbers once they hit disk. Once that system attempted to move onto the internet, it ran into the obvious problem that you can't actually transmit credit card numbers over the internet-as-it-was-at-the-time safely.

Enter SSL

Clearly the situation was intolerable to people building web systems that demanded integration with the payment systems of the time. Mailing checks wasn't precisely an option, nor was proceeding with the obviously flawed system. It was proposed and cemented into the infrastructure of the internet that the centralized bodies closely related to those issuing domain names (ensuring that DNS requests for actually returned the Nordstrom IP's) would thenceforth be responsible for building and deploying the infrastructure to convince consumers that when they did visit a website like Nordstrom's or Zumiez', that it was safe to put the keys to the kingdom (aka debit card numbers) into that web site, primarily by displaying the now-classic Green Lock in the browser bar.

This is SSL: widely known, and reviled for its role in centralizing and rendering more vulnerable to statal control the open internet.

In a nutshell, browsers use mathematics similar to those employed by GPG to ensure that they are talking to the correct servers. Upon connection (this description is of necessity incomplete and incorrect in the specifics, but I hope it is accurate enough to convey the general flow to the non-technical reader. My colleagues in #b-a will no doubt cane me thoroughly for this bastardization, and I'll update this section as appropriate), the browser requests the server's public key in order to establish a secure connection. The server responds with both a public key, and an SSL certificate from a third party verifying that the public key is in fact valid for the web site in question. The certificate (another crypto artifact) is produced by a key in the "trust chain", descending from the (USG-blessed) DNS and SSL regulators' keys. Eg, I buy a certificate of my private key's legitimacy from Namecheap, who buys a certificate of their private key's legitimacy from someone closer to the Forbidden City, who in turn buys a certificate of their private key's legitimacy…on and on until you reach Lizard Hitler's Czar of SSL Issuance himself.

The core flaw with this system is that ex a bunch of hitherto undescribed infrastructure, the browser has no way to validate that the "trust chain", eg the list of certificates leading up to LHCSI does in fact terminate with the Czar's key. The obvious(ly incredibly stupid) solution is to bundle the relevant public keys into the browser from the get-go.

A classic bootstrapping problem. How is one to obtain certificates that are valid, if one cannot connect to servers that one knows to be trustworthy in the first place?! The simple and incorrect answer is to bundle those certificates in the operating system, or the default browser. The correct answer is that developed and practiced by people who take personal cryptographic hygenie very seriously: we meet face to face, and confirm each other's public keys while actually in each others' presence. This is clearly impractical for mass-market implementations.

SSL, as implemented, guarantees that the USG and its affiliates in the ICANN and throughout the rest of the world will retain a stranglehold on website "authentication", and as a direct result, the freedom of anyone who wishes to attach to The Internet (or the USG's internet, if you will) and process payments through the USG-and-NATO-affiliates' systems.

In the minds of the statists, control of the transmission of money is both the goal of the state and its primary tool for exerting its power. In my mind, government control both of the monetary supply and transmission media is the keystone that must be hammered first from the arch of global socialism.

Enter then Bitcoin

While SSL nominally exists to provide comfort of mind to the average person with a few thousand bucks in the bank that their tiny savings won't be pilfered instantly upon exposure of card data to the internet, its subtler and more important raison d'etre is to ensure the control of what I grew up understanding to be the internet and what I grew up understanding to be the payments systems. I suppose that this is the cost of pandering to the ill-educated public: the big-government mindset of necessity leads to centralized solutions to comfort the public and corrupt free and independent systems like the early Internet.

Bitcoin blows this wide open in any number of ways. The first, and apparently least obvious reason (based only on how often I find myself explaining this) is that even in a world of intercepted and compromised connections, one is never exposed to the risk of permanent loss of all of the capital in a given account simply by remitting funds. Absolutely, an attacker can provide a fraudulent delivery address and balance to remit, but even then the victim is only out however much they sent of their own volition. Due to the protocol nature, users never risk the entire balance of an account (if you'll pardon the poetic license) by simply engaging in a transaction, unlike the credit/debit card systems. The onus falls back upon the remitter to balance the size of transaction against the risk of the remittance destination being malformed en route to their eyes. Another obvious point I find myself reiterating is that adult use of strong cryptography renders the interception and malleation of remittance amounts and destinations completely impossible barring a failure of operational security by one of the transacting parties.

The transition away from SSL won't happen overnight, and likely won't even look like a real transition. It's too deeply embedded in the fiat systems to disappear until they do, and their doom was sealed with the loss of control of the monetary base and transmission media. Ultimately SSL will simply cease to matter, as all of the currencies that exist by the fiat of man will eventually suffer a flight of capital into Bitcoin, or whatever successor dominates the landscape at that far point in the future.

At that point, the five billion dollar salary Google pays its serfs will be about as useful as the million dollar flats the Soviet Union gave away to its serfs was, and nobody will give a shit about credit cards, because they'll be backed by all of (and only) the reserves of all those Weimar Republics who failed to get out of Bitcoin's way.


HA! Simple XML…Don't make me disembowel you.

Perhaps not for consumers anytime soon, but eventually. And for the rest of us who want to shoop money around the globe, immediately.

Who at the time in question retained some vestigal relevance by virtue of sitting atop piles of actually hard-earned capital (in stark contrast to today's VC's, whose capital accumulation process documented elsewhere) and actually thinking for half a second about how to deploy it rather than simply shotgunning it at the parade of merit-washed graduates of such storied institutions as Stanford and MIT (those graduates, it's worth noting, whose own sole role in the operation is to drain money back out of the far-down-market funds that Chuck runs in the form of salaries paid to "startup CEOS" and reinvest it in the Harvard/Yale/Stanford "ecosystem" of graduates and subsequent round-raisers. The odd lucky sod strikes it lucky with the VCs and either knowingly hands the bag down to the next-greater-fool at a phenomenal profit or is gently shepharded out of the operation by his earliest and savviest investors claiming to work for "the good of the company", and eking out only a miserable fraction of what he might have earned had he embraced the classic American ponzi with both arms).

This is actually a common problem with systems that evolve into new ecological niches. Assumptions made in the old world don't hold true in the new, and vast amounts of complexity must be papier-mache'd atop the old system to broker between its existing interface and that which the new world demands.

There is simply not enough money in the world to construct the requisite systematically-available interface layers between BTC and the ancien regime that'd be necessary for them to survive in the new world. Not that the task's impossibility prevents the tiny slice of high-risk capital currently masquerading as Venture Capital from burning as many dollars as their retirement-fund-managing friends are willing to drop into the "high risk" bucket, mostly because they fundamentally misunderstand the fiat system's goals for their frenetic activity, and the impossibility thereof.

The joke here is that SSL has never been anything but shit.

It's not a sexist example, yo, I just like girls in heels.

Generated with, source follows:

title unvarnished and simplified old-skool HTTP

participant girlfriend as g
participant browser as b
participant dns as d
participant internet as i
participant as n

g->b: lezzgo a nordies
activate b
b->d: plz
activate d
deactivate d
b->i: relay these packets to plz
activate i
i->n: hey have some packets (GET /shoes.html)
activate n
n->i: here's more packets (shoes.html)
deactivate n
i->b: yer packets, ma'am
deactivate i
deactivate b
g->b: add shoes to cart plz
activate b
b->i: more packets for nordies (POST /cart.html)
activate i
i->n: relays POST /cart.html
activate n
n->i: relay 200 OK plz
deactivate n
i->b: 200
deactivate i
b->g: SHOES IN CART NAO, also cc form
deactivate b
g->b: cc digits
activate b
b->i: relay to nordies (POST credit card deets to /checkout.html)
activate i
i->n: here are some magic money numbers
activate n
n->n: talk to payment network
deactivate n
i->b: relays OK
deactivate i
b->g: ok u gots shyooz nao
deactivate b

That "GPG doesn't scale" is not a concern for people who use GPG and Bitcoin. It should be, however, a concern for everyone whose world is constructed on the paper foundations of centralized key infrastructure, now that we have an uninterdictable currency.

If they control both the monetary base and its transmission vehicles, they posesses also the ability to freeze their adversaries funds and debase their own currency to pay for thousand-dollar hammers from "favorite son" contractors. That Bitcoin will bring an end to both aspects of this reprehensible system should be a foregone conclusion to readers of this blog by now.

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL


« The American consumer, in two photos --- Perceived vs. actual barriers to homeownership for young adults »