> The vulnerable zlib 1.1.3 code can be even found on the freeswan > 1.95 source tree and previous versions, therefore there's a > potential vulnerability at kernel level; besides at the web site > http://www.freeswan.org the problem is not properly treated. From the developers @ freeswan: <snip> It is not of great importance to VPN applications, since compressed packets don't get fed to zlib until they've passed authentication. It's a little more serious for opportunistic encryption, where the tunnel doesn't imply trust... but our experimental OE setup currently isn't proposing or accepting compression. </snip> Zlib apparently is not called into play unless the "compress=yes" option is turned on. This feature could be individual to each tunnel or globally set for all tunnels. default = no. Additionally in order for zlib to even be accessed you have to authenticate an IPsec session. FYI, "opportunistic encryption" means using DNS to accomplish IPsec gateways without hard-coding ipsec setup information into some configuration file. It's currently still very experimental and thus not used in any production environments. Hope that helps, Peter
This archive was generated by hypermail 2b30 : Fri Mar 15 2002 - 11:33:06 PST