On 2014-10-19 at 04:08 +0000, Viktor Dukhovni wrote:
> On Sun, Oct 19, 2014 at 03:32:26AM +0000, Phil Pennock wrote:
>
> > On 2014-10-18 at 10:37 +0200, elrippo wrote:
> > > I am running exim on Ubuntu 12.04 LTS
> > >
> > > If i define "tls_require_ciphers = NORMAL:!VERS-SSL3.0"
> > >
> > > i get an error in the log and the messages are not handled...
> > > "2014-10-18 10:07:55 TLS error on connection from (user) [151.236.xxx.xxx] (gnutls_handshake): No supported cipher suites have been found."
> > >
> > > Can you advise please?
> >
> > That client only supports SSL and doesn't support TLS?
>
> More likely the syntax is subtly wrong, the user disabled all SSLv3
> ciphers instead of disabling the SSLv3 protocol with its sub-optimal
> use of CBC padding.
When recent Exim is built against GnuTLS, Exim's `tls_require_ciphers`
option is interpreted as a GnuTLS Priority String, as documented at
<
http://gnutls.org/manual/html_node/Priority-Strings.html>; the VERS-*
values disable protocol versions. The syntax is correct, it was taken
from our exim-announce announcement.
> The best advise for most SMTP server operators with respect to
> "POODLE" is "do nothing". Even if you don't make any mistakes,
> there is little to be gained by disabling SSLv3.
>
> This is an HTTPS problem, to be addressed by web browsers and
> web server operators.
I encourage you to read:
<
https://lists.exim.org/lurker/message/20141017.093614.e5c38176.en.html>
While technically true that it's an HTTPS problem, when Tony and I
discussed the announcement which Tony was drafting, I put forward the
view that the TLS library maintainers are likely to treat this as a good
point to _finally_ start dropping support for SSL3.0; when HTTPS stops
using it, it will certainly become less well tested as time passes and
support rots, even if the library keeps it around.
Even if SSL3.0 lasts in libraries for a few years, compliance audits
will start dinging its use and folks who need to pass audits will have
to disable SSL3.0; those sorts of audits are checkbox affairs and
there's not much room for saying "it doesn't affect this application
protocol", particularly since you have to actually say "yeah, it's old
and buggy and difficult to use securely, but the final straw for HTTP
doesn't affect SMTP or IMAP, so we only have to worry about these other
issues here, none of which were bad enough to force dropping support for
SSL3.0".
People who want to _not_ be spending their time always reacting to
fire-drills plan ahead; the way to be ready for SSL3.0 being dropped by
the libraries or blocked by audits is to start identifying connections
which require SSL3.0 now, and working with affected parties within their
organisation to find ways out which will continue to work. Sometimes
that will be software updates, sometimes it will come down to "well, you
can keep using that unsupported client, but when we have to stop
supporting the best security your client supports, you'll find out how
bad 'unsupported' really is".
Thus our stance is, as Tony wrote:
You should probably try to identify problems before you have no
back-out strategy, by working to eliminate those clients and servers
which do not support TLS. Exim logs cipher suite details by default,
so you can check the size of the problem at your site by scanning
your logs for the string " X=SSL".
Really, it's time for SSL3.0 to die. Let's all get onto a protocol
which supports extensions such as SNI, SHA-2 checksums and all the other
cryptographic fixes which have been made in the past 15 years. If HTTPS
being unable to use SSL3.0 kills SSL3.0 then good riddance, let's not
try to keep it around for SMTP's sake.
-Phil
