On Tue, Jun 02, 2015 at 09:51:26PM +0300, T?r?k Edwin wrote: > On 06/02/2015 10:15 AM, Gilles Chehade wrote: > > Hi, > > > > The last snapshot switches from 1024-bits to 2048-bits DH parameters. > > > > We need as many people as possible to run with this to determine if this > > can make our upcoming release or if we need to at least provide a way to > > fallback to 1024-bits. > > > > Last time we tried, 4 years ago, we were having trouble exchanging mails > > with other hosts, we need to know if this is still true. > > > > If it turns out that we can't switch to 2048-bits just yet and you can't > > take risks, you can simply edit the smtpd makefile, and add -DUSE_DH1024 > > to revert to our previous behaviour. > > > > PLEASE REPORT BOTH SUCCESS AND FAILURES ! > > > > I'm running it, grepping for TLS shows this: > TLS started version=TLSv1/SSLv3 (SSLv3), cipher=DHE-RSA-CAMELLIA256-SHA, > bits=256 > TLS started version=TLSv1/SSLv3 (TLSv1.2), > cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128 > TLS started version=TLSv1/SSLv3 (TLSv1.2), > cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256 > > Also see some client certificate verification failures. > IIUC if TLS fails it'll just fall back to unencrypted connections, is there a > log message for that? >
Kind of. You will not see a fallback because there is no such thing as a fallback in TLS really, what we call fallback is a re-attempt to contact the same host but bypassing TLS when we know we failed earlier. When this happen with a client connecting to us, what you'll see is that a TLS session has failed (usually with "IO Error") and then the same one is establishing a new session without TLS. Same applies for the outgoing path when we fallback ourselves. -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
