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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
