On 10/16/14 06:19, Thijs Kinkhorst wrote:
On Wed, October 15, 2014 16:30, Henrik Langos wrote:
Here's the patch:
http://www.dovecot.org/pipermail/dovecot/2014-October/098244.html
There is also a statement that pop/imap might be harder/impossible to
exploit but I wouldn't buy that just yet:
http://www.dovecot.org/pipermail/dovecot/2014-October/098248.html
Thanks. But the patch does not make SSLv3 configurable, it just blocks it
in a hardcoded way. This may be acceptable to some, but I'm reluctant to
release this patch through the LTS security channel, because there's no
way to avoid any breakage by admins except for not installing the update.
Especially because, contrary to web browsers, we do not have a clear
picture of the state of SSL/TLS version support in mail clients out there,
so the impact is hard to measure.
Well, true. With that minimal patch, there's no way to configure it.
Hardcoding might not seem the elegant way but upstream disabled SSLv2
by hardcoding in dovecot 2.0 more than 4 years ago (I just looked at the
patch timestamps, not at the commit history.)
SSLv2 was only released one year before SSLv3. Following that (admittedly
crooked) logic it would have been OK to disable SSLv3 three years ago.
Even if you don't take the protocol's age but the availability of a
successor
as a measure (SSLv3 1996, TLSv1 1999), you still come up with the result
that SSLv3 would have been OK to disable a year ago. ;-)
I appreciate the thought given to compatibility with very very old clients.
But there's also the upgrade compatibility to consider.
Admins upgrading from oldstable (dovecot 1.2) to stable (dovecot 2.1.7)
will have to contend with the vast changes in configuration format already.
There's even a bug complaining about those "too frequent" changes in
configuration format.
IMHO introducing a configuration variable in 1.2 (lets say
"ssl_disable_sslv3"
defaulting to "no") that becomes meaningless in 2.1 will not help.
Dovecot 1.2 reacts very straight forward to unknown configuration
variables, by refusing to start:
> Starting IMAP/POP3 mail server: dovecotError: Error in configuration
file /etc/dovecot/dovecot.conf line 135: Unknown setting: ssl_disable_sslv3
I have no reason to belief that dovecot 2.1 will react differently.
The upgrade compatible way would therefore be to backport the
introduction of the "ssl_protocols" variable.
At the first glance that looks risky and like a lot of work.
Baseline is: You have to weigh the risk of breaking access for
some very very old clients against the risk of introducing new
code in an LTS release.
Are there Debian policies/guidelines for situations like this?
cheers
-henrik
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
