Last modified: 2014-09-23 23:42:34 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T5729, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 3729 - SSL client certificate authentication
SSL client certificate authentication
Status: NEW
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
1.6.x
All Linux
: Low enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://lunkwill.org/src/nym/
: patch, patch-need-review
Depends on:
Blocks: 9816
  Show dependency treegraph
 
Reported: 2005-10-17 23:21 UTC by Jason
Modified: 2014-09-23 23:42 UTC (History)
9 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
The actual patch to CVS files (2.00 KB, patch)
2005-10-17 23:27 UTC, Jason
Details

Description Jason 2005-10-17 23:21:33 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;
Comment 1 Jason 2005-10-17 23:27:47 UTC
Created attachment 1006 [details]
The actual patch to CVS files
Comment 2 Jason 2005-10-17 23:36:42 UTC
Incidentally, adding this code to httpd.conf makes apache 1.3 demand client
certificates from users:

  SSLVerifyClient 2
  SSLCACertificateFile /whatever/cacert.pem
  SSLVerifyDepth 1
Comment 3 Jason 2005-10-17 23:43:21 UTC
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).

Comment 4 Evaldo Gardenali 2005-10-31 16:28:47 UTC
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 :)
Comment 5 Timo Jyrinki 2006-03-24 13:00:17 UTC
see also bug 3725
Comment 6 Tyler Romeo 2008-06-28 01:14:43 UTC
Would enabling the SSL authentication extension help this at all, or is it irrelevant?
Comment 7 Sumana Harihareswara 2012-01-13 01:12:30 UTC
Jason, is your patch still applicable to MediaWiki as it is currently, in Subversion trunk?
Comment 8 Jason 2012-04-09 21:42:24 UTC
No idea.  I haven't thought about this patch for years.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links