1996-07-26 - Re: www.anonymizer.com

Header Data

From: Bill Stewart <stewarts@ix.netcom.com>
To: cypherpunks@toad.com
Message Hash: 9460ec1e19b37136b108b40dcbf4fde0c6fc39cc47110511073a2127eae11134
Message ID: <199607260639.XAA21189@toad.com>
Reply To: N/A
UTC Datetime: 1996-07-26 10:32:27 UTC
Raw Date: Fri, 26 Jul 1996 18:32:27 +0800

Raw message

From: Bill Stewart <stewarts@ix.netcom.com>
Date: Fri, 26 Jul 1996 18:32:27 +0800
To: cypherpunks@toad.com
Subject: Re: www.anonymizer.com
Message-ID: <199607260639.XAA21189@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


At 08:53 PM 7/25/96 -0700, mpd@netcom.com (Mike Duvos) wrote:
>I had occasion to try www.anonymizer.com recently, and noticed
>that it does not make SSL connections to other Web servers, nor
>does it seem to accept them from the user.
>
>Is there some technical reason for this?  If I wish to grep the
>Web without my browsing habits becoming known to someone
>monitoring my Net connection, https://www.anonymizer.com with 128
>bit encryption would probably be a good thing to connect to.

I suspect the primary reason is "that takes work we haven't done yet"
rather than anything more cryptographic :-)  However, there are
a couple of theoretical problems with doing it as well.

0A) Suppose You and Webserver are secure by definition (because
        otherwise you're hosed anyway....)
0B) Let -s- denote an SSL connection and --- denote a non-SSL connection.
0C) A connection from You-s-Webserver is as secure as SSL.

1)  A connection from You-s-Anonymizer-s-Webserver is less secure,
        because any flaw or breakin or dishonesty or compromise
        of the Anonymizer compromises the security of your connection.
1A) You may get ripped off or arrested if the Anonymizer's compromised
1B) The Anonymizer may be liable if you get ripped off through it.

2)  An SSL connection may carry a certain amount of indentification
        data across it (I'm speculating a bit), which isn't
        really what you want in an Anonymizer.

3)  A connection You-s-Anonymizer-s-Webserver may not always work
        the same as You-s-Webserver, because the latter may make
        assumptions about the connection that don't hold with the former.
3A) Of course, that's also true with non-SSL connections*,
        but there's less likely to be money riding on the deal.
3B) In particular, there may be different identification data
        passing across the Anonymized connection than the non-Anonymized.
3C) You may trust the Anonymizer and not the Webserver, or vice versa,
        and SSL probably isn't designed to do both correctly.
3D) The Webserver may trust the Anonymizer and not You, or vice versa,
        and SSL probably isn't designed to handle those correctly either.

4)  The Anonymizer may have different encryption types/strengths
        than You or the Webserver.  
4A) If You only do 40-bit RC4 and the Anonymizer can do 3DES,
        the Webserver may think it's got a secure connection
        when your end is weak - especially a problem if the Anonymizer
        is a popular wiretap target.  This can be remedied by
        having the Anonymizer only make https: connections to
        Webservers at the same strength as its connection to You,
        which either requires annoyingly complex programming (bad)
        or a cheap hack like running several Anonymizer servers,
        one with wimpy encryption and one with strong encryption.
4B) If You have a strong crypto connection to the Anonymizer and
        the Webserver only has wimpy RC4/40, there isn't any good
        way for the Anonymizer to tell you about it - so your
        browser may be happily telling you it's got a two-toothed
        3DES/RSA-2048 connection while it's really just RC4/40/RSA-512.
4B1)And that happy Java+JavaScript application your browser is 
        running can check that it's got the MachoCrypto flag set
        and send your credit card number and Secret Plans to the
        Secret Plan Evaluation Service Website, which is a Bad Move...
4B2)Maybe you could program the Anonymizer to check out https:URLs 
        to see what kind of crypto they support, and return 
        anonymizered URLs that use the different-strength Anonymizers
        referred to in 4A.  Not sure this would always work.

5)  The extra RSA encryption from using SSL would probably cause a
        non-trivial amount of extra load for the anonymizer machine.

Summary: Having said all that, I'd probably still like to have it.



<<<<>>>>
* Frames, for instance, do bizzare things when anonymized, at least
with Netscape 3.0b5.  Frames are, of course, _evil_, and are banned
by the CDA, and anyone who uses them should be flamed mercilessly
and forced to use Lynx on a 24x80 monochrome display until he or she
repents and sees the error of their ways, and if that doesn't work
they should be exiled to AOL with only Microsoft Word Internet Assistant.
But that's a flame for another day....
<<<<>>>>

#				Thanks;  Bill
# Bill Stewart +1-415-442-2215 stewarts@ix.netcom.com
# http://www.idiom.com/~wcs
#				Confuse Authority!






Thread