From: Rick Osborne <osborne@gateway.grumman.com>
Date: Wed, 14 May 1997 10:25:44 +0800
To: cypherpunks mailing list <cypherpunks@algebra.com>
Subject: Spoofing Corporate Proxy Servers: poor man's SSL
Message-ID: <3.0.1.32.19970513221218.00a5bcf0@gateway.grumman.com>
MIME-Version: 1.0
Content-Type: text/plain


________________________ R i c k   O s b o r n e ________________________
My company, as well as many of yours I'm sure, uses a proxy server to give
its users access to the internet beyond its firewall.  There are strict
policies concerning what is and isn't viewable or retreivable according to
corporate guidelines.  Unfortunately, the people making these policies
aren't always as open and "fair" as they could be.  Not to mention the fact
that each and every request is logged and achived for eternity (or at least
as long as the CDs and/or tapes last).

Some of you may remember my post from ~6 months ago concerning my company's
view on the use of PGP (they didn't like it and were very frank about it).
My pursuit of crypto-related information is viewed very dimly, even while
at the same time I am told to implement certain levels of crypto in some of
the applications I develop.  The constant barrage of "why did you visit
this page?", or "what does this application you downloaded do?" is not only
irritating but counter-productive.  This got me thinking: disregarding
outside proxy schemes (such as Anonymizer), we can't really keep the proxy
server from knowing the site we are connecting to.  We can, however, hide
the page we are retrieving.

Suppose each web server had a public/private key pair, sort of like SSL.
Instead of requesting a page using the normal "GET /mypage.html HTTP/1.1"
method, the user could encrypt the URL with the server's public key (along
with appropriate headers and a random string to prevent known-plaintext
attacks) and pass that to a CGI or even a dedicated server on another port.
 The server then decrypts the request, which may or may not have included a
public key to encrypt the response, grabs the appropriate page, and sends
it back (possibly encrypted).  Other than the CGI (or the port number of
the dedicated server), the proxy server has no idea what document has been
retrieved.  Essentially we have made a remailer out of an HTTPd,
tangentally related to Adam's Eternity server, sort of like a poor-man's SSL.

For extensibility concerns, a loose protocol would have to be developed
such that different encryption schemes could be plugged in, but even a Perl
POST CGI using PGP would be trivial.  This would not only solve security
problems (varying keysizes would set the security of the data), but could
remove the corporate presence from the HTTPS market (who wants to pay
$150/key, when you can generate 2048-bit keys with PGP?).  While this does
not stop the proxy server admins from simply blocking the entire site, it
does at least offer anonymity until they figure it out.  (I successfully
used the Anonymizer for about 2 weeks before it was blocked.)
_________ o s b o r n e @ g a t e w a y . g r u m m a n . c o m _________
(A)bort, (R)etry, (T)ake down entire network?