On 20.05.2014 15:11, Colin Fowler wrote: > Thank you Viktor for your reply! > > On 20-05-2014 13:44, Viktor Dukhovni wrote: >> On Tue, May 20, 2014 at 02:25:49PM +0200, Thomas Leuxner wrote: >> >>> In any case you miserably failed to elaborate how to mitigate >>> the issue other than stating 'revert the change'. >> >> Without defending the tone of that advice, I'd like to affirm its >> technical content. Receiving MTAs should not disable SSLv3, they >> gain nothing by doing so, all that happens is that clients that >> are only capable of SSLv3 are forced to send in the clear. >> >> Even sending MTAs should not disable SSLv3, since it is possible >> and normal to send all relevant TLSv1 and later extensions in SSLv3 >> HELLO messages (provided the client also offers to negotiate >> TLSv1 or greater), they just get ignored by SSLv3-only servers. >> >> Opportunistic TLS is sometimes counter-intuitive, attempting to >> make it stronger by removing weaker features actually makes it >> weaker. Don't give in to the urge to tweak TLS settings, they >> are largely fine as they are. >> > > Is it not true though that allowing weak features merely gives the > illusion of security? > It could be argued that a weak method is technically no better than no > encryption so removing the weak method just removes the illusion (which > some would say was a gain).
Opportunistic Encryption as performed by SMTP is merely a band-aid. It doesn’t claim to be actually secure, but it claims to do its best -- and sometimes the best you can get is to do anonymous DH, which at least protects you against a passive eavesdropper (although an active attacker will be able to spoof the connection). Disabling ADH would make that connection drop back to plaintext, which is worse because it cannot even protect against a passive eavesdropper. As said elsewhere, without DANE+DNSSEC, this is the best we can get right now. regards, Jonas
