On 06 Aug 2015, at 21:44, Michael Ströder <mich...@stroeder.com> wrote:
>>> simply look whether their system uses STARTTLS or not and won't check >>> which particular ciphers are used. IMO it might be a good learning effect >>> for >>> them if you disable STARTTLS for them. >> >> This is wrong. RC4 is not worse than cleartext. We'll disable >> RC4, once doing so almost never causes downgrades to cleartext. > > Yes, that's your opinion on that. > > But my opinion is that forcing clear-text might make admins wake up. > The point is that many people simply look at whether STARTTLS was used or not, > and not at the protocol and cipher details. > > Frankly I also consider your enquiry about statistics on RC4 usage to be > pretty much useless. > >> I posted best-practice settings, that protect as much traffic as >> possible, to the extent possible. > > ...at the risk that admins justify everything's ok forever because STARTTLS > was used. Except that those who deliberately keep using legacy software because they consider it 'safe enough', despite the general consensus on it, are a very small minority. For most systems, monitoring the status of their encryption just isn't done at all; they use the defaults their device or server came with at the time they purchased it, and rarely keep up with the times. Their transport encryption profile changes when they replace the legacy system, and the settings in the new server take over. Which are usually, again, the defaults the device ships with. Why does the Exchange 2003 problem disappear? Because the organisation has moved to a newer version of Exchange on a newer version of Windows Server. Also, unlike HTTPS, there is no way to surface the usage of bad settings to the user and raise awareness that way, because the user (employee or customer) has no real visibility into the state of transport encryption between MTAs. There is generally very little they can leverage to force change, even if they wanted to. Add to that the general level of misunderstanding when it comes to the workings of STARTTLS, and how it is NOT like HTTPS, misunderstandings about transport encryption in general, budget constraints, time constraints, and so on, and there's rarely enough leverage to actually force change. I say this as someone who takes a very proactive stance on this, for STARTTLS, HTTPS and other forms of transport encryption. Naming and shaming in public, if necessary. As a company, we have a great many conversations about this with a wide variety of organisations. We have special introductory fixed price audit rates for cases where just tuning the defaults will already improve their security profile by a lot. We have implemented fairly strict minimum requirements with a 'or else' deadline for clients we relay mail for. We blacklist without hesitation if a sender presents an actual security risk to our customers. And you know what? In the majority of cases, we LOSE. We've had customers go elsewhere when we enacted the 'or else' minimum requirements (with a reasonable grace period) because the responsible administrator does not want to be told that their stuff is broken, and out of date. Or a problem remains because they don't dare touch a legacy configuration, because they misunderstand how it actually works, despite our assurances that it will be OK. Or because they are not in direct control, and whoever is refuses to accept the evidence presented. Looking at you, MailGun dropping down to plain text because 'self-signed certificates are insecure'. In other words, you gain NOTHING by dropping RC4 connections down to plain text, at this point. It makes you, as a delivery destination, less secure. You're punishing the end user out of some misplaced sense of righteousness, doing disservice to both them and the recipients you are responsible for. The only reason to disable old ciphers still in use for MTA-to-MTA traffic is if leaving them enabled makes your systems vulnerable. In all other cases, fallback to plain text is worse. Mvg, Joni
