RE: Encrypted sessions

["Bob Walder" <bwalder () nss co uk>]

In order for any device to perform decryption it needs the private key of
the end-point. If an organisation uses end-to-end (i.e. user to user)
encryption, Snort would require access to EVERY private key of EVERY user in
the organisation.

The whole point of a PRIVATE key is hinted at by its name..... it's PRIVATE.
Once a user loses control of his private key, even to a supposedly "trusted"
third party, then there is no longer a case for non-repudiation - only by
keeping private keys private does the PKI model work.

No private key - no in-line decrypt. Sorry - you cannot have your cake and
eat it in this case. The only way around this is to employ perimeter tunnel
termination devices to that data is decrypted at the edge of the network and
travels in clear text over the private LAN. Then Snort can have at it.

Regards,

Bob


> -----Original Message-----
> From: snort-users-admin () lists sourceforge net
> [mailto:snort-users-admin () lists sourceforge net]On Behalf Of
> Erek Adams
> Sent: 28 November 2001 06:57
> To: Abe L. Getchell
> Cc: 'Ronneil Camara'; snort-users () lists sourceforge net;
> snort-devel () lists sourceforge net
> Subject: RE: [Snort-users] Encrypted sessions
>
>
> On Wed, 28 Nov 2001, Abe L. Getchell wrote:
>
> [...snip...]
>
> > What I would love to see is a crypto feature built into
> Snort much like
> > has been built into tcpdump (compiled using './configure
> --with-crypto'
> > and used at run-time using 'tcpdump -E <stuff>'), with a little more
> > flexibility (more algorithm options, better support for the
> ESP RFC's,
> > etc).  If the correct key or passphrase is known, it could
> be provided
> > to Snort at run-time, traffic could be decrypted on the fly by a
> > preprocessor, and the clear text data checked against the
> rule set being
> > used.
>
> That would indeed be a kick ass pre/post processor to have!
>
> > The one major drawback I see to this approach is the possibility of
> > processor saturation.  A Snort box in a high-traffic
> environment already
> > has it's hands full checking packets against the large
> number of sigs
> > common in networks such as these.  Chances are, it wouldn't
> have many
> > free proc cycles to perform such a processor intensive task as
> > decrypting data.  This feature would thus only be useful in a
> > low-traffic environment without introducing a packet loss problem.
>
> Hrm...  This brings to mind something--Sun and IBM are both
> sporting Crypto
> Accelerator cards.  Intel (and 3com?) now have a crypto chip
> built into some
> ethernet cards...  With the benefit of those two bits of
> hardware, I wonder
> how much saturation you would get?  If the key/algorithm is
> known, and can
> have a decoder built for it, it should scream!  And no, I'm
> not a Crypto
> Monkey, nor do I play one on T.V.  :)
>
> -----
> Erek Adams
> Nifty-Type-Guy
> TheAdamsFamily.Net
>
>
> _______________________________________________
> Snort-users mailing list
> Snort-users () lists sourceforge net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users



_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users