Re: [mailop] Blog: Logjam, Openssl and Email Deliverability
On 2015-06-24 at 14:06 -0700, Carl Byington wrote: > Does Exim (immediately or delayed) retry that connection and > (temporarily or permanently) ignore the offer of STARTTLS? Depends upon the configuration. Assuming defaults, "yes". http://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html See under "9. Configuring an Exim client to use TLS" 8< cut here >8-- When the server host is not in hosts_require_tls, Exim may try to deliver the message unencrypted. It always does this if the response to STARTTLS is a 5xx code. For a temporary error code, or for a failure to negotiate a TLS session after a success response code, what happens is controlled by the tls_tempfail_tryclear option of the smtp transport. If it is false, delivery to this host is deferred, and other hosts (if available) are tried. If it is true, Exim attempts to deliver unencrypted after a 4xx response to STARTTLS, and if STARTTLS is accepted, but the subsequent TLS negotiation fails, Exim closes the current connection (because it is in an unknown state), opens a new one to the same host, and then tries the delivery unencrypted. 8< cut here >8-- The default setting of `tls_tempfail_tryclear` is `true`. > What is the "correct" behavior in this case? The recipient is offering > an encrypted channel that we cannot (well, will not) use. RFC 7435 "Opportunistic Security: Some Protection Most of the Time" Section 4, "Example: Opportunistic TLS in SMTP": 8< cut here >8-- Various MTAs that advertise STARTTLS exhibit interoperability problems in their implementations. As a work-around, it is common for a client MTA to fall back to cleartext when the TLS handshake fails, or when TLS fails during message transmission. This is a reasonable trade-off, since STARTTLS only protects against passive attacks. In the absence of an active attack, TLS failures are generally one of the known interoperability problems. 8< cut here >8-- If you want remote servers to refuse to downgrade to cleartext when talking to you, DANE is the way to go. See also: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ FWIW, I think it's reasonable to use a TLSA RRset in insecure DNS as a signal to not fall back to cleartext. I think that I talked about it with Viktor and he had some good reason to not do that. I'm not going to dig into this further tonight. If you want TLS for MX delivery, you really should be looking at DNSSEC/TLSA for DANE. I don't recall what Exim's 4.86 release will be doing in terms of fallback to plaintext given DANE, but it's the first DANE release so there may well be Issues. Postfix's DANE support is more mature at this time (unsurprising, since Viktor works on that). -Phil ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to A record if MX exists ?
Hi Kurt, At 01:16 17-06-2015, Kurt Jaeger wrote: 5.1. Locating the Target Host can be read that MX records have preference, but it explizitly avoids mentioning "A or " records if no MX is found. The sentence: [...] If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host. [...] implies a A/ DNS query, but does not explicitly state so. That section explains how to locate the target host. The section also has the following: 'the "implicit MX" rule above applies only if there are no MX records present' Regards, -sm ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Blog: Logjam, Openssl and Email Deliverability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 2015-06-25 at 00:09 +0100, Brandon Long wrote: > Not in front of a computer to check if we see failures like this, but > we (google) stopped falling back to unencrypted connections >2y ago. > This had an impact on a small number of misconfigured sites. Does google have strength limits on the DH key size like openssl. In particular, will gmail deliver to a server with a 512 bit DH key? I no longer have access to such a machine for testing since we upgraded all the DH keys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAlWLPLcACgkQL6j7milTFsFCYACfW0QzJWqUmBo2DFiA2d41JqR9 7s4AnjcqVr+/f9MTiSunE5u0sS2ugB4r =b5os -END PGP SIGNATURE- ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Blog: Logjam, Openssl and Email Deliverability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 2015-06-23 at 20:16 +, Phil Pennock wrote: > A key issue though is that by default, Exim will fall back to > unencrypted because encryption to MX is opportunistic. Sendmail as a client sends EHLO, receives an offer of STARTTLS, sends STARTTLS command and uses openssl to switch to an encrypted connection. When openssl fails the handshake, sendmail just temp fails 403 the attempt and requeues the mail. In particular, sendmail does not immediately retry without STARTTLS, leading to an eventual delivery failure - by default 5 days later. Does Exim (immediately or delayed) retry that connection and (temporarily or permanently) ignore the offer of STARTTLS? Does anyone know the behavior of Postfix or other software in this circumstance? What is the "correct" behavior in this case? The recipient is offering an encrypted channel that we cannot (well, will not) use. If everyone backs off and sends plain text, the recipient will never realize that they should upgrade their DH parameters. We can easily write a script to tail the log files and automatically add "Try_TLS:server NO" entries to /etc/mail/access. But should we? Given how widespread Redhat EL5/6/7 servers are, the inability of RHEL6/7 to send mail to RHEL5 servers that have enabled TLS is surprising. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAlWLG9sACgkQL6j7milTFsGErQCfYEAlCh+rhjIVYBz9iw/hzsgU OloAmwUZ/9HOrLdNyXDVOxOXBa78jnAg =6NjB -END PGP SIGNATURE- ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Blog: Logjam, Openssl and Email Deliverability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 2015-06-23 at 12:27 -0500, Frank Bulk wrote: > Is there a public list of such weak domains/MXes? Well, I have a few from grepping my logs: mail.ritz.edu hawk.dcu.ie inbound30.exchangedefender.com smtp.raymondcorp.com smtp1.raymondcorp.com smtp2.raymondcorp.com mail.axs2000.net and on 213.199.154.87 I have seen "reject=403 4.7.0 TLS handshake failed", followed 30 minutes later by a successful delivery. There are possibly multiple machines behind some load balancer, and some of them may have week keys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAlWLF54ACgkQL6j7milTFsFHpgCfUs+19GXG078z3FMTy9H1EcJM OVUAnjKv2FiKJ3Bn66i1vxdKz16BojCW =I3+t -END PGP SIGNATURE- ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
