TLS errors with GMX/web.de
Hello, GMX and web.de started an initiative for secure E-Mail made in Germany... they turned TLS on. But in addition to that bold move the did something else that causes the following errors when they try to send mail to my postfix: postfix/smtpd[28706]: connect from mout.web.de[212.227.15.14] postfix/smtpd[28706]: SSL_accept error from mout.web.de[212.227.15.14]: 0 postfix/smtpd[28706]: warning: TLS library problem: 28706:error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert internal error:s3_pkt.c:1256:SSL alert number 80: postfix/smtpd[28706]: lost connection after STARTTLS from mout.web.de[212.227.15.14] postfix/smtpd[28706]: disconnect from mout.web.de[212.227.15.14] Postfix 2.9.6 running on Debian 7.1. This error ONLY occurs with their servers. My question is if anyone has an idea what could cause this error. My first guess is that they check certificates for validity and I only have an CACert certificate. Also I would like to know if anyone else sees this on their postfix? Currently I've disabled STARTTLS for their mailservers but of course I would like to use TLS if possible. Would increasing the tls log level reveal additional helpful information? Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
Re: TLS errors with GMX/web.de
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 20.08.2013 11:48, schrieb Sebastian Wiesinger: > This error ONLY occurs with their servers. My question is if > anyone has an idea what could cause this error. My first guess is > that they check certificates for validity and I only have an CACert > certificate. Also I would like to know if anyone else sees this on > their postfix? Still delivers fine for me (and my mail-server) running Postfix 2.10.1: Received: from mout.web.de (mout.web.de [212.227.15.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.modelnine.org (Postfix) with ESMTPS id 8854E3640A for ; Tue, 20 Aug 2013 08:35:39 +0200 (CEST) - -- - --- Heiko. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSEz9zAAoJEDMqpHf921/S1/gIAJolkXgx6z8yVWorTK2xG/F5 CbPJLXBgZhtLQg4zkoXPQGhImXGVK8SesH6fW6E8Pb/+PXROPOtmZ5azFjoBwQVX 6ihljFw8dCQxGW12CTSIs4AvYwv2peaGxWMkIufnSg57xl9b/grdbcujoekCZ70l FHFT4ZDlZ3X8V52VrvTolUrA0zA3vmzthuNxEhPY00EeSy5qn7usVhFPOhAcSf5T kwsGnCOo+Fsq8Eejqw4abCGSizO3hWO0tsmqUDo77t8Hp0Pih/yr2jggiwC0F3Xo T+HHGKCQC1ZSZ+4mLRU7tGk4aDEoaEZhMV955Tr6TYT6K7+29QoBXK+2+4Ru4eg= =stXd -END PGP SIGNATURE-
Re: TLS errors with GMX/web.de
* Heiko Wundram [2013-08-20 12:09]: > Still delivers fine for me (and my mail-server) running Postfix 2.10.1: > > Received: from mout.web.de (mout.web.de [212.227.15.3]) > (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) > (No client certificate requested) > by mail.modelnine.org (Postfix) with ESMTPS id 8854E3640A > for ; Tue, 20 Aug 2013 08:35:39 +0200 (CEST) Hi, what kind of certificate do you have? Official, selfsigned? I have one from CACert and I wonder if that is the problem... Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
Re: TLS errors with GMX/web.de
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 20.08.2013 12:12, schrieb Sebastian Wiesinger: > * Heiko Wundram [2013-08-20 12:09]: >> Still delivers fine for me (and my mail-server) running Postfix >> 2.10.1: >> >> Received: from mout.web.de (mout.web.de [212.227.15.3]) (using >> TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No >> client certificate requested) by mail.modelnine.org (Postfix) >> with ESMTPS id 8854E3640A for ; Tue, 20 >> Aug 2013 08:35:39 +0200 (CEST) > > what kind of certificate do you have? Official, selfsigned? I have > one from CACert and I wonder if that is the problem... Official certificate by StartSSL on this host, but I'm also getting inbound mail from web.de without problems on other systems that have self-singled certificates and do offer STARTTLS. I'd rather take a guess that your SSL library doesn't advertise a cipher spec that's accepted by the web.de servers (although I wouldn't know about restrictions they impose) - you might also simply want to try and test whether openssl s_client has anything to say about your exposed configuration. Anyway, testing mx.karotte.org from mail.modelnine.org seems to show that the connection should work in principle (I'm getting the same results as to SSL session negotiation as when I'm connecting to my MX): New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 1024 bit Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-GCM-SHA384 except for the fact that my key is 2048 bits, and yours is 1024 bits. - -- - --- Heiko. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSE0PuAAoJEDMqpHf921/SoWoIAJo5Vz2AJv7d2NJr4C6g88se 8Y/ItWFynoYmWuHmYgKYgmtHnLW7WQFq08k0TDrL1SsNJvc2al0T3cNvqEUTnENZ UoTsye0rfg6Zp9TIdj85DmmyBkKjKtMBgaEu+aeXB29CR6g5P1FcWIpNbpu1U+Cg f0pngeVVWGpMZdiCC0cctbROllarFaMQBtX9Cuxw74m92mRkMArDzErsFtB/dc6Z TSJtbb2BmH0uCduAGcBzrzMHHcP6eULIZgubp6gxGSNddlT+jEMPDTj/N2PPj7pi gcWk/Eh5eU/QcyeE7Q2kaZmVf5C7AZ70xD2nPFyDU80XUstKTCYXZM9ylFWMQTE= =PZ2s -END PGP SIGNATURE-
Re: TLS errors with GMX/web.de
On Aug 20, 2013, at 11:48, Sebastian Wiesinger wrote: > GMX and web.de started an initiative for secure E-Mail made in > Germany... they turned TLS on. > > But in addition to that bold move the did something else that causes > the following errors when they try to send mail to my postfix: > > postfix/smtpd[28706]: connect from mout.web.de[212.227.15.14] > postfix/smtpd[28706]: SSL_accept error from mout.web.de[212.227.15.14]: 0 > postfix/smtpd[28706]: warning: TLS library problem: 28706:error:14094438:SSL > routines:SSL3_READ_BYTES:tlsv1 alert internal error:s3_pkt.c:1256:SSL alert > number 80: > postfix/smtpd[28706]: lost connection after STARTTLS from > mout.web.de[212.227.15.14] > postfix/smtpd[28706]: disconnect from mout.web.de[212.227.15.14] > > Postfix 2.9.6 running on Debian 7.1. > > This error ONLY occurs with their servers. My question is if anyone > has an idea what could cause this error. My first guess is that they > check certificates for validity and I only have an CACert certificate. > Also I would like to know if anyone else sees this on their postfix? > > Currently I've disabled STARTTLS for their mailservers but of course I > would like to use TLS if possible. Would increasing the tls log level > reveal additional helpful information? Same Postfix, same Debian, from yesterday afternoon; == postfix/smtpd[25199]: connect from mout.web.de[212.227.15.14] postfix/smtpd[25199]: Anonymous TLS connection established from mout.web.de[212.227.15.14]: TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits) postfix/smtpd[25199]: 3cJRKD6cRCz5G: client=mout.web.de[212.227.15.14] postfix/smtpd[25199]: disconnect from mout.web.de[212.227.15.14] == Self-signed, 2048 bits certificate from our own root. Picks the same cipher and TLS version as in Heiko's example, it seems. Perhaps it's your certificate, perhaps your Postfix settings? No odd overrides for the defaults anywhere, forced cipher suites or anything? Aside from the certificate and key, these are our only non-default settings; smtpd_tls_loglevel = 1 smtpd_tls_security_level = may HTH, Joni
Re: TLS errors with GMX/web.de
* DTNX Postmaster [2013-08-20 12:57]: > Self-signed, 2048 bits certificate from our own root. Picks the same cipher > and TLS version as in Heiko's example, it seems. Perhaps it's your > certificate, perhaps your Postfix settings? No odd overrides for the defaults > anywhere, forced cipher suites or anything? > > Aside from the certificate and key, these are our only non-default settings; I found the problem... In addition to my normal certificate, I had an EC certificate. smtpd_tls_eccert_file=/etc/postfix/certs/cacert-karotte-ec.crt As soon as I removed that line it started working... Noone else had a problem with that certificate. For completeness here is the cert output: Certificate: Data: Version: 3 (0x2) Serial Number: 133035 (0x207ab) Signature Algorithm: sha1WithRSAEncryption Issuer: O=CAcert Inc., OU=http://www.CAcert.org, CN=CAcert Class 3 Root Validity Not Before: Aug 13 11:39:24 2013 GMT Not After : Aug 13 11:39:24 2015 GMT Subject: CN=*.karotte.org Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:6d:69:d6:06:1f:7c:b2:8d:2b:6b:a5:0e:d9:8f: c9:6c:cf:ad:32:3d:35:3b:82:a6:58:ea:38:66:ae: 3d:43:ac:b0:cd:41:28:c6:7a:f7:3f:da:cf:50:be: 93:a5:90:30:cb:98:9c:b7:a1:07:93:39:bf:32:7f: 01:9c:59:04:8a:7d:fc:72:e9:78:a9:e5:22:e7:22: 5d:b5:80:bf:77:e1:be:65:3d:ce:10:c4:f3:5c:52: 73:aa:80:56:81:02:29 ASN1 OID: secp384r1 X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Digital Signature, Key Encipherment, Key Agreement X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication, Netscape Server Gated Crypto, Microsoft Server Gated Crypto Authority Information Access: OCSP - URI:http://ocsp.cacert.org/ X509v3 CRL Distribution Points: Full Name: URI:http://crl.cacert.org/class3-revoke.crl X509v3 Subject Alternative Name: DNS:*.karotte.org, othername:, DNS:karotte.org, othername: Signature Algorithm: sha1WithRSAEncryption 04:ca:17:b7:09:b5:00:e0:9f:ac:9b:25:9f:4b:78:d9:fb:a5: ... Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
Re: TLS errors with GMX/web.de
On Tue, Aug 20, 2013 at 01:27:01PM +0200, Sebastian Wiesinger wrote:
> I found the problem... In addition to my normal certificate, I had an
> EC certificate.
>
> smtpd_tls_eccert_file=/etc/postfix/certs/cacert-karotte-ec.crt
Though I think OpenSSL will generally detect attempts to configure
a public key (certificate) without a matching private key, you
should check that the private key and certificate match:
(
# Adjust as necessary
certfile=/etc/postfix/certs/cacert-karotte-ec.crt # cert
pkeyfile=/etc/postfix/certs/cacert-karotte-ec.crt # private key
# Digest of public key from certificate:
openssl x509 -in ${certfile} -noout -pubkey |
openssl pkey -pubin -outform DER |
openssl dgst -sha1 -c
# Digest of public key from private key:
openssl pkey -in ${pkeyfile} -pubout -outform DER |
openssl dgst -sha1 -c
) | uniq -c
This should output a single digest with a count of "2".
> As soon as I removed that line it started working...
If you're willing to test briefly with the EC certificate re-enabled,
it would be helpful to capture a full packet capture tcpdump (aka
pcap) file with a failed delivery from gmx.de/web.de. Viewing this
with "wireshark" will show exactly where in the handshake the problem
ocurred and may shed some light on the reason.
After capturing all traffic from the source in question for a period of
time that includes at least one complete failed session, extract just that
session from the capture file by identifying the TCP source port of such a
session and running:
client_source_port=58459 # example adjust to match reality
tcpdump -s0 -r /tmp/full-capture.pcap -w /tmp/session-capture.pcap \
tcp port $client_source_port
The resulting output file should contain just a single TCP session with
three way handshake (SYN, SYN-ACK, ACK) and three-way shutdown
(FIN, FIN, ACK or in some cases either FIN or final ACK may be an RST).
Please post a URL to the binary PCAP file.
> Certificate:
> Subject Public Key Info:
> Public Key Algorithm: id-ecPublicKey
> Public-Key: (384 bit)
> pub:
> 04:6d:69:d6:06:1f:7c:b2:8d:2b:6b:a5:0e:d9:8f:
> c9:6c:cf:ad:32:3d:35:3b:82:a6:58:ea:38:66:ae:
> 3d:43:ac:b0:cd:41:28:c6:7a:f7:3f:da:cf:50:be:
> 93:a5:90:30:cb:98:9c:b7:a1:07:93:39:bf:32:7f:
> 01:9c:59:04:8a:7d:fc:72:e9:78:a9:e5:22:e7:22:
> 5d:b5:80:bf:77:e1:be:65:3d:ce:10:c4:f3:5c:52:
> 73:aa:80:56:81:02:29
> ASN1 OID: secp384r1
There are no known practical attacks on 256-bit EC keys and 384-bit
EC is slower. AES-128 with EC-256 is sufficiently secure for SMTP
TLS. Though I expect that if the sender has trouble with 384-bit
EC, they'll have trouble with EC in general.
--
Viktor.
Re: TLS errors with GMX/web.de
* Viktor Dukhovni [2013-08-20 16:51]: > > I found the problem... In addition to my normal certificate, I had an > > EC certificate. > > > > smtpd_tls_eccert_file=/etc/postfix/certs/cacert-karotte-ec.crt > > Though I think OpenSSL will generally detect attempts to configure > a public key (certificate) without a matching private key, you > should check that the private key and certificate match: Hi, yes I checked and they are matching. > If you're willing to test briefly with the EC certificate re-enabled, > it would be helpful to capture a full packet capture tcpdump (aka > pcap) file with a failed delivery from gmx.de/web.de. Viewing this > with "wireshark" will show exactly where in the handshake the problem > ocurred and may shed some light on the reason. I just did, here is the PCAP: http://www.karotte.org/smtp-gmx.pcap > There are no known practical attacks on 256-bit EC keys and 384-bit > EC is slower. AES-128 with EC-256 is sufficiently secure for SMTP > TLS. Though I expect that if the sender has trouble with 384-bit > EC, they'll have trouble with EC in general. I found no real guidance in regards to EC so I chose a higher one. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
Re: TLS errors with GMX/web.de
On Wed, Aug 21, 2013 at 10:44:40PM +0200, Sebastian Wiesinger wrote: > I just did, here is the PCAP: > > http://www.karotte.org/smtp-gmx.pcap The client sends an "internal error" alert. It is not clear what problem it is encountering. The server elects: Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) and the client purports to support the curve in the server certificate. I don't have the expertise to try to debug the server's key exchange message, but it it is typically secp256r1 aka prime256v1, which the client purports to support. > > There are no known practical attacks on 256-bit EC keys and 384-bit > > EC is slower. AES-128 with EC-256 is sufficiently secure for SMTP > > TLS. Though I expect that if the sender has trouble with 384-bit > > EC, they'll have trouble with EC in general. > > I found no real guidance in regards to EC so I chose a higher one. It may be overkill, but it should work. I am afraid the best path forward is for GMX to debug this with their client software. -- Viktor.
Re: TLS errors with GMX/web.de
* Viktor Dukhovni [2013-08-24 05:27]: > > > I just did, here is the PCAP: > > > > http://www.karotte.org/smtp-gmx.pcap > > The client sends an "internal error" alert. It is not clear what > problem it is encountering. The server elects: > > Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) > > and the client purports to support the curve in the server certificate. > I don't have the expertise to try to debug the server's key exchange > message, but it it is typically secp256r1 aka prime256v1, which the > client purports to support. > > It may be overkill, but it should work. I am afraid the best path > forward is for GMX to debug this with their client software. Yeah I'm not holding my breath for that. Is there a way to exclude the web.de/GMX mailservers from the EC certificate? Let postfix always use the other certificate for them? Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
Re: TLS errors with GMX/web.de
On Mon, Aug 26, 2013 at 12:04:28PM +0200, Sebastian Wiesinger wrote: > > It may be overkill, but it should work. I am afraid the best path > > forward is for GMX to debug this with their client software. > > Yeah I'm not holding my breath for that. Send them (postmaster@) a pointer to this thread, over time they'll have similar problems with more sites. > Is there a way to exclude the > web.de/GMX mailservers from the EC certificate? Let postfix always > use the other certificate for them? Only by redirecting their connections to a different port via NAT. The Postfix SMTP server has very minimal client-specific TLS policy: - You can disable STARTTLS support for a set of clients. smtpd_discard_ehlo_keyword_address_maps - You can do access control based on client certificates smtpd_tls_ask_ccert permit_tls_clientcerts check_ccert_access One of the main problems is that while the client knows who the server is (it chose to connect there), the server has little idea who the client is (IP address ranges change over time). Policies intended to improve interoperability with legitimate clients (that don't lie about their identity) could in principle do lookups based on the client EHLO name. Postfix does not yet have such features. -- Viktor.
