Re: Hardened OpenSSL fork
Here's a good catch I think:
http://freshbsd.org/commit/openbsd/b6c83fa20a2269dadd0a9a73049813c75c2bcbbb
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS disables a workaround for the
weakness described in https://www.openssl.org/~bodo/tls-cbc.txt which, I
think, was exploited by the BEAST attack ~9 years later.
Much software in Debian can be seen to use SSL_OP_ALL, which includes
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS which could disable that mitigation.
This has been addressed in some Debian packages already, typically with
&= (~SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS):
https://security-tracker.debian.org/tracker/CVE-2011-3389
But it looks like some packages have perhaps not addressed this yet?
>From http://codesearch.debian.net/search?q=SSL_OP_ALL :
neon27
nmap
ruby1.8, ruby2.0 (possibly?)
freerdp (perhaps necessary for compatiblity with some Windows versions?)
cyrus-imapd-2.4
links2
w3m
apache2 (mod_ssl)
nginx
stud
postfix
...and many more.
I wonder if a bug filing is sensible or if I missed something obvious.
I'd like to establish exactly which SSL/TLS implementations are known to
be incompatible with this workaround; I saw MSIE 6.0 mentioned
somewhere. AIUI if using TLS >=1.1 this is already mitigated.
Breaking compatibility with Windows XP or MSIE 6.0 should be
increasingly viable nowadays, if it improves security for the rest of us.
Regards,
--
Steven Chamberlain
steven@pyro.eu.org
Reply to: