On Sat, Jun 21, 2014 at 12:21 PM, li...@rhsoft.net <li...@rhsoft.net> wrote: > > > Am 21.06.2014 13:11, schrieb Stefan Foerster: >> our current situation is as follows: >> >> 1. Public MX, very low incoming volume, "smtpd_tls_security_level = may" >> 2. Senders aren't known beforehand, i.e. no previous business relationship. >> 3. Senders' IT usually doesn't support DANE. >> 4. Incoming mail is considered highly(!) valuable to business. >> >> During a security audit, it was determined that the MX supported what >> the auditors called "weak" ciphers and protocols (SSLv3, TLSv1.0, >> RC4-MD5, anonymous ciphers and so on). The auditors demanded that we >> disable all those - not considering the fact that our Postifx _did_ >> assing a higher priority to "more secure" ciphers. >> >> Not surprisingly, a lot of sending systems failed back to plain text >> after we pushed the change to production. >> >> Could someone share experience with or point me to some kind of "best >> practices" regarding opportunistic TLS, or explain the reasoning for >> banning "weak" ciphers/protocols on a public MX? (again, not talking >> about a MSA, or a third party that we have ties with, which would allow >> us to nail down protocols/ciphers with TLS policy maps) > > fire the clueless auditor not in the position to demand anything while > lacking basics himself and not able to make a difference between > HTTP and SMTP - what such people not understand is that HTTPS > don't fall back to plaintext - SMTP does
Totally agree. Just like to add also, on a public MX, there is no human intervention to decide if transaction should go or not. One arguable issue is if we keep supporting weak ciphers, there is no incentive to people to upgrade. Right now I prefer weak ciphers to plaintext. So unless you have a critical data exchanged with some domains then you should go for end to end encryption or setup your postfix instances to only send and received with strong/strict ciphers. José Borges Ferreira
