[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Hooking nym to wikipedia


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