O SendMail suporta criptografia TLS de saída SEM adições ao arquivo sendmail.mc?

1

CentOS 5.x

O SendMail suporta TLS oportunista "fora da caixa"?

Estou acostumado a ter que adicionar explicitamente a seguinte sinopse para /etc/mail/sendmail.mc

define('confAUTH_MECHANISMS’, 'LOGIN PLAIN’)dnl
define('confCACERT_PATH’,'/etc/pki/tls/certs’)dnl
define('confCACERT’,' /etc/pki/tls/certs/intermediates.crt’)dnl
define('confSERVER_CERT’,' /etc/pki/tls/certs/tls-cert-public.pem’)dnl
define('confSERVER_KEY’,' /etc/pki/tls/certs/tls-cert-private.key‘)dnl
define('confCLIENT_CERT’,' /etc/pki/tls/certs/tls-cert-public.pem‘)dnl
define('confCLIENT_KEY’,' /etc/pki/tls/certs/tls-cert-private.key‘)dnl

No entanto, parece que o TLS de saída está funcionando sem que seja necessário estar lá. Observo os seguintes registros de entrega:

Mar  4 04:36:08 bob sendmail[23831]: q29Ja84u011122: from=<[email protected]>, size=3262, class=0, nrcpts=1, msgid=<[email protected]>, proto=ESMTP, daemon=MTA, relay=exch.foo.com [192.168.0.1]
Mar  4 04:36:08 bob sendmail[23834]: STARTTLS=client, relay=mx.remotefoo.com., version=TLSv1/SSLv3, verify=FAIL, cipher=AES128-SHA, bits=128/128
Mar  4 04:36:08 bob sendmail[23834]: q29Ja84u011122: to=<[email protected]>, delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=123262, relay=mx.remotefoo.com. [12.13.14.15], dsn=4.0.0, stat=Deferred: Connection reset by mx.remotefoo.com.

IP, endereços de e-mail e nomes de host foram renomeados para proteger os inocentes. =) A linha do meio é o que me confunde. Eu esperaria ver isso apenas se o sendmail realmente usar o TLS.

Isso é possível? Em caso afirmativo, onde estão as chaves públicas / privadas usadas para isso?

UPDATE

Estou revisitando esse problema porque ainda estou curioso. Aqui está o sendmail.mc completo (IPs alterados para proteger os inocentes):

divert(-1)
#
# DO NOT EDIT THIS FILE.  It is managed by the appliance node manager
# or create_smtp_profile script.  Any changes you make may be
# overwritten.
#
divert(0)
dnl #
dnl # This is the sendmail macro config file for m4. If you make changes to
dnl # /etc/mail/sendmail.mc, you will need to regenerate the
dnl # /etc/mail/sendmail.cf file by confirming that the sendmail-cf package is
dnl # installed and then performing a
dnl #
dnl #     make -C /etc/mail
dnl #
include('/usr/share/sendmail-cf/m4/cf.m4')dnl
VERSIONID('setup for linux-gnu')dnl
OSTYPE('linux-gnu')dnl
dnl #
dnl # Disable DNS lookups
FEATURE('nocanonify')dnl
define('confBIND_OPTS','-DNSRCH -DEFNAMES')dnl
dnl #
dnl # default logging level is 9, you might want to set it higher to
dnl # debug the configuration
dnl #
dnl define('confLOG_LEVEL', '9')dnl
define('confLOG_LEVEL', '9')dnl

dnl #
dnl # Uncomment and edit the following line if your outgoing mail needs to
dnl # be sent out through an external mail server:
dnl #

dnl #
dnl # Uncomment and edit the following line if your incoming mail needs to
dnl # be sent to an internal mail server:
dnl #
dnl define('MAIL_HUB','smtp.your.provider')dnl
dnl FEATURE('stickyhost')dnl
dnl #
define('confDOMAIN_NAME', 'subdomain.support.foo.com')dnl
define('confDEF_USER_ID',''8:12'')dnl
dnl define('confAUTO_REBUILD')dnl
define('confTO_CONNECT', '1m')dnl
define('confTRY_NULL_MX_LIST',true)dnl
define('confDONT_PROBE_INTERFACES',true)dnl
define('PROCMAIL_MAILER_PATH','/usr/bin/procmail')dnl
define('ALIAS_FILE', '/etc/aliases')dnl
define('STATUS_FILE', '/var/log/mail/statistics')dnl
define('UUCP_MAILER_MAX', '2000000')dnl
define('confUSERDB_SPEC', '/etc/mail/userdb.db')dnl
define('confPRIVACY_FLAGS', 'authwarnings,novrfy,noexpn,restrictqrun')dnl
define('confAUTH_OPTIONS', 'A')dnl
dnl #
dnl # The following allows relaying if the user authenticates, and disallows
dnl # plaintext authentication (PLAIN/LOGIN) on non-TLS links
dnl #
dnl define('confAUTH_OPTIONS', 'A p')dnl
dnl #
dnl # PLAIN is the preferred plaintext authentication method and used by
dnl # Mozilla Mail and Evolution, though Outlook Express and other MUAs do
dnl # use LOGIN. Other mechanisms should be used if the connection is not
dnl # guaranteed secure.
dnl # Please remember that saslauthd needs to be running for AUTH.
dnl #
dnl TRUST_AUTH_MECH('EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
dnl define('confAUTH_MECHANISMS', 'EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
dnl #
dnl # Rudimentary information on creating certificates for sendmail TLS:
dnl #     cd /usr/share/ssl/certs; make sendmail.pem
dnl # Complete usage:
dnl #     make -C /usr/share/ssl/certs usage
dnl #
dnl define('confCACERT_PATH','/usr/share/ssl/certs')
dnl define('confCACERT','/usr/share/ssl/certs/ca-bundle.crt')
dnl define('confSERVER_CERT','/usr/share/ssl/certs/sendmail.pem')
dnl define('confSERVER_KEY','/usr/share/ssl/certs/sendmail.pem')
dnl #
dnl # This allows sendmail to use a keyfile that is shared with OpenLDAP's
dnl # slapd, which requires the file to be readble by group ldap
dnl #
dnl define('confDONT_BLAME_SENDMAIL','groupreadablekeyfile')dnl
dnl #
dnl define('confTO_QUEUEWARN', '4h')dnl
dnl define('confTO_QUEUERETURN', '5d')dnl
define('confQUEUE_LA', '50')dnl
define('confREFUSE_LA', '50')dnl
define('confTO_IDENT', '0')dnl
dnl FEATURE(delay_checks)dnl
FEATURE('no_default_msa','dnl')dnl
FEATURE('smrsh','/usr/sbin/smrsh')dnl
FEATURE('mailertable','hash -o /etc/mail/mailertable.db')dnl
FEATURE('virtusertable','hash -o /etc/mail/virtusertable.db')dnl
FEATURE(redirect)dnl
FEATURE(always_add_domain)dnl
FEATURE(use_cw_file)dnl
FEATURE(use_ct_file)dnl
dnl #
dnl # The following limits the number of processes sendmail can fork to accept
dnl # incoming messages or process its message queues to 12.) sendmail refuses
dnl # to accept connections once it has reached its quota of child processes.
dnl #
dnl define('confMAX_DAEMON_CHILDREN', 12)dnl
dnl #
dnl # Limits the number of new connections per second. This caps the overhead
dnl # incurred due to forking new sendmail processes. May be useful against
dnl # DoS attacks or barrages of spam. (As mentioned below, a per-IP address
dnl # limit would be useful but is not available as an option at this writing.)
dnl #
dnl define('confCONNECTION_RATE_THROTTLE', 3)dnl
dnl #
dnl # The -t option will retry delivery if e.g. the user runs over his quota.
dnl #
FEATURE(local_procmail,'','procmail -t -Y -a $h -d $u')dnl
FEATURE('access_db','hash -T<TMPF> -o /etc/mail/access.db')dnl
FEATURE('blacklist_recipients')dnl
define('confDOUBLE_BOUNCE_ADDRESS', '')dnl
EXPOSED_USER('root')dnl
dnl #
dnl # The following causes sendmail to only listen on the IPv4 loopback address
dnl # 127.0.0.1 and not on any other network devices. Remove the loopback
dnl # address restriction to accept email from the internet or intranet.
dnl #
DAEMON_OPTIONS('Port=smtp,Addr=127.0.0.1, Name=MTA, InputMailFilters=')dnl
DAEMON_OPTIONS('Port=smtp, Addr=192.168.1.1,Name=MTA,Modifiers=b,InputMailFilters=')dnl
CLIENT_OPTIONS('Family=inet, Addr=192.168.1.1')dnl

dnl #
dnl # The following causes sendmail to additionally listen to port 587 for
dnl # mail from MUAs that authenticate. Roaming users who can't reach their
dnl # preferred sendmail daemon due to port 25 being blocked or redirected find
dnl # this useful.
dnl #
dnl DAEMON_OPTIONS('Port=submission, Name=MSA, M=Ea')dnl
dnl #
dnl # The following causes sendmail to additionally listen to port 465, but
dnl # starting immediately in TLS mode upon connecting. Port 25 or 587 followed
dnl # by STARTTLS is preferred, but roaming clients using Outlook Express can't
dnl # do STARTTLS on ports other than 25. Mozilla Mail can ONLY use STARTTLS
dnl # and doesn't support the deprecated smtps; Evolution <1.1.1 uses smtps
dnl # when SSL is enabled-- STARTTLS support is available in version 1.1.1.
dnl #
dnl # For this to work your OpenSSL certificates must be configured.
dnl #
dnl DAEMON_OPTIONS('Port=smtps, Name=TLSMTA, M=s')dnl
dnl #
dnl # The following causes sendmail to additionally listen on the IPv6 loopback
dnl # device. Remove the loopback address restriction listen to the network.
dnl #
dnl DAEMON_OPTIONS('port=smtp,Addr=::1, Name=MTA-v6, Family=inet6')dnl
dnl #
dnl # enable both ipv6 and ipv4 in sendmail:
dnl #
dnl DAEMON_OPTIONS('Name=MTA-v4, Family=inet, Name=MTA-v6, Family=inet6')
dnl #
dnl # We strongly recommend not accepting unresolvable domains if you want to
dnl # protect yourself from spam. However, the laptop and users on computers
dnl # that do not have 24x7 DNS do need this.
dnl #
FEATURE('accept_unresolvable_domains')dnl
dnl #
dnl FEATURE('relay_based_on_MX')dnl
dnl #
dnl # Also accept email sent to "localhost.localdomain" as local email.
dnl #
LOCAL_DOMAIN('localhost.localdomain')dnl
dnl #
dnl # The following example makes mail from this host and any additional
dnl # specified domains appear to be sent from mydomain.com
dnl #
dnl MASQUERADE_AS('mydomain.com')dnl
dnl #
dnl # masquerade not just the headers, but the envelope as well
dnl #
dnl FEATURE(masquerade_envelope)dnl
dnl #
dnl # masquerade not just @mydomainalias.com, but @*.mydomainalias.com as well
dnl #
dnl FEATURE(masquerade_entire_domain)dnl
dnl #
dnl MASQUERADE_DOMAIN(localhost)dnl
dnl MASQUERADE_DOMAIN(localhost.localdomain)dnl
dnl MASQUERADE_DOMAIN(mydomainalias.com)dnl
dnl MASQUERADE_DOMAIN(mydomain.lan)dnl



MAILER(smtp)dnl
MAILER(procmail)dnl

Também colecionei uma captura de pacote e confirmei que o servidor está, de fato, iniciando conexões TLS com a parte externa.

UPDATE # 2

Iniciei o registro em log todo (99) e enviei uma mensagem de teste para uma conta do Gmail. Estou percebendo detalhes interessantes:

Jun  6 12:55:10 foobox sendmail[1663]: r56Jsk7N001660: SMTP outgoing connect on foobox.foo.com
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS: ClientCertFile missing
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS: ClientKeyFile missing
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS: CACertPath missing
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS: CACertFile missing
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS: CRLFile missing
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=client, init=1
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=client, start=ok
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=client, info: fds=10/9, err=2
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=client, info: fds=10/9, err=2
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=client, get_verify: 20 get_peer: 0x8907258
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., version=TLSv1/SSLv3, verify=FAIL, cipher=RC4-SHA, bits=128/128
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=client, cert-subject=/C=US/ST=California/L=Mountain+20View/O=Google+20Inc/CN=mx.google.com, cert-issuer=/C=US/O=Google+20Inc/CN=Google+20Internet+20Authority, verifymsg=unable to get local issuer certificate
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=read, info: fds=10/9, err=2
Jun  6 12:55:10 foobox last message repeated 3 times
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=write, info: fds=10/9, err=3
Jun  6 12:55:10 foobox last message repeated 3 times
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=read, info: fds=10/9, err=2
Jun  6 12:55:10 foobox sendmail[1663]: r56Jsk7N001660: to=<[email protected]>, delay=00:00:07, xdelay=00:00:00, mailer=esmtp, pri=120015, relay=gmail-smtp-in.l.google.com. [74.125.129.27], dsn=2.0.0, stat=Sent (OK 198738510 s9si492345031pan.259 - gsmtp)
    
por Mike B 13.03.2012 / 21:35

2 respostas

2

Eu posso confirmar que estou vendo a mesma coisa, independentemente; uma instalação sendmail sem certificados configurados ainda está aproveitando o TLS ao enviar para um servidor que se anuncia como suporte a esse protocolo.

Para ver o que está acontecendo, executei uma captura de pacote com tcpdump -n -n -w /tmp/pax.dump port 25 and host 178.18.123.145 no servidor de envio e, em seguida, enviei esse pacote de dados para o wireshark, o que me disse:

Observecomoopacotedestacado(no.17)contéminformaçõesdecertificado,assimcomoopacotequatroanterior(no.13).Opacote13éocertificadodoservidor,comacadeiadeconfiança,epossui"Comprimento de certificados" de 2327 bytes. Este é o certificado do cliente e tem comprimento zero bytes (linha destacada na janela de decomposição de pacotes). Então, acho que há boas evidências para sugerir que o sendmail gera um par de chaves aleatório para propósitos do cliente e o apresenta com um certificado de tamanho zero.

Se você achar esse comportamento irritante, como eu fiz, você pode desativá-lo para comunicações com todos os hosts colocando

Try_TLS:                NO

em /etc/mail/access e regenerando access.db .

    
por 07.06.2013 / 19:05
0

Nas linhas de log que você apresenta, você vê verify=FAIL . De acordo com o livro de morcegos, um valor de FALHA para $ {verify} significa que

A certificate was presented but could not be verified.

Então poderia ser o caso que você atualizou seu sendmail.mc mas não produziu um novo sendmail.cf?

    
por 14.03.2012 / 10:25