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.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Hooking nym to wikipedia
More thoughts regarding the tokens vs. certs decision, and also multi-use: * Client certs are a pain to turn on and off. If you select ask me every time before sending a client cert, you have to click half a dozen OKs per page. (This could be mitigated by having Wikipedia only use the SSL server for edits, since they're not blocking article viewing anyway, just editing.) If you tell the browser to send the certificate automatically and then forget about it, other SSL sites can silently request it, which is particularly bad if you're not using tor just then. * Using tokens directly at site login time avoids the client cert hassles. However, evil web servers could then collect tokens (nyms) for use at other sites, suggesting that each server should run its own token server. But now each server has a (potentially short) list of client IPs, whereas a centralized token server would provide better concealment. Obviously, if wikipedia is the only site that ever bothers to use nym, this is a moot point. * Lack of forward secrecy is indeed an issue, since our metaphorical Chinese dissident must keep around her cert to continue using it, which if discovered links her with all her past activities. This is a problem even if Wikipedia maps each client cert to a particular random value for public display, since the attackers can simply use the stolen cert to make an edit on wikipedia and then check to see if the identifier comes up the same. If Wikipedia generates a new random ID for each edit, then attackers have to access Wikipedia internals to map the IDs back to the cert, but then, so do Wikipedia admins when they want to assess a user's pattern of (bad) behavior. Note that SSL does not (IIRC) encrypt certificates, so a passive network eavesdropper can associate client certs with the random IDs. (Do the ephemeral modes hide the certs?) A related approach that thwarts the network eavesdropper would be to issue a series of certificates which expire one per interval (hour/day/whatever, trading privacy against the hassle of managing lots of certs). Then our dissident uses each cert in turn, securely deleting it after it expires. The CA keeps a list recording all the certs issued to the same user, and when Wikipedia wishes to ban a user, the CA revokes all the unexpired certs for that user. The CA also securely deletes expired certs from its lists, so that if compromised, it has merely the same list of certs found on the client machine, and is likewise devoid of any reference to certs used in prior transactions. Of course, there are nifty cryptographic solutions to the problem of revoking repeat offenders without linking activities of good users. Private Credentials and Idemix are the two best known examples, but both are complicated and patent-ridden. -J - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Hooking nym to wikipedia (fwd)
-- Forwarded message -- Date: Mon, 3 Oct 2005 08:32:44 -0400 From: Paul Syverson [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: cryptography@metzdowd.com Subject: Re: Hooking nym to wikipedia Hi Jason et al, On Mon, Oct 03, 2005 at 11:48:48AM +, Jason Holt wrote: More thoughts regarding the tokens vs. certs decision, and also multi-use: [snip] A related approach that thwarts the network eavesdropper would be to issue a series of certificates which expire one per interval (hour/day/whatever, trading privacy against the hassle of managing lots of certs). Then our dissident uses each cert in turn, securely deleting it after it expires. The CA keeps a list recording all the certs issued to the same user, and when Wikipedia wishes to ban a user, the CA revokes all the unexpired certs for that user. The CA also securely deletes expired certs from its lists, so that if compromised, it has merely the same list of certs found on the client machine, and is likewise devoid of any reference to certs used in prior transactions. Of course, there are nifty cryptographic solutions to the problem of revoking repeat offenders without linking activities of good users. Private Credentials and Idemix are the two best known examples, but both are complicated and patent-ridden. You might want to have a look at our UST (Unlinkable Serial Transactions) It was published in ACM TISSEC http://chacs.nrl.navy.mil/publications/CHACS/1999/1999stubblebine-serial.pdf (or .ps) There was also an earlier version published at Financial Crypto. (It lacks the proofs and some improvements to the protocols) http://chacs.nrl.navy.mil/publications/CHACS/1997/1997goldschlag-FC97.pdf (or .ps) 1. I think it is much less complicated than the other things you raised, but of course has other tradeoffs. 2. The papers are it. There is no current code worth looking at. 3. Thanks for the reminder. It too is patented if not patent-ridden, but we should be able to cope with that. Basically you shouldn't put huge work in assuming that there are no encumbrances to address, but if you are interested given 1 and 2 after you look at it, let me know. I can then explain the issues regarding the patent situation. aloha, Paul - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
