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 ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53602ab9.7050...@pyro.eu.org
