RE: Encrypted sessions

["Abe L. Getchell" <abegetchell () home com>]

Hi Bob,

> 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.

I didn't mean to imply that this type of feature would be practical for
use in this kind of scenario, that being user-to-user encryption, I
meant for this feature to be geared towards IPSec tunnel monitoring
where the private keys on either end remain static.  For instance,
site-to-site VPN's where putting a sensor behind the perimeter device
doing the encrypting and decrypting is impractical or impossible.  After
going back and reading my e-mail when it's not 1:00am, I can see that I
didn't make this clear.

> 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.

I never said it would _enhance_ the security of a PKI, I said it was 'a
feature I would love to see'. =)  Besides, there's always a risk when
implementing a security device that performs traffic monitoring and
recording whether working with private keys or not.  For example, If
you're performing post-processing of data captured off of the wire, you
better be _very_ worried about how securely those all-inclusive packet
dumps are stored.  Having this data compromised, and allowing access to
unfiltered internal network traffic could be just as (if not more)
devastating than an intruder getting a hold of a private key.  My point
is, we're probably already keep data that is just as, if not more,
sensitive than private keys on our IDS's.  We should take the same
precautions to protect this data as we would if a private key were
housed there as well.

That being said, having a private key stored somewhere besides where the
user has sole control of it is a bad thing, and it makes the IDS a much
higher value target, it's necessary for the engineer implementing the
system to decide whether or not the risk is worth it.  Depending on how
you classify the sensitivity of the traffic you'll be decrypting (and
hence keeping a copy of the private key on the IDS) the risk may be
acceptable.

> 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.

Again, the concept I presented in my previous post was aimed at giving
Snort the ability to monitor device-to-device IPSec tunnels where keys
remain static, not user-to-user encryption which would require access to
a large number of keys.  Sorry I didn't clarify this.

Thanks,
Abe

--
Abe L. Getchell
Security Engineer
abegetchell () home com


_______________________________________________
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