Hooking nym to wikipedia

Jason Holt jason at lunkwill.org
Mon Oct 3 07:02:54 EDT 2005


Thanks to everyone who has contributed feedback, cyphrpunk in particular. Here 
are my thoughts on connecting nym to wikipedia.  I'll take feedback here 
first, then approach the WikiMedia folks.

* I believe the best solution would be for wikipedia to do the following:

   - Run an SSL server (optionally using a self-signed cert) which requires
     client certificates.  This is a 4-line addition to the httpd.conf.

   - Apache (already) automatically sets an environment variable identifying
     the client certificate used.  MediaWiki would map this to a random state
     variable equivalent to its IP identifier.

   - When admins wish to block an "IP", they follow the usual procedure, which
     has a special case for the special identifiers which adds the
     corresponding cert to a CRL instead of modifying the IP blacklist.  The
     client will no longer be able to connect to the SSL server.

   - Optionally, wikipedia can also send its list of perma-banned IPs to the
     (externally operated, but wikipedia-specific) token server, which will
     then refuse to serve those IPs.

* Alternatives to this approach involve someone else setting up such an SSL 
server as a reverse proxy for en.wikipedia.org and communicating a special 
identifier to wikipedia along with the proxied data in some combination of 
HTTP headers and cookies. I quite like the simplicity of these approaches, 
which could also allow avoiding certificates entirely by allowing users to 
trade a token directly for a cookie.  But now the header/cookie is subject (on 
the proxy->wikipedia link in particular) to eavesdropping, forgery and all the 
other things SSL is designed to prevent.  So ideally, wikipedia would allow an 
SSL connection from the proxy, and might as well just accept the client certs 
or tokens directly.  Also, if we eliminate certs, tokens would then have to be 
kept around and treated as secrets in case the user needs to get cookies 
issued onto other browsers or refreshed when a browser chooses to delete the 
cookie. Certs, OTOH, have a public cert that can be passed around, and come in 
a standardized file that has browser-supported passphrase en/decryption 
support.

* Incidentally, making my apache-ssl (1.3) server reverse-proxy (impersonate, 
essentially) en.wikipedia.org is ridiculously simple.  In the httpd.conf:

   # Inside the <IfModule mod_proxy.c> block:
         ProxyRequests Off
         ProxyPass / http://en.wikipedia.org/
         ProxyPassReverse / http://en.wikipedia.org/

And in the modules.conf:
   LoadModule proxy_module /usr/lib/apache/1.3/libproxy.so


 							-J


(Side note to Damian Gerow: our mail servers refuse to talk to each other; my 
admin claims pandora.afflictions.org is reporting its IP as 10.9.22.67 (an 
unroutable IP), which makes a validity test fail.  We'll have to find a side 
channel.)

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list