On Wed, Nov 07, 2018 at 08:52:26AM -0800, pg...@dev-mail.net wrote:
> Re: this particular, *internal* connection,
>
> Nov 4 15:21:45 mx postfix/postscreen-internal/smtpd[15675]:
> Anonymous TLS connection established from mx.example.com[XX.XX.XX.XX]:
> TLSv1.3 with cipher TLS_AES_256_GCM_SHA
Viktor
On Wed, Nov 7, 2018, at 8:34 AM, Viktor Dukhovni wrote:
> ...
Thx for the clarifications!
> That's TLS 1.3, which as I mentioned is a different beast. It
> always does PFS, and never RSA key exchange, but this is not reflected
> in the cipher name, because the ciphers no longer specify t
On Wed, Nov 07, 2018 at 08:07:40AM -0800, pg...@dev-mail.net wrote:
> On Wed, Nov 7, 2018, at 12:03 AM, Viktor Dukhovni wrote:
> > Check your logs for evidence of TLS <= 1.2 ciphers
>
> Doing the quick check you mentioned, first for my messy 'test' server,
> results are just
>
> 11 TLS_AE
Viktor,
On Wed, Nov 7, 2018, at 12:03 AM, Viktor Dukhovni wrote:
> Check your logs for evidence of TLS <= 1.2 ciphers
Doing the quick check you mentioned, first for my messy 'test' server, results
are just
11 TLS_AES_256_GCM_SHA384
Those log messages, for me, are all generated on inter
> On Nov 5, 2018, at 10:18 PM, Alice Wonder wrote:
>
> if not using keyUsage but using extendedKeyUsage within req_extensions should
> digitalSignature be used?
>
> I basically do the following for my postfix certs
>
> [req]
> distinguished_name = dn
> req_extensions = ext
> pro
On 11/05/2018 06:58 PM, Viktor Dukhovni wrote:
I've recently come across an interoperability problem between my
DANE survey scan engine and some STARTTLS implementations on remote
SMTP servers. The issue resulted from an upgrade of the TLS library
(not OpenSSL, which does not seem to mind) on m
I've recently come across an interoperability problem between my
DANE survey scan engine and some STARTTLS implementations on remote
SMTP servers. The issue resulted from an upgrade of the TLS library
(not OpenSSL, which does not seem to mind) on my side, which introduced
more strict checking of
