Nonrepudiation - in some sense

leichter_jerrold at emc.com leichter_jerrold at emc.com
Fri Feb 10 15:08:07 EST 2006


| >>From a description of the Imperva "SecureSphere" technology.  Imperva
makes 
| > firewalls that can "look inside" SSL sessions:
| > 
| >  	SSL Security that Maintains Non-Repudiation
| > 
| >  	SecureSphere can inspect the contents of both HTTP and HTTPS
| >  	(SSL) traffic.  SecureSphere delivers higher HTTPS performance
| >  	than competing reverse proxy point solutions because
| >  	SecureSphere decrypts SSL encrypted traffic but does not
| >  	terminate it. Therefore SecureSphere simply passes the encrypted
| >  	packets unchanged to the application or database server. This
| >  	eliminates the overhead of re-packaging (i.e. changing) the
| >  	communications, re-negotiating a new SSL connection to the
| >  	server, and re-encrypting the information. Moreover, it
| >  	maintains the non-repudiation of transactions since the
| >  	encrypted communication is between client and application with
| >  	no proxy acting as middleman.
| 
| Firstly, even if you believe that _any_ crypto provides non-repudiation
| (see http://www.apache-ssl.org/tech-legal.pdf for a paper I co-authored
| on this and other stuff - executive summary: I don't believe it), you
| can't "maintain" the non-repudation of SSL because it doesn't provide
| non-repudation.
| 
| Secondly, obviously, you can only decrypt SSL if you have the private
| key, so presumably this is referring only to incoming SSL connections.
Well, yes, that was my point:  Even if you somehow convince yourself that
SSL
provides non-repudation "since the encrypted communication is between client
and application", an appliance like this must have access to the server's
key,
and by its very nature, is watching the entire transaction.  How can anyone
ever prove that a message came from the server when the appliance was in a
position to create exactly the same message?  If it's "non-repudiation" of
what the client sent, how does it matter whether there's a proxy in the
picture?  (Not to mention how few clients have certs to begin with.)

BTW, I got to this page from a Computerworld article about a system manager
who was up nights worrying that his whole security infrastructure ended up
providing a means for hackers to penetrate his system without him being
able to track them (because he couldn't see what they were doing inside
their
SSL sessions).  The Imperva appliance reassures him that they can no longer
hide.

I'll leave it to everyone on this list to try and come up with a reasonable
real-world binding of either (a) his fears; (b) the fix.

							-- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list