[exim] Weirdness when forcing TLS and checking that its work…

Top Page
Delete this message
Reply to this message
Author: Mike Tubby
Date:  
To: exim users
Subject: [exim] Weirdness when forcing TLS and checking that its working in ACLs
All,

Some government departments that we work with asked us to increase email
security via "forced TLS" for which I developed a solution for:

    a) our public email relay servers (with upstream/downstream and
local/remote hosts - 4 legs) - this is moderately complex but all worked
first time

    b) our private email server/endpoint (with Exim+Dovecot and just in
and out) - should have been simpler but was weird

and on this journey I observed some strange behaviour.

Running Exim 4.93.04 compiled on AMD64 (Dell R320) with Devuan 3.0 Beowulf.


On our internal server I added the following at the top of the
acl_check_mail:

acl_check_mail:

        #
        # refuse all connections that are not TLS
        #
        deny    message = Connection not secure. You must use STARTTLS
to send to this server!
                logwrite = MAIL: Denied host
$sender_host_address:$sender_host_port not using TLS secure connection!
                ! encrypted = *


and it produced the following result:

2020-02-13 09:36:51 CONNECT: New connection from 195.171.43.2 port:
63615 -> 195.171.43.20 port: 587
2020-02-13 09:36:51 CONNECT: Accept connection from host: 195.171.43.2
in whitelist +relay_from_hosts
2020-02-13 09:36:51 HELO: Could not verify HELO/EHLO: [192.168.1.107]
from remote host: 195.171.43.2 (gate.thorcom.com)
2020-02-13 09:36:51 HELO: Accepted HELO/EHLO [192.168.1.107] from remote
host: 195.171.43.2 (gate.thorcom.com)
2020-02-13 09:36:51 CRYPTO: Client 195.171.43.2 port: 63615 issued STARTTLS
2020-02-13 09:36:51 HELO: Client 195.171.43.2:63615 using SSL/TLS
cipher: TLS1.3:TLS_AES_256_GCM_SHA384:256
2020-02-13 09:36:51 HELO: Could not verify HELO/EHLO: [192.168.1.107]
from remote host: 195.171.43.2 (gate.thorcom.com)
2020-02-13 09:36:51 HELO: Accepted HELO/EHLO [192.168.1.107] from remote
host: 195.171.43.2 (gate.thorcom.com)
2020-02-13 09:36:51 MAIL: Denied host 195.171.43.2:63615 not using TLS
secure connection!
2020-02-13 09:36:51 MAIL: Accept from gate.thorcom.com ([192.168.1.107])
[195.171.43.2] as in +relay_from_hosts
2020-02-13 09:36:51 RCPT: Accept non-local domain for outbound delivery


Which confused me for two reasons:

    1. It says 'deny' when the connection is, infact, secure - you can
see the TLS
    2. It says 'deny' and then carries on to the next rule and accepts
the MAIL command

Changing the acl to read:

acl_check_mail:

        #
        # report/check/deny TLS as approriate
        #
        warn    condition = ${if def:tls_in_cipher {1}{0}}
                logwrite = MAIL: Client
$sender_host_address:$sender_host_port using SSL/TLS cipher: $tls_in_cipher

        deny    condition = ${if def:tls_in_cipher {0}{1}}
                message = Connection not secure. You must use STARTTLS
to send mail to this server.
                logwrite = MAIL: Client
$sender_host_address:$sender_host_port NOT using TLS connection


gives consistent results as expected and either logs the cipher in use
or denies the connection.

What did I miss?


Mike