Re: Not Quite [WAS] Re: Very scary!

[Ravi <ravi@xxxxxxxxxxx>]

Hallo:

On Wed, 20 Dec 2000 at 22:21, Prabhu Ramachandran <prabhu@xxxxxxxxxxxxxxxxxx> chittered thus:

	
-> Well, thanks for the info, but it still reminds us that the
-> man-in-the-middle attacks are possible with smart enough crackers.  I

	I continue to maintain: "As long as there are clueless users and admins, fool enough to not follow basic security precautions, when administering a large enough website...there will remain a community of h4x0rs, smart or not, using psychological tools (Mitnick?) or being just lame script kiddies...who will bust the lusers' happiness" ...

-> thought all public key systems are liable to such attacks.  IIRC even

	Yeah, I guess all public key systems are liable to such attacks.
	But I'm only guessing....

-> IPSec is liable to man-in-the-middle attacks.  Any ideas on how
-> easy/difficult it is to do this kind of stuff??  Or is there some kind
-> of manual key exchange that is necessary - like PGP key signing etc.??

	Not sure about this. http://www.netbsd.org/Documentation/network/ipsec/ is a nice document to begin with. They say, you're pretty much safe, as long as you keep changing your key, and obviously securely, and keep it secret at all costs.

	In particular, they speak of IPSec itself being a collection of sub-protocols which include:

a)	Authentication Header (AH) -> It covers the IP Header to end of packet - that is, the *entire packet* and it comes with a strong crypto checksum, wherein, if you're sure that the key is safe, you can be sure, a) it originated from where you think it originated b) it did _not_ get modified in transit

b)	Encapsulating Security Payload (ESP) -> Ensures that there are no MITM attacks, again, under the presumtion that the key is safe.

c)	IP Payload Compression (IPComp) -> ESP prevents successful compression, whereas IPComp is going to let you compress stuff, before ESP happens.

d)	Internet Key Exchange (IKE) -> If the 2 hosts are far apart, this provides a *secure* (The page does not say how) way of transferring keys across. Also, while the first three are at the kernel-level, IKE is at the userland level, running as a daemon, in conjunction with a kettable inbetween the Kernel <-> Userland

	The irony of this all, is that Bruce Schneier, and his team at Counterpane think that (http://www.counterpane.com/ipsec.html) it is too complex to be correctly implemented, and may be relatively thus easily broken into. So whats the need to protect your keys if some guy is going to _anyway_ break your encryption?! Heh!

	Oh, and Prabhu, there's a ton of docs, posted even at USENIX conferences, that are available online. Check them out -- They make interesting reading for a lazy sunday afternoon ;)

	Cheers.

	-r.	
-- 
Ravikant K.Rao | ravi@xxxxxxxxxxx | ravi@xxxxxxxxxxx 
  3:46pm  up 5 days,  6:38,  4 users,  load average: 0.39, 0.30, 0.23
If you learn one useless thing every day, in a single year you'll learn
365 useless things.
---
Visit our home page at: www.chennailug.org
Send e-mail to 'ilugc-request@xxxxxxxxxxxxxxxxxx' with 'unsubscribe' 
in either the subject or the body to unsubscribe from this list.