Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Hi Peter,
OpenSSL version 1.1.1 (RHEL8) and derivatives uses a different function
than OpenSSL 1.0.2 (RHEL7) to set connection ciphers. Before the patch,
the function in question for qmail-remote wasn't setting the connection
ciphers (tlsclientciphers) so it went to default from opensslcnf.conf,
the patched version will set connection ciphers correctly. I'm guessing
you won't need the settings in openssl.cnf anymore since the new
function is used and it sets the cipher list for the connection. It
would be interesting to revert openssl.cnf back to it's original
settings and test. If okay change the crypto policies to DEFAULT and see
what happens.
Let me know your findings if you go that way.
Eric
On 3/24/2022 2:18 PM, Peter Peltonen wrote:
Hi Eric,
I now installed the rpm from testing repo, restarted qmail and did three tests:
- emailed Gmail address, mail relayed through my qmail box: OK
- replied from Gmail to my qmail box: OK
- emailed hornet security: OK
What I have in qmail send log is:
Remote_host_said:_250_2.0.0_OK_accept_as_13208F02763:a113fcad4200a6e05349a9b2d4c38ecd_by_mx-gate19-hz2/
So far so good.
My other settings currently:
# update-crypto-policies --show
LEGACY
and in /etc/crypto-policies/back-ends/opensslcnf.config I have
CipherString = @SECLEVEL=1
Is LEGACY still fine ? And should I switch back to @SECLEVEL=2 ?
Best,
Peter
On Sat, Mar 19, 2022 at 6:40 PM Eric Broch wrote:
List,
qmail-1.03-3.3.6.qt.md.el8.x86_64.rpm is in the testing repo. This is
patched with updated loading of ciphers consistent with OpenSSL 1.1.1 on
RHEL8 (and 8 derivatives) both in mysql and mariadb trees (non md to come).
Here's the patch:
--- qmail-1.03-3.3.5/qmail-remote.c 2022-03-18 08:22:01.810701523 -0600
+++ qmail-1.03-3.3.5-new/qmail-remote.c 2022-03-18 13:48:22.951868716 -0600
@@ -426,16 +426,26 @@
}
}
- SSL_library_init();
- ctx = SSL_CTX_new(SSLv23_client_method());
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+ OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS,NULL); /* TLS 1.3 */
+ ctx = SSL_CTX_new(TLS_client_method());
+#else
+ SSL_library_init(); /* TLS < 1.3 */
+ ctx = SSL_CTX_new(SSLv23_client_method());
+#endif
if (!ctx) {
if (!smtps && !servercert) return 0;
smtptext.len = 0;
tls_quit_error("ZTLS error initializing ctx");
}
- /* POODLE vulnerability */
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+ SSL_CTX_set_options(ctx,SSL_OP_ALL);
+ SSL_CTX_set_min_proto_version(ctx,TLS1_VERSION);
+ SSL_CTX_set_max_proto_version(ctx,TLS1_3_VERSION);
+#else
SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
+#endif
if (servercert) {
if (!SSL_CTX_load_verify_locations(ctx, servercert, NULL)) {
@@ -476,7 +486,11 @@
ciphers = saciphers.s;
}
else ciphers = "DEFAULT";
- SSL_set_cipher_list(myssl, ciphers);
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+ SSL_set_ciphersuites(myssl,ciphers); /* TLS 1.3 */
+#else
+ SSL_set_cipher_list(myssl,ciphers); /* TLS < 1.3 */
+#endif
alloc_free(saciphers.s);
SSL_set_fd(myssl, smtpfd);
--- qmail-1.03-3.3.5/tls.c 2022-03-18 08:22:02.507741854 -0600
+++ qmail-1.03-3.3.5-new/tls.c 2022-03-18 14:02:17.001103857 -0600
@@ -14,7 +14,9 @@
{
int r = ERR_get_error();
if (!r) return NULL;
+#if OPENSSL_VERSION_NUMBER < 0x10101000L
SSL_load_error_strings();
+#endif
return ERR_error_string(r, NULL);
}
const char *ssl_error_str()
--- qmail-1.03-3.3.5/qmail-smtpd.c 2022-03-18 08:22:01.827702507 -0600
+++ qmail-1.03-3.3.5-new/qmail-smtpd.c 2022-03-18 14:41:30.512190971 -0600
@@ -1469,14 +1469,22 @@
X509_LOOKUP *lookup;
int session_id_context = 1; /* anything will do */
- SSL_library_init();
-
- /* a new SSL context with the bare minimum of options */
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+ OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS,NULL); /* TLS 1.3 */
+ ctx = SSL_CTX_new(TLS_server_method());
+#else
+ SSL_library_init(); /* TLS < 1.3 */
ctx = SSL_CTX_new(SSLv23_server_method());
+#endif
if (!ctx) { tls_err("unable to initialize ctx"); return; }
- /* POODLE vulnerability */
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+ SSL_CTX_set_options(ctx,SSL_OP_ALL);
+ SSL_CTX_set_min_proto_version(ctx,TLS1_VERSION);
+ SSL_CTX_set_max_proto_version(ctx,TLS1_3_VERSION);
+#else
SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
+#endif
/* renegotiation should include certificate request */
SSL_CTX_set_options(ctx, SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION);
@@ -1529,7 +1537,11 @@
}
}
if (!ciphers || !*ciphers) ciphers = "DEFAULT";
- SSL_set_cipher_list(myssl, ciphers);
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+ SSL_set_ciphersuites(myssl,ciphers); /* TLS 1.3 */
+#else
+ SSL_set_cipher_list(myssl,ciphers); /* TLS < 1.3 */
+#endif
alloc_free(saciphers.s);
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Hi Eric,
I now installed the rpm from testing repo, restarted qmail and did three tests:
- emailed Gmail address, mail relayed through my qmail box: OK
- replied from Gmail to my qmail box: OK
- emailed hornet security: OK
What I have in qmail send log is:
Remote_host_said:_250_2.0.0_OK_accept_as_13208F02763:a113fcad4200a6e05349a9b2d4c38ecd_by_mx-gate19-hz2/
So far so good.
My other settings currently:
# update-crypto-policies --show
LEGACY
and in /etc/crypto-policies/back-ends/opensslcnf.config I have
CipherString = @SECLEVEL=1
Is LEGACY still fine ? And should I switch back to @SECLEVEL=2 ?
Best,
Peter
On Sat, Mar 19, 2022 at 6:40 PM Eric Broch wrote:
>
> List,
>
> qmail-1.03-3.3.6.qt.md.el8.x86_64.rpm is in the testing repo. This is
> patched with updated loading of ciphers consistent with OpenSSL 1.1.1 on
> RHEL8 (and 8 derivatives) both in mysql and mariadb trees (non md to come).
>
> Here's the patch:
>
> --- qmail-1.03-3.3.5/qmail-remote.c 2022-03-18 08:22:01.810701523 -0600
> +++ qmail-1.03-3.3.5-new/qmail-remote.c 2022-03-18 13:48:22.951868716 -0600
> @@ -426,16 +426,26 @@
> }
> }
>
> - SSL_library_init();
> - ctx = SSL_CTX_new(SSLv23_client_method());
> +#if OPENSSL_VERSION_NUMBER >= 0x10101000L
> + OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS,NULL); /* TLS 1.3 */
> + ctx = SSL_CTX_new(TLS_client_method());
> +#else
> + SSL_library_init(); /* TLS < 1.3 */
> + ctx = SSL_CTX_new(SSLv23_client_method());
> +#endif
> if (!ctx) {
> if (!smtps && !servercert) return 0;
> smtptext.len = 0;
> tls_quit_error("ZTLS error initializing ctx");
> }
>
> - /* POODLE vulnerability */
> +#if OPENSSL_VERSION_NUMBER >= 0x10101000L
> + SSL_CTX_set_options(ctx,SSL_OP_ALL);
> + SSL_CTX_set_min_proto_version(ctx,TLS1_VERSION);
> + SSL_CTX_set_max_proto_version(ctx,TLS1_3_VERSION);
> +#else
> SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
> +#endif
>
> if (servercert) {
> if (!SSL_CTX_load_verify_locations(ctx, servercert, NULL)) {
> @@ -476,7 +486,11 @@
> ciphers = saciphers.s;
> }
> else ciphers = "DEFAULT";
> - SSL_set_cipher_list(myssl, ciphers);
> +#if OPENSSL_VERSION_NUMBER >= 0x10101000L
> + SSL_set_ciphersuites(myssl,ciphers); /* TLS 1.3 */
> +#else
> + SSL_set_cipher_list(myssl,ciphers); /* TLS < 1.3 */
> +#endif
> alloc_free(saciphers.s);
>
> SSL_set_fd(myssl, smtpfd);
> --- qmail-1.03-3.3.5/tls.c 2022-03-18 08:22:02.507741854 -0600
> +++ qmail-1.03-3.3.5-new/tls.c 2022-03-18 14:02:17.001103857 -0600
> @@ -14,7 +14,9 @@
> {
> int r = ERR_get_error();
> if (!r) return NULL;
> +#if OPENSSL_VERSION_NUMBER < 0x10101000L
> SSL_load_error_strings();
> +#endif
> return ERR_error_string(r, NULL);
> }
> const char *ssl_error_str()
> --- qmail-1.03-3.3.5/qmail-smtpd.c 2022-03-18 08:22:01.827702507 -0600
> +++ qmail-1.03-3.3.5-new/qmail-smtpd.c 2022-03-18 14:41:30.512190971 -0600
> @@ -1469,14 +1469,22 @@
> X509_LOOKUP *lookup;
> int session_id_context = 1; /* anything will do */
>
> - SSL_library_init();
> -
> - /* a new SSL context with the bare minimum of options */
> +#if OPENSSL_VERSION_NUMBER >= 0x10101000L
> + OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS,NULL); /* TLS 1.3 */
> + ctx = SSL_CTX_new(TLS_server_method());
> +#else
> + SSL_library_init(); /* TLS < 1.3 */
> ctx = SSL_CTX_new(SSLv23_server_method());
> +#endif
> if (!ctx) { tls_err("unable to initialize ctx"); return; }
>
> - /* POODLE vulnerability */
> +#if OPENSSL_VERSION_NUMBER >= 0x10101000L
> + SSL_CTX_set_options(ctx,SSL_OP_ALL);
> + SSL_CTX_set_min_proto_version(ctx,TLS1_VERSION);
> + SSL_CTX_set_max_proto_version(ctx,TLS1_3_VERSION);
> +#else
> SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
> +#endif
>
> /* renegotiation should include certificate request */
> SSL_CTX_set_options(ctx, SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION);
> @@ -1529,7 +1537,11 @@
> }
> }
> if (!ciphers || !*ciphers) ciphers = "DEFAULT";
> - SSL_set_cipher_list(myssl, ciphers);
> +#if OPENSSL_VERSION_NUMBER >= 0x10101000L
> + SSL_set_ciphersuites(myssl,ciphers); /* TLS 1.3 */
> +#else
> + SSL_set_cipher_list(myssl,ciphers); /* TLS < 1.3 */
> +#endif
> alloc_free(saciphers.s);
>
> SSL_set_tmp_rsa_callback(myssl, tmp_rsa_cb);
>
> On 3/18/2022 9:32 AM, Eric Broch wrote:
> > Hi Peter,
> >
> > I've been looking into this TLS issue and think I've found the
> > solution. It seems that the function in the newest version of OpenSSL
> > used in qmail-remote to load ciphers suits from the control directory
> > has been replaced so the default ciphers are loaded instead of the one
> > in the control directory. I've made changes to qmail-remote for the
> > latest OpenSSL to support TLS 1.3 and am using the proper function to
> > load the ciphers. It has been compiled on my Rocky8 box
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
List,
qmail-1.03-3.3.6.qt.md.el8.x86_64.rpm is in the testing repo. This is
patched with updated loading of ciphers consistent with OpenSSL 1.1.1 on
RHEL8 (and 8 derivatives) both in mysql and mariadb trees (non md to come).
Here's the patch:
--- qmail-1.03-3.3.5/qmail-remote.c 2022-03-18 08:22:01.810701523 -0600
+++ qmail-1.03-3.3.5-new/qmail-remote.c 2022-03-18 13:48:22.951868716 -0600
@@ -426,16 +426,26 @@
}
}
- SSL_library_init();
- ctx = SSL_CTX_new(SSLv23_client_method());
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+ OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS,NULL); /* TLS 1.3 */
+ ctx = SSL_CTX_new(TLS_client_method());
+#else
+ SSL_library_init(); /* TLS < 1.3 */
+ ctx = SSL_CTX_new(SSLv23_client_method());
+#endif
if (!ctx) {
if (!smtps && !servercert) return 0;
smtptext.len = 0;
tls_quit_error("ZTLS error initializing ctx");
}
- /* POODLE vulnerability */
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+ SSL_CTX_set_options(ctx,SSL_OP_ALL);
+ SSL_CTX_set_min_proto_version(ctx,TLS1_VERSION);
+ SSL_CTX_set_max_proto_version(ctx,TLS1_3_VERSION);
+#else
SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
+#endif
if (servercert) {
if (!SSL_CTX_load_verify_locations(ctx, servercert, NULL)) {
@@ -476,7 +486,11 @@
ciphers = saciphers.s;
}
else ciphers = "DEFAULT";
- SSL_set_cipher_list(myssl, ciphers);
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+ SSL_set_ciphersuites(myssl,ciphers); /* TLS 1.3 */
+#else
+ SSL_set_cipher_list(myssl,ciphers); /* TLS < 1.3 */
+#endif
alloc_free(saciphers.s);
SSL_set_fd(myssl, smtpfd);
--- qmail-1.03-3.3.5/tls.c 2022-03-18 08:22:02.507741854 -0600
+++ qmail-1.03-3.3.5-new/tls.c 2022-03-18 14:02:17.001103857 -0600
@@ -14,7 +14,9 @@
{
int r = ERR_get_error();
if (!r) return NULL;
+#if OPENSSL_VERSION_NUMBER < 0x10101000L
SSL_load_error_strings();
+#endif
return ERR_error_string(r, NULL);
}
const char *ssl_error_str()
--- qmail-1.03-3.3.5/qmail-smtpd.c 2022-03-18 08:22:01.827702507 -0600
+++ qmail-1.03-3.3.5-new/qmail-smtpd.c 2022-03-18 14:41:30.512190971 -0600
@@ -1469,14 +1469,22 @@
X509_LOOKUP *lookup;
int session_id_context = 1; /* anything will do */
- SSL_library_init();
-
- /* a new SSL context with the bare minimum of options */
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+ OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS,NULL); /* TLS 1.3 */
+ ctx = SSL_CTX_new(TLS_server_method());
+#else
+ SSL_library_init(); /* TLS < 1.3 */
ctx = SSL_CTX_new(SSLv23_server_method());
+#endif
if (!ctx) { tls_err("unable to initialize ctx"); return; }
- /* POODLE vulnerability */
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+ SSL_CTX_set_options(ctx,SSL_OP_ALL);
+ SSL_CTX_set_min_proto_version(ctx,TLS1_VERSION);
+ SSL_CTX_set_max_proto_version(ctx,TLS1_3_VERSION);
+#else
SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
+#endif
/* renegotiation should include certificate request */
SSL_CTX_set_options(ctx, SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION);
@@ -1529,7 +1537,11 @@
}
}
if (!ciphers || !*ciphers) ciphers = "DEFAULT";
- SSL_set_cipher_list(myssl, ciphers);
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+ SSL_set_ciphersuites(myssl,ciphers); /* TLS 1.3 */
+#else
+ SSL_set_cipher_list(myssl,ciphers); /* TLS < 1.3 */
+#endif
alloc_free(saciphers.s);
SSL_set_tmp_rsa_callback(myssl, tmp_rsa_cb);
On 3/18/2022 9:32 AM, Eric Broch wrote:
Hi Peter,
I've been looking into this TLS issue and think I've found the
solution. It seems that the function in the newest version of OpenSSL
used in qmail-remote to load ciphers suits from the control directory
has been replaced so the default ciphers are loaded instead of the one
in the control directory. I've made changes to qmail-remote for the
latest OpenSSL to support TLS 1.3 and am using the proper function to
load the ciphers. It has been compiled on my Rocky8 box and I've
successfully used it to send emails. I can create and new RPM or make
available the qmail-remote executable for download and testing. Let me
know which you'd prefer.
Eric
On 3/2/2022 1:02 AM, Peter Peltonen wrote:
Any ideas how to solve the TLS connect errors?
A bit of a hack that comes to my mind would be to have a cron job to
switch back to LEGACY, process the queue and then switch back to
DEFAULT?
But a more elegant solution would be preferable :)
Best,
Peter
On Tue, Mar 1, 2022 at 9:13 AM Peter Peltonen
wrote:
Now after monitoring 36h after the change no cipher related errors,
but a few servers apparently have problems with higher TLS versions:
TLS_connect_failed:_error:1425F102:SSL_routines:ssl_choose_client_version:unsupported_protocol
I assume that this is due to these
/etc/crypto-policies/back-ends/opensslcnf.config settings:
TLS.MinProtocol = TLSv1.2
TLS.MaxProtocol = TLSv1.3
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Hi Peter, I've been looking into this TLS issue and think I've found the solution. It seems that the function in the newest version of OpenSSL used in qmail-remote to load ciphers suits from the control directory has been replaced so the default ciphers are loaded instead of the one in the control directory. I've made changes to qmail-remote for the latest OpenSSL to support TLS 1.3 and am using the proper function to load the ciphers. It has been compiled on my Rocky8 box and I've successfully used it to send emails. I can create and new RPM or make available the qmail-remote executable for download and testing. Let me know which you'd prefer. Eric On 3/2/2022 1:02 AM, Peter Peltonen wrote: Any ideas how to solve the TLS connect errors? A bit of a hack that comes to my mind would be to have a cron job to switch back to LEGACY, process the queue and then switch back to DEFAULT? But a more elegant solution would be preferable :) Best, Peter On Tue, Mar 1, 2022 at 9:13 AM Peter Peltonen wrote: Now after monitoring 36h after the change no cipher related errors, but a few servers apparently have problems with higher TLS versions: TLS_connect_failed:_error:1425F102:SSL_routines:ssl_choose_client_version:unsupported_protocol I assume that this is due to these /etc/crypto-policies/back-ends/opensslcnf.config settings: TLS.MinProtocol = TLSv1.2 TLS.MaxProtocol = TLSv1.3 DTLS.MinProtocol = DTLSv1.2 DTLS.MaxProtocol = DTLSv1.2 If I lower MinProtocol to TLSv1.0 would that enable access to those servers but use the higher protocol version for the rest of the world? Best, Peter On Mon, Feb 28, 2022 at 1:44 AM Eric Broch wrote: I'd like to implement this programmatically so that we can set parameters in a /var/qmail/control/sslconf file On 2/27/2022 2:25 PM, Peter Peltonen wrote: Hi Eric, Okay my crypto-policy is now DEFAULT again and in opensslcnf.config I now have: CipherString = DEFAULT@SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 I am grepping ssl from qmail/send log. Let's see how it goes. Best, Peter On Thu, Feb 24, 2022 at 7:36 PM Eric Broch wrote: Peter, Can you try something with your server to get mail delivery to normal. Run command: update-crypto-policies --set DEFAULT Edit file /etc/crypto-policies/back-ends/opensslcnf.config particularly setting CipherString = @SECLEVEL=2 change to CipherString = DEFAULT@SECLEVEL=1 Watch logs Eric On 2/23/2022 8:53 AM, Peter Peltonen wrote: You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not qmail-1.03-2.2.1) with the LEGACY setting? As far as I know the only problem I am having is with the hornetsecurity.com servers. But to be honest I have not really been monitoring the logs that carefully, that's the only server I've received a complain about. I now tried sending them email with unencrypted connection and it failed. So I think I will now leave it to LEGACY, accept that I cannot deliver mail to the hornet serers and keep monitoring now more closely for TLS errors in the logs: if more turn up then I might consider again switching to DEFAULT and then adding those servers to notlshosts/ although that looks like a nonendint task. If someone comes up with a solution how I could have the best of both worlds (= support everyone), let me know? Best, Peter On Wed, Feb 23, 2022 at 5:08 PM Eric Broch wrote: Does your legacy server qmail-1.03-2.2.1 send to all? On 2/23/2022 8:03 AM, Peter Peltonen wrote: Here is another error I have now seen qmail/send log about 10 times in the recent hour: TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small And this has now happened with two pretty big local service provider's servers as well. I don't think I can continue with the DEFAULT setting. I will now try to fall back to LEGACY and see if hornetsecurity.com accepts unencrypted connections. And I really do not understand the core of this problem: why cannot my server just have the whole range of ciphers and protocols in use and apply the most secure / appropriate one that the other party supports? Best, Peter On Wed, Feb 23, 2022 at 4:29 PM Eric Broch wrote: If I remember correctly it had something to do with Dovecot On Feb 23, 2022, at 2:25 AM, Peter Peltonen wrote: Hello, Okay I now tested:: With LEGACY (which I had earlier) I get the SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in qmail/send log: But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result And I did the test without rebooting nor restarting qmail. So apparently this command did the trick like Eric suggested: update-crypto-policies --set DEFAULT Now I wonder if this has some other consequences, what legacy stuff is now incompatible...? Best, Peter ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> kirjoitti: reboot On 2/21/2022 8:30 AM, Peter Peltonen
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
I think it would, but I would try it to see. On 3/1/2022 12:13 AM, Peter Peltonen wrote: If I lower MinProtocol to TLSv1.0 would that enable access to those servers but use the higher protocol version for the rest of the world? - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Any ideas how to solve the TLS connect errors? A bit of a hack that comes to my mind would be to have a cron job to switch back to LEGACY, process the queue and then switch back to DEFAULT? But a more elegant solution would be preferable :) Best, Peter On Tue, Mar 1, 2022 at 9:13 AM Peter Peltonen wrote: > > Now after monitoring 36h after the change no cipher related errors, > but a few servers apparently have problems with higher TLS versions: > > TLS_connect_failed:_error:1425F102:SSL_routines:ssl_choose_client_version:unsupported_protocol > > I assume that this is due to these > /etc/crypto-policies/back-ends/opensslcnf.config settings: > > TLS.MinProtocol = TLSv1.2 > TLS.MaxProtocol = TLSv1.3 > DTLS.MinProtocol = DTLSv1.2 > DTLS.MaxProtocol = DTLSv1.2 > > If I lower MinProtocol to TLSv1.0 would that enable access to those > servers but use the higher protocol version for the rest of the world? > > Best, > Peter > > > On Mon, Feb 28, 2022 at 1:44 AM Eric Broch wrote: > > > > I'd like to implement this programmatically so that we can set > > parameters in a /var/qmail/control/sslconf file > > > > On 2/27/2022 2:25 PM, Peter Peltonen wrote: > > > Hi Eric, > > > > > > Okay my crypto-policy is now DEFAULT again and in opensslcnf.config I now > > > have: > > > > > > CipherString = > > > DEFAULT@SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 > > > > > > I am grepping ssl from qmail/send log. Let's see how it goes. > > > > > > Best, > > > Peter > > > > > > On Thu, Feb 24, 2022 at 7:36 PM Eric Broch > > > wrote: > > >> Peter, > > >> > > >> Can you try something with your server to get mail delivery to normal. > > >> Run command: > > >> > > >> update-crypto-policies --set DEFAULT > > >> > > >> Edit file /etc/crypto-policies/back-ends/opensslcnf.config particularly > > >> setting > > >> > > >> CipherString = @SECLEVEL=2 > > >> > > >> change to > > >> > > >> CipherString = DEFAULT@SECLEVEL=1 > > >> > > >> Watch logs > > >> > > >> Eric > > >> > > >> On 2/23/2022 8:53 AM, Peter Peltonen wrote: > > >>> You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not > > >>> qmail-1.03-2.2.1) with the LEGACY setting? > > >>> > > >>> As far as I know the only problem I am having is with the > > >>> hornetsecurity.com servers. But to be honest I have not really been > > >>> monitoring the logs that carefully, that's the only server I've > > >>> received a complain about. I now tried sending them email with > > >>> unencrypted connection and it failed. > > >>> > > >>> So I think I will now leave it to LEGACY, accept that I cannot deliver > > >>> mail to the hornet serers and keep monitoring now more closely for TLS > > >>> errors in the logs: if more turn up then I might consider again > > >>> switching to DEFAULT and then adding those servers to notlshosts/ > > >>> although that looks like a nonendint task. > > >>> > > >>> If someone comes up with a solution how I could have the best of both > > >>> worlds (= support everyone), let me know? > > >>> > > >>> Best, > > >>> Peter > > >>> > > >>> On Wed, Feb 23, 2022 at 5:08 PM Eric Broch > > >>> wrote: > > Does your legacy server qmail-1.03-2.2.1 send to all? > > > > On 2/23/2022 8:03 AM, Peter Peltonen wrote: > > > Here is another error I have now seen qmail/send log about 10 times in > > > the recent hour: > > > > > > TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small > > > > > > And this has now happened with two pretty big local service provider's > > > servers as well. I don't think I can continue with the DEFAULT > > > setting. I will now try to fall back to LEGACY and see if > > > hornetsecurity.com accepts unencrypted connections. And I really do > > > not understand the core of this problem: why cannot my server just > > > have the whole range of ciphers and protocols in use and apply the > > > most secure / appropriate one that the other party supports? > > > > > > Best, > > > Peter > > > > > > On Wed, Feb 23, 2022 at 4:29 PM Eric Broch > > > wrote: > > >> If I remember correctly it had something to do with Dovecot > > >> On Feb 23, 2022, at 2:25 AM, Peter Peltonen > > >> wrote: > > >>> Hello, > > >>> > > >>> Okay I now tested:: > > >>> > > >>> With LEGACY (which I had earlier) I get the > > >>> SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in > > >>> qmail/send log: > > >>> > > >>> But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the > > >>> result > > >>> > > >>> And I did the test without rebooting nor restarting qmail. > > >>> > > >>> So apparently this command did the trick like Eric suggested: > > >>> > > >>> update-crypto-policies --set DEFAULT > > >>> > > >>> Now I wonder if this has some other consequences, what
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Now after monitoring 36h after the change no cipher related errors, but a few servers apparently have problems with higher TLS versions: TLS_connect_failed:_error:1425F102:SSL_routines:ssl_choose_client_version:unsupported_protocol I assume that this is due to these /etc/crypto-policies/back-ends/opensslcnf.config settings: TLS.MinProtocol = TLSv1.2 TLS.MaxProtocol = TLSv1.3 DTLS.MinProtocol = DTLSv1.2 DTLS.MaxProtocol = DTLSv1.2 If I lower MinProtocol to TLSv1.0 would that enable access to those servers but use the higher protocol version for the rest of the world? Best, Peter On Mon, Feb 28, 2022 at 1:44 AM Eric Broch wrote: > > I'd like to implement this programmatically so that we can set > parameters in a /var/qmail/control/sslconf file > > On 2/27/2022 2:25 PM, Peter Peltonen wrote: > > Hi Eric, > > > > Okay my crypto-policy is now DEFAULT again and in opensslcnf.config I now > > have: > > > > CipherString = > > DEFAULT@SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 > > > > I am grepping ssl from qmail/send log. Let's see how it goes. > > > > Best, > > Peter > > > > On Thu, Feb 24, 2022 at 7:36 PM Eric Broch wrote: > >> Peter, > >> > >> Can you try something with your server to get mail delivery to normal. > >> Run command: > >> > >> update-crypto-policies --set DEFAULT > >> > >> Edit file /etc/crypto-policies/back-ends/opensslcnf.config particularly > >> setting > >> > >> CipherString = @SECLEVEL=2 > >> > >> change to > >> > >> CipherString = DEFAULT@SECLEVEL=1 > >> > >> Watch logs > >> > >> Eric > >> > >> On 2/23/2022 8:53 AM, Peter Peltonen wrote: > >>> You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not > >>> qmail-1.03-2.2.1) with the LEGACY setting? > >>> > >>> As far as I know the only problem I am having is with the > >>> hornetsecurity.com servers. But to be honest I have not really been > >>> monitoring the logs that carefully, that's the only server I've > >>> received a complain about. I now tried sending them email with > >>> unencrypted connection and it failed. > >>> > >>> So I think I will now leave it to LEGACY, accept that I cannot deliver > >>> mail to the hornet serers and keep monitoring now more closely for TLS > >>> errors in the logs: if more turn up then I might consider again > >>> switching to DEFAULT and then adding those servers to notlshosts/ > >>> although that looks like a nonendint task. > >>> > >>> If someone comes up with a solution how I could have the best of both > >>> worlds (= support everyone), let me know? > >>> > >>> Best, > >>> Peter > >>> > >>> On Wed, Feb 23, 2022 at 5:08 PM Eric Broch > >>> wrote: > Does your legacy server qmail-1.03-2.2.1 send to all? > > On 2/23/2022 8:03 AM, Peter Peltonen wrote: > > Here is another error I have now seen qmail/send log about 10 times in > > the recent hour: > > > > TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small > > > > And this has now happened with two pretty big local service provider's > > servers as well. I don't think I can continue with the DEFAULT > > setting. I will now try to fall back to LEGACY and see if > > hornetsecurity.com accepts unencrypted connections. And I really do > > not understand the core of this problem: why cannot my server just > > have the whole range of ciphers and protocols in use and apply the > > most secure / appropriate one that the other party supports? > > > > Best, > > Peter > > > > On Wed, Feb 23, 2022 at 4:29 PM Eric Broch > > wrote: > >> If I remember correctly it had something to do with Dovecot > >> On Feb 23, 2022, at 2:25 AM, Peter Peltonen > >> wrote: > >>> Hello, > >>> > >>> Okay I now tested:: > >>> > >>> With LEGACY (which I had earlier) I get the > >>> SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in > >>> qmail/send log: > >>> > >>> But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the > >>> result > >>> > >>> And I did the test without rebooting nor restarting qmail. > >>> > >>> So apparently this command did the trick like Eric suggested: > >>> > >>> update-crypto-policies --set DEFAULT > >>> > >>> Now I wonder if this has some other consequences, what legacy stuff > >>> is now incompatible...? > >>> > >>> Best, > >>> Peter > >>> > >>> > >>> ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> > >>> kirjoitti: > reboot > > On 2/21/2022 8:30 AM, Peter Peltonen wrote: > > Thanks Eric for the update. Here is what I see: > > > > [root@mail ~]# update-crypto-policies --show > > LEGACY > > [root@mail ~]# update-crypto-policies --set DEFAULT > > Setting system policy to DEFAULT > >
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
I'd like to implement this programmatically so that we can set parameters in a /var/qmail/control/sslconf file On 2/27/2022 2:25 PM, Peter Peltonen wrote: Hi Eric, Okay my crypto-policy is now DEFAULT again and in opensslcnf.config I now have: CipherString = DEFAULT@SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 I am grepping ssl from qmail/send log. Let's see how it goes. Best, Peter On Thu, Feb 24, 2022 at 7:36 PM Eric Broch wrote: Peter, Can you try something with your server to get mail delivery to normal. Run command: update-crypto-policies --set DEFAULT Edit file /etc/crypto-policies/back-ends/opensslcnf.config particularly setting CipherString = @SECLEVEL=2 change to CipherString = DEFAULT@SECLEVEL=1 Watch logs Eric On 2/23/2022 8:53 AM, Peter Peltonen wrote: You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not qmail-1.03-2.2.1) with the LEGACY setting? As far as I know the only problem I am having is with the hornetsecurity.com servers. But to be honest I have not really been monitoring the logs that carefully, that's the only server I've received a complain about. I now tried sending them email with unencrypted connection and it failed. So I think I will now leave it to LEGACY, accept that I cannot deliver mail to the hornet serers and keep monitoring now more closely for TLS errors in the logs: if more turn up then I might consider again switching to DEFAULT and then adding those servers to notlshosts/ although that looks like a nonendint task. If someone comes up with a solution how I could have the best of both worlds (= support everyone), let me know? Best, Peter On Wed, Feb 23, 2022 at 5:08 PM Eric Broch wrote: Does your legacy server qmail-1.03-2.2.1 send to all? On 2/23/2022 8:03 AM, Peter Peltonen wrote: Here is another error I have now seen qmail/send log about 10 times in the recent hour: TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small And this has now happened with two pretty big local service provider's servers as well. I don't think I can continue with the DEFAULT setting. I will now try to fall back to LEGACY and see if hornetsecurity.com accepts unencrypted connections. And I really do not understand the core of this problem: why cannot my server just have the whole range of ciphers and protocols in use and apply the most secure / appropriate one that the other party supports? Best, Peter On Wed, Feb 23, 2022 at 4:29 PM Eric Broch wrote: If I remember correctly it had something to do with Dovecot On Feb 23, 2022, at 2:25 AM, Peter Peltonen wrote: Hello, Okay I now tested:: With LEGACY (which I had earlier) I get the SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in qmail/send log: But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result And I did the test without rebooting nor restarting qmail. So apparently this command did the trick like Eric suggested: update-crypto-policies --set DEFAULT Now I wonder if this has some other consequences, what legacy stuff is now incompatible...? Best, Peter ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> kirjoitti: reboot On 2/21/2022 8:30 AM, Peter Peltonen wrote: Thanks Eric for the update. Here is what I see: [root@mail ~]# update-crypto-policies --show LEGACY [root@mail ~]# update-crypto-policies --set DEFAULT Setting system policy to DEFAULT Note: System-wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place. Is restarting qmail enough or should I even reboot? And is there some difference between DEFAULT and FUTURE or are they the same? Best, Peter On Mon, Feb 21, 2022 at 4:39 PM Eric Broch < ebr...@whitehorsetc.com> wrote: Upon further reflection, at the end of the qt/cos8 install script there is a command, 'update-crypto-policies --set LEGACY' intended for old email clients I don't wonder if this change between cos7 and cos8 might caused the problem. Have a look here: https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82 If you've change it to 'update-crypto-policies --set DEFAULT' or 'update-crypto-policies --set FUTURE' and are still having issue ask hornet security if we can see the actual smtp transaction. In my earlier email I was saying that there was not much difference between the old code and the new code for remote delivery and it was not immediately obvious why we would be having a problem. Eric On 2/21/2022 7:17 AM, Peter Peltonen wrote: Hi, Is there something I can test? I didn't quite understand from Eric's earlier msg what I should try... One email address producing this error for me is supp...@hornetsecurity.com -> If you like Eric, you could try emailing themselves asking for more details (either they reply to you or you will face the same error). If you
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Hi Eric, Okay my crypto-policy is now DEFAULT again and in opensslcnf.config I now have: CipherString = DEFAULT@SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 I am grepping ssl from qmail/send log. Let's see how it goes. Best, Peter On Thu, Feb 24, 2022 at 7:36 PM Eric Broch wrote: > > Peter, > > Can you try something with your server to get mail delivery to normal. > Run command: > > update-crypto-policies --set DEFAULT > > Edit file /etc/crypto-policies/back-ends/opensslcnf.config particularly > setting > > CipherString = @SECLEVEL=2 > > change to > > CipherString = DEFAULT@SECLEVEL=1 > > Watch logs > > Eric > > On 2/23/2022 8:53 AM, Peter Peltonen wrote: > > You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not > > qmail-1.03-2.2.1) with the LEGACY setting? > > > > As far as I know the only problem I am having is with the > > hornetsecurity.com servers. But to be honest I have not really been > > monitoring the logs that carefully, that's the only server I've > > received a complain about. I now tried sending them email with > > unencrypted connection and it failed. > > > > So I think I will now leave it to LEGACY, accept that I cannot deliver > > mail to the hornet serers and keep monitoring now more closely for TLS > > errors in the logs: if more turn up then I might consider again > > switching to DEFAULT and then adding those servers to notlshosts/ > > although that looks like a nonendint task. > > > > If someone comes up with a solution how I could have the best of both > > worlds (= support everyone), let me know? > > > > Best, > > Peter > > > > On Wed, Feb 23, 2022 at 5:08 PM Eric Broch wrote: > >> Does your legacy server qmail-1.03-2.2.1 send to all? > >> > >> On 2/23/2022 8:03 AM, Peter Peltonen wrote: > >>> Here is another error I have now seen qmail/send log about 10 times in > >>> the recent hour: > >>> > >>> TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small > >>> > >>> And this has now happened with two pretty big local service provider's > >>> servers as well. I don't think I can continue with the DEFAULT > >>> setting. I will now try to fall back to LEGACY and see if > >>> hornetsecurity.com accepts unencrypted connections. And I really do > >>> not understand the core of this problem: why cannot my server just > >>> have the whole range of ciphers and protocols in use and apply the > >>> most secure / appropriate one that the other party supports? > >>> > >>> Best, > >>> Peter > >>> > >>> On Wed, Feb 23, 2022 at 4:29 PM Eric Broch > >>> wrote: > If I remember correctly it had something to do with Dovecot > On Feb 23, 2022, at 2:25 AM, Peter Peltonen > wrote: > > Hello, > > > > Okay I now tested:: > > > > With LEGACY (which I had earlier) I get the > > SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in > > qmail/send log: > > > > But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the > > result > > > > And I did the test without rebooting nor restarting qmail. > > > > So apparently this command did the trick like Eric suggested: > > > > update-crypto-policies --set DEFAULT > > > > Now I wonder if this has some other consequences, what legacy stuff is > > now incompatible...? > > > > Best, > > Peter > > > > > > ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> > > kirjoitti: > >> reboot > >> > >> On 2/21/2022 8:30 AM, Peter Peltonen wrote: > >>> Thanks Eric for the update. Here is what I see: > >>> > >>> [root@mail ~]# update-crypto-policies --show > >>> LEGACY > >>> [root@mail ~]# update-crypto-policies --set DEFAULT > >>> Setting system policy to DEFAULT > >>> Note: System-wide crypto policies are applied on application start-up. > >>> It is recommended to restart the system for the change of policies > >>> to fully take place. > >>> > >>> Is restarting qmail enough or should I even reboot? > >>> > >>> And is there some difference between DEFAULT and FUTURE or are they > >>> the same? > >>> > >>> Best, > >>> Peter > >>> > >>> On Mon, Feb 21, 2022 at 4:39 PM Eric Broch < ebr...@whitehorsetc.com> > >>> wrote: > Upon further reflection, at the end of the qt/cos8 install script > there > is a command, 'update-crypto-policies --set LEGACY' intended for old > email clients I don't wonder if this change between cos7 and cos8 > might > caused the problem. Have a look here: > > https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82 > > If you've change it to 'update-crypto-policies --set DEFAULT' or > 'update-crypto-policies --set FUTURE' and are still having issue ask >
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Peter, Can you try something with your server to get mail delivery to normal. Run command: update-crypto-policies --set DEFAULT Edit file /etc/crypto-policies/back-ends/opensslcnf.config particularly setting CipherString = @SECLEVEL=2 change to CipherString = DEFAULT@SECLEVEL=1 Watch logs Eric On 2/23/2022 8:53 AM, Peter Peltonen wrote: You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not qmail-1.03-2.2.1) with the LEGACY setting? As far as I know the only problem I am having is with the hornetsecurity.com servers. But to be honest I have not really been monitoring the logs that carefully, that's the only server I've received a complain about. I now tried sending them email with unencrypted connection and it failed. So I think I will now leave it to LEGACY, accept that I cannot deliver mail to the hornet serers and keep monitoring now more closely for TLS errors in the logs: if more turn up then I might consider again switching to DEFAULT and then adding those servers to notlshosts/ although that looks like a nonendint task. If someone comes up with a solution how I could have the best of both worlds (= support everyone), let me know? Best, Peter On Wed, Feb 23, 2022 at 5:08 PM Eric Broch wrote: Does your legacy server qmail-1.03-2.2.1 send to all? On 2/23/2022 8:03 AM, Peter Peltonen wrote: Here is another error I have now seen qmail/send log about 10 times in the recent hour: TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small And this has now happened with two pretty big local service provider's servers as well. I don't think I can continue with the DEFAULT setting. I will now try to fall back to LEGACY and see if hornetsecurity.com accepts unencrypted connections. And I really do not understand the core of this problem: why cannot my server just have the whole range of ciphers and protocols in use and apply the most secure / appropriate one that the other party supports? Best, Peter On Wed, Feb 23, 2022 at 4:29 PM Eric Broch wrote: If I remember correctly it had something to do with Dovecot On Feb 23, 2022, at 2:25 AM, Peter Peltonen wrote: Hello, Okay I now tested:: With LEGACY (which I had earlier) I get the SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in qmail/send log: But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result And I did the test without rebooting nor restarting qmail. So apparently this command did the trick like Eric suggested: update-crypto-policies --set DEFAULT Now I wonder if this has some other consequences, what legacy stuff is now incompatible...? Best, Peter ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> kirjoitti: reboot On 2/21/2022 8:30 AM, Peter Peltonen wrote: Thanks Eric for the update. Here is what I see: [root@mail ~]# update-crypto-policies --show LEGACY [root@mail ~]# update-crypto-policies --set DEFAULT Setting system policy to DEFAULT Note: System-wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place. Is restarting qmail enough or should I even reboot? And is there some difference between DEFAULT and FUTURE or are they the same? Best, Peter On Mon, Feb 21, 2022 at 4:39 PM Eric Broch < ebr...@whitehorsetc.com> wrote: Upon further reflection, at the end of the qt/cos8 install script there is a command, 'update-crypto-policies --set LEGACY' intended for old email clients I don't wonder if this change between cos7 and cos8 might caused the problem. Have a look here: https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82 If you've change it to 'update-crypto-policies --set DEFAULT' or 'update-crypto-policies --set FUTURE' and are still having issue ask hornet security if we can see the actual smtp transaction. In my earlier email I was saying that there was not much difference between the old code and the new code for remote delivery and it was not immediately obvious why we would be having a problem. Eric On 2/21/2022 7:17 AM, Peter Peltonen wrote: Hi, Is there something I can test? I didn't quite understand from Eric's earlier msg what I should try... One email address producing this error for me is supp...@hornetsecurity.com -> If you like Eric, you could try emailing themselves asking for more details (either they reply to you or you will face the same error). If you don't face the same error then we could try figuring out what is different in our setups? Best, Peter On Sat, Feb 19, 2022 at 6:29 PM Eric Broch < ebr...@whitehorsetc.com> wrote: Looking through the function tls_init() in the code for qmail-remote.c I don't see much that it could be, they're almost identical between 2.2.1 and 3.3.5 Will continue looking... On 2/18/2022 1:54 PM, Andreas Galatis wrote: Hi Finn, I have tested with the tlsserverciphers of my older server, completed with some of the ciphers from the new file and
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Hi List, Since having setup the cipher-policy to DEFAULT I had no more failures for wrong ciphersuite. Even the hornetservers can be reached (they told me they accept TLS1.2 and TLS1.3 only). Until having changed the policy I routed all mails to domains that didn't accept my ciphers via my old server with qmail-1.03-2.2.1 and had no issues. The only issue I actually know off is that my clients cannot authenticate with an alias-name. I thank all developers working on qmailtoaster for this great software that I use and appreciate since many years. Andreas Am 23.02.22 um 17:07 schrieb Eric Broch: when you run the command update-crypto-policies --set 'POLICY' it actually modifies the file /etc/crypto-policies/back-ends/opensslcnf.config If you set to DEFAULT you may be able to modify the file with the correct cipher Eric On 2/23/2022 9:49 AM, xaf wrote: Peter Peltonen a écrit le 23/02/2022 à 16:53 : So I think I will now leave it to LEGACY, accept that I cannot deliver mail to the hornet serers and keep monitoring now more closely for TLS errors in the logs: if more turn up then I might consider again switching to DEFAULT and then adding those servers to notlshosts/ although that looks like a nonendint task. provides cat /etc/redhat-release cat /usr/share/crypto-policies/LEGACY/opensslcnf.txt xaf - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
when you run the command update-crypto-policies --set 'POLICY' it actually modifies the file /etc/crypto-policies/back-ends/opensslcnf.config If you set to DEFAULT you may be able to modify the file with the correct cipher Eric On 2/23/2022 9:49 AM, xaf wrote: Peter Peltonen a écrit le 23/02/2022 à 16:53 : So I think I will now leave it to LEGACY, accept that I cannot deliver mail to the hornet serers and keep monitoring now more closely for TLS errors in the logs: if more turn up then I might consider again switching to DEFAULT and then adding those servers to notlshosts/ although that looks like a nonendint task. provides cat /etc/redhat-release cat /usr/share/crypto-policies/LEGACY/opensslcnf.txt xaf - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
No, I miss spoke, I meant the server you have with qmail-1.03-2.2.1 On 2/23/2022 8:53 AM, Peter Peltonen wrote: You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not qmail-1.03-2.2.1) with the LEGACY setting? As far as I know the only problem I am having is with the hornetsecurity.com servers. But to be honest I have not really been monitoring the logs that carefully, that's the only server I've received a complain about. I now tried sending them email with unencrypted connection and it failed. So I think I will now leave it to LEGACY, accept that I cannot deliver mail to the hornet serers and keep monitoring now more closely for TLS errors in the logs: if more turn up then I might consider again switching to DEFAULT and then adding those servers to notlshosts/ although that looks like a nonendint task. If someone comes up with a solution how I could have the best of both worlds (= support everyone), let me know? Best, Peter On Wed, Feb 23, 2022 at 5:08 PM Eric Broch wrote: Does your legacy server qmail-1.03-2.2.1 send to all? On 2/23/2022 8:03 AM, Peter Peltonen wrote: Here is another error I have now seen qmail/send log about 10 times in the recent hour: TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small And this has now happened with two pretty big local service provider's servers as well. I don't think I can continue with the DEFAULT setting. I will now try to fall back to LEGACY and see if hornetsecurity.com accepts unencrypted connections. And I really do not understand the core of this problem: why cannot my server just have the whole range of ciphers and protocols in use and apply the most secure / appropriate one that the other party supports? Best, Peter On Wed, Feb 23, 2022 at 4:29 PM Eric Broch wrote: If I remember correctly it had something to do with Dovecot On Feb 23, 2022, at 2:25 AM, Peter Peltonen wrote: Hello, Okay I now tested:: With LEGACY (which I had earlier) I get the SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in qmail/send log: But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result And I did the test without rebooting nor restarting qmail. So apparently this command did the trick like Eric suggested: update-crypto-policies --set DEFAULT Now I wonder if this has some other consequences, what legacy stuff is now incompatible...? Best, Peter ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> kirjoitti: reboot On 2/21/2022 8:30 AM, Peter Peltonen wrote: Thanks Eric for the update. Here is what I see: [root@mail ~]# update-crypto-policies --show LEGACY [root@mail ~]# update-crypto-policies --set DEFAULT Setting system policy to DEFAULT Note: System-wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place. Is restarting qmail enough or should I even reboot? And is there some difference between DEFAULT and FUTURE or are they the same? Best, Peter On Mon, Feb 21, 2022 at 4:39 PM Eric Broch < ebr...@whitehorsetc.com> wrote: Upon further reflection, at the end of the qt/cos8 install script there is a command, 'update-crypto-policies --set LEGACY' intended for old email clients I don't wonder if this change between cos7 and cos8 might caused the problem. Have a look here: https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82 If you've change it to 'update-crypto-policies --set DEFAULT' or 'update-crypto-policies --set FUTURE' and are still having issue ask hornet security if we can see the actual smtp transaction. In my earlier email I was saying that there was not much difference between the old code and the new code for remote delivery and it was not immediately obvious why we would be having a problem. Eric On 2/21/2022 7:17 AM, Peter Peltonen wrote: Hi, Is there something I can test? I didn't quite understand from Eric's earlier msg what I should try... One email address producing this error for me is supp...@hornetsecurity.com -> If you like Eric, you could try emailing themselves asking for more details (either they reply to you or you will face the same error). If you don't face the same error then we could try figuring out what is different in our setups? Best, Peter On Sat, Feb 19, 2022 at 6:29 PM Eric Broch < ebr...@whitehorsetc.com> wrote: Looking through the function tls_init() in the code for qmail-remote.c I don't see much that it could be, they're almost identical between 2.2.1 and 3.3.5 Will continue looking... On 2/18/2022 1:54 PM, Andreas Galatis wrote: Hi Finn, I have tested with the tlsserverciphers of my older server, completed with some of the ciphers from the new file and my mails came through. Thanks a lot for your tip, Finn, I didn't find it in the code Andreas Am 18.02.22 um 16:56 schrieb Qmail: Hi Andreas. In qmail You're properly using /var/qmail/control/tlsclientciphers (that are a link to
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not qmail-1.03-2.2.1) with the LEGACY setting? As far as I know the only problem I am having is with the hornetsecurity.com servers. But to be honest I have not really been monitoring the logs that carefully, that's the only server I've received a complain about. I now tried sending them email with unencrypted connection and it failed. So I think I will now leave it to LEGACY, accept that I cannot deliver mail to the hornet serers and keep monitoring now more closely for TLS errors in the logs: if more turn up then I might consider again switching to DEFAULT and then adding those servers to notlshosts/ although that looks like a nonendint task. If someone comes up with a solution how I could have the best of both worlds (= support everyone), let me know? Best, Peter On Wed, Feb 23, 2022 at 5:08 PM Eric Broch wrote: > > Does your legacy server qmail-1.03-2.2.1 send to all? > > On 2/23/2022 8:03 AM, Peter Peltonen wrote: > > Here is another error I have now seen qmail/send log about 10 times in > > the recent hour: > > > > TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small > > > > And this has now happened with two pretty big local service provider's > > servers as well. I don't think I can continue with the DEFAULT > > setting. I will now try to fall back to LEGACY and see if > > hornetsecurity.com accepts unencrypted connections. And I really do > > not understand the core of this problem: why cannot my server just > > have the whole range of ciphers and protocols in use and apply the > > most secure / appropriate one that the other party supports? > > > > Best, > > Peter > > > > On Wed, Feb 23, 2022 at 4:29 PM Eric Broch wrote: > >> If I remember correctly it had something to do with Dovecot > >> On Feb 23, 2022, at 2:25 AM, Peter Peltonen > >> wrote: > >>> Hello, > >>> > >>> Okay I now tested:: > >>> > >>> With LEGACY (which I had earlier) I get the > >>> SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in > >>> qmail/send log: > >>> > >>> But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result > >>> > >>> And I did the test without rebooting nor restarting qmail. > >>> > >>> So apparently this command did the trick like Eric suggested: > >>> > >>> update-crypto-policies --set DEFAULT > >>> > >>> Now I wonder if this has some other consequences, what legacy stuff is > >>> now incompatible...? > >>> > >>> Best, > >>> Peter > >>> > >>> > >>> ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> > >>> kirjoitti: > reboot > > On 2/21/2022 8:30 AM, Peter Peltonen wrote: > > Thanks Eric for the update. Here is what I see: > > > > [root@mail ~]# update-crypto-policies --show > > LEGACY > > [root@mail ~]# update-crypto-policies --set DEFAULT > > Setting system policy to DEFAULT > > Note: System-wide crypto policies are applied on application start-up. > > It is recommended to restart the system for the change of policies > > to fully take place. > > > > Is restarting qmail enough or should I even reboot? > > > > And is there some difference between DEFAULT and FUTURE or are they the > > same? > > > > Best, > > Peter > > > > On Mon, Feb 21, 2022 at 4:39 PM Eric Broch < ebr...@whitehorsetc.com> > > wrote: > >> Upon further reflection, at the end of the qt/cos8 install script there > >> is a command, 'update-crypto-policies --set LEGACY' intended for old > >> email clients I don't wonder if this change between cos7 and cos8 might > >> caused the problem. Have a look here: > >> > >> https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82 > >> > >> If you've change it to 'update-crypto-policies --set DEFAULT' or > >> 'update-crypto-policies --set FUTURE' and are still having issue ask > >> hornet security if we can see the actual smtp transaction. > >> > >> In my earlier email I was saying that there was not much difference > >> between the old code and the new code for remote delivery and it was > >> not > >> immediately obvious why we would be having a problem. > >> > >> Eric > >> > >> > >> On 2/21/2022 7:17 AM, Peter Peltonen wrote: > >>> Hi, > >>> > >>> Is there something I can test? I didn't quite understand from Eric's > >>> earlier msg what I should try... > >>> > >>> One email address producing this error for me is > >>> supp...@hornetsecurity.com -> If you like Eric, you could try emailing > >>> themselves asking for more details (either they reply to you or you > >>> will face the same error). If you don't face the same error then we > >>> could try figuring out what is different in our setups? > >>> > >>> Best, > >>> Peter > >>> > >>> > >>> > >>> > >>> On Sat, Feb 19, 2022 at 6:29 PM Eric Broch <
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Does your legacy server qmail-1.03-2.2.1 send to all? On 2/23/2022 8:03 AM, Peter Peltonen wrote: Here is another error I have now seen qmail/send log about 10 times in the recent hour: TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small And this has now happened with two pretty big local service provider's servers as well. I don't think I can continue with the DEFAULT setting. I will now try to fall back to LEGACY and see if hornetsecurity.com accepts unencrypted connections. And I really do not understand the core of this problem: why cannot my server just have the whole range of ciphers and protocols in use and apply the most secure / appropriate one that the other party supports? Best, Peter On Wed, Feb 23, 2022 at 4:29 PM Eric Broch wrote: If I remember correctly it had something to do with Dovecot On Feb 23, 2022, at 2:25 AM, Peter Peltonen wrote: Hello, Okay I now tested:: With LEGACY (which I had earlier) I get the SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in qmail/send log: But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result And I did the test without rebooting nor restarting qmail. So apparently this command did the trick like Eric suggested: update-crypto-policies --set DEFAULT Now I wonder if this has some other consequences, what legacy stuff is now incompatible...? Best, Peter ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> kirjoitti: reboot On 2/21/2022 8:30 AM, Peter Peltonen wrote: Thanks Eric for the update. Here is what I see: [root@mail ~]# update-crypto-policies --show LEGACY [root@mail ~]# update-crypto-policies --set DEFAULT Setting system policy to DEFAULT Note: System-wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place. Is restarting qmail enough or should I even reboot? And is there some difference between DEFAULT and FUTURE or are they the same? Best, Peter On Mon, Feb 21, 2022 at 4:39 PM Eric Broch < ebr...@whitehorsetc.com> wrote: Upon further reflection, at the end of the qt/cos8 install script there is a command, 'update-crypto-policies --set LEGACY' intended for old email clients I don't wonder if this change between cos7 and cos8 might caused the problem. Have a look here: https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82 If you've change it to 'update-crypto-policies --set DEFAULT' or 'update-crypto-policies --set FUTURE' and are still having issue ask hornet security if we can see the actual smtp transaction. In my earlier email I was saying that there was not much difference between the old code and the new code for remote delivery and it was not immediately obvious why we would be having a problem. Eric On 2/21/2022 7:17 AM, Peter Peltonen wrote: Hi, Is there something I can test? I didn't quite understand from Eric's earlier msg what I should try... One email address producing this error for me is supp...@hornetsecurity.com -> If you like Eric, you could try emailing themselves asking for more details (either they reply to you or you will face the same error). If you don't face the same error then we could try figuring out what is different in our setups? Best, Peter On Sat, Feb 19, 2022 at 6:29 PM Eric Broch < ebr...@whitehorsetc.com> wrote: Looking through the function tls_init() in the code for qmail-remote.c I don't see much that it could be, they're almost identical between 2.2.1 and 3.3.5 Will continue looking... On 2/18/2022 1:54 PM, Andreas Galatis wrote: Hi Finn, I have tested with the tlsserverciphers of my older server, completed with some of the ciphers from the new file and my mails came through. Thanks a lot for your tip, Finn, I didn't find it in the code Andreas Am 18.02.22 um 16:56 schrieb Qmail: Hi Andreas. In qmail You're properly using /var/qmail/control/tlsclientciphers (that are a link to tlcserverciphers) According to what I read at the Nginx forum, the problem there is because some of the included ciphers are with underscore '_' and not hyphen '-' - I don't know if changing that in the tlsservercipher file will solve the problem. /Finn Den 18-02-2022 kl. 16:29 skrev Andreas: I cannot find any file where those ciphers could be adjust. Is that compiled in? Me too, I have clients not beeing reachable with the new server (qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt. Did anyone find a solution? Andreas Am 17.02.22 um 20:28 schrieb Qmail: Hi. Not sure it is related, but I just read in the Nginx forum that some have issues (failed (SSL: error:0AB9:SSL routines::no cipher match)) using Mozillas 'modern' 5.5 ciphers, but everything works with Mozillas 'modern' ciphers 4.0. (found testing the Nginx config) The 5.5 list contains : ssl_ciphers'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'; The 4.0 list contains:
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Here is another error I have now seen qmail/send log about 10 times in the recent hour: TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small And this has now happened with two pretty big local service provider's servers as well. I don't think I can continue with the DEFAULT setting. I will now try to fall back to LEGACY and see if hornetsecurity.com accepts unencrypted connections. And I really do not understand the core of this problem: why cannot my server just have the whole range of ciphers and protocols in use and apply the most secure / appropriate one that the other party supports? Best, Peter On Wed, Feb 23, 2022 at 4:29 PM Eric Broch wrote: > > If I remember correctly it had something to do with Dovecot > On Feb 23, 2022, at 2:25 AM, Peter Peltonen wrote: >> >> Hello, >> >> Okay I now tested:: >> >> With LEGACY (which I had earlier) I get the >> SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in qmail/send >> log: >> >> But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result >> >> And I did the test without rebooting nor restarting qmail. >> >> So apparently this command did the trick like Eric suggested: >> >> update-crypto-policies --set DEFAULT >> >> Now I wonder if this has some other consequences, what legacy stuff is now >> incompatible...? >> >> Best, >> Peter >> >> >> ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> >> kirjoitti: >>> >>> reboot >>> >>> On 2/21/2022 8:30 AM, Peter Peltonen wrote: >>> > Thanks Eric for the update. Here is what I see: >>> > >>> > [root@mail ~]# update-crypto-policies --show >>> > LEGACY >>> > [root@mail ~]# update-crypto-policies --set DEFAULT >>> > Setting system policy to DEFAULT >>> > Note: System-wide crypto policies are applied on application start-up. >>> > It is recommended to restart the system for the change of policies >>> > to fully take place. >>> > >>> > Is restarting qmail enough or should I even reboot? >>> > >>> > And is there some difference between DEFAULT and FUTURE or are they the >>> > same? >>> > >>> > Best, >>> > Peter >>> > >>> > On Mon, Feb 21, 2022 at 4:39 PM Eric Broch < ebr...@whitehorsetc.com> >>> > wrote: >>> >> Upon further reflection, at the end of the qt/cos8 install script there >>> >> is a command, 'update-crypto-policies --set LEGACY' intended for old >>> >> email clients I don't wonder if this change between cos7 and cos8 might >>> >> caused the problem. Have a look here: >>> >> >>> >> https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82 >>> >> >>> >> If you've change it to 'update-crypto-policies --set DEFAULT' or >>> >> 'update-crypto-policies --set FUTURE' and are still having issue ask >>> >> hornet security if we can see the actual smtp transaction. >>> >> >>> >> In my earlier email I was saying that there was not much difference >>> >> between the old code and the new code for remote delivery and it was not >>> >> immediately obvious why we would be having a problem. >>> >> >>> >> Eric >>> >> >>> >> >>> >> On 2/21/2022 7:17 AM, Peter Peltonen wrote: >>> >>> Hi, >>> >>> >>> >>> Is there something I can test? I didn't quite understand from Eric's >>> >>> earlier msg what I should try... >>> >>> >>> >>> One email address producing this error for me is >>> >>> supp...@hornetsecurity.com -> If you like Eric, you could try emailing >>> >>> themselves asking for more details (either they reply to you or you >>> >>> will face the same error). If you don't face the same error then we >>> >>> could try figuring out what is different in our setups? >>> >>> >>> >>> Best, >>> >>> Peter >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Sat, Feb 19, 2022 at 6:29 PM Eric Broch < ebr...@whitehorsetc.com> >>> >>> wrote: >>> Looking through the function tls_init() in the code for qmail-remote.c >>> >>> I don't see much that it could be, they're almost identical between >>> 2.2.1 and 3.3.5 >>> >>> Will continue looking... >>> >>> On 2/18/2022 1:54 PM, Andreas Galatis wrote: >>> > Hi Finn, >>> > >>> > >>> > I have tested with the tlsserverciphers of my older server, completed >>> > with some of the ciphers from the new file and my mails came through. >>> > >>> > >>> > Thanks a lot for your tip, Finn, I didn't find it in the code >>> > >>> > >>> > Andreas >>> > >>> > >>> > Am 18.02.22 um 16:56 schrieb Qmail: >>> >> Hi Andreas. >>> >> >>> >> In qmail You're properly using /var/qmail/control/tlsclientciphers >>> >> (that are a link to tlcserverciphers) >>> >> >>> >> According to what I read at the Nginx forum, the problem there is >>> >> because some of the included ciphers are with underscore '_' and not >>> >> hyphen '-' - I don't know if changing that in the tlsservercipher >>> >> file will solve the problem. >>> >> >>> >> >>> >> /Finn >>> >> >>> >> Den 18-02-2022 kl. 16:29 skrev
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
If I remember correctly it had something to do with Dovecot On Feb 23, 2022, 2:25 AM, at 2:25 AM, Peter Peltonen wrote: >Hello, > >Okay I now tested:: > >With LEGACY (which I had earlier) I get the >SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in >qmail/send log: > >But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the >result > >And I did the test without rebooting nor restarting qmail. > >So apparently this command did the trick like Eric suggested: > >update-crypto-policies --set DEFAULT > >Now I wonder if this has some other consequences, what legacy stuff is >now >incompatible...? > >Best, >Peter > > >ma 21. helmik. 2022 klo 17.55 Eric Broch >kirjoitti: > >> reboot >> >> On 2/21/2022 8:30 AM, Peter Peltonen wrote: >> > Thanks Eric for the update. Here is what I see: >> > >> > [root@mail ~]# update-crypto-policies --show >> > LEGACY >> > [root@mail ~]# update-crypto-policies --set DEFAULT >> > Setting system policy to DEFAULT >> > Note: System-wide crypto policies are applied on application >start-up. >> > It is recommended to restart the system for the change of policies >> > to fully take place. >> > >> > Is restarting qmail enough or should I even reboot? >> > >> > And is there some difference between DEFAULT and FUTURE or are they >the >> same? >> > >> > Best, >> > Peter >> > >> > On Mon, Feb 21, 2022 at 4:39 PM Eric Broch > >> wrote: >> >> Upon further reflection, at the end of the qt/cos8 install script >there >> >> is a command, 'update-crypto-policies --set LEGACY' intended for >old >> >> email clients I don't wonder if this change between cos7 and cos8 >might >> >> caused the problem. Have a look here: >> >> >> >> >https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82 >> >> >> >> If you've change it to 'update-crypto-policies --set DEFAULT' or >> >> 'update-crypto-policies --set FUTURE' and are still having issue >ask >> >> hornet security if we can see the actual smtp transaction. >> >> >> >> In my earlier email I was saying that there was not much >difference >> >> between the old code and the new code for remote delivery and it >was not >> >> immediately obvious why we would be having a problem. >> >> >> >> Eric >> >> >> >> >> >> On 2/21/2022 7:17 AM, Peter Peltonen wrote: >> >>> Hi, >> >>> >> >>> Is there something I can test? I didn't quite understand from >Eric's >> >>> earlier msg what I should try... >> >>> >> >>> One email address producing this error for me is >> >>> supp...@hornetsecurity.com -> If you like Eric, you could try >emailing >> >>> themselves asking for more details (either they reply to you or >you >> >>> will face the same error). If you don't face the same error then >we >> >>> could try figuring out what is different in our setups? >> >>> >> >>> Best, >> >>> Peter >> >>> >> >>> >> >>> >> >>> >> >>> On Sat, Feb 19, 2022 at 6:29 PM Eric Broch > >> wrote: >> Looking through the function tls_init() in the code for >qmail-remote.c >> >> I don't see much that it could be, they're almost identical >between >> 2.2.1 and 3.3.5 >> >> Will continue looking... >> >> On 2/18/2022 1:54 PM, Andreas Galatis wrote: >> > Hi Finn, >> > >> > >> > I have tested with the tlsserverciphers of my older server, >completed >> > with some of the ciphers from the new file and my mails came >through. >> > >> > >> > Thanks a lot for your tip, Finn, I didn't find it in the code >> > >> > >> > Andreas >> > >> > >> > Am 18.02.22 um 16:56 schrieb Qmail: >> >> Hi Andreas. >> >> >> >> In qmail You're properly using >/var/qmail/control/tlsclientciphers >> >> (that are a link to tlcserverciphers) >> >> >> >> According to what I read at the Nginx forum, the problem there >is >> >> because some of the included ciphers are with underscore '_' >and not >> >> hyphen '-' - I don't know if changing that in the >tlsservercipher >> >> file will solve the problem. >> >> >> >> >> >> /Finn >> >> >> >> Den 18-02-2022 kl. 16:29 skrev Andreas: >> >>> I cannot find any file where those ciphers could be adjust. >> >>> Is that compiled in? >> >>> >> >>> Me too, I have clients not beeing reachable with the new >server >> >>> (qmail-1.03-3.3.5), but my old server running >qmail-1.03.2.2.1.qt. >> >>> Did anyone find a solution? >> >>> >> >>> Andreas >> >>> >> >>> Am 17.02.22 um 20:28 schrieb Qmail: >> Hi. >> >> Not sure it is related, but I just read in the Nginx forum >that >> some have issues (failed (SSL: error:0AB9:SSL >routines::no >> cipher match)) using Mozillas 'modern' 5.5 ciphers, but >> everything >> works with Mozillas 'modern' ciphers 4.0. >> (found testing the Nginx config) >> >> The 5.5 list contains : >> >> >>
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
I've been now monitoring my qmail/send log and there has been now two instances of a new error: TLS_connect_failed:_error:1425F102:SSL_routines:ssl_choose_client_version:unsupported_protocol The other one was my own very old qmail box that can do only TLSv1.0/TLSv1.1. So apparently the new setting will break compatibility with the older servers, but I guess that is the expected behaviour with the DEFAULT setting. For now I will just monitor the send log and if I see problematic behaviour I will just add the hostnames to /var/qmail/control/notlshosts/ Best, Peter On Wed, Feb 23, 2022 at 11:25 AM Peter Peltonen wrote: > > Hello, > > Okay I now tested:: > > With LEGACY (which I had earlier) I get the > SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in qmail/send > log: > > But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result > > And I did the test without rebooting nor restarting qmail. > > So apparently this command did the trick like Eric suggested: > > update-crypto-policies --set DEFAULT > > Now I wonder if this has some other consequences, what legacy stuff is now > incompatible...? > > Best, > Peter > > > ma 21. helmik. 2022 klo 17.55 Eric Broch kirjoitti: >> >> reboot >> >> On 2/21/2022 8:30 AM, Peter Peltonen wrote: >> > Thanks Eric for the update. Here is what I see: >> > >> > [root@mail ~]# update-crypto-policies --show >> > LEGACY >> > [root@mail ~]# update-crypto-policies --set DEFAULT >> > Setting system policy to DEFAULT >> > Note: System-wide crypto policies are applied on application start-up. >> > It is recommended to restart the system for the change of policies >> > to fully take place. >> > >> > Is restarting qmail enough or should I even reboot? >> > >> > And is there some difference between DEFAULT and FUTURE or are they the >> > same? >> > >> > Best, >> > Peter >> > >> > On Mon, Feb 21, 2022 at 4:39 PM Eric Broch wrote: >> >> Upon further reflection, at the end of the qt/cos8 install script there >> >> is a command, 'update-crypto-policies --set LEGACY' intended for old >> >> email clients I don't wonder if this change between cos7 and cos8 might >> >> caused the problem. Have a look here: >> >> >> >> https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82 >> >> >> >> If you've change it to 'update-crypto-policies --set DEFAULT' or >> >> 'update-crypto-policies --set FUTURE' and are still having issue ask >> >> hornet security if we can see the actual smtp transaction. >> >> >> >> In my earlier email I was saying that there was not much difference >> >> between the old code and the new code for remote delivery and it was not >> >> immediately obvious why we would be having a problem. >> >> >> >> Eric >> >> >> >> >> >> On 2/21/2022 7:17 AM, Peter Peltonen wrote: >> >>> Hi, >> >>> >> >>> Is there something I can test? I didn't quite understand from Eric's >> >>> earlier msg what I should try... >> >>> >> >>> One email address producing this error for me is >> >>> supp...@hornetsecurity.com -> If you like Eric, you could try emailing >> >>> themselves asking for more details (either they reply to you or you >> >>> will face the same error). If you don't face the same error then we >> >>> could try figuring out what is different in our setups? >> >>> >> >>> Best, >> >>> Peter >> >>> >> >>> >> >>> >> >>> >> >>> On Sat, Feb 19, 2022 at 6:29 PM Eric Broch >> >>> wrote: >> Looking through the function tls_init() in the code for qmail-remote.c >> >> I don't see much that it could be, they're almost identical between >> 2.2.1 and 3.3.5 >> >> Will continue looking... >> >> On 2/18/2022 1:54 PM, Andreas Galatis wrote: >> > Hi Finn, >> > >> > >> > I have tested with the tlsserverciphers of my older server, completed >> > with some of the ciphers from the new file and my mails came through. >> > >> > >> > Thanks a lot for your tip, Finn, I didn't find it in the code >> > >> > >> > Andreas >> > >> > >> > Am 18.02.22 um 16:56 schrieb Qmail: >> >> Hi Andreas. >> >> >> >> In qmail You're properly using /var/qmail/control/tlsclientciphers >> >> (that are a link to tlcserverciphers) >> >> >> >> According to what I read at the Nginx forum, the problem there is >> >> because some of the included ciphers are with underscore '_' and not >> >> hyphen '-' - I don't know if changing that in the tlsservercipher >> >> file will solve the problem. >> >> >> >> >> >> /Finn >> >> >> >> Den 18-02-2022 kl. 16:29 skrev Andreas: >> >>> I cannot find any file where those ciphers could be adjust. >> >>> Is that compiled in? >> >>> >> >>> Me too, I have clients not beeing reachable with the new server >> >>> (qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt. >> >>> Did anyone find a solution? >> >>> >> >>> Andreas >> >>> >> >>> Am 17.02.22 um 20:28 schrieb
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Hello, Okay I now tested:: With LEGACY (which I had earlier) I get the SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in qmail/send log: But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result And I did the test without rebooting nor restarting qmail. So apparently this command did the trick like Eric suggested: update-crypto-policies --set DEFAULT Now I wonder if this has some other consequences, what legacy stuff is now incompatible...? Best, Peter ma 21. helmik. 2022 klo 17.55 Eric Broch kirjoitti: > reboot > > On 2/21/2022 8:30 AM, Peter Peltonen wrote: > > Thanks Eric for the update. Here is what I see: > > > > [root@mail ~]# update-crypto-policies --show > > LEGACY > > [root@mail ~]# update-crypto-policies --set DEFAULT > > Setting system policy to DEFAULT > > Note: System-wide crypto policies are applied on application start-up. > > It is recommended to restart the system for the change of policies > > to fully take place. > > > > Is restarting qmail enough or should I even reboot? > > > > And is there some difference between DEFAULT and FUTURE or are they the > same? > > > > Best, > > Peter > > > > On Mon, Feb 21, 2022 at 4:39 PM Eric Broch > wrote: > >> Upon further reflection, at the end of the qt/cos8 install script there > >> is a command, 'update-crypto-policies --set LEGACY' intended for old > >> email clients I don't wonder if this change between cos7 and cos8 might > >> caused the problem. Have a look here: > >> > >> https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82 > >> > >> If you've change it to 'update-crypto-policies --set DEFAULT' or > >> 'update-crypto-policies --set FUTURE' and are still having issue ask > >> hornet security if we can see the actual smtp transaction. > >> > >> In my earlier email I was saying that there was not much difference > >> between the old code and the new code for remote delivery and it was not > >> immediately obvious why we would be having a problem. > >> > >> Eric > >> > >> > >> On 2/21/2022 7:17 AM, Peter Peltonen wrote: > >>> Hi, > >>> > >>> Is there something I can test? I didn't quite understand from Eric's > >>> earlier msg what I should try... > >>> > >>> One email address producing this error for me is > >>> supp...@hornetsecurity.com -> If you like Eric, you could try emailing > >>> themselves asking for more details (either they reply to you or you > >>> will face the same error). If you don't face the same error then we > >>> could try figuring out what is different in our setups? > >>> > >>> Best, > >>> Peter > >>> > >>> > >>> > >>> > >>> On Sat, Feb 19, 2022 at 6:29 PM Eric Broch > wrote: > Looking through the function tls_init() in the code for qmail-remote.c > > I don't see much that it could be, they're almost identical between > 2.2.1 and 3.3.5 > > Will continue looking... > > On 2/18/2022 1:54 PM, Andreas Galatis wrote: > > Hi Finn, > > > > > > I have tested with the tlsserverciphers of my older server, completed > > with some of the ciphers from the new file and my mails came through. > > > > > > Thanks a lot for your tip, Finn, I didn't find it in the code > > > > > > Andreas > > > > > > Am 18.02.22 um 16:56 schrieb Qmail: > >> Hi Andreas. > >> > >> In qmail You're properly using /var/qmail/control/tlsclientciphers > >> (that are a link to tlcserverciphers) > >> > >> According to what I read at the Nginx forum, the problem there is > >> because some of the included ciphers are with underscore '_' and not > >> hyphen '-' - I don't know if changing that in the tlsservercipher > >> file will solve the problem. > >> > >> > >> /Finn > >> > >> Den 18-02-2022 kl. 16:29 skrev Andreas: > >>> I cannot find any file where those ciphers could be adjust. > >>> Is that compiled in? > >>> > >>> Me too, I have clients not beeing reachable with the new server > >>> (qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt. > >>> Did anyone find a solution? > >>> > >>> Andreas > >>> > >>> Am 17.02.22 um 20:28 schrieb Qmail: > Hi. > > Not sure it is related, but I just read in the Nginx forum that > some have issues (failed (SSL: error:0AB9:SSL routines::no > cipher match)) using Mozillas 'modern' 5.5 ciphers, but > everything > works with Mozillas 'modern' ciphers 4.0. > (found testing the Nginx config) > > The 5.5 list contains : > > > ssl_ciphers'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'; > > > The 4.0 list contains: > > >
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
reboot On 2/21/2022 8:30 AM, Peter Peltonen wrote: Thanks Eric for the update. Here is what I see: [root@mail ~]# update-crypto-policies --show LEGACY [root@mail ~]# update-crypto-policies --set DEFAULT Setting system policy to DEFAULT Note: System-wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place. Is restarting qmail enough or should I even reboot? And is there some difference between DEFAULT and FUTURE or are they the same? Best, Peter On Mon, Feb 21, 2022 at 4:39 PM Eric Broch wrote: Upon further reflection, at the end of the qt/cos8 install script there is a command, 'update-crypto-policies --set LEGACY' intended for old email clients I don't wonder if this change between cos7 and cos8 might caused the problem. Have a look here: https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82 If you've change it to 'update-crypto-policies --set DEFAULT' or 'update-crypto-policies --set FUTURE' and are still having issue ask hornet security if we can see the actual smtp transaction. In my earlier email I was saying that there was not much difference between the old code and the new code for remote delivery and it was not immediately obvious why we would be having a problem. Eric On 2/21/2022 7:17 AM, Peter Peltonen wrote: Hi, Is there something I can test? I didn't quite understand from Eric's earlier msg what I should try... One email address producing this error for me is supp...@hornetsecurity.com -> If you like Eric, you could try emailing themselves asking for more details (either they reply to you or you will face the same error). If you don't face the same error then we could try figuring out what is different in our setups? Best, Peter On Sat, Feb 19, 2022 at 6:29 PM Eric Broch wrote: Looking through the function tls_init() in the code for qmail-remote.c I don't see much that it could be, they're almost identical between 2.2.1 and 3.3.5 Will continue looking... On 2/18/2022 1:54 PM, Andreas Galatis wrote: Hi Finn, I have tested with the tlsserverciphers of my older server, completed with some of the ciphers from the new file and my mails came through. Thanks a lot for your tip, Finn, I didn't find it in the code Andreas Am 18.02.22 um 16:56 schrieb Qmail: Hi Andreas. In qmail You're properly using /var/qmail/control/tlsclientciphers (that are a link to tlcserverciphers) According to what I read at the Nginx forum, the problem there is because some of the included ciphers are with underscore '_' and not hyphen '-' - I don't know if changing that in the tlsservercipher file will solve the problem. /Finn Den 18-02-2022 kl. 16:29 skrev Andreas: I cannot find any file where those ciphers could be adjust. Is that compiled in? Me too, I have clients not beeing reachable with the new server (qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt. Did anyone find a solution? Andreas Am 17.02.22 um 20:28 schrieb Qmail: Hi. Not sure it is related, but I just read in the Nginx forum that some have issues (failed (SSL: error:0AB9:SSL routines::no cipher match)) using Mozillas 'modern' 5.5 ciphers, but everything works with Mozillas 'modern' ciphers 4.0. (found testing the Nginx config) The 5.5 list contains : ssl_ciphers'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'; The 4.0 list contains: ssl_ciphers'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; These are matched against the openssl ciphers that are located on the server but are more or less same as the tlsclientciphers used in qmail. Nginx can be setup as a MAIL proxy and therefore may be the reason for Your issue ?? or maybe it's just a coincidence ? Regards, Finn Den 17-02-2022 kl. 08:14 skrev Andreas: Hi list, I have the same failure-mails with some servers, my version of qmail is qmail-1.03-3.3.5.qt.md.el8.x86_64 TLS connect failed: error:1421C105:SSL routines:set_client_ciphersuite:wrong cipher returnedZConnected to 83.246.65.85 but connection died. With my old server (qmail-1.03-2.2.1.qt.el7.x86_64) I can send emails to the same recipients. Andreas Am 15.02.22 um 09:39 schrieb Peter Peltonen: What I have installed is qmail-1.03-3.3.1.qt.md.el8.x86_64 Any reason to update? Best, Peter On Sun, Feb 13, 2022 at 5:15 PM Eric Broch wrote: What version of qmail ? On 2/12/2022 12:56 PM, Peter Peltonen wrote: Finally got an answer from them (see list below). I see some matching siphers on their and on my own list. Any idea how I could debug this more so I can find out why mail is not being delivered to their server? best, Peter " OPTON All ciphers DESCRIPTION TLS encryption is only possible with ciphers that are
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Thanks Eric for the update. Here is what I see: [root@mail ~]# update-crypto-policies --show LEGACY [root@mail ~]# update-crypto-policies --set DEFAULT Setting system policy to DEFAULT Note: System-wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place. Is restarting qmail enough or should I even reboot? And is there some difference between DEFAULT and FUTURE or are they the same? Best, Peter On Mon, Feb 21, 2022 at 4:39 PM Eric Broch wrote: > > Upon further reflection, at the end of the qt/cos8 install script there > is a command, 'update-crypto-policies --set LEGACY' intended for old > email clients I don't wonder if this change between cos7 and cos8 might > caused the problem. Have a look here: > > https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82 > > If you've change it to 'update-crypto-policies --set DEFAULT' or > 'update-crypto-policies --set FUTURE' and are still having issue ask > hornet security if we can see the actual smtp transaction. > > In my earlier email I was saying that there was not much difference > between the old code and the new code for remote delivery and it was not > immediately obvious why we would be having a problem. > > Eric > > > On 2/21/2022 7:17 AM, Peter Peltonen wrote: > > Hi, > > > > Is there something I can test? I didn't quite understand from Eric's > > earlier msg what I should try... > > > > One email address producing this error for me is > > supp...@hornetsecurity.com -> If you like Eric, you could try emailing > > themselves asking for more details (either they reply to you or you > > will face the same error). If you don't face the same error then we > > could try figuring out what is different in our setups? > > > > Best, > > Peter > > > > > > > > > > On Sat, Feb 19, 2022 at 6:29 PM Eric Broch wrote: > >> Looking through the function tls_init() in the code for qmail-remote.c > >> > >> I don't see much that it could be, they're almost identical between > >> 2.2.1 and 3.3.5 > >> > >> Will continue looking... > >> > >> On 2/18/2022 1:54 PM, Andreas Galatis wrote: > >>> Hi Finn, > >>> > >>> > >>> I have tested with the tlsserverciphers of my older server, completed > >>> with some of the ciphers from the new file and my mails came through. > >>> > >>> > >>> Thanks a lot for your tip, Finn, I didn't find it in the code > >>> > >>> > >>> Andreas > >>> > >>> > >>> Am 18.02.22 um 16:56 schrieb Qmail: > Hi Andreas. > > In qmail You're properly using /var/qmail/control/tlsclientciphers > (that are a link to tlcserverciphers) > > According to what I read at the Nginx forum, the problem there is > because some of the included ciphers are with underscore '_' and not > hyphen '-' - I don't know if changing that in the tlsservercipher > file will solve the problem. > > > /Finn > > Den 18-02-2022 kl. 16:29 skrev Andreas: > > I cannot find any file where those ciphers could be adjust. > > Is that compiled in? > > > > Me too, I have clients not beeing reachable with the new server > > (qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt. > > Did anyone find a solution? > > > > Andreas > > > > Am 17.02.22 um 20:28 schrieb Qmail: > >> Hi. > >> > >> Not sure it is related, but I just read in the Nginx forum that > >> some have issues (failed (SSL: error:0AB9:SSL routines::no > >> cipher match)) using Mozillas 'modern' 5.5 ciphers, but everything > >> works with Mozillas 'modern' ciphers 4.0. > >> (found testing the Nginx config) > >> > >> The 5.5 list contains : > >> > >> ssl_ciphers'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'; > >> > >> > >> The 4.0 list contains: > >> > >> ssl_ciphers'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; > >> > >> > >> > >> These are matched against the openssl ciphers that are located on > >> the server but are more or less same as the tlsclientciphers used > >> in qmail. > >> > >> Nginx can be setup as a MAIL proxy and therefore may be the reason > >> for Your issue ?? > >> > >> or maybe it's just a coincidence ? > >> > >> Regards, > >> Finn > >> > >> > >> > >> Den 17-02-2022 kl. 08:14 skrev Andreas: > >>> Hi list, > >>> I have the same failure-mails with some servers, my version of > >>> qmail is > >>> qmail-1.03-3.3.5.qt.md.el8.x86_64 > >>> > >>> TLS connect failed: error:1421C105:SSL > >>> routines:set_client_ciphersuite:wrong > >>> cipher returnedZConnected to 83.246.65.85 but
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Upon further reflection, at the end of the qt/cos8 install script there is a command, 'update-crypto-policies --set LEGACY' intended for old email clients I don't wonder if this change between cos7 and cos8 might caused the problem. Have a look here: https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82 If you've change it to 'update-crypto-policies --set DEFAULT' or 'update-crypto-policies --set FUTURE' and are still having issue ask hornet security if we can see the actual smtp transaction. In my earlier email I was saying that there was not much difference between the old code and the new code for remote delivery and it was not immediately obvious why we would be having a problem. Eric On 2/21/2022 7:17 AM, Peter Peltonen wrote: Hi, Is there something I can test? I didn't quite understand from Eric's earlier msg what I should try... One email address producing this error for me is supp...@hornetsecurity.com -> If you like Eric, you could try emailing themselves asking for more details (either they reply to you or you will face the same error). If you don't face the same error then we could try figuring out what is different in our setups? Best, Peter On Sat, Feb 19, 2022 at 6:29 PM Eric Broch wrote: Looking through the function tls_init() in the code for qmail-remote.c I don't see much that it could be, they're almost identical between 2.2.1 and 3.3.5 Will continue looking... On 2/18/2022 1:54 PM, Andreas Galatis wrote: Hi Finn, I have tested with the tlsserverciphers of my older server, completed with some of the ciphers from the new file and my mails came through. Thanks a lot for your tip, Finn, I didn't find it in the code Andreas Am 18.02.22 um 16:56 schrieb Qmail: Hi Andreas. In qmail You're properly using /var/qmail/control/tlsclientciphers (that are a link to tlcserverciphers) According to what I read at the Nginx forum, the problem there is because some of the included ciphers are with underscore '_' and not hyphen '-' - I don't know if changing that in the tlsservercipher file will solve the problem. /Finn Den 18-02-2022 kl. 16:29 skrev Andreas: I cannot find any file where those ciphers could be adjust. Is that compiled in? Me too, I have clients not beeing reachable with the new server (qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt. Did anyone find a solution? Andreas Am 17.02.22 um 20:28 schrieb Qmail: Hi. Not sure it is related, but I just read in the Nginx forum that some have issues (failed (SSL: error:0AB9:SSL routines::no cipher match)) using Mozillas 'modern' 5.5 ciphers, but everything works with Mozillas 'modern' ciphers 4.0. (found testing the Nginx config) The 5.5 list contains : ssl_ciphers'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'; The 4.0 list contains: ssl_ciphers'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; These are matched against the openssl ciphers that are located on the server but are more or less same as the tlsclientciphers used in qmail. Nginx can be setup as a MAIL proxy and therefore may be the reason for Your issue ?? or maybe it's just a coincidence ? Regards, Finn Den 17-02-2022 kl. 08:14 skrev Andreas: Hi list, I have the same failure-mails with some servers, my version of qmail is qmail-1.03-3.3.5.qt.md.el8.x86_64 TLS connect failed: error:1421C105:SSL routines:set_client_ciphersuite:wrong cipher returnedZConnected to 83.246.65.85 but connection died. With my old server (qmail-1.03-2.2.1.qt.el7.x86_64) I can send emails to the same recipients. Andreas Am 15.02.22 um 09:39 schrieb Peter Peltonen: What I have installed is qmail-1.03-3.3.1.qt.md.el8.x86_64 Any reason to update? Best, Peter On Sun, Feb 13, 2022 at 5:15 PM Eric Broch wrote: What version of qmail ? On 2/12/2022 12:56 PM, Peter Peltonen wrote: Finally got an answer from them (see list below). I see some matching siphers on their and on my own list. Any idea how I could debug this more so I can find out why mail is not being delivered to their server? best, Peter " OPTON All ciphers DESCRIPTION TLS encryption is only possible with ciphers that are considered as secure by the German Federal Office for Information Security. A TLS connection is only established if the email server of the communication partner supports one of the following ciphers: • ECDHE-RSA-AES256-GCM-SHA384 • ECDHE-RSA-AES256-SHA384 • ECDHE-RSA-AES256-SHA • DHE-RSA-AES256-GCM-SHA384 • DHE-RSA-AES256-SHA256 • DHE-RSA-AES256-SHA • AES256-GCM-SHA384 • AES256-SHA256 • AES256-SHA • ECDHE-RSA-DES-CBC3-SHA • EDH-RSA-DES-CBC3-SHA • DES-CBC3-SHA OPTION Secure ciphers DESCRIPTION Secure ciphers TLS encryption is only possible with ciphers that are considered as
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Hi, Is there something I can test? I didn't quite understand from Eric's earlier msg what I should try... One email address producing this error for me is supp...@hornetsecurity.com -> If you like Eric, you could try emailing themselves asking for more details (either they reply to you or you will face the same error). If you don't face the same error then we could try figuring out what is different in our setups? Best, Peter On Sat, Feb 19, 2022 at 6:29 PM Eric Broch wrote: > > Looking through the function tls_init() in the code for qmail-remote.c > > I don't see much that it could be, they're almost identical between > 2.2.1 and 3.3.5 > > Will continue looking... > > On 2/18/2022 1:54 PM, Andreas Galatis wrote: > > Hi Finn, > > > > > > I have tested with the tlsserverciphers of my older server, completed > > with some of the ciphers from the new file and my mails came through. > > > > > > Thanks a lot for your tip, Finn, I didn't find it in the code > > > > > > Andreas > > > > > > Am 18.02.22 um 16:56 schrieb Qmail: > >> Hi Andreas. > >> > >> In qmail You're properly using /var/qmail/control/tlsclientciphers > >> (that are a link to tlcserverciphers) > >> > >> According to what I read at the Nginx forum, the problem there is > >> because some of the included ciphers are with underscore '_' and not > >> hyphen '-' - I don't know if changing that in the tlsservercipher > >> file will solve the problem. > >> > >> > >> /Finn > >> > >> Den 18-02-2022 kl. 16:29 skrev Andreas: > >>> I cannot find any file where those ciphers could be adjust. > >>> Is that compiled in? > >>> > >>> Me too, I have clients not beeing reachable with the new server > >>> (qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt. > >>> Did anyone find a solution? > >>> > >>> Andreas > >>> > >>> Am 17.02.22 um 20:28 schrieb Qmail: > Hi. > > Not sure it is related, but I just read in the Nginx forum that > some have issues (failed (SSL: error:0AB9:SSL routines::no > cipher match)) using Mozillas 'modern' 5.5 ciphers, but everything > works with Mozillas 'modern' ciphers 4.0. > (found testing the Nginx config) > > The 5.5 list contains : > > ssl_ciphers'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'; > > > The 4.0 list contains: > > ssl_ciphers'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; > > > > These are matched against the openssl ciphers that are located on > the server but are more or less same as the tlsclientciphers used > in qmail. > > Nginx can be setup as a MAIL proxy and therefore may be the reason > for Your issue ?? > > or maybe it's just a coincidence ? > > Regards, > Finn > > > > Den 17-02-2022 kl. 08:14 skrev Andreas: > > Hi list, > > I have the same failure-mails with some servers, my version of > > qmail is > > qmail-1.03-3.3.5.qt.md.el8.x86_64 > > > > TLS connect failed: error:1421C105:SSL > > routines:set_client_ciphersuite:wrong > > cipher returnedZConnected to 83.246.65.85 but connection died. > > > > With my old server (qmail-1.03-2.2.1.qt.el7.x86_64) I can send > > emails to the same recipients. > > Andreas > > > > Am 15.02.22 um 09:39 schrieb Peter Peltonen: > >> What I have installed is qmail-1.03-3.3.1.qt.md.el8.x86_64 > >> > >> Any reason to update? > >> > >> Best, > >> Peter > >> > >> On Sun, Feb 13, 2022 at 5:15 PM Eric Broch > >> wrote: > >>> What version of qmail ? > >>> > >>> On 2/12/2022 12:56 PM, Peter Peltonen wrote: > Finally got an answer from them (see list below). I see some > matching > siphers on their and on my own list. Any idea how I could debug > this > more so I can find out why mail is not being delivered to their > server? > > best, > Peter > > " > OPTON > All ciphers > > DESCRIPTION > TLS encryption is only possible with ciphers that are > considered as > secure by the German Federal Office for Information Security. A > TLS > connection is only established if the email server of the > communication partner supports one of the following ciphers: > > • ECDHE-RSA-AES256-GCM-SHA384 > • ECDHE-RSA-AES256-SHA384 > • ECDHE-RSA-AES256-SHA > • DHE-RSA-AES256-GCM-SHA384 > • DHE-RSA-AES256-SHA256 > • DHE-RSA-AES256-SHA > • AES256-GCM-SHA384 > • AES256-SHA256 > • AES256-SHA >
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Looking through the function tls_init() in the code for qmail-remote.c I don't see much that it could be, they're almost identical between 2.2.1 and 3.3.5 Will continue looking... On 2/18/2022 1:54 PM, Andreas Galatis wrote: Hi Finn, I have tested with the tlsserverciphers of my older server, completed with some of the ciphers from the new file and my mails came through. Thanks a lot for your tip, Finn, I didn't find it in the code Andreas Am 18.02.22 um 16:56 schrieb Qmail: Hi Andreas. In qmail You're properly using /var/qmail/control/tlsclientciphers (that are a link to tlcserverciphers) According to what I read at the Nginx forum, the problem there is because some of the included ciphers are with underscore '_' and not hyphen '-' - I don't know if changing that in the tlsservercipher file will solve the problem. /Finn Den 18-02-2022 kl. 16:29 skrev Andreas: I cannot find any file where those ciphers could be adjust. Is that compiled in? Me too, I have clients not beeing reachable with the new server (qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt. Did anyone find a solution? Andreas Am 17.02.22 um 20:28 schrieb Qmail: Hi. Not sure it is related, but I just read in the Nginx forum that some have issues (failed (SSL: error:0AB9:SSL routines::no cipher match)) using Mozillas 'modern' 5.5 ciphers, but everything works with Mozillas 'modern' ciphers 4.0. (found testing the Nginx config) The 5.5 list contains : ssl_ciphers'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'; The 4.0 list contains: ssl_ciphers'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; These are matched against the openssl ciphers that are located on the server but are more or less same as the tlsclientciphers used in qmail. Nginx can be setup as a MAIL proxy and therefore may be the reason for Your issue ?? or maybe it's just a coincidence ? Regards, Finn Den 17-02-2022 kl. 08:14 skrev Andreas: Hi list, I have the same failure-mails with some servers, my version of qmail is qmail-1.03-3.3.5.qt.md.el8.x86_64 TLS connect failed: error:1421C105:SSL routines:set_client_ciphersuite:wrong cipher returnedZConnected to 83.246.65.85 but connection died. With my old server (qmail-1.03-2.2.1.qt.el7.x86_64) I can send emails to the same recipients. Andreas Am 15.02.22 um 09:39 schrieb Peter Peltonen: What I have installed is qmail-1.03-3.3.1.qt.md.el8.x86_64 Any reason to update? Best, Peter On Sun, Feb 13, 2022 at 5:15 PM Eric Broch wrote: What version of qmail ? On 2/12/2022 12:56 PM, Peter Peltonen wrote: Finally got an answer from them (see list below). I see some matching siphers on their and on my own list. Any idea how I could debug this more so I can find out why mail is not being delivered to their server? best, Peter " OPTON All ciphers DESCRIPTION TLS encryption is only possible with ciphers that are considered as secure by the German Federal Office for Information Security. A TLS connection is only established if the email server of the communication partner supports one of the following ciphers: • ECDHE-RSA-AES256-GCM-SHA384 • ECDHE-RSA-AES256-SHA384 • ECDHE-RSA-AES256-SHA • DHE-RSA-AES256-GCM-SHA384 • DHE-RSA-AES256-SHA256 • DHE-RSA-AES256-SHA • AES256-GCM-SHA384 • AES256-SHA256 • AES256-SHA • ECDHE-RSA-DES-CBC3-SHA • EDH-RSA-DES-CBC3-SHA • DES-CBC3-SHA OPTION Secure ciphers DESCRIPTION Secure ciphers TLS encryption is only possible with ciphers that are considered as secure by the German Federal Office for Information Security. A TLS connection is only established if the email server of the communication partner supports one of the following ciphers: • ECDHE-RSA-AES256-GCM-SHA384 • ECDHE-RSA-AES256-SHA384 • DHE-RSA-AES256-GCM-SHA384 • DHE-RSA-AES256-SHA256 • ECDHE-RSA-AES128-GCM-SHA256 • ECDHE-RSA-AES128-SHA256 • DHE-RSA-AES128-GCM-SHA256 • DHE-RSA-AES128-SHA256 " On Mon, Feb 7, 2022 at 4:08 PM Eric Broch wrote: Is there a way to contact them and find out what obscure B.S. they want? On 2/7/2022 12:26 AM, Peter Peltonen wrote: When trying to deliver email to a domain that is using spam protection from antispameurope.com I get the following error: deferral: TLS_connect_failed:_error:1421C105:SSL_routines:set_client_ciphersuite:wrong_cipher_returnedZConnected_to_83.246.65.85_but_connection_died._(#4.4.2)/ So am I missing something here: [root@mail ~]# cat /var/qmail/control/tlsclientciphers
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Hi Finn, I have tested with the tlsserverciphers of my older server, completed with some of the ciphers from the new file and my mails came through. Thanks a lot for your tip, Finn, I didn't find it in the code Andreas Am 18.02.22 um 16:56 schrieb Qmail: Hi Andreas. In qmail You're properly using /var/qmail/control/tlsclientciphers (that are a link to tlcserverciphers) According to what I read at the Nginx forum, the problem there is because some of the included ciphers are with underscore '_' and not hyphen '-' - I don't know if changing that in the tlsservercipher file will solve the problem. /Finn Den 18-02-2022 kl. 16:29 skrev Andreas: I cannot find any file where those ciphers could be adjust. Is that compiled in? Me too, I have clients not beeing reachable with the new server (qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt. Did anyone find a solution? Andreas Am 17.02.22 um 20:28 schrieb Qmail: Hi. Not sure it is related, but I just read in the Nginx forum that some have issues (failed (SSL: error:0AB9:SSL routines::no cipher match)) using Mozillas 'modern' 5.5 ciphers, but everything works with Mozillas 'modern' ciphers 4.0. (found testing the Nginx config) The 5.5 list contains : ssl_ciphers'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'; The 4.0 list contains: ssl_ciphers'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; These are matched against the openssl ciphers that are located on the server but are more or less same as the tlsclientciphers used in qmail. Nginx can be setup as a MAIL proxy and therefore may be the reason for Your issue ?? or maybe it's just a coincidence ? Regards, Finn Den 17-02-2022 kl. 08:14 skrev Andreas: Hi list, I have the same failure-mails with some servers, my version of qmail is qmail-1.03-3.3.5.qt.md.el8.x86_64 TLS connect failed: error:1421C105:SSL routines:set_client_ciphersuite:wrong cipher returnedZConnected to 83.246.65.85 but connection died. With my old server (qmail-1.03-2.2.1.qt.el7.x86_64) I can send emails to the same recipients. Andreas Am 15.02.22 um 09:39 schrieb Peter Peltonen: What I have installed is qmail-1.03-3.3.1.qt.md.el8.x86_64 Any reason to update? Best, Peter On Sun, Feb 13, 2022 at 5:15 PM Eric Broch wrote: What version of qmail ? On 2/12/2022 12:56 PM, Peter Peltonen wrote: Finally got an answer from them (see list below). I see some matching siphers on their and on my own list. Any idea how I could debug this more so I can find out why mail is not being delivered to their server? best, Peter " OPTON All ciphers DESCRIPTION TLS encryption is only possible with ciphers that are considered as secure by the German Federal Office for Information Security. A TLS connection is only established if the email server of the communication partner supports one of the following ciphers: • ECDHE-RSA-AES256-GCM-SHA384 • ECDHE-RSA-AES256-SHA384 • ECDHE-RSA-AES256-SHA • DHE-RSA-AES256-GCM-SHA384 • DHE-RSA-AES256-SHA256 • DHE-RSA-AES256-SHA • AES256-GCM-SHA384 • AES256-SHA256 • AES256-SHA • ECDHE-RSA-DES-CBC3-SHA • EDH-RSA-DES-CBC3-SHA • DES-CBC3-SHA OPTION Secure ciphers DESCRIPTION Secure ciphers TLS encryption is only possible with ciphers that are considered as secure by the German Federal Office for Information Security. A TLS connection is only established if the email server of the communication partner supports one of the following ciphers: • ECDHE-RSA-AES256-GCM-SHA384 • ECDHE-RSA-AES256-SHA384 • DHE-RSA-AES256-GCM-SHA384 • DHE-RSA-AES256-SHA256 • ECDHE-RSA-AES128-GCM-SHA256 • ECDHE-RSA-AES128-SHA256 • DHE-RSA-AES128-GCM-SHA256 • DHE-RSA-AES128-SHA256 " On Mon, Feb 7, 2022 at 4:08 PM Eric Broch wrote: Is there a way to contact them and find out what obscure B.S. they want? On 2/7/2022 12:26 AM, Peter Peltonen wrote: When trying to deliver email to a domain that is using spam protection from antispameurope.com I get the following error: deferral: TLS_connect_failed:_error:1421C105:SSL_routines:set_client_ciphersuite:wrong_cipher_returnedZConnected_to_83.246.65.85_but_connection_died._(#4.4.2)/ So am I missing something here: [root@mail ~]# cat /var/qmail/control/tlsclientciphers
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Hi list, I have the same failure-mails with some servers, my version of qmail is qmail-1.03-3.3.5.qt.md.el8.x86_64 TLS connect failed: error:1421C105:SSL routines:set_client_ciphersuite:wrong cipher returnedZConnected to 83.246.65.85 but connection died. With my old server (qmail-1.03-2.2.1.qt.el7.x86_64) I can send emails to the same recipients. Andreas Am 15.02.22 um 09:39 schrieb Peter Peltonen: What I have installed is qmail-1.03-3.3.1.qt.md.el8.x86_64 Any reason to update? Best, Peter On Sun, Feb 13, 2022 at 5:15 PM Eric Broch wrote: What version of qmail ? On 2/12/2022 12:56 PM, Peter Peltonen wrote: Finally got an answer from them (see list below). I see some matching siphers on their and on my own list. Any idea how I could debug this more so I can find out why mail is not being delivered to their server? best, Peter " OPTON All ciphers DESCRIPTION TLS encryption is only possible with ciphers that are considered as secure by the German Federal Office for Information Security. A TLS connection is only established if the email server of the communication partner supports one of the following ciphers: • ECDHE-RSA-AES256-GCM-SHA384 • ECDHE-RSA-AES256-SHA384 • ECDHE-RSA-AES256-SHA • DHE-RSA-AES256-GCM-SHA384 • DHE-RSA-AES256-SHA256 • DHE-RSA-AES256-SHA • AES256-GCM-SHA384 • AES256-SHA256 • AES256-SHA • ECDHE-RSA-DES-CBC3-SHA • EDH-RSA-DES-CBC3-SHA • DES-CBC3-SHA OPTION Secure ciphers DESCRIPTION Secure ciphers TLS encryption is only possible with ciphers that are considered as secure by the German Federal Office for Information Security. A TLS connection is only established if the email server of the communication partner supports one of the following ciphers: • ECDHE-RSA-AES256-GCM-SHA384 • ECDHE-RSA-AES256-SHA384 • DHE-RSA-AES256-GCM-SHA384 • DHE-RSA-AES256-SHA256 • ECDHE-RSA-AES128-GCM-SHA256 • ECDHE-RSA-AES128-SHA256 • DHE-RSA-AES128-GCM-SHA256 • DHE-RSA-AES128-SHA256 " On Mon, Feb 7, 2022 at 4:08 PM Eric Broch wrote: Is there a way to contact them and find out what obscure B.S. they want? On 2/7/2022 12:26 AM, Peter Peltonen wrote: When trying to deliver email to a domain that is using spam protection from antispameurope.com I get the following error: deferral: TLS_connect_failed:_error:1421C105:SSL_routines:set_client_ciphersuite:wrong_cipher_returnedZConnected_to_83.246.65.85_but_connection_died._(#4.4.2)/ So am I missing something here: [root@mail ~]# cat /var/qmail/control/tlsclientciphers
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
No update necessary. No difference in TLS, it is the same in 3.3.1 and 3.3.5. What about a shot in the dark as I'm at a loss (right now) as to what they want: Since tlsclientciphers is a link to tlsserverciphers I'm wondering if copying tlsserverciphers to tlsserverciphers.bak and only putting those allowable ciphers in tlsserverciphers. I'm not sure why it is a problem since all ciphers are being passed to the server host and it is indicating that the ones they want aren't among them. Eric On 2/15/2022 1:39 AM, Peter Peltonen wrote: What I have installed is qmail-1.03-3.3.1.qt.md.el8.x86_64 Any reason to update? Best, Peter On Sun, Feb 13, 2022 at 5:15 PM Eric Broch wrote: What version of qmail ? On 2/12/2022 12:56 PM, Peter Peltonen wrote: Finally got an answer from them (see list below). I see some matching siphers on their and on my own list. Any idea how I could debug this more so I can find out why mail is not being delivered to their server? best, Peter " OPTON All ciphers DESCRIPTION TLS encryption is only possible with ciphers that are considered as secure by the German Federal Office for Information Security. A TLS connection is only established if the email server of the communication partner supports one of the following ciphers: • ECDHE-RSA-AES256-GCM-SHA384 • ECDHE-RSA-AES256-SHA384 • ECDHE-RSA-AES256-SHA • DHE-RSA-AES256-GCM-SHA384 • DHE-RSA-AES256-SHA256 • DHE-RSA-AES256-SHA • AES256-GCM-SHA384 • AES256-SHA256 • AES256-SHA • ECDHE-RSA-DES-CBC3-SHA • EDH-RSA-DES-CBC3-SHA • DES-CBC3-SHA OPTION Secure ciphers DESCRIPTION Secure ciphers TLS encryption is only possible with ciphers that are considered as secure by the German Federal Office for Information Security. A TLS connection is only established if the email server of the communication partner supports one of the following ciphers: • ECDHE-RSA-AES256-GCM-SHA384 • ECDHE-RSA-AES256-SHA384 • DHE-RSA-AES256-GCM-SHA384 • DHE-RSA-AES256-SHA256 • ECDHE-RSA-AES128-GCM-SHA256 • ECDHE-RSA-AES128-SHA256 • DHE-RSA-AES128-GCM-SHA256 • DHE-RSA-AES128-SHA256 " On Mon, Feb 7, 2022 at 4:08 PM Eric Broch wrote: Is there a way to contact them and find out what obscure B.S. they want? On 2/7/2022 12:26 AM, Peter Peltonen wrote: When trying to deliver email to a domain that is using spam protection from antispameurope.com I get the following error: deferral: TLS_connect_failed:_error:1421C105:SSL_routines:set_client_ciphersuite:wrong_cipher_returnedZConnected_to_83.246.65.85_but_connection_died._(#4.4.2)/ So am I missing something here: [root@mail ~]# cat /var/qmail/control/tlsclientciphers
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
What I have installed is qmail-1.03-3.3.1.qt.md.el8.x86_64 Any reason to update? Best, Peter On Sun, Feb 13, 2022 at 5:15 PM Eric Broch wrote: > > What version of qmail ? > > On 2/12/2022 12:56 PM, Peter Peltonen wrote: > > Finally got an answer from them (see list below). I see some matching > > siphers on their and on my own list. Any idea how I could debug this > > more so I can find out why mail is not being delivered to their > > server? > > > > best, > > Peter > > > > " > > OPTON > > All ciphers > > > > DESCRIPTION > > TLS encryption is only possible with ciphers that are considered as > > secure by the German Federal Office for Information Security. A TLS > > connection is only established if the email server of the > > communication partner supports one of the following ciphers: > > > > • ECDHE-RSA-AES256-GCM-SHA384 > > • ECDHE-RSA-AES256-SHA384 > > • ECDHE-RSA-AES256-SHA > > • DHE-RSA-AES256-GCM-SHA384 > > • DHE-RSA-AES256-SHA256 > > • DHE-RSA-AES256-SHA > > • AES256-GCM-SHA384 > > • AES256-SHA256 > > • AES256-SHA > > • ECDHE-RSA-DES-CBC3-SHA > > • EDH-RSA-DES-CBC3-SHA > > • DES-CBC3-SHA > > > > OPTION > > Secure ciphers > > > > DESCRIPTION > > Secure ciphers TLS encryption is only possible with ciphers that are > > considered as secure by the German Federal Office for Information > > Security. A TLS connection is only established if the email > > server of the communication partner supports one of the following ciphers: > > > > • ECDHE-RSA-AES256-GCM-SHA384 > > • ECDHE-RSA-AES256-SHA384 > > • DHE-RSA-AES256-GCM-SHA384 > > • DHE-RSA-AES256-SHA256 > > • ECDHE-RSA-AES128-GCM-SHA256 > > • ECDHE-RSA-AES128-SHA256 > > • DHE-RSA-AES128-GCM-SHA256 > > • DHE-RSA-AES128-SHA256 > > " > > > > > > On Mon, Feb 7, 2022 at 4:08 PM Eric Broch wrote: > >> Is there a way to contact them and find out what obscure B.S. they want? > >> > >> On 2/7/2022 12:26 AM, Peter Peltonen wrote: > >>> When trying to deliver email to a domain that is using spam protection > >>> from antispameurope.com I get the following error: > >>> > >>> deferral: > >>> TLS_connect_failed:_error:1421C105:SSL_routines:set_client_ciphersuite:wrong_cipher_returnedZConnected_to_83.246.65.85_but_connection_died._(#4.4.2)/ > >>> > >>> So am I missing something here: > >>> > >>> [root@mail ~]# cat /var/qmail/control/tlsclientciphers > >>>
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
What version of qmail ? On 2/12/2022 12:56 PM, Peter Peltonen wrote: Finally got an answer from them (see list below). I see some matching siphers on their and on my own list. Any idea how I could debug this more so I can find out why mail is not being delivered to their server? best, Peter " OPTON All ciphers DESCRIPTION TLS encryption is only possible with ciphers that are considered as secure by the German Federal Office for Information Security. A TLS connection is only established if the email server of the communication partner supports one of the following ciphers: • ECDHE-RSA-AES256-GCM-SHA384 • ECDHE-RSA-AES256-SHA384 • ECDHE-RSA-AES256-SHA • DHE-RSA-AES256-GCM-SHA384 • DHE-RSA-AES256-SHA256 • DHE-RSA-AES256-SHA • AES256-GCM-SHA384 • AES256-SHA256 • AES256-SHA • ECDHE-RSA-DES-CBC3-SHA • EDH-RSA-DES-CBC3-SHA • DES-CBC3-SHA OPTION Secure ciphers DESCRIPTION Secure ciphers TLS encryption is only possible with ciphers that are considered as secure by the German Federal Office for Information Security. A TLS connection is only established if the email server of the communication partner supports one of the following ciphers: • ECDHE-RSA-AES256-GCM-SHA384 • ECDHE-RSA-AES256-SHA384 • DHE-RSA-AES256-GCM-SHA384 • DHE-RSA-AES256-SHA256 • ECDHE-RSA-AES128-GCM-SHA256 • ECDHE-RSA-AES128-SHA256 • DHE-RSA-AES128-GCM-SHA256 • DHE-RSA-AES128-SHA256 " On Mon, Feb 7, 2022 at 4:08 PM Eric Broch wrote: Is there a way to contact them and find out what obscure B.S. they want? On 2/7/2022 12:26 AM, Peter Peltonen wrote: When trying to deliver email to a domain that is using spam protection from antispameurope.com I get the following error: deferral: TLS_connect_failed:_error:1421C105:SSL_routines:set_client_ciphersuite:wrong_cipher_returnedZConnected_to_83.246.65.85_but_connection_died._(#4.4.2)/ So am I missing something here: [root@mail ~]# cat /var/qmail/control/tlsclientciphers
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Finally got an answer from them (see list below). I see some matching siphers on their and on my own list. Any idea how I could debug this more so I can find out why mail is not being delivered to their server? best, Peter " OPTON All ciphers DESCRIPTION TLS encryption is only possible with ciphers that are considered as secure by the German Federal Office for Information Security. A TLS connection is only established if the email server of the communication partner supports one of the following ciphers: • ECDHE-RSA-AES256-GCM-SHA384 • ECDHE-RSA-AES256-SHA384 • ECDHE-RSA-AES256-SHA • DHE-RSA-AES256-GCM-SHA384 • DHE-RSA-AES256-SHA256 • DHE-RSA-AES256-SHA • AES256-GCM-SHA384 • AES256-SHA256 • AES256-SHA • ECDHE-RSA-DES-CBC3-SHA • EDH-RSA-DES-CBC3-SHA • DES-CBC3-SHA OPTION Secure ciphers DESCRIPTION Secure ciphers TLS encryption is only possible with ciphers that are considered as secure by the German Federal Office for Information Security. A TLS connection is only established if the email server of the communication partner supports one of the following ciphers: • ECDHE-RSA-AES256-GCM-SHA384 • ECDHE-RSA-AES256-SHA384 • DHE-RSA-AES256-GCM-SHA384 • DHE-RSA-AES256-SHA256 • ECDHE-RSA-AES128-GCM-SHA256 • ECDHE-RSA-AES128-SHA256 • DHE-RSA-AES128-GCM-SHA256 • DHE-RSA-AES128-SHA256 " On Mon, Feb 7, 2022 at 4:08 PM Eric Broch wrote: > > Is there a way to contact them and find out what obscure B.S. they want? > > On 2/7/2022 12:26 AM, Peter Peltonen wrote: > > When trying to deliver email to a domain that is using spam protection > > from antispameurope.com I get the following error: > > > > deferral: > > TLS_connect_failed:_error:1421C105:SSL_routines:set_client_ciphersuite:wrong_cipher_returnedZConnected_to_83.246.65.85_but_connection_died._(#4.4.2)/ > > > > So am I missing something here: > > > > [root@mail ~]# cat /var/qmail/control/tlsclientciphers > >
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Is there a way to contact them and find out what obscure B.S. they want? On 2/7/2022 12:26 AM, Peter Peltonen wrote: When trying to deliver email to a domain that is using spam protection from antispameurope.com I get the following error: deferral: TLS_connect_failed:_error:1421C105:SSL_routines:set_client_ciphersuite:wrong_cipher_returnedZConnected_to_83.246.65.85_but_connection_died._(#4.4.2)/ So am I missing something here: [root@mail ~]# cat /var/qmail/control/tlsclientciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:ADH-SEED-SHA:SEED-SHA:IDEA-CBC-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES256-CCM:DHE-RSA-AES256-CCM8:DHE-RSA-AES256-CCM:ECDHE-ECDSA-ARIA256-GCM-SHA384:ECDHE-ARIA256-GCM-SHA384:DHE-DSS-ARIA256-GCM-SHA384:DHE-RSA-ARIA256-GCM-SHA384:ADH-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-AES128-CCM:DHE-RSA-AES128-CCM8:DHE-RSA-AES128-CCM:ECDHE-ECDSA-ARIA128-GCM-SHA256:ECDHE-ARIA128-GCM-SHA256:DHE-DSS-ARIA128-GCM-SHA256:DHE-RSA-ARIA128-GCM-SHA256:ADH-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:DHE-RSA-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA256-SHA256:ADH-AES256-SHA256:ADH-CAMELLIA256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA128-SHA256:DHE-DSS-CAMELLIA128-SHA256:ADH-AES128-SHA256:ADH-CAMELLIA128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:RSA-PSK-AES256-GCM-SHA384:DHE-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:DHE-PSK-AES256-CCM8:DHE-PSK-AES256-CCM:RSA-PSK-ARIA256-GCM-SHA384:DHE-PSK-ARIA256-GCM-SHA384:AES256-GCM-SHA384:AES256-CCM8:AES256-CCM:ARIA256-GCM-SHA384:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:PSK-AES256-CCM8:PSK-AES256-CCM:PSK-ARIA256-GCM-SHA384:RSA-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-CCM8:DHE-PSK-AES128-CCM:RSA-PSK-ARIA128-GCM-SHA256:DHE-PSK-ARIA128-GCM-SHA256:AES128-GCM-SHA256:AES128-CCM8:AES128-CCM:ARIA128-GCM-SHA256:PSK-AES128-GCM-SHA256:PSK-AES128-CCM8:PSK-AES128-CCM:PSK-ARIA128-GCM-SHA256:AES256-SHA256:CAMELLIA256-SHA256:AES128-SHA256:CAMELLIA128-SHA256:ECDHE-PSK-AES256-CBC-SHA384:ECDHE-PSK-AES256-CBC-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:RSA-PSK-AES256-CBC-SHA384:DHE-PSK-AES256-CBC-SHA384:RSA-PSK-AES256-CBC-SHA:DHE-PSK-AES256-CBC-SHA:ECDHE-PSK-CAMELLIA256-SHA384:RSA-PSK-CAMELLIA256-SHA384:DHE-PSK-CAMELLIA256-SHA384:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA384:PSK-AES256-CBC-SHA:PSK-CAMELLIA256-SHA384:ECDHE-PSK-AES128-CBC-SHA256:ECDHE-PSK-AES128-CBC-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:RSA-PSK-AES128-CBC-SHA256:DHE-PSK-AES128-CBC-SHA256:RSA-PSK-AES128-CBC-SHA:DHE-PSK-AES128-CBC-SHA:ECDHE-PSK-CAMELLIA128-SHA256:RSA-PSK-CAMELLIA128-SHA256:DHE-PSK-CAMELLIA128-SHA256:AES128-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA256:PSK-AES128-CBC-SHA:PSK-CAMELLIA128-SHA256 ? Best, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
