Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #225309 > unrolled thread
| Started by | Harald Dunkel <harri@afaics.de> |
|---|---|
| First post | 2020-07-27 11:00 +0200 |
| Last post | 2020-07-27 17:20 +0200 |
| Articles | 7 — 4 participants |
Back to article view | Back to linux.debian.user
ssl handshake problem with bugs.debian.org? Harald Dunkel <harri@afaics.de> - 2020-07-27 11:00 +0200
Re: ssl handshake problem with bugs.debian.org? Reco <recoverym4n@enotuniq.net> - 2020-07-27 11:10 +0200
Re: ssl handshake problem with bugs.debian.org? Sven Hartge <sven@svenhartge.de> - 2020-07-27 11:20 +0200
Re: ssl handshake problem with bugs.debian.org? Harald Dunkel <harald.dunkel@aixigo.com> - 2020-07-27 12:30 +0200
Re: ssl handshake problem with bugs.debian.org? Sven Hartge <sven@svenhartge.de> - 2020-07-27 14:00 +0200
Re: ssl handshake problem with bugs.debian.org? Harald Dunkel <harald.dunkel@aixigo.com> - 2020-07-27 15:40 +0200
Re: ssl handshake problem with bugs.debian.org? Sven Hartge <sven@svenhartge.de> - 2020-07-27 17:20 +0200
| From | Harald Dunkel <harri@afaics.de> |
|---|---|
| Date | 2020-07-27 11:00 +0200 |
| Subject | ssl handshake problem with bugs.debian.org? |
| Message-ID | <Ax79f-3Vg-1@gated-at.bofh.it> |
Hi folks, I've got a ssl handshake problem with bugs.debian.org on sending an EMail. My mta (OpenBSD 6.7, i.e. libressl) in the office says in its logfile : Jul 27 10:23:37 gate5a smtpd[67056]: d4df9298d18e1596 mta connecting address=smtp://209.87.16.39:25 host=buxtehude.debian.org Jul 27 10:23:37 gate5a smtpd[67056]: d4df9298d18e1596 mta connected Jul 27 10:23:39 gate5a smtpd[67056]: d4df9298d18e1596 mta tls ciphers=TLSv1.3:AEAD-AES256-GCM-SHA384:256 Jul 27 10:23:39 gate5a smtpd[67056]: d4df9298d18e1596 mta server-cert-check result="failure" Jul 27 10:23:39 gate5a smtpd[67056]: d4df9299bfe4df24 mta connecting address=smtp://[2607:f8f0:614:1::1274:39]:25 host=buxtehude.debian.org Jul 27 10:23:39 gate5a smtpd[67056]: d4df9298d18e1596 mta error reason=IO Error: error:1404C410:SSL routines:ST_OK:sslv3 alert handshake failure Jul 27 10:23:39 gate5a smtpd[67056]: smtp-out: Disabling route 5.145.142.10 <-> 209.87.16.39 (buxtehude.debian.org) for 15s Jul 27 10:23:39 gate5a smtpd[67056]: d4df9299bfe4df24 mta connected Jul 27 10:23:41 gate5a smtpd[67056]: d4df9299bfe4df24 mta tls ciphers=TLSv1.3:AEAD-AES256-GCM-SHA384:256 Jul 27 10:23:41 gate5a smtpd[67056]: d4df9299bfe4df24 mta server-cert-check result="failure" Jul 27 10:23:41 gate5a smtpd[67056]: d4df9299bfe4df24 mta error reason=IO Error: error:1404C410:SSL routines:ST_OK:sslv3 alert handshake failure Jul 27 10:23:41 gate5a smtpd[67056]: smtp-out: Disabling route [2001:67c:13b0:ffff::60] <-> [2607:f8f0:614:1::1274:39] (buxtehude.debian.org) for 15s Jul 27 10:23:41 gate5a smtpd[67056]: smtp-out: Address family mismatch on [connector:[2001:67c:13b0:ffff::60]->[relay:bugs.debian.org,smtp,sourcetable=<dynamic:2>,heloname=mail.aixigo.de],0x0] Jul 27 10:23:41 gate5a smtpd[67056]: smtp-out: Address family mismatch on [connector:5.145.142.10->[relay:bugs.debian.org,smtp,sourcetable=<dynamic:2>,heloname=mail.aixigo.de],0x0] : Please note the "sslv3 alert handshake failure". We send a bazillion of EMails via this MTA each day. This handshake problem shows up only for buxtehude, AFAICT. Is there a compatibility issue with openssl in Debian and libressl used in OpenBSD 6.7? AFAIU TLS 1.3 is not in libressl yet. Every helpful hint is highly appreciated. Harri
[toc] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2020-07-27 11:10 +0200 |
| Message-ID | <Ax7iV-4dZ-3@gated-at.bofh.it> |
| In reply to | #225309 |
Hi. On Mon, Jul 27, 2020 at 10:43:11AM +0200, Harald Dunkel wrote: > Hi folks, > > I've got a ssl handshake problem with bugs.debian.org on sending an EMail. > My mta (OpenBSD 6.7, i.e. libressl) in the office says in its logfile > > : > Jul 27 10:23:39 gate5a smtpd[67056]: d4df9298d18e1596 mta tls ciphers=TLSv1.3:AEAD-AES256-GCM-SHA384:256 > Jul 27 10:23:39 gate5a smtpd[67056]: d4df9298d18e1596 mta server-cert-check result="failure" This tells me that buxtehude does not support TLSv1.3 at all. $ nmap -6 -p 25 -sV --script ssl-enum-ciphers buxtehude.debian.org Starting Nmap 7.70 ( https://nmap.org ) at 2020-07-27 11:00 CEST Stats: 0:00:24 elapsed; 0 hosts completed (1 up), 1 undergoing Script Scan NSE Timing: About 95.74% done; ETC: 11:00 (0:00:01 remaining) Nmap scan report for buxtehude.debian.org (2607:f8f0:614:1::1274:39) Host is up (0.15s latency). Other addresses for buxtehude.debian.org (not scanned): 209.87.16.39 PORT STATE SERVICE VERSION 25/tcp open smtp Exim smtpd 4.92 | ssl-enum-ciphers: | TLSv1.0: | ciphers: | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | TLSv1.1: | ciphers: | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | TLSv1.2: | ciphers: | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A | TLS_DHE_RSA_WITH_AES_128_CCM (dh 2048) - A | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A | TLS_DHE_RSA_WITH_AES_256_CCM (dh 2048) - A | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (dh 2048) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_128_CCM (rsa 2048) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CCM (rsa 2048) - A | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A | compressors: | NULL | cipher preference: client |_ least strength: A > We send a bazillion of EMails via this MTA each day. This handshake > problem shows up only for buxtehude, AFAICT. Is there a compatibility > issue with openssl in Debian and libressl used in OpenBSD 6.7? AFAIU > TLS 1.3 is not in libressl yet. Hardly. It's rather buxtehude does not announce TLSv1.3 at all, and it may be attributed to the state of TLSv1.3 in GNUTLS (which exim-daemon-heavy should use). Reco
[toc] | [prev] | [next] | [standalone]
| From | Sven Hartge <sven@svenhartge.de> |
|---|---|
| Date | 2020-07-27 11:20 +0200 |
| Message-ID | <Ax7sB-4hd-5@gated-at.bofh.it> |
| In reply to | #225312 |
Reco <recoverym4n@enotuniq.net> wrote: > On Mon, Jul 27, 2020 at 10:43:11AM +0200, Harald Dunkel wrote: >> I've got a ssl handshake problem with bugs.debian.org on sending an EMail. >> My mta (OpenBSD 6.7, i.e. libressl) in the office says in its logfile >> >> : >> Jul 27 10:23:39 gate5a smtpd[67056]: d4df9298d18e1596 mta tls ciphers=TLSv1.3:AEAD-AES256-GCM-SHA384:256 >> Jul 27 10:23:39 gate5a smtpd[67056]: d4df9298d18e1596 mta server-cert-check result="failure" > This tells me that buxtehude does not support TLSv1.3 at all. > $ nmap -6 -p 25 -sV --script ssl-enum-ciphers buxtehude.debian.org Interesting. nmap shows the same for me, but testssl.sh does not: ,---- | Testing protocols via sockets | | SSLv2 not offered (OK) | SSLv3 not offered (OK) | TLS 1 offered (deprecated) | TLS 1.1 offered (deprecated) | TLS 1.2 offered (OK) | TLS 1.3 offered (OK): final | | Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC) | ----------------------------------------------------------------------------------------------------------------------------- | SSLv2 | - | SSLv3 | - | TLSv1 (no server order, thus listed by strength) | xc014 ECDHE-RSA-AES256-SHA ECDH 521 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | x39 DHE-RSA-AES256-SHA DH 2048 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA | x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA | xc013 ECDHE-RSA-AES128-SHA ECDH 521 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | x33 DHE-RSA-AES128-SHA DH 2048 AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA | x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA | TLSv1.1 (no server order, thus listed by strength) | xc014 ECDHE-RSA-AES256-SHA ECDH 521 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | x39 DHE-RSA-AES256-SHA DH 2048 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA | x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA | xc013 ECDHE-RSA-AES128-SHA ECDH 521 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | x33 DHE-RSA-AES128-SHA DH 2048 AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA | x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA | TLSv1.2 (no server order, thus listed by strength) | xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 521 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | xc014 ECDHE-RSA-AES256-SHA ECDH 521 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | x9f DHE-RSA-AES256-GCM-SHA384 DH 2048 AESGCM 256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | xcca8 ECDHE-RSA-CHACHA20-POLY1305 ECDH 521 ChaCha20 256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | xccaa DHE-RSA-CHACHA20-POLY1305 DH 2048 ChaCha20 256 TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | xc09f DHE-RSA-AES256-CCM DH 2048 AESCCM 256 TLS_DHE_RSA_WITH_AES_256_CCM | x39 DHE-RSA-AES256-SHA DH 2048 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA | x9d AES256-GCM-SHA384 RSA AESGCM 256 TLS_RSA_WITH_AES_256_GCM_SHA384 | xc09d AES256-CCM RSA AESCCM 256 TLS_RSA_WITH_AES_256_CCM | x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA | xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 521 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | xc013 ECDHE-RSA-AES128-SHA ECDH 521 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | x9e DHE-RSA-AES128-GCM-SHA256 DH 2048 AESGCM 128 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | xc09e DHE-RSA-AES128-CCM DH 2048 AESCCM 128 TLS_DHE_RSA_WITH_AES_128_CCM | xc09c AES128-CCM RSA AESCCM 128 TLS_RSA_WITH_AES_128_CCM | x33 DHE-RSA-AES128-SHA DH 2048 AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA | x9c AES128-GCM-SHA256 RSA AESGCM 128 TLS_RSA_WITH_AES_128_GCM_SHA256 | x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA | TLSv1.3 (no server order, thus listed by strength) | x1302 TLS_AES_256_GCM_SHA384 ECDH 253 AESGCM 256 TLS_AES_256_GCM_SHA384 | x1303 TLS_CHACHA20_POLY1305_SHA256 ECDH 253 ChaCha20 256 TLS_CHACHA20_POLY1305_SHA256 | x1301 TLS_AES_128_GCM_SHA256 ECDH 253 AESGCM 128 TLS_AES_128_GCM_SHA256 | x1304 TLS_AES_128_CCM_SHA256 ECDH 253 AESCCM 128 TLS_AES_128_CCM_SHA256 `---- But I think the error might be here: ,---- | Common Name (CN) buxtehude.debian.org | subjectAltName (SAN) missing -- no SAN is deprecated | Issuer Debian SMTP CA (Debian SMTP from NA) | Trust (hostname) via CN only -- CN only match is deprecated (same w/o SNI) | Chain of trust NOT ok (chain incomplete) `---- Debian uses their own CA to sign this certificate, which is fine for SMTP, which normally only uses opportunistic encryption. But if the client SMTP-Server is set to *verify* the certificate, it will fail. S! -- Sigmentation fault. Core dumped.
[toc] | [prev] | [next] | [standalone]
| From | Harald Dunkel <harald.dunkel@aixigo.com> |
|---|---|
| Date | 2020-07-27 12:30 +0200 |
| Message-ID | <Ax8ym-4Ty-7@gated-at.bofh.it> |
| In reply to | #225313 |
On 2020-07-27 11:17, Sven Hartge wrote: > > Debian uses their own CA to sign this certificate, which is fine for > SMTP, which normally only uses opportunistic encryption. > > But if the client SMTP-Server is set to *verify* the certificate, it > will fail. > Certificate verification is optional on my MTA. See the log file. AFAICT it ignored the failed certificate check and continued with the ssl handshake. *Then* it failed. It would be interesting to know whats written in the log files on buxtehude. Are there other similar incidents? Regards Harri
[toc] | [prev] | [next] | [standalone]
| From | Sven Hartge <sven@svenhartge.de> |
|---|---|
| Date | 2020-07-27 14:00 +0200 |
| Message-ID | <Ax9Xr-5Em-3@gated-at.bofh.it> |
| In reply to | #225315 |
Harald Dunkel <harald.dunkel@aixigo.com> wrote: > On 2020-07-27 11:17, Sven Hartge wrote: >> Debian uses their own CA to sign this certificate, which is fine for >> SMTP, which normally only uses opportunistic encryption. >> >> But if the client SMTP-Server is set to *verify* the certificate, it >> will fail. > Certificate verification is optional on my MTA. See the log file. > AFAICT it ignored the failed certificate check and continued with the > ssl handshake. *Then* it failed. Right. > It would be interesting to know whats written in the log files on > buxtehude. Are there other similar incidents? Does your MTA present a client certificate? Maybe buxtehude does not like that? When diagnosing SSL errors I also find it helpful to wireshark the connection to see which side exactly triggers the SSL Alert. That may help highlight the culprit here. Grüße, Sven. -- Sigmentation fault. Core dumped.
[toc] | [prev] | [next] | [standalone]
| From | Harald Dunkel <harald.dunkel@aixigo.com> |
|---|---|
| Date | 2020-07-27 15:40 +0200 |
| Message-ID | <Axbwe-6Jq-15@gated-at.bofh.it> |
| In reply to | #225319 |
[Multipart message — attachments visible in raw view] — view raw
On 2020-07-27 13:49, Sven Hartge wrote:
>
> Does your MTA present a client certificate? Maybe buxtehude does not
> like that?
>
Yes, it has a certificate. Whether buxtehude likes it I cannot say,
but it looks OK to me. Its a wildcard certificate, though:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
0b:4b:72:01:12:76:76:75:a8:ec:10:0d:11:36:7b:f8
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA
Validity
Not Before: Jul 9 00:00:00 2020 GMT
Not After : Sep 8 12:00:00 2022 GMT
Subject: C=DE, ST=Nordrhein-Westfalen, L=Aachen, O=aixigo AG, OU=Internet, CN=*.aixigo.de
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:c7:43:b9:e8:1b:5b:2c:b0:a8:26:05:d3:9f:06:
:
:
47:58:c2:17:be:c9:d8:26:7a:4b:45:d6:df:19:cb:
50:79
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:0F:80:61:1C:82:31:61:D5:2F:28:E7:8D:46:38:B4:2C:E1:C6:D9:E2
X509v3 Subject Key Identifier:
F7:5D:C6:13:97:9B:F8:D4:49:9E:EC:36:E1:B3:26:C2:12:BD:D2:8C
X509v3 Subject Alternative Name:
DNS:*.aixigo.de, DNS:aixigo.de, DNS:mail.aixigo.de
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:
:
:
BTW, the problem showed up first on June 17th.
> When diagnosing SSL errors I also find it helpful to wireshark the
> connection to see which side exactly triggers the SSL Alert. That may
> help highlight the culprit here.
>
See attachment. AFAICT this is all encrypted.
Regards
Harri
[toc] | [prev] | [next] | [standalone]
| From | Sven Hartge <sven@svenhartge.de> |
|---|---|
| Date | 2020-07-27 17:20 +0200 |
| Message-ID | <Axd50-7M3-15@gated-at.bofh.it> |
| In reply to | #225336 |
Harald Dunkel <harald.dunkel@aixigo.com> wrote: > [-- text/plain, encoding 7bit, charset: utf-8, 60 lines --] > On 2020-07-27 13:49, Sven Hartge wrote: >> >> Does your MTA present a client certificate? Maybe buxtehude does not >> like that? >> > Yes, it has a certificate. Whether buxtehude likes it I cannot say, > but it looks OK to me. Its a wildcard certificate, though: > Certificate: > Subject: C=DE, ST=Nordrhein-Westfalen, L=Aachen, O=aixigo AG, OU=Internet, CN=*.aixigo.de Wildcard or not shouldn't matter. What matters if the Server uses that certificate as a client certificate. > BTW, the problem showed up first on June 17th. >> When diagnosing SSL errors I also find it helpful to wireshark the >> connection to see which side exactly triggers the SSL Alert. That may >> help highlight the culprit here. >> > See attachment. AFAICT this is all encrypted. Yes, but with TLS1.0 to TLS1.2 you could see the Alert and the rejection of the connection unencrypted. But your server and buxtehude switch to TLS1.3 and that prevents that kind of information from showing, IIRC, including the handshake with the certificate exchange. So, unfortunately this seems to be a dead end. S° -- Sigmentation fault. Core dumped.
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.user
csiph-web