W3C home > Mailing lists > Public > www-jigsaw@w3.org > September to October 2000

Jigsaw SSL proxy server

From: Michael S. Zick <mszick@pflash.com>
Date: Fri, 29 Sep 2000 11:16:06 -0500
To: www-jigsaw@w3.org
Cc: senthilvasan@givingcircle.com
Message-Id: <00092911430900.00427@wolf01.localdomain>
The short answer: Of course, Jigsaw can be extended to do just about anything.
The code will have to come from someone much better at Java than I - BUT
consider:  Is this really what you want (need) to do?

1) The point of communication security is that a message is understandable only
to the sender and the intended distant party, excluding any unintended third
parties.  Wouldn't a proxy server that decyrpted and re-encyrpted a message be
one of those unintended third parties?

2) Say that the above does not apply, perhaps your proxy is the boundary
between the public and a private network using different encyrption methods or
is on a national boundary that only allows different encyrption methods.  In
such a case, your proxy server is the intended party for both the incoming
messages and re-originated outgoing messages.  Then I must ask the obvious
question - why encrypt the headers?  If the headers are not encrypted (only the
content is encrypted), then any old proxy configuration should do.

Note: The content of the headers is known (or easily guessed) - giving an
unintended third party corresponding samples of the plain text and encyrpted
text which could seriously impact the security of the key system being used. 
So,  if you are really serious about security, DON'T encyrpt the headers.

A further note: If the content has any sort of easily guessed structure to it
(such as a HTML page) you could again be compromising the security of your key
system.

Mike
Received on Friday, 29 September 2000 12:44:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 April 2012 12:13:34 GMT