From: Earl C. <ear...@ya...> - 2012-09-03 21:43:47
|
Matthias, > The question I am asking myself is: What use is there in supporting > "older implementations" (meaning before 0.9.8m)? How many systems are > affected (and I would tend to ignore enterprise distributions - they > ought to patch OpenSSL instead). I suppose those older implementations > would likely also be vulnerable to several other attacks, which might > subvert the effort of closing this (minor) hole. Yes, a reasonable question to ask. I think that there are two separate considerations: a. The absence/presence of SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS b. The absence/presence of SSL_CTX_clear_options() My reading is that (a) is the key to closing the vulnerability. The availability of SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS indicates that the vulnerability is closed and it is important that SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is _not_ set in this scenario (except when overridden by FETCHMAIL_DISABLE_CBC_IV_COUNTERMEASURE). There are two obvious ways to achieve this. One way is to simply clear the bit in SSL_OP_ALL, and for prior art, I refer you to: http://www.opensource.apple.com/source/curl/curl-69.1/patches/curl-dont-insert-empty-fragments.patch This brings me to (b) which use SSL_CTX_clear_options() as an alternate way to manipulate the options. But as the prior art shows, it is entirely unnecessary in this scenario to use this new function. > I suppose those older implementations > would likely also be vulnerable to several other attacks, which might > subvert the effort of closing this (minor) hole. As I described above, the whole question of using SSL_CTX_clear_options() is a separate one from the ability to close down the vulnerability. The patch I submitted keeps the vulnerability closed, but does not require SSL_CTX_clear_options(). As you have probably figured out, one of the OpenSSL installations that I have (1.0.0-0.10.beta3.fc12) supports SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS but does not support SSL_CTX_clear_options(). Earl |