| 1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> |
|---|
| 2 | <html> |
|---|
| 3 | <head> |
|---|
| 4 | <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15"> |
|---|
| 5 | <title>Technical Architecture shapes Social Structure</title> |
|---|
| 6 | <link rel="stylesheet" href="style.css" type="text/css" /> |
|---|
| 7 | <link rel="shortcut icon" href="icon.png" type="image/png" > |
|---|
| 8 | <link rel="icon" href="icon.png" type="image/png" > |
|---|
| 9 | </head> |
|---|
| 10 | |
|---|
| 11 | <body> |
|---|
| 12 | <h1>Technical Architecture shapes Social Structure:<br />an example from the real world</h1> |
|---|
| 13 | |
|---|
| 14 | When you use the Internet, most of your communications rely on many |
|---|
| 15 | different computers co-operating with each other. The computers |
|---|
| 16 | co-operate with each other because they have agreed beforehand on a |
|---|
| 17 | <term>protocol</term>. |
|---|
| 18 | |
|---|
| 19 | <p>The protocols we use for communication shape not just the |
|---|
| 20 | communications themselves, but social and economic structures beyond |
|---|
| 21 | them. In the USA, we have seen how choices in infrastructure can |
|---|
| 22 | shape social structure in the physical world. Our society builds |
|---|
| 23 | highways, malls, and suburban developments while neglecting its rail |
|---|
| 24 | lines, public spaces, and cities. In doing so, we <a |
|---|
| 25 | href="http://www.planning.org/APAStore/Search/Default.aspx?p=3333">discourage |
|---|
| 26 | civic interaction while facilitating pollution and dangerously |
|---|
| 27 | sedentary lifestyles</a>. This article shows how choices in digital |
|---|
| 28 | communications infrastructure can also have an effect on our social |
|---|
| 29 | fabric by focusing on one small example out of many. |
|---|
| 30 | |
|---|
| 31 | <p>I'll discuss here a protocol in common use on the internet |
|---|
| 32 | today: <term>Transport Layer Security</term> (<term>TLS</term>) and |
|---|
| 33 | its precursor, the <term>Secure Sockets Layer</term> |
|---|
| 34 | (<term>SSL</term>). These are used (among other places) in secure |
|---|
| 35 | World Wide Web connections. <term>TLS</term>, as it is currently |
|---|
| 36 | implemented, fosters the concentration of power and money among |
|---|
| 37 | certain groups while hampering the public's ability to engage in |
|---|
| 38 | trust-worthy, secure communications. |
|---|
| 39 | |
|---|
| 40 | <p>This is important because we still have an opportunity to choose |
|---|
| 41 | the tools and protocols we use. By choosing our protocols, we can |
|---|
| 42 | help move toward a social order we prefer. I'll present an existing |
|---|
| 43 | modification to <term>TLS</term> which I think can move our online |
|---|
| 44 | culture in a direction that is more democratically-engaged and less |
|---|
| 45 | authoritarian. |
|---|
| 46 | |
|---|
| 47 | <p>TLS is only one small piece of the puzzle. There are thousands of |
|---|
| 48 | protocols and tools in use on the Internet today, with a variety of |
|---|
| 49 | subtle societal effects. We can choose the way we want to go, but we |
|---|
| 50 | can choose well only if we understand the issues! |
|---|
| 51 | |
|---|
| 52 | <h2>Background and introduction</h2> |
|---|
| 53 | |
|---|
| 54 | This article has a relatively narrow technical focus, but it's one |
|---|
| 55 | which most people reading probably encounter every week, when using |
|---|
| 56 | the <term>World Wide Web</term> (<term>www</term>). |
|---|
| 57 | |
|---|
| 58 | <h3>What is HTTPS and why do we use it?</h3> |
|---|
| 59 | |
|---|
| 60 | Most of your everyday use of the <term>www</term> consists of <a |
|---|
| 61 | href="http://www.ietf.org/rfc/rfc2616.txt"><term>HyperText Transfer |
|---|
| 62 | Protocol</term></a> (<term>HTTP</term>) connections. This is the |
|---|
| 63 | <code>http://</code> you see at the beginning of many web addresses |
|---|
| 64 | (known as <term>Uniform Resource Locator</term>s, or |
|---|
| 65 | <term>URL</term>s). An <term>HTTP</term> session consists of your web |
|---|
| 66 | browser sending a request to the remote web server, which is just |
|---|
| 67 | another computer connected to the internet. Your request consists of |
|---|
| 68 | several things, potentially including: <ul><li>the full |
|---|
| 69 | <term>URL</term> of the page you are viewing,<li>identifying |
|---|
| 70 | information about your web browser,<li>small pieces of data called |
|---|
| 71 | <q>cookies</q>,<li>the contents of any form fields you might have |
|---|
| 72 | filled in.</ul> The web server replies to your request with its own |
|---|
| 73 | information, potentially including: <ul><li>information about the page |
|---|
| 74 | you requested,<li>identifying information about the web server |
|---|
| 75 | itself,<li>more <q>cookies</q>, <li>the contents of the page |
|---|
| 76 | requested.</ul> |
|---|
| 77 | |
|---|
| 78 | These communications (in both directions) are all visible to any |
|---|
| 79 | computer along the way between your computer and the web server. If |
|---|
| 80 | you included some information that you'd rather keep private (for |
|---|
| 81 | example, if you typed your bank account number in a field of a web |
|---|
| 82 | form), you might be upset that the intermediate machines can all |
|---|
| 83 | snoop! Even worse, if your password is included in this information, |
|---|
| 84 | the snooper could then use that password to take actions that <em>only |
|---|
| 85 | you</em> should be allowed to take, such as updating your |
|---|
| 86 | organization's web page, transferring money, making travel |
|---|
| 87 | reservations, etc. |
|---|
| 88 | |
|---|
| 89 | <p>So just using unencrypted, plain <term>HTTP</term> is dangerously |
|---|
| 90 | insecure! If you are anonymously reporting unethical activity of your |
|---|
| 91 | employer, you do not want your employer (who controls the network you |
|---|
| 92 | are using) to see what you are doing, or to alter the contents of your |
|---|
| 93 | complaint as it is in transit. If you are dealing with your bank, you |
|---|
| 94 | don't want the other machines on the network to be able to get |
|---|
| 95 | information about your accounts, much less to withdraw money from |
|---|
| 96 | them. We need some sort of way to keep our communications private and |
|---|
| 97 | secure. |
|---|
| 98 | |
|---|
| 99 | <p>This is exactly why we use <term>HTTPS</term>, the <q>secure</q> |
|---|
| 100 | version of <term>HTTP</term>. This protocol can be identified by the |
|---|
| 101 | fact that the <term>URL</term> in your browser's address bar begins |
|---|
| 102 | with <code>https://</code>. It is also often indicated by the little |
|---|
| 103 | lock icon in your browser. <captionedimage><img src="lock.png" |
|---|
| 104 | alt="image of lock in browser"/><br/><cap>The lock in my |
|---|
| 105 | browser</cap></captionedimage> <a |
|---|
| 106 | href="http://www.ietf.org/rfc/rfc2818.txt"><term>HTTPS</term></a> is |
|---|
| 107 | the same protocol as <term>HTTP</term>, but wrapped inside a layer of |
|---|
| 108 | strong encryption. The encryption provides your communication with |
|---|
| 109 | two things: privacy and integrity. Privacy means that computers other |
|---|
| 110 | than your own machine and the web server will see the communications |
|---|
| 111 | as a stream of gobbledy-gook, but your web browser and the web server |
|---|
| 112 | involved will be able to understand them. Integrity means that both |
|---|
| 113 | parties can be certain that the information they receive is actually |
|---|
| 114 | the same information that was sent by the other party. |
|---|
| 115 | |
|---|
| 116 | <p>This is a good thing, but some questions are still unanswered. If |
|---|
| 117 | i'm using <term>HTTPS</term>, I can be reasonably sure that the only |
|---|
| 118 | parties who can decipher the communication are:<ul><li>myself <li>the |
|---|
| 119 | web server</ul> But who is the web server really? |
|---|
| 120 | |
|---|
| 121 | <h3>How do we know who we're talking to?</h3> |
|---|
| 122 | |
|---|
| 123 | Near the little <q>lock</q>, many modern browsers will show you the |
|---|
| 124 | name of the site you are connecting to. The first thing is to make |
|---|
| 125 | sure that this is who you think it is. If you are about to send |
|---|
| 126 | confidential information to your local credit union via their web page |
|---|
| 127 | (e.g. <code>lespeoples.org</code>), you should be sure that the name |
|---|
| 128 | near the lock is the name of your credit union. If the machine you |
|---|
| 129 | are connecting to is something different |
|---|
| 130 | (e.g. <code>bigbadbank.com</code>), then all the cryptography in the |
|---|
| 131 | world won't help you keep your information private, because you are |
|---|
| 132 | sending it to the wrong folks! |
|---|
| 133 | |
|---|
| 134 | <p> But if the name <em>does</em> match, there could still be |
|---|
| 135 | problems: some nasty group could be intercepting your communications, |
|---|
| 136 | and claiming to be the group you actually want to talk to. This isn't |
|---|
| 137 | veering into paranoia here: the global network is very flexible; it |
|---|
| 138 | relies on wide-scale co-operation; and the malicious actors are often |
|---|
| 139 | tireless and conscienceless machines, not individual humans. |
|---|
| 140 | |
|---|
| 141 | <p> So how does your browser know to show that lock, since anyone |
|---|
| 142 | could claim to be anyone else? <captionedimage><img src="tooltip.png" |
|---|
| 143 | alt="image of lock in browser with tooltip showing certificate |
|---|
| 144 | authority"/><br/><cap>browser lock showing |
|---|
| 145 | tooltip</cap></captionedimage> Because during the initial claim of |
|---|
| 146 | identity, the web server presents a certificate which is |
|---|
| 147 | cryptographically signed by an <term>Certificate Authority</term> |
|---|
| 148 | (<term>CA</term>) who your browser already knows about and trusts. On |
|---|
| 149 | some modern web browsers, if you hover your mouse over the |
|---|
| 150 | <q>lock</q>, a tool tip will pop up showing which <term>CA</term> |
|---|
| 151 | signed off on the certificate presented by the web server. In the |
|---|
| 152 | image here, you can see that the authority who signed this certificate |
|---|
| 153 | is <q>Equifax</q>. |
|---|
| 154 | |
|---|
| 155 | <h3>Who do you trust?</h3> |
|---|
| 156 | |
|---|
| 157 | But wait a minute! Who said that <q>Equifax</q> is an authority who |
|---|
| 158 | can verify that folks are who they say they are? As any good |
|---|
| 159 | anarchist would ask, why should you trust this authority? At the |
|---|
| 160 | moment, you trust them implicitly because your web browser comes |
|---|
| 161 | pre-configured to trust them. Many modern browsers ship with 30 or |
|---|
| 162 | more of these <term>CA</term>s trusted <em>automatically</em>. If any |
|---|
| 163 | one of these authorities is compromised or malicious, they could |
|---|
| 164 | create fake certificates with whatever name they want, which means |
|---|
| 165 | that, with only a few other small modifications, they could intercept |
|---|
| 166 | (and tamper with) communications you intend to be private and |
|---|
| 167 | untamperable. |
|---|
| 168 | |
|---|
| 169 | <p>Who are these authorities? Why are they included by default in our |
|---|
| 170 | web browsers? Do they really do a good job in verifying identities |
|---|
| 171 | before signing certificates? Do they have your best interests in |
|---|
| 172 | mind? Do they share your political principles? If they received an |
|---|
| 173 | unethical request from a corrupt governmental power or financial |
|---|
| 174 | sponsor, would they comply, or would they resist? |
|---|
| 175 | |
|---|
| 176 | <p>I don't have the answers to these questions about any particular |
|---|
| 177 | <term>CA</term>. But I think that the current technical |
|---|
| 178 | infrastructure gives them incentives to behave in untrustworthy ways. |
|---|
| 179 | We have very little reason to think that these <term>CA</term>s have |
|---|
| 180 | the average web user (or server administrator) in mind when they |
|---|
| 181 | decide policy, which makes our implicit trust in them all the more |
|---|
| 182 | unjustified. |
|---|
| 183 | |
|---|
| 184 | <h2>Relevant Architecture Components</h2> |
|---|
| 185 | |
|---|
| 186 | What is it about the architecture of the Web that encourages this |
|---|
| 187 | insecurity and lack of integrity? This requires a basic understanding |
|---|
| 188 | of the underlying protocols used to create secure web connections. |
|---|
| 189 | The Internet is a collection of co-operating machines, all passing |
|---|
| 190 | messages to each other in various forms. Viewed from another angle, |
|---|
| 191 | the Internet is also a collection of interacting protocols, which fit |
|---|
| 192 | together in certain ways. |
|---|
| 193 | |
|---|
| 194 | <h3>TLS</h3> |
|---|
| 195 | |
|---|
| 196 | <p><term>HTTPS</term> is, at its root, <term>HTTP</term> (the common |
|---|
| 197 | protocol by which web browsers talk to web servers) tunneled through |
|---|
| 198 | <a href="http://www.ietf.org/rfc/rfc4346.txt"><term>Transport Layer |
|---|
| 199 | Security</term></a>, or <term>TLS</term>. <term>TLS</term> itself |
|---|
| 200 | grew out of the <term>Secure Sockets Layer</term>, or |
|---|
| 201 | <term>SSL</term>. <term>TLS</term> and <term>SSL</term> are generic |
|---|
| 202 | protocols which define methods for encrypting a potentially lengthy |
|---|
| 203 | bidirectional communications session. We call the side of the |
|---|
| 204 | communications session that waits and listens for new connections the |
|---|
| 205 | <term>server</term>, and the side that actively initiates connections |
|---|
| 206 | the <term>client</term>. In the case of <term>HTTPS</term>, your web |
|---|
| 207 | browser acts as a <term>TLS</term> <term>client</term>. |
|---|
| 208 | |
|---|
| 209 | <p><term>TLS</term> (like many session-based protocols) begins with a |
|---|
| 210 | <q>handshake</q>, which is used by the <term>client</term> and |
|---|
| 211 | <term>server</term> to establish their shared assumptions. You can |
|---|
| 212 | think of this as two complete strangers on a phone call: they run |
|---|
| 213 | through the languages they speak, in an attempt to find a common |
|---|
| 214 | language in which they can communicate. |
|---|
| 215 | |
|---|
| 216 | <p>Assuming both <term>client</term> and <term>server</term> find that |
|---|
| 217 | each other <q>speaks</q> some common form of <term>TLS</term>, the |
|---|
| 218 | handshake continues with the <term>server</term> offering the client a |
|---|
| 219 | <em>single</em> certificate asserting the <term>server</term>'s |
|---|
| 220 | identity. |
|---|
| 221 | |
|---|
| 222 | <h3>X.509 v3 certificates</h3> |
|---|
| 223 | |
|---|
| 224 | |
|---|
| 225 | <p>The certificate presented is a combination of a cryptographic |
|---|
| 226 | <term>public key</term> with an identifying name of the <q>subject</q> |
|---|
| 227 | (typically the name of the server), where the combination of these two |
|---|
| 228 | things is signed by a <term>Certificate Authority</term>. The |
|---|
| 229 | signature is a statement by the <term>Certificate Authority</term> |
|---|
| 230 | that the <term>public key</term> shown does in fact belong to the |
|---|
| 231 | subject. You can think of these three parts as a state driver's |
|---|
| 232 | license. The certificate's <q>key</q> is sort of like the driver's |
|---|
| 233 | license ID number. The certificate's <q>subject</q> is the driver's |
|---|
| 234 | name, photo, and other identifying characteristics. The certificate's |
|---|
| 235 | <q>signature</q> is like the hologram on a state driver's license. |
|---|
| 236 | Only the <acronym title="Department of Motor Vehicles">DMV</acronym> |
|---|
| 237 | can make that hologram, and by applying it over the ID number and the |
|---|
| 238 | statistics, the DMV is saying that this particular driver has this |
|---|
| 239 | particular ID number. The specific format of the certificate used in |
|---|
| 240 | <term>TLS</term> is not a driver's license, of course. It is |
|---|
| 241 | specified by the <term>X.509</term> standard. |
|---|
| 242 | |
|---|
| 243 | <p><a href="http://www.ietf.org/rfc/rfc3280.txt"><term>X.509</term></a> |
|---|
| 244 | covers a lot of different things, but for the purposes of this |
|---|
| 245 | discussion, we're only interested in how it specifies the certificates |
|---|
| 246 | used in <term>TLS</term>. In particular, I want to focus on two |
|---|
| 247 | things: how the server is identified, and how the signature is |
|---|
| 248 | attached to the identity/public key combination. |
|---|
| 249 | |
|---|
| 250 | <p>The server is identified by a long string of which only the bit |
|---|
| 251 | after the last <code>CN=</code> is really inspected by your web |
|---|
| 252 | browser. Here's an example subject from a real-world certificate: |
|---|
| 253 | |
|---|
| 254 | <pre>/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</pre> |
|---|
| 255 | |
|---|
| 256 | <p>The identity of the signer (aka the <term>issuer</term>) is also |
|---|
| 257 | present in the certificate, and a <em>single</em> signature is allowed |
|---|
| 258 | within the certificate. |
|---|
| 259 | |
|---|
| 260 | <p>Your browser (or other <term>TLS</term>-capable client) takes the |
|---|
| 261 | certificate, looks through its list of trusted <term>certificate |
|---|
| 262 | authorities</term> for the signer. If it doesn't see the signer in |
|---|
| 263 | that list, it treats the certificate as invalid. If the signer is |
|---|
| 264 | present in the list of trusted <term>CA</term>s, your client uses |
|---|
| 265 | information it already has about the signer to verify that the |
|---|
| 266 | signature is in fact legitimate. |
|---|
| 267 | |
|---|
| 268 | <p>There's an extra step that can be thrown in here sometimes called |
|---|
| 269 | <q>certificate chaining</q>, where the server presents not only its own |
|---|
| 270 | certificate, but also the certificate of its <term>issuer</term>, |
|---|
| 271 | where the assumption is that the <term>issuer</term>'s own certificate |
|---|
| 272 | is signed by a <term>CA</term> that the client already trusts. |
|---|
| 273 | |
|---|
| 274 | <p>But however the trust is followed, we end with one conclusion: the |
|---|
| 275 | client must already know of and trust the ultimate signer of the |
|---|
| 276 | certificate, and there can only be one ultimate signer for any |
|---|
| 277 | certificate. If the client doesn't know of and trust that signer, |
|---|
| 278 | they are merely guessing that the machine on the other end of the |
|---|
| 279 | connection is the intended machine. |
|---|
| 280 | |
|---|
| 281 | |
|---|
| 282 | <h2>Concentration of Power, Financial Incentives, and Trust</h2> |
|---|
| 283 | |
|---|
| 284 | <p>So again, the question is: who are these <term>Certificate |
|---|
| 285 | Authorities</term>? What is their background? Who operates them? |
|---|
| 286 | What are their political convictions? |
|---|
| 287 | |
|---|
| 288 | <h3>How does a typical certificate authority stay afloat?</h3> |
|---|
| 289 | |
|---|
| 290 | The biggest <term>Certificate Authority</term> today at the beginning |
|---|
| 291 | of 2007 is <a href="http://verisign.com/">VeriSign</a>. With their |
|---|
| 292 | purchase of <a href="http://thawte.com/">Thawte</a> in 1999 and of of |
|---|
| 293 | <a href="http://geotrust.com/">GeoTrust</a> in 2006, they are by far |
|---|
| 294 | the largest issuer of certificates to the general public (over 70% in |
|---|
| 295 | aggregate, according to <a |
|---|
| 296 | href="http://news.netcraft.com/archives/2006/05/17/verisign_to_buy_geotrust_combining_top_ssl_providers.html">Netcraft</a>). |
|---|
| 297 | |
|---|
| 298 | <p>Verisign has a lot of other businesses, but it makes its |
|---|
| 299 | <term>CA</term> money by selling certification to the entities |
|---|
| 300 | requesting it. That is, if you decide to set up a new web site on a |
|---|
| 301 | server named <code>example.com</code>, and you want to provide secured |
|---|
| 302 | web access via <code>https://example.com/</code>, you might begin by |
|---|
| 303 | paying VeriSign for a certificate that identifies your server as |
|---|
| 304 | <code>example.com</code>. Why should VeriSign certify you with this |
|---|
| 305 | name? For one thing, because you're paying them to do so. But their |
|---|
| 306 | responsibility as a <term>CA</term> should include more rigorous |
|---|
| 307 | checking. And they do so — but just a little bit more — |
|---|
| 308 | often relying on the <code>example.com</code> DNS and e-mail (both |
|---|
| 309 | forgeable systems) to be configured properly and securely. |
|---|
| 310 | |
|---|
| 311 | <p>At any rate, the <em>site operator</em> is the one who foots the |
|---|
| 312 | bill for the certificate, and the <term>CA</term> has little |
|---|
| 313 | disincentive to turn down certification, since it would presumably |
|---|
| 314 | mean they'd lose paying customers. If the <term>CA</term> were to |
|---|
| 315 | engage in massive, wide-scale illegitimate certification, there's a |
|---|
| 316 | possibility that browser vendors would drop them as a trusted root |
|---|
| 317 | <term>CA</term>, but it would probably take a really large scandal, |
|---|
| 318 | and it would likely take months (at least) for browser vendors to |
|---|
| 319 | actively drop trust for the <term>CA</term>. This has never been |
|---|
| 320 | done, as far as I know. |
|---|
| 321 | |
|---|
| 322 | <h3>Who can be a <term>Certificate Authority</term>?</h3> |
|---|
| 323 | |
|---|
| 324 | The kicker in all of this is that Verisign and the other commercial |
|---|
| 325 | <term>Certificate Authorities</term> aren't using any expensive |
|---|
| 326 | hardware or software to issue certificates. Free tools like <a |
|---|
| 327 | href="http://openssl.org/">OpenSSL</a> or <a |
|---|
| 328 | href="http://www.gnu.org/software/gnutls/">GnuTLS</a> form the |
|---|
| 329 | technical basis of most <term>CA</term>s, and there are free graphical |
|---|
| 330 | frontends (like <a href="http://tinyca.sm-zone.net/">TinyCA</a>) which |
|---|
| 331 | make running a <term>Certificate Authority</term> a relatively simple |
|---|
| 332 | task. These tools can be run on bottom-of-the-barrel hardware, and |
|---|
| 333 | being a <term>CA</term> doesn't even require a heavy-duty connection |
|---|
| 334 | to the Internet. |
|---|
| 335 | |
|---|
| 336 | <p>So if anyone can technically be a <term>CA</term>, how come people |
|---|
| 337 | aren't doing it? For one thing, doing legitimate verification of |
|---|
| 338 | identities is actually significant work. But the verification done by |
|---|
| 339 | most <term>CA</term>s (including VeriSign) doesn't come close to this |
|---|
| 340 | level of work, so that shouldn't be holding people back. It turns out |
|---|
| 341 | the architecture of <term>TLS</term> itself discourages diversity. |
|---|
| 342 | |
|---|
| 343 | <h3>Why does the architecture encourage concentration?</h3> |
|---|
| 344 | |
|---|
| 345 | Remember that a <term>TLS</term> (<term>HTTPS</term>) server can only |
|---|
| 346 | offer a single certificate. For hassle-free, secure connections, the |
|---|
| 347 | signer of that certificate must already be trusted by the client (web |
|---|
| 348 | browser). As a site administrator, you need to decide who is going to |
|---|
| 349 | sign your certificate. Most browsers out there already <q>trust</q> |
|---|
| 350 | the big corporate <term>CA</term>s. If a new independent |
|---|
| 351 | <term>CA</term> were to spring up, it won't be trusted by any of the |
|---|
| 352 | browsers, which means connections using a certificate from the new |
|---|
| 353 | <term>CA</term> would likely cause errors for your site's visitors. |
|---|
| 354 | Since you can only choose one, you probably will go with the existing |
|---|
| 355 | goliath, even if you feel no political affinity with them, and even if |
|---|
| 356 | you resent paying money for their signature which could have been |
|---|
| 357 | better used elsewhere. |
|---|
| 358 | |
|---|
| 359 | <p>As an individual who uses the web, your browser already |
|---|
| 360 | <q>trusts</q> the big corporate CAs. Most of the web sites you visit |
|---|
| 361 | are probably run by admnistrators who have made the tradeoff above. |
|---|
| 362 | Why should you ask your browser to trust a new <term>CA</term>, even |
|---|
| 363 | if it's one you personally actually trust more? It can be a hassle to |
|---|
| 364 | maintain a list of trusted authorities, and it seems especially |
|---|
| 365 | fruitless when the new authority you've added isn't actually used by |
|---|
| 366 | any site that you visit. So why bother? And you're certainly not |
|---|
| 367 | going to tell your browser to stop <q>trusting</q> the big corporate |
|---|
| 368 | <term>CA</term>s, because nearly every site you visit has certificates |
|---|
| 369 | issued by one of them. |
|---|
| 370 | |
|---|
| 371 | <p>What's worse, to make any change in the situation at all, there |
|---|
| 372 | would need to be a massive break. The day that a site offers a new |
|---|
| 373 | certificate signed by a new authority, <em>every one of its |
|---|
| 374 | visitors</em> will see that cert, and will get errors if they don't |
|---|
| 375 | already trust the new authority. The site administrator is pretty |
|---|
| 376 | much guaranteed to cause problems for hir visitors by switching away |
|---|
| 377 | from the mega-<term>CA</term>s. |
|---|
| 378 | |
|---|
| 379 | <p>This seems like a no-win situation, but there are ways out. |
|---|
| 380 | |
|---|
| 381 | <h2>Alternate Architectures</h2> |
|---|
| 382 | |
|---|
| 383 | The <term>TLS</term> architecture is the cause of this concentration |
|---|
| 384 | of power, and changes to the architecture can permit or even encourage |
|---|
| 385 | its dissolution. |
|---|
| 386 | |
|---|
| 387 | <h3>What could change the incentives?</h3> |
|---|
| 388 | |
|---|
| 389 | As usual, we need to follow the money. One of the reasons the big |
|---|
| 390 | <term>CA</term>s have little reason to provide real security via |
|---|
| 391 | heavy-duty verification before certification is because they lack |
|---|
| 392 | significant competition. Making it easier to start and run a separate |
|---|
| 393 | <term>Certificate Authority</term>, while actually encouraging its |
|---|
| 394 | adoption would be a good thing. |
|---|
| 395 | |
|---|
| 396 | <p>If we were to modify the <term>TLS</term> protocol so that a server |
|---|
| 397 | could offer multiple certificates at once, that would make it much |
|---|
| 398 | easier to do a smooth transtion away from un-trustworthy big |
|---|
| 399 | <term>CA</term>s, because sites and users would no longer need the |
|---|
| 400 | massive, disruptive transition that switching certificates would |
|---|
| 401 | entail. One year, a web site could offer certificates from Verisign |
|---|
| 402 | and a new, politically-active <term>CA</term>, while explaining to |
|---|
| 403 | their users the reason for switching away, and then the next year, the |
|---|
| 404 | site could drop the VeriSign certificate entirely. |
|---|
| 405 | |
|---|
| 406 | <p>An analogous change would be to enable multiple signatures on a |
|---|
| 407 | single certificate. Recall that a single <term>X.509</term> |
|---|
| 408 | certificate contains a public key, a subject, and a signature binding |
|---|
| 409 | the two together from a <term>CA</term>. There's no reason (in |
|---|
| 410 | principle) that we couldn't declare a certificate as a public key, a |
|---|
| 411 | subject, and a <em>set of signatures</em>, each from a different |
|---|
| 412 | <term>CA</term>. It turns out that there is a proposal for this kind |
|---|
| 413 | of alternate, multi-signature certificate (using the |
|---|
| 414 | <term>OpenPGP</term> standard), which i'll talk about later. |
|---|
| 415 | |
|---|
| 416 | <p>But why should you trust a lot of small <term>CA</term>s more than |
|---|
| 417 | a handful of big ones? The answer is that you wouldn't (and |
|---|
| 418 | shouldn't) trust all the small <term>CA</term>s. You might trust a |
|---|
| 419 | handful of smaller <term>CA</term>s, who you have a personal |
|---|
| 420 | relationship with. Or you could spread your trust out over a wider |
|---|
| 421 | range, deciding that you don't give full trust to any single |
|---|
| 422 | <term>CA</term>. Instead, you could require certification by any 3 of |
|---|
| 423 | the 20 <term>CA</term>s that you trust marginally. Although CA might |
|---|
| 424 | be compromised, but it would be a harder job to infiltrate 3 of them. |
|---|
| 425 | |
|---|
| 426 | <p>If <term>CA</term>s are able to really compete on trustworthiness |
|---|
| 427 | (which they can't right now because of the architecture), you could |
|---|
| 428 | simply dismiss the <term>CA</term>s who are known to do a terrible job |
|---|
| 429 | of verification, or who you don't trust for other reasons. For |
|---|
| 430 | example why should you trust the <term>Certificate Authority</term> |
|---|
| 431 | run by an oppressive government? |
|---|
| 432 | |
|---|
| 433 | <p>Once it becomes easier to phase in trust of new, alternative |
|---|
| 434 | <term>Certificate Authorities</term>, we need to think about which |
|---|
| 435 | ones technologically-aware activists would want to support. I suggest |
|---|
| 436 | that a full change in the funding model is needed. Instead of being |
|---|
| 437 | paid for by the site owner, a new-model <term>Certificate |
|---|
| 438 | Authority</term> could operate independently, funded by its members |
|---|
| 439 | who, by joining, help shape policy about what sort of verification |
|---|
| 440 | should be required to grant a certificate. |
|---|
| 441 | |
|---|
| 442 | <p>With the ability to have multiple signatures, there's nothing |
|---|
| 443 | stopping individuals from acting as their own <term>CA</term>s as |
|---|
| 444 | well. Do you run your own web site? Certify it! Does your |
|---|
| 445 | organization have a web site? You and your colleagues could each |
|---|
| 446 | certify it. This sort of decentralization is healthy, fosters |
|---|
| 447 | community networks, and can cut out the big corporate middlemen. |
|---|
| 448 | |
|---|
| 449 | <h3>What else exists?</h3> |
|---|
| 450 | |
|---|
| 451 | <h4><term>EV</term> Certificates</h4> The big corporate middlemen don't |
|---|
| 452 | want to be cut out, of course. A plan is afoot from some of the |
|---|
| 453 | larger <term>CA</term>s called <a |
|---|
| 454 | href="http://www.cabforum.org/certificates.html"><term>Extended |
|---|
| 455 | Validation</term> (<term>EV</term>) Certificates</a>. From what I |
|---|
| 456 | can tell, this is simply the big <term>CA</term>s offering to actually |
|---|
| 457 | do a serious level of identity verification — what they should |
|---|
| 458 | have been doing all along! The bills for an <term>EV</term> cert, |
|---|
| 459 | likely even heftier than usual, will probably continue to be paid by |
|---|
| 460 | the sites requesting the certificates. |
|---|
| 461 | |
|---|
| 462 | <p>This does nothing to change the financial dynamics that make the |
|---|
| 463 | system currently so untrustworthy. But it does relegate sites who |
|---|
| 464 | can't pay the new larger fees to a second-class level of |
|---|
| 465 | <q>security</q>, and it minimizes the number of entities considered |
|---|
| 466 | officially capable of being an <term>EV</term>-cert-granting |
|---|
| 467 | <term>CA</term>, further consolidating the power of the few at the |
|---|
| 468 | top. |
|---|
| 469 | |
|---|
| 470 | <h4>CACert.org</h4> |
|---|
| 471 | |
|---|
| 472 | Another interesting player is <a href="http://cacert.org">CACert</a>. |
|---|
| 473 | This is a group that has set up to operate in the fashion of a typical |
|---|
| 474 | certificate authority, but has set up <a |
|---|
| 475 | href="http://wiki.cacert.org/wiki/FAQ/AssuranceIntroduction">a |
|---|
| 476 | sophisticated, clear system</a> explaining what it will take for them |
|---|
| 477 | to grant you certification, based strictly on a network of trust built |
|---|
| 478 | among their membership. This is a pretty good model, but it's a shame |
|---|
| 479 | that they're the only one implementing anything like it. There should |
|---|
| 480 | be multiple organizations with comparable models to this, so that each |
|---|
| 481 | user could make hir own decisions about who they actually trust. |
|---|
| 482 | |
|---|
| 483 | <p>Another downside to CACert is the fact that their certificates are |
|---|
| 484 | <em>still issued only by one agency</em> — the CACert |
|---|
| 485 | <term>CA</term>. Even though they explicitly say they will only grant |
|---|
| 486 | certificates according to their model, if their infrastructure is |
|---|
| 487 | somehow compromised, it's possible for an attacker (or malicious |
|---|
| 488 | employee) to issue certificates as CACert without following their |
|---|
| 489 | published protocol. |
|---|
| 490 | |
|---|
| 491 | <h3>Don't throw out the baby with the bathwater</h3> |
|---|
| 492 | |
|---|
| 493 | All of this might seem more complicated than it needs to be; it's |
|---|
| 494 | worth asking whether we need any of this at all. I want to make it |
|---|
| 495 | clear that <em>we do need secure communications</em>. As activists, |
|---|
| 496 | politically-outspoken workers, anti-authoritarians, or simply people |
|---|
| 497 | who want to preserve our right to dissent, we need to be able to |
|---|
| 498 | communicate to each other without eavesdropping or — worse |
|---|
| 499 | — interference or impersonation. As members of a capitalist |
|---|
| 500 | society, we are also purchasers and vendors of goods and services, and |
|---|
| 501 | monetary donors and recipients. We need those transactions to be |
|---|
| 502 | handled safely, so that we don't have our financial backing usurped. |
|---|
| 503 | |
|---|
| 504 | <p>More than just needing secure communications, we need secure |
|---|
| 505 | communications without faceless, unaccountable, politically-fickle, |
|---|
| 506 | mercenary gatekeepers. We need to take control of our own |
|---|
| 507 | communications by taking responsibility for them. |
|---|
| 508 | |
|---|
| 509 | <h2>Moving forward</h2> |
|---|
| 510 | |
|---|
| 511 | So where can we go from here on the specific problem of the stunted |
|---|
| 512 | <term>TLS</term> architecture? |
|---|
| 513 | |
|---|
| 514 | <h3>An alternate architecture exists!</h3> |
|---|
| 515 | |
|---|
| 516 | I mentioned earlier that there is an alternate proposal — <a |
|---|
| 517 | href="http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-keys-11.txt"><term>OpenPGP</term> |
|---|
| 518 | Certificates instead of <term>X.509</term> certificates</a> — |
|---|
| 519 | which allows multiple signatures per certificate. The proposal is |
|---|
| 520 | designed to be implementable in parallel with existing |
|---|
| 521 | <term>X.509</term> certificates. However, it is not widely |
|---|
| 522 | implemented or adopted yet. |
|---|
| 523 | |
|---|
| 524 | <p>Most programs which use <term>TLS</term> do not actually implement |
|---|
| 525 | their TLS functionality directly. Instead, they make use of software |
|---|
| 526 | <term>libraries</term>, which are collections of code that can be used |
|---|
| 527 | by many programs. |
|---|
| 528 | |
|---|
| 529 | <p>At least one TLS library exists which can use OpenPGP certificates: |
|---|
| 530 | the free <a href="http://www.gnu.org/software/gnutls/">GnuTLS |
|---|
| 531 | library</a> has supported <term>OpenPGP</term> certificates in |
|---|
| 532 | addition to <term>X.509</term> certificates since at least the end of |
|---|
| 533 | 2003. Tools (like web browsers) which use the GnuTLS library |
|---|
| 534 | basically can get this extra feature without any extra work. |
|---|
| 535 | |
|---|
| 536 | <p>However, the <a href="http://openssl.org/">OpenSSL library</a> is |
|---|
| 537 | by far the most widely-used free library, and it only includes support |
|---|
| 538 | for <term>X.509</term> certificates. Some developers <a |
|---|
| 539 | href="http://www.mail-archive.com/openssl-dev@openssl.org/msg21728.html">are |
|---|
| 540 | discussing adding OpenPGP support for OpenSSL</a>, but it's doubtful |
|---|
| 541 | that anything will be ready in the near future. Tools which |
|---|
| 542 | use OpenSSL are going to take a while to migrate to this new |
|---|
| 543 | architecture. |
|---|
| 544 | |
|---|
| 545 | <p>So what needs to happen? Web browsers (and other TLS-enabled |
|---|
| 546 | clients) need to start working with the new architecture. Web servers |
|---|
| 547 | (and other TLS-enabled servers) need to start working with it as well. |
|---|
| 548 | |
|---|
| 549 | <p>One of the reasons to focus on Free Software (as covered by Amanda |
|---|
| 550 | Hickman elsewhere in this book) is that we have an opportunity to |
|---|
| 551 | contribute changes that we want to see. The big proprietary software |
|---|
| 552 | makers may not share our agendas, or may actually be antagonistic. |
|---|
| 553 | |
|---|
| 554 | <h3>Web Browser Buy-in</h3> |
|---|
| 555 | |
|---|
| 556 | <a href="http://mozilla.com/firefox/">Mozilla Firefox</a> is probably |
|---|
| 557 | the widest-distributed Free Browser today. In my version of it on my |
|---|
| 558 | <a href="http://debian.org/">debian</a> operating system, it actually |
|---|
| 559 | already uses the GnuTLS library, but I haven't reviewed the sources to |
|---|
| 560 | see how it gets used (it could be used for library features unrelated |
|---|
| 561 | to certificate verification). Furthermore, there is no clear way |
|---|
| 562 | through the Firefox graphical interface to manage OpenPGP |
|---|
| 563 | <term>CA</term>s, the way there is to manage <term>X.509</term> |
|---|
| 564 | <term>CA</term>s. So that needs work. Firefox is also the basis for |
|---|
| 565 | the proprietary Netscape browser, so any fix to Firefox could have an |
|---|
| 566 | effect there. Many other Free browsers also derive from Firefox, so a |
|---|
| 567 | fix here would be a big win. |
|---|
| 568 | |
|---|
| 569 | <p><a href="http://www.konqueror.org/">Konqueror</a> is another |
|---|
| 570 | leading Free browser with an effect on other tools (Macintosh's <a |
|---|
| 571 | href="http://www.apple.com/safari/">Safari</a> is based on Konqueror). |
|---|
| 572 | It seems to use an SSL wrapper library (<tt>kssl</tt>) to talk to |
|---|
| 573 | other libraries, but it appears to use OpenSSL exclusively at the |
|---|
| 574 | moment. A fix to <tt>kssl</tt> to allow it to talk to GnuTLS would |
|---|
| 575 | actually enable OpenPGP certificates for all the software in the <a |
|---|
| 576 | href="http://kde.org/">KDE</a> suite. |
|---|
| 577 | |
|---|
| 578 | <p>Finally, a couple of text-mode browsers, <a |
|---|
| 579 | href="http://elinks.or.cz/"><tt>elinks</tt></a> and the venerable <a |
|---|
| 580 | href="http://lynx.browser.org/"><tt>lynx</tt></a> appear to use the |
|---|
| 581 | GnuTLS library these days. |
|---|
| 582 | |
|---|
| 583 | <h3>Web Server Buy-in</h3> |
|---|
| 584 | |
|---|
| 585 | <a href="http://httpd.apache.org//"><tt>apache</tt></a> is the |
|---|
| 586 | flagship Free web server. While the standard way to make apache work |
|---|
| 587 | with <term>TLS</term> is the OpenSSL libraries via <a |
|---|
| 588 | href="http://www.modssl.org/"><tt>mod_ssl</tt></a>, a new module |
|---|
| 589 | called <a |
|---|
| 590 | href="http://www.outoforder.cc/projects/apache/mod_gnutls/"><tt>mod_gnutls</tt></a> |
|---|
| 591 | aims to make <tt>apache</tt> work with GnuTLS. However, |
|---|
| 592 | <tt>mod_gnutls</tt> is still in its infancy, and is not clear if it is |
|---|
| 593 | able to support OpenPGP keys or not. |
|---|
| 594 | |
|---|
| 595 | <p>Other web servers operate behind separate processes which handle |
|---|
| 596 | all the <term>TLS</term> wrapping. These servers should be more |
|---|
| 597 | easily switched to a library which supports <term>OpenPGP</term>. And |
|---|
| 598 | <tt>gnutls-serv</tt> appears to offer itself as a rudimentary web |
|---|
| 599 | server as well, if you needed a server to test browsers. |
|---|
| 600 | |
|---|
| 601 | <h3>Who will be the new authorities?</h3> |
|---|
| 602 | |
|---|
| 603 | If we do shift to this new architecture, who will offer these |
|---|
| 604 | new-style certificates? Initially, I imagine that VeriSign and any |
|---|
| 605 | other very big commercial <term>CA</term>s won't do it, because of the |
|---|
| 606 | threat to their business model. But smaller <term>CA</term>s might be |
|---|
| 607 | convinced to offer this service as an add-on to their existing |
|---|
| 608 | business. And now groups like <a |
|---|
| 609 | href="http://mayfirst.org/">MayFirst</a> can simply and easily sign on |
|---|
| 610 | as additional certifying agencies. |
|---|
| 611 | |
|---|
| 612 | <p><a href="http://cacert.org/">CACert.org</a> already offers OpenPGP |
|---|
| 613 | signatures, so it could probably be used immediately as an initial |
|---|
| 614 | authority. |
|---|
| 615 | |
|---|
| 616 | <p>And of course, everyone who is aware and interested in these things |
|---|
| 617 | can perform their own certifications, and publish them freely. |
|---|
| 618 | |
|---|
| 619 | <h2>Back to the larger issue</h2> |
|---|
| 620 | |
|---|
| 621 | This article goes into some technical detail on one particular corner |
|---|
| 622 | of technical infrastructure that we use regularly, and looks at ways |
|---|
| 623 | that architectural choices shape the social forces and structures |
|---|
| 624 | attached to the infrastructure. But this is just one small corner. |
|---|
| 625 | Most technological protocols we adhere to have social ramifications |
|---|
| 626 | which are worthy of consideration. The <term>Domain Name |
|---|
| 627 | System</term>, or <term>DNS</term> is another example: the US |
|---|
| 628 | government at the moment wields a heavy influence over its direction |
|---|
| 629 | because of some architectural choices, and the placement of a few key |
|---|
| 630 | servers. This has international ramifications, and has actually |
|---|
| 631 | caused some political tension recently. |
|---|
| 632 | |
|---|
| 633 | <p>The technical decisions made in the early days of e-mail (as |
|---|
| 634 | discussed in one of Jamie McClelland's articles in this book) continue |
|---|
| 635 | to shape our lives and our communication choices today, and new |
|---|
| 636 | extensions to the basic e-mail protocols will continue to have impacts |
|---|
| 637 | on how we can talk to each other. |
|---|
| 638 | |
|---|
| 639 | <p>Technical choices about how we store the music and movies that we |
|---|
| 640 | make and listen to, documents and other data, all have social |
|---|
| 641 | ramifications and are worthy of inspection and political |
|---|
| 642 | consideration. And if the consideration reveals that there is |
|---|
| 643 | technical work to be done to improve the social consequences, we need |
|---|
| 644 | to take that work on, and support others who have similar social goals |
|---|
| 645 | by adopting their work, even if it means occasional short-term |
|---|
| 646 | inconvenience or cost. |
|---|
| 647 | |
|---|
| 648 | <p>If we make these social decisions in solidarity with each other, |
|---|
| 649 | together we can build towards an egalitarian, democratic, |
|---|
| 650 | non-hierarchical culture that spans the globe. The alternative is a |
|---|
| 651 | fragmented society, where we are connected only to each other by the |
|---|
| 652 | mechanisms of financial and cultural control, subjected to the whims |
|---|
| 653 | of a small, powerful elite. So let's get to work! |
|---|
| 654 | |
|---|
| 655 | |
|---|
| 656 | <hr> |
|---|
| 657 | <address></address> |
|---|
| 658 | <!-- hhmts start -->Last modified: Tue Feb 20 10:13:41 EST 2007 <!-- hhmts end --> |
|---|
| 659 | </body> </html> |
|---|
