As the initiator of https://starttls.info/ (developed and run by Einar Otto Stangvik), let me just say that I've e-mailed this list earlier on this topic.
While Viktor shows very clearly why starttls by itself is insufficient through his IETF draft, I still personally vote for disabling SSLv2 and ANON ciphers used with STARTTLS as we do today. My reasoning is simple: if we continue to support old & insecure ciphers etc, there is less incentive for moving forward to safer solutions. We did discuss and change the scoring soon after the service launched, while originally being based on the scoring system from Ivan Ristic @ Qualys at ssllabs.com for https. Yes, perhaps stupid, but it seemed better than creating our own scoring system. On May 13 Facebook published "The Current State of SMTP STARTTLS Deployment" https://www.facebook.com/notes/protect-the-graph/the-current-state-of-smtp-starttls-deployment/1453015901605223 Allow me to quote them: "The majority of encrypted email is sent with the ECDHE-RSA-RC4-SHA or DHE-RSA-AES256-SHA cipher suite. This is likely due to those being the preferred cipher suites of the major providers. DHE-RSA-AES128-SHA, however, is the preferred cipher suite for the largest percentage of deployments. AES128-SHA is the next most prevalent, which is concerning because it does not provide Perfect Forward Secrecy." Facebook are concerned over the lack of PFS. Right. Well, we started out by saying we were concerned over SSLv2, ANON suites and expired certificates. One of our goals with starttls.info was to aid in the global deployment of STARTTLS, another goal was to improve the minimum level used by anyone deploying STARTTLS. That is until Viktors IETF proposal, or anything similar, reaches broad adoption on the Internet. Best regards, Per Thorsheim Den 20.05.2014 15:35, skrev Colin Fowler: > Thank you Viktor (and other commenters) > > One of the primary reasons I use {ostfix is because of its great > track record in security (its stability, performance and feature set > are also great too). It would be foolish of me to disregard the devs > who have achieved helped give Postfix its recommendation. I'll stick > with excluding EXPORT and LOW as you mentioned earlier. > > BTW, this whole thing came about from me testing using > https://starttls.info/ which scored what I thought was a well secured > server quite badly. I see now that the testing site is itself the > problem, not my original config. > > thanks again, Colin > > > > On 20-05-2014 14:25, Viktor Dukhovni wrote: >> On Tue, May 20, 2014 at 02:11:34PM +0100, Colin Fowler wrote: >> >>>> 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? >> >> Opportunistic TLS, is only secure against passive attacks. >> Against passive attackers, any encryption, even weak is better than >> no encryption. This applies even more strongly to authentication >> or lack thereof. Authentication adds no protection against >> passive attacks, once you've negotiated ephemeral keys (ideally >> with PFS, see http://www.postfix.org/FORWARD_SECRECY_README.html) >> you're set. >> >>> 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). >> >> All kinds of misguided points of view could be argued. :-) >> >>>> Most other "hardening" configuration changes are likely to >>>> reduce, rather than improve SMTP transport security. >>> >>> I've heard anecdotes of clients not using the best mutually >>> supported encryption and instead just using whatever's first in >>> the list of methods accepted by the server. I don't have anything >>> to back this up though. Ever heard of this? If this was true, >>> then disabling weak methods might be beneficial. >> >> This is not how TLS works, the client sends a list of >> cipher-suites, and the server chooses exactly one of these. >> Depending on server configuration, this is either the client's most >> preferred cipher also supported by the server or else the server's >> most preferred cipher supported by the client. >> >> Grossly misconfigured clients or servers might choose weak >> cipher-suites, but I've never seen this happen in practice. >> >> If you disable EXPORT and LOW, the rest are substantially better >> than cleartext even with the recent statistical anomalies in the >> first 256 bytes of RC4 output. Forcing the client to use >> cleartext is not a better option. However, one might want to use >> the server's cipher preferences on the submission port: >> >> submission inet ... smtpd -o tls_preempt_cipherlist=yes ... >> >> where it is unlikely to run into friction with remote Exchange >> 2003 servers (unless you're hosting remote Exchange MTAs as >> submission clients). >
