Technical Architecture shapes Social Structure:
an example from the real world

When you use the Internet, most of your communications rely on many different computers co-operating with each other. The computers co-operate with each other because they have agreed beforehand on a protocol.

The protocols we use for communication shape not just the communications themselves, but social and economic structures beyond them. In the USA, we have seen how choices in infrastructure can shape social structure in the physical world. Our society builds highways, malls, and suburban developments while neglecting its rail lines, public spaces, and cities. In doing so, we discourage civic interaction while facilitating pollution and dangerously sedentary lifestyles. This article shows how choices in digital communications infrastructure can also have an effect on our social fabric by focusing on one small example out of many.

I'll discuss here a protocol in common use on the internet today: Transport Layer Security (TLS) and its precursor, the Secure Sockets Layer (SSL). These are used (among other places) in secure World Wide Web connections. TLS, as it is currently implemented, fosters the concentration of power and money among certain groups while hampering the public's ability to engage in trust-worthy, secure communications.

This is important because we still have an opportunity to choose the tools and protocols we use. By choosing our protocols, we can help move toward a social order we prefer. I'll present an existing modification to TLS which I think can move our online culture in a direction that is more democratically-engaged and less authoritarian.

TLS is only one small piece of the puzzle. There are thousands of protocols and tools in use on the Internet today, with a variety of subtle societal effects. We can choose the way we want to go, but we can choose well only if we understand the issues!

Background and introduction

This article has a relatively narrow technical focus, but it's one which most people reading probably encounter every week, when using the World Wide Web (www).

What is HTTPS and why do we use it?

Most of your everyday use of the www consists of HyperText Transfer Protocol (HTTP) connections. This is the http:// you see at the beginning of many web addresses (known as Uniform Resource Locators, or URLs). An HTTP session consists of your web browser sending a request to the remote web server, which is just another computer connected to the internet. Your request consists of several things, potentially including: The web server replies to your request with its own information, potentially including: These communications (in both directions) are all visible to any computer along the way between your computer and the web server. If you included some information that you'd rather keep private (for example, if you typed your bank account number in a field of a web form), you might be upset that the intermediate machines can all snoop! Even worse, if your password is included in this information, the snooper could then use that password to take actions that only you should be allowed to take, such as updating your organization's web page, transferring money, making travel reservations, etc.

So just using unencrypted, plain HTTP is dangerously insecure! If you are anonymously reporting unethical activity of your employer, you do not want your employer (who controls the network you are using) to see what you are doing, or to alter the contents of your complaint as it is in transit. If you are dealing with your bank, you don't want the other machines on the network to be able to get information about your accounts, much less to withdraw money from them. We need some sort of way to keep our communications private and secure.

This is exactly why we use HTTPS, the secure version of HTTP. This protocol can be identified by the fact that the URL in your browser's address bar begins with https://. It is also often indicated by the little lock icon in your browser. image of lock in browser
The lock in my browser HTTPS is the same protocol as HTTP, but wrapped inside a layer of strong encryption. The encryption provides your communication with two things: privacy and integrity. Privacy means that computers other than your own machine and the web server will see the communications as a stream of gobbledy-gook, but your web browser and the web server involved will be able to understand them. Integrity means that both parties can be certain that the information they receive is actually the same information that was sent by the other party.

This is a good thing, but some questions are still unanswered. If i'm using HTTPS, I can be reasonably sure that the only parties who can decipher the communication are:

But who is the web server really?

How do we know who we're talking to?

Near the little lock, many modern browsers will show you the name of the site you are connecting to. The first thing is to make sure that this is who you think it is. If you are about to send confidential information to your local credit union via their web page (e.g. lespeoples.org), you should be sure that the name near the lock is the name of your credit union. If the machine you are connecting to is something different (e.g. bigbadbank.com), then all the cryptography in the world won't help you keep your information private, because you are sending it to the wrong folks!

But if the name does match, there could still be problems: some nasty group could be intercepting your communications, and claiming to be the group you actually want to talk to. This isn't veering into paranoia here: the global network is very flexible; it relies on wide-scale co-operation; and the malicious actors are often tireless and conscienceless machines, not individual humans.

So how does your browser know to show that lock, since anyone could claim to be anyone else? image of lock in browser with tooltip showing certificate authority
browser lock showing tooltip Because during the initial claim of identity, the web server presents a certificate which is cryptographically signed by an Certificate Authority (CA) who your browser already knows about and trusts. On some modern web browsers, if you hover your mouse over the lock, a tool tip will pop up showing which CA signed off on the certificate presented by the web server. In the image here, you can see that the authority who signed this certificate is Equifax.

Who do you trust?

But wait a minute! Who said that Equifax is an authority who can verify that folks are who they say they are? As any good anarchist would ask, why should you trust this authority? At the moment, you trust them implicitly because your web browser comes pre-configured to trust them. Many modern browsers ship with 30 or more of these CAs trusted automatically. If any one of these authorities is compromised or malicious, they could create fake certificates with whatever name they want, which means that, with only a few other small modifications, they could intercept (and tamper with) communications you intend to be private and untamperable.

Who are these authorities? Why are they included by default in our web browsers? Do they really do a good job in verifying identities before signing certificates? Do they have your best interests in mind? Do they share your political principles? If they received an unethical request from a corrupt governmental power or financial sponsor, would they comply, or would they resist?

I don't have the answers to these questions about any particular CA. But I think that the current technical infrastructure gives them incentives to behave in untrustworthy ways. We have very little reason to think that these CAs have the average web user (or server administrator) in mind when they decide policy, which makes our implicit trust in them all the more unjustified.

Relevant Architecture Components

What is it about the architecture of the Web that encourages this insecurity and lack of integrity? This requires a basic understanding of the underlying protocols used to create secure web connections. The Internet is a collection of co-operating machines, all passing messages to each other in various forms. Viewed from another angle, the Internet is also a collection of interacting protocols, which fit together in certain ways.

TLS

HTTPS is, at its root, HTTP (the common protocol by which web browsers talk to web servers) tunneled through Transport Layer Security, or TLS. TLS itself grew out of the Secure Sockets Layer, or SSL. TLS and SSL are generic protocols which define methods for encrypting a potentially lengthy bidirectional communications session. We call the side of the communications session that waits and listens for new connections the server, and the side that actively initiates connections the client. In the case of HTTPS, your web browser acts as a TLS client.

TLS (like many session-based protocols) begins with a handshake, which is used by the client and server to establish their shared assumptions. You can think of this as two complete strangers on a phone call: they run through the languages they speak, in an attempt to find a common language in which they can communicate.

Assuming both client and server find that each other speaks some common form of TLS, the handshake continues with the server offering the client a single certificate asserting the server's identity.

X.509 v3 certificates

The certificate presented is a combination of a cryptographic public key with an identifying name of the subject (typically the name of the server), where the combination of these two things is signed by a Certificate Authority. The signature is a statement by the Certificate Authority that the public key shown does in fact belong to the subject. You can think of these three parts as a state driver's license. The certificate's key is sort of like the driver's license ID number. The certificate's subject is the driver's name, photo, and other identifying characteristics. The certificate's signature is like the hologram on a state driver's license. Only the DMV can make that hologram, and by applying it over the ID number and the statistics, the DMV is saying that this particular driver has this particular ID number. The specific format of the certificate used in TLS is not a driver's license, of course. It is specified by the X.509 standard.

X.509 covers a lot of different things, but for the purposes of this discussion, we're only interested in how it specifies the certificates used in TLS. In particular, I want to focus on two things: how the server is identified, and how the signature is attached to the identity/public key combination.

The server is identified by a long string of which only the bit after the last CN= is really inspected by your web browser. Here's an example subject from a real-world certificate: 

/O=secure.mayfirst.org/OU=Domain Validated/OU=Go to https://www.thawte.com/repository/index.html/OU=Thawte SSL123 certificate/CN=secure.mayfirst.org

The identity of the signer (aka the issuer) is also present in the certificate, and a single signature is allowed within the certificate.

Your browser (or other TLS-capable client) takes the certificate, looks through its list of trusted certificate authorities for the signer. If it doesn't see the signer in that list, it treats the certificate as invalid. If the signer is present in the list of trusted CAs, your client uses information it already has about the signer to verify that the signature is in fact legitimate.

There's an extra step that can be thrown in here sometimes called certificate chaining, where the server presents not only its own certificate, but also the certificate of its issuer, where the assumption is that the issuer's own certificate is signed by a CA that the client already trusts.

But however the trust is followed, we end with one conclusion: the client must already know of and trust the ultimate signer of the certificate, and there can only be one ultimate signer for any certificate. If the client doesn't know of and trust that signer, they are merely guessing that the machine on the other end of the connection is the intended machine.

Concentration of Power, Financial Incentives, and Trust

So again, the question is: who are these Certificate Authorities? What is their background? Who operates them? What are their political convictions?

How does a typical certificate authority stay afloat?

The biggest Certificate Authority today at the beginning of 2007 is VeriSign. With their purchase of Thawte in 1999 and of of GeoTrust in 2006, they are by far the largest issuer of certificates to the general public (over 70% in aggregate, according to Netcraft).

Verisign has a lot of other businesses, but it makes its CA money by selling certification to the entities requesting it. That is, if you decide to set up a new web site on a server named example.com, and you want to provide secured web access via https://example.com/, you might begin by paying VeriSign for a certificate that identifies your server as example.com. Why should VeriSign certify you with this name? For one thing, because you're paying them to do so. But their responsibility as a CA should include more rigorous checking. And they do so — but just a little bit more — often relying on the example.com DNS and e-mail (both forgeable systems) to be configured properly and securely.

At any rate, the site operator is the one who foots the bill for the certificate, and the CA has little disincentive to turn down certification, since it would presumably mean they'd lose paying customers. If the CA were to engage in massive, wide-scale illegitimate certification, there's a possibility that browser vendors would drop them as a trusted root CA, but it would probably take a really large scandal, and it would likely take months (at least) for browser vendors to actively drop trust for the CA. This has never been done, as far as I know.

Who can be a Certificate Authority?

The kicker in all of this is that Verisign and the other commercial Certificate Authorities aren't using any expensive hardware or software to issue certificates. Free tools like OpenSSL or GnuTLS form the technical basis of most CAs, and there are free graphical frontends (like TinyCA) which make running a Certificate Authority a relatively simple task. These tools can be run on bottom-of-the-barrel hardware, and being a CA doesn't even require a heavy-duty connection to the Internet.

So if anyone can technically be a CA, how come people aren't doing it? For one thing, doing legitimate verification of identities is actually significant work. But the verification done by most CAs (including VeriSign) doesn't come close to this level of work, so that shouldn't be holding people back. It turns out the architecture of TLS itself discourages diversity.

Why does the architecture encourage concentration?

Remember that a TLS (HTTPS) server can only offer a single certificate. For hassle-free, secure connections, the signer of that certificate must already be trusted by the client (web browser). As a site administrator, you need to decide who is going to sign your certificate. Most browsers out there already trust the big corporate CAs. If a new independent CA were to spring up, it won't be trusted by any of the browsers, which means connections using a certificate from the new CA would likely cause errors for your site's visitors. Since you can only choose one, you probably will go with the existing goliath, even if you feel no political affinity with them, and even if you resent paying money for their signature which could have been better used elsewhere.

As an individual who uses the web, your browser already trusts the big corporate CAs. Most of the web sites you visit are probably run by admnistrators who have made the tradeoff above. Why should you ask your browser to trust a new CA, even if it's one you personally actually trust more? It can be a hassle to maintain a list of trusted authorities, and it seems especially fruitless when the new authority you've added isn't actually used by any site that you visit. So why bother? And you're certainly not going to tell your browser to stop trusting the big corporate CAs, because nearly every site you visit has certificates issued by one of them.

What's worse, to make any change in the situation at all, there would need to be a massive break. The day that a site offers a new certificate signed by a new authority, every one of its visitors will see that cert, and will get errors if they don't already trust the new authority. The site administrator is pretty much guaranteed to cause problems for hir visitors by switching away from the mega-CAs.

This seems like a no-win situation, but there are ways out.

Alternate Architectures

The TLS architecture is the cause of this concentration of power, and changes to the architecture can permit or even encourage its dissolution.

What could change the incentives?

As usual, we need to follow the money. One of the reasons the big CAs have little reason to provide real security via heavy-duty verification before certification is because they lack significant competition. Making it easier to start and run a separate Certificate Authority, while actually encouraging its adoption would be a good thing.

If we were to modify the TLS protocol so that a server could offer multiple certificates at once, that would make it much easier to do a smooth transtion away from un-trustworthy big CAs, because sites and users would no longer need the massive, disruptive transition that switching certificates would entail. One year, a web site could offer certificates from Verisign and a new, politically-active CA, while explaining to their users the reason for switching away, and then the next year, the site could drop the VeriSign certificate entirely.

An analogous change would be to enable multiple signatures on a single certificate. Recall that a single X.509 certificate contains a public key, a subject, and a signature binding the two together from a CA. There's no reason (in principle) that we couldn't declare a certificate as a public key, a subject, and a set of signatures, each from a different CA. It turns out that there is a proposal for this kind of alternate, multi-signature certificate (using the OpenPGP standard), which i'll talk about later.

But why should you trust a lot of small CAs more than a handful of big ones? The answer is that you wouldn't (and shouldn't) trust all the small CAs. You might trust a handful of smaller CAs, who you have a personal relationship with. Or you could spread your trust out over a wider range, deciding that you don't give full trust to any single CA. Instead, you could require certification by any 3 of the 20 CAs that you trust marginally. Although CA might be compromised, but it would be a harder job to infiltrate 3 of them.

If CAs are able to really compete on trustworthiness (which they can't right now because of the architecture), you could simply dismiss the CAs who are known to do a terrible job of verification, or who you don't trust for other reasons. For example why should you trust the Certificate Authority run by an oppressive government?

Once it becomes easier to phase in trust of new, alternative Certificate Authorities, we need to think about which ones technologically-aware activists would want to support. I suggest that a full change in the funding model is needed. Instead of being paid for by the site owner, a new-model Certificate Authority could operate independently, funded by its members who, by joining, help shape policy about what sort of verification should be required to grant a certificate.

With the ability to have multiple signatures, there's nothing stopping individuals from acting as their own CAs as well. Do you run your own web site? Certify it! Does your organization have a web site? You and your colleagues could each certify it. This sort of decentralization is healthy, fosters community networks, and can cut out the big corporate middlemen.

What else exists?

EV Certificates

The big corporate middlemen don't want to be cut out, of course. A plan is afoot from some of the larger CAs called Extended Validation (EV) Certificates. From what I can tell, this is simply the big CAs offering to actually do a serious level of identity verification — what they should have been doing all along! The bills for an EV cert, likely even heftier than usual, will probably continue to be paid by the sites requesting the certificates.

This does nothing to change the financial dynamics that make the system currently so untrustworthy. But it does relegate sites who can't pay the new larger fees to a second-class level of security, and it minimizes the number of entities considered officially capable of being an EV-cert-granting CA, further consolidating the power of the few at the top.

CACert.org

Another interesting player is CACert. This is a group that has set up to operate in the fashion of a typical certificate authority, but has set up a sophisticated, clear system explaining what it will take for them to grant you certification, based strictly on a network of trust built among their membership. This is a pretty good model, but it's a shame that they're the only one implementing anything like it. There should be multiple organizations with comparable models to this, so that each user could make hir own decisions about who they actually trust.

Another downside to CACert is the fact that their certificates are still issued only by one agency — the CACert CA. Even though they explicitly say they will only grant certificates according to their model, if their infrastructure is somehow compromised, it's possible for an attacker (or malicious employee) to issue certificates as CACert without following their published protocol.

Don't throw out the baby with the bathwater

All of this might seem more complicated than it needs to be; it's worth asking whether we need any of this at all. I want to make it clear that we do need secure communications. As activists, politically-outspoken workers, anti-authoritarians, or simply people who want to preserve our right to dissent, we need to be able to communicate to each other without eavesdropping or — worse — interference or impersonation. As members of a capitalist society, we are also purchasers and vendors of goods and services, and monetary donors and recipients. We need those transactions to be handled safely, so that we don't have our financial backing usurped.

More than just needing secure communications, we need secure communications without faceless, unaccountable, politically-fickle, mercenary gatekeepers. We need to take control of our own communications by taking responsibility for them.

Moving forward

So where can we go from here on the specific problem of the stunted TLS architecture?

An alternate architecture exists!

I mentioned earlier that there is an alternate proposal — OpenPGP Certificates instead of X.509 certificates — which allows multiple signatures per certificate. The proposal is designed to be implementable in parallel with existing X.509 certificates. However, it is not widely implemented or adopted yet.

Most programs which use TLS do not actually implement their TLS functionality directly. Instead, they make use of software libraries, which are collections of code that can be used by many programs.

At least one TLS library exists which can use OpenPGP certificates: the free GnuTLS library has supported OpenPGP certificates in addition to X.509 certificates since at least the end of 2003. Tools (like web browsers) which use the GnuTLS library basically can get this extra feature without any extra work.

However, the OpenSSL library is by far the most widely-used free library, and it only includes support for X.509 certificates. Some developers are discussing adding OpenPGP support for OpenSSL, but it's doubtful that anything will be ready in the near future. Tools which use OpenSSL are going to take a while to migrate to this new architecture.

So what needs to happen? Web browsers (and other TLS-enabled clients) need to start working with the new architecture. Web servers (and other TLS-enabled servers) need to start working with it as well.

One of the reasons to focus on Free Software (as covered by Amanda Hickman elsewhere in this book) is that we have an opportunity to contribute changes that we want to see. The big proprietary software makers may not share our agendas, or may actually be antagonistic.

Web Browser Buy-in

Mozilla Firefox is probably the widest-distributed Free Browser today. In my version of it on my debian operating system, it actually already uses the GnuTLS library, but I haven't reviewed the sources to see how it gets used (it could be used for library features unrelated to certificate verification). Furthermore, there is no clear way through the Firefox graphical interface to manage OpenPGP CAs, the way there is to manage X.509 CAs. So that needs work. Firefox is also the basis for the proprietary Netscape browser, so any fix to Firefox could have an effect there. Many other Free browsers also derive from Firefox, so a fix here would be a big win.

Konqueror is another leading Free browser with an effect on other tools (Macintosh's Safari is based on Konqueror). It seems to use an SSL wrapper library (kssl) to talk to other libraries, but it appears to use OpenSSL exclusively at the moment. A fix to kssl to allow it to talk to GnuTLS would actually enable OpenPGP certificates for all the software in the KDE suite.

Finally, a couple of text-mode browsers, elinks and the venerable lynx appear to use the GnuTLS library these days.

Web Server Buy-in

apache is the flagship Free web server. While the standard way to make apache work with TLS is the OpenSSL libraries via mod_ssl, a new module called mod_gnutls aims to make apache work with GnuTLS. However, mod_gnutls is still in its infancy, and is not clear if it is able to support OpenPGP keys or not.

Other web servers operate behind separate processes which handle all the TLS wrapping. These servers should be more easily switched to a library which supports OpenPGP. And gnutls-serv appears to offer itself as a rudimentary web server as well, if you needed a server to test browsers.

Who will be the new authorities?

If we do shift to this new architecture, who will offer these new-style certificates? Initially, I imagine that VeriSign and any other very big commercial CAs won't do it, because of the threat to their business model. But smaller CAs might be convinced to offer this service as an add-on to their existing business. And now groups like MayFirst can simply and easily sign on as additional certifying agencies.

CACert.org already offers OpenPGP signatures, so it could probably be used immediately as an initial authority.

And of course, everyone who is aware and interested in these things can perform their own certifications, and publish them freely.

Back to the larger issue

This article goes into some technical detail on one particular corner of technical infrastructure that we use regularly, and looks at ways that architectural choices shape the social forces and structures attached to the infrastructure. But this is just one small corner. Most technological protocols we adhere to have social ramifications which are worthy of consideration. The Domain Name System, or DNS is another example: the US government at the moment wields a heavy influence over its direction because of some architectural choices, and the placement of a few key servers. This has international ramifications, and has actually caused some political tension recently.

The technical decisions made in the early days of e-mail (as discussed in one of Jamie McClelland's articles in this book) continue to shape our lives and our communication choices today, and new extensions to the basic e-mail protocols will continue to have impacts on how we can talk to each other.

Technical choices about how we store the music and movies that we make and listen to, documents and other data, all have social ramifications and are worthy of inspection and political consideration. And if the consideration reveals that there is technical work to be done to improve the social consequences, we need to take that work on, and support others who have similar social goals by adopting their work, even if it means occasional short-term inconvenience or cost.

If we make these social decisions in solidarity with each other, together we can build towards an egalitarian, democratic, non-hierarchical culture that spans the globe. The alternative is a fragmented society, where we are connected only to each other by the mechanisms of financial and cultural control, subjected to the whims of a small, powerful elite. So let's get to work!

Last modified: Tue Feb 20 10:13:41 EST 2007