Page MenuHomePhabricator

SSL client certificate authentication
Closed, DeclinedPublic


Author: nym

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 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:

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

    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:

  1. Enable this setting if you want to use strong authentication
  2. based on SSL client certificates; the serial number of the certificate
  3. will be mapped to the last three octets of a 10.*.*.* IP address

$wgMapClientCertToIP = false;

Version: 1.6.x
Severity: enhancement
OS: Linux



Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 8:51 PM
bzimport set Reference to bz3729.
bzimport added a subscriber: Unknown Object (MLST).

nym wrote:

The actual patch to CVS files


nym wrote:

Incidentally, adding this code to httpd.conf makes apache 1.3 demand client
certificates from users:

SSLVerifyClient 2
SSLCACertificateFile /whatever/cacert.pem
SSLVerifyDepth 1

nym wrote:

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:

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).

evaldo wrote:

It would be nice if it features regular user authentication as suggested in

I use certificate-based login on most of my internal things, and MediaWiki will
certainly gain some space once this is implemented :)

timo.jyrinki wrote:

see also bug 3725

Would enabling the SSL authentication extension help this at all, or is it irrelevant?

sumanah wrote:

Jason, is your patch still applicable to MediaWiki as it is currently, in Subversion trunk?

nym wrote:

No idea. I haven't thought about this patch for years.

jeremyb-phone lowered the priority of this task from Low to Lowest.Dec 29 2014, 4:12 PM
jeremyb-phone added a subscriber: jeremyb-phone.
Tgr claimed this task.
Tgr added a subscriber: Tgr.

I don't think this belongs to core. It can be implemented as an extension (and has been, for the most part - see SSL authentication and SSLClientAuthentication). If you think there is core functionality missing please reopen and explain what that is.