> 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
