On 9/24/2013 2:28 AM, Reindl Harald wrote: > maybe on your server, my logs showing the opposite and since > the "smtp" are outgoing messages your conclusion of "nobody" > is strange > > cat maillog | grep smtp | grep -v smtpd | grep TLS | wc -l > 12327 > > cat maillog | grep smtpd | grep TLS | wc -l > 13350 > > cat maillog | grep smtp | grep -v smtpd | grep TLSv1.2 | wc -l > 2603 > > cat maillog | grep smtpd | grep TLSv1.2 | wc -l > 2219
This doesn't necessarily mean the encryption is effective at cloaking the data exchange. Remember: 1) Most admins who use TLS on their MTAs don't reject the transaction of the presented certificates FAIL to be validated against your local trust store's certificates. Unlike the error dialog boxes presented to the end user when a certificate fails to validate against its local trust store, these "error fallbacks" are "silent" and to most users, completely invisible. (Yes, I know most MTAs will log a TLS certificate failure in the headers, but we're talking about Lusers here, not readers of this list.) Failing certificate validity means it could be ANYONE's key/cert used to setup the ephemeral connection, and you can place no reliance on that channel being opaque to third-party scrutiny. 2) Even if you DO reject all failing certifcate trust-stores (on *ALL* MX hosts that receive/send mail), it's increasingly likely that one or more of those root certificates are compromised, either publicly(*) or secretly though some back-door arrangement with the NSA. The Big Ugly elephant in the room is the notion of the NSA having a certificate signing key for VeriSlime/GeoBust/et al so that they're free to use their own key + cert in a MITM interception, with the end user being none the wiser(**). Take a tally of the jurisdictions of the big root-level CAs. It's alarmingly AUSCANNZUKUS-centric. 3) Even with all of the above dealt with, the rush for people to use Diffie-Hellman "PFS" based on elliptic curves (EC) may be itself subject to additional problems based on revelations and leaks that suggest the NSA has been busy subverting various standards and publicly designed software reference implementations to weaken its security in ways to benefit them. In particular, Schneier and Bernstein feel very uneasy about the NIST specified parametres for the EC-based cryptographic algorithms. These aren't "tin foil hatters" or kooks. To that end, there are proposals to adopt elliptic-curve parametres and methods that each and every generated public key maps to a valid EC point. See: https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929 http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4x3.pdf http://cr.yp.to/ecdh/curve25519-20060209.pdf An Ivory Tower organisation with total control over the clients' and the servers' configurations can pin all of its certs + keys, and configure them to dump connections that fail to validate local trust stores. This is an unfortunately very subtle and nuanced problem that defies mere "throwing more bits" at your key sizes. And I would hope that the IQ and worldly mindsets of those generally reading this list have an appreciation for why retaining complete control and privilege within your organisation's end-to-end security is important, now more than ever. It has nothing to do with "I'm not doing anything wrong, so they can read all they want." For an ISP or other provider with a "random" and "noisy" userbase with who-knows-what clients + OS/platform brain damage, the problem is probably intractable unless you accept that some users will be simply unable to access the services from some or all of their devices. =R= (*) Despite many compromised CAs (Certificate Authorities) being known publicly, I discover an annoying large number of improperly configured systems who accept these as valid. Maybe there are/were distros who incorrectly compiled lists of CAs and didn't remove those compromised CAs from the trust-store. Maybe they're out of date. Who knows why. (**) If you "pin" various trust store certificates + keys, you can detect this when it occurs. See: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
