[VPN] Application timeouts over VPN...HELP!

James McNeill james at heague.com.au
Thu Apr 10 02:19:43 EDT 2003


The more traffic that is exposed with the same key, the easier it will be to
crypto-analise and discover bad random number generating patterns. For any
secuerly implemented encryption protocol, this should not be a problem. In
most cases you either crack the encryption or you don't. Doesn't matter how
much stuff you have to decrypt.

as for TCP sessions, since the keys and algorithms will all be the same
between sessions, it won't have any effect on security. anyone capable of
attacking your VPN tunnel won't care what you do with your TCP sessions. as
far as your attacker is concerend, a TCP session is just a number in the
header, but so long as it uses the same tunnel, he won't care. It's the
contents of the packet that is valuable.

having abnormally long/short TCP sessions is bad practice, and likely to
cause more problems than it's worth.

-James

|
| Ryan Malayter wrote:
| > From: Alex Pankratov [mailto:alex at cipherica.com]
| >
| >>can you explain why *exactly* it's
| >>a "bad security" ? Especially given
| >>that the TCP connection in question
| >>is IPsec'ed in first place.
| >
| > If the tunnel is left open, and the engineer's workstation is online and
| > idle, the workstation becomes a vector for compromising the security of
| > the encrypted traffic.
|
| That's not what I asked about. The question was how keeping *TCP
| sessions* open reduces overall VPN security. Let me rephrase it -
| which attacks mountable against VPNs would have a lesser chances of
| succeeding if all TCP connections are short-lived ?
|
| > [bunch of unrelated to TCP question stuff snipped]
|
| _______________________________________________
| VPN mailing list
| VPN at lists.shmoo.com
| http://lists.shmoo.com/mailman/listinfo/vpn
|
|




More information about the VPN mailing list