Last modified: 2014-09-23 23:42:34 UTC
This tiny patch maps SSL client certificates, which could be either those used in my pseudonymity package "nym" or traditionally issued certificates, to IP addresses in the reserved 10.0.0.0 network. I have a live MediaWiki installation which uses this patch with nym to allow pseudonymous editing as I described in my proposal to wikitech-l on 7 October 2005. nym-0.3, which includes the patch, can be found here: http://www.lunkwill.org/src/nym/ This is the code: if ( $wgMapClientCertToIP && isset( $_SERVER['SSL_CLIENT_M_SERIAL'] ) ) { # This is a little classier, but would require # more codebase changes and might cause subtle bugs # $ip = 'anonuser.' . $_SERVER['SSL_CLIENT_M_SERIAL']; # This, on the other hand, is almost guaranteed to work, but could # cause problems for people using the 10.*.*.* private IP range $s = $_SERVER['SSL_CLIENT_M_SERIAL']; if ( $s >= (2 << 24) ) { die('Client certificate ID too large(!)'); } $o1 = ($s >> 16); $o2 = ($s >> 8) & 255; $o3 = $s & 255; $ip = '10.' . $o1 .'.'. $o2 .'.'. $o3; } It should be placed in includes/ProxyTools.php just before the last three lines of wfGetIP: wfDebug( "IP: $ip\n" ); $wgIP = $ip; return $ip; } (I'm using MediaWiki from CVS, ProxyTools.php RCS version 1.6.). The following should then be added to DefaultSettings.php: # Enable this setting if you want to use strong authentication # based on SSL client certificates; the serial number of the certificate # will be mapped to the last three octets of a 10.*.*.* IP address $wgMapClientCertToIP = false;
Created attachment 1006 [details] The actual patch to CVS files
Incidentally, adding this code to httpd.conf makes apache 1.3 demand client certificates from users: SSLVerifyClient 2 SSLCACertificateFile /whatever/cacert.pem SSLVerifyDepth 1
Here's most of the proposal I posted to the list for using this patch along with nym to allow pseudonymous edits to wikipedia. I propose that Wikipedia (eventually) should set up an SSL server demanding client certificates issued by a nym CA. Note, however, that this patch is useful for any mediawiki installation that wants to use strong authentication via client certificates, regardless of whether the pedia ever supports nym/tor users. ---- There has been a lot of discussion lately on the or-talk list about how to let tor and other anonymizing proxy users edit wikipedia without allowing vandals free rein. Several straightforward approaches have been proposed, such as holding edits in escrow pending approval by a trusted user, and requiring anonymizing network users to login before posting. The latter idea in particular could easily be abused, since abusers can create a new account for each edit. Roger Dingledine, tor's author, suggested creating a pseudonym service using a cryptographic construction called blind signatures: http://www.rsasecurity.com/rsalabs/node.asp?id=2339 Basically, Alice can generate a token, mathematically blind it (obscuring its value), have it signed, then unblind the signature. Anyone can verify that the signature on the token is valid, but nobody, including the signer, can link the blinded value Alice had signed with her unblinded token. I implemented such a scheme which works as follows: * Alice creates and blinds a token, then submits it to a token server for signing. Optionally, the token server may have a list of IPs banned from wikipedia, and refuse to sign Alice's token if her IP is on the list. * The token server signs the blinded token, then records what IP address Alice used so that she can't obtain multiple tokens per IP address. Later, this will allow us to block Alice's IP address if she misbehaves, just as Wikipedia admins currently do, except that now it'll work even when she connects via tor. Token rationing could also be done based on other (more or less) scarce resources, including email addresses, captchas, CPU-intensive tasks or even money, just as I'm sure has been proposed for the vanilla wikipedia. The advantage of blind signatures is that tokens can be recorded and blocked without revealing the potentially sensitive underlying resource (such as a personal email address or IP address). * Alice can now turn on tor and present her token to wp, without revealing her actual IP address. This token takes the place of the IP address record currently stored along with article edits, and can be blacklisted just the same way that IPs are banned. * However, I implemented an intermediary step which has several advantages. Instead of presenting her token to wp, Alice generates an essentially empty client certificate and presents it via the tor network to a certificate authority (CA) for signing, along with the signed token. The CA records that the token has been "spent" (preventing her from receiving multiple certs per token), then signs her cert just as Verisign would sign a server SSL certificate. Since she connects via tor, the CA doesn't learn her real IP address. * Alice installs the client certificate in her browser, then connects to a special wp server running an SSL server that demands valid client certificates from our CA. That configuration takes only 4 lines in my apache-ssl server's httpd.conf. Apache automatically sets environment variables which identify the client certificate, and which can be used in place of the REMOTE_ADDR variable currently used to record users' incoming IP addresses when marking page edits. Blocking a client cert would then be just as easy as blocking an IP address. All of Alice's edits will be marked with that identifier unless she obtains a new IP address (or other scarce resource) and repeats the process to obtain another certificate. Later, features can optionally be added which will allow her to have separate identifiers for each edit (protecting her in case, say, her repressive government confiscates her computer in order to find out if she wrote a particular article they disagree with).
It would be nice if it features regular user authentication as suggested in http://www.cacert.org/help.php?id=9 I use certificate-based login on most of my internal things, and MediaWiki will certainly gain some space once this is implemented :)
see also bug 3725
Would enabling the SSL authentication extension help this at all, or is it irrelevant?
Jason, is your patch still applicable to MediaWiki as it is currently, in Subversion trunk?
No idea. I haven't thought about this patch for years.
