Mailing List Archive

Debugging TLS_connect_failed / Question on TLS
Hi,

a customer of mine complained that he can not send mail to a certain
domain. The NDR says:

<info@mattes-immobilien.de>:
TLS connect failed; connected to 217.115.151.70.
I'm not going to try again; this message has been in the queue too long.

The logs also says "TLS_connect_failed;_connected_to_217.115.151.70."

What I recognized when testing with dig and s_client is, that the DNS MX
is mail.mattes-immobilien.de but the server certificate protects
*.neutralerserver.de.

Questions:
a) Does qmail validate the hostname? (that would explain the problem)
b) Is there any way to get some more debuggin info from qmail
c) Is it possible to configure qmail to fallback to Non-SSL

I run netqmail 1.06 with DNS and Queue patch.

tia

Oliver

--
Protect your environment - close windows and adopt a penguin!
Re: Debugging TLS_connect_failed / Question on TLS [ In reply to ]
Hi

I'm not using TLS currently but am looking forward to using it, thus
I'm interested in the topic.

On October 23, 2015 8:37:05 AM CEST, Oliver Welter <mail@oliwel.de> wrote:
> I run netqmail 1.06 with DNS and Queue patch.

It is my understanding that netqmail does not include TLS support and
that those patches don't either, so you must have added another
patch. Perhaps this one?: http://inoa.net/qmail-tls/

> What I recognized when testing with dig and s_client is, that the DNS
> MX
> is mail.mattes-immobilien.de but the server certificate protects
> *.neutralerserver.de.
>
> Questions:
> a) Does qmail validate the hostname? (that would explain the problem)

I would hope so, since encryption without identity validation is
rather useless (men in the middle can then subvert it).

> b) Is there any way to get some more debuggin info from qmail

(Dunno.)

> c) Is it possible to configure qmail to fallback to Non-SSL

This again would easily allow MITM to defeat encryption, thus you
would only want that configurable per-server as
exceptions. http://inoa.net/qmail-tls/qmail-remote.txt shows how:

notlshosts/<FQDN>
qmail-remote will not try TLS on servers for which
this file exists (<FQDN> is the fully-qualified
domain name of the server). (tlshosts/<FQDN>.pem
takes precedence over this file however).

Since it seems that mattes-immobilien.de have a broken configuration,
why not tell them and ask them to fix it? I wonder how comes why they
haven't fixed it already, though, I hope it's not the case that other
MTAs make a reverse lookup on the IP and use that to compare with the
domain in the certificate? The RFC[1] does not seem to mention this,
but I haven't examined it closely.

[1] http://datatracker.ietf.org/doc/rfc3207/?include_text=1

Christian.
Re: Debugging TLS_connect_failed / Question on TLS [ In reply to ]
Hi,

On 2015-10-23 08:37, Oliver Welter wrote:
> Hi,
>
> a customer of mine complained that he can not send mail to a certain
> domain. The NDR says:
>
> <info@mattes-immobilien.de>:
> TLS connect failed; connected to 217.115.151.70.
> I'm not going to try again; this message has been in the queue too
> long.
>
> The logs also says "TLS_connect_failed;_connected_to_217.115.151.70."
>
> What I recognized when testing with dig and s_client is, that the DNS
> MX is mail.mattes-immobilien.de but the server certificate protects
> *.neutralerserver.de.
>
Just tried s_client and get:

...
140079687251600:error:14082174:SSL
routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3554:
...

So it seems that mail.mattes-immobilien.de is not correct configured.
The DH key is 512 bits.
>
> tia
>
> Oliver

regards
Kai
--
----------------------------------------
Dynamic DNS Service: www.dyndn.es
DynDN.eS is NOT dyn.com!!!
Re: Debugging TLS_connect_failed / Question on TLS [ In reply to ]
Hi Oliver,

seems your Qmail TLS implementation is broken. With s/qmail I get:

2015-10-23 20:57:59.253610500 info msg 28854308: bytes 1901 from <feh@fehcom.de> qp 17623 uid 7005
2015-10-23 20:57:59.354379500 starting delivery 699: msg 28854308 to remote postmaster@mattes-immobilien.de
2015-10-23 20:57:59.354383500 status: local 0/10 remote 1/100
2015-10-23 20:58:06.821585500 delivery 699: success: 217.115.151.70_TLS_transmitted_message_accepted./Remote_host_said:_250_2.0.0_t9NKvxqE028803_Message_accepted_for_delivery/
2015-10-23 20:58:06.821953500 status: local 0/10 remote 0/100


regards.
—eh.


Am 23.10.2015 um 08:37 schrieb Oliver Welter <mail@oliwel.de>:

> Hi,
>
> a customer of mine complained that he can not send mail to a certain domain. The NDR says:
>
> <info@mattes-immobilien.de>:
> TLS connect failed; connected to 217.115.151.70.
> I'm not going to try again; this message has been in the queue too long.
>
> The logs also says "TLS_connect_failed;_connected_to_217.115.151.70."
>
> What I recognized when testing with dig and s_client is, that the DNS MX is mail.mattes-immobilien.de but the server certificate protects *.neutralerserver.de.
>
> Questions:
> a) Does qmail validate the hostname? (that would explain the problem)
> b) Is there any way to get some more debuggin info from qmail
> c) Is it possible to configure qmail to fallback to Non-SSL
>
> I run netqmail 1.06 with DNS and Queue patch.
>
> tia
>
> Oliver
>
> --
> Protect your environment - close windows and adopt a penguin!
>

---
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id: 7E4034BE