> 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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]