Giters

imthenachoman / How-To-Secure-A-Linux-Server

An evolving how-to guide for securing a Linux server.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Prefer TLS over STARTTLS

opened this issue · comments

commented

RFC 8314 recommends that you prefer implicit TLS on port 465 over STARTTLS on 587:

o TLS version 1.2 or greater be used for all traffic between MUAs
and Mail Submission Servers, and also between MUAs and Mail Access
Servers.

o MUAs and Mail Service Providers (MSPs) (a) discourage the use of
cleartext protocols for mail access and mail submission and
(b) deprecate the use of cleartext protocols for these purposes as
soon as practicable.

o Connections to Mail Submission Servers and Mail Access Servers be
made using "Implicit TLS" (as defined below), in preference to
connecting to the "cleartext" port and negotiating TLS using the
STARTTLS command or a similar command.

So I would at least recommend changing the GMail port used. I'm not sure what if any other changes are needed to be made to the document.

commented

I think port 465 is depreciated. That is what https://wiki.debian.org/GmailAndExim4 says. And https://tools.ietf.org/html/rfc8314#section-7.3 says the same thing.

Although STARTTLS on port 587 has been deployed, it has not replaced the deployed use of Implicit TLS submission on port 465.

Also https://stackoverflow.com/a/19942206/3383907:

SMTPS and its use on port 465 should remain nothing more than an historical footnote.

commented

That page hasn't been updated since 2017 (the RFC was published in 2018). It mentions the use of SSL and it is true that SSL should not be used (TLS should be preferred). Also, the section you quote talks about smtps. The wikipedia page should clarify the intent here:

Port 587 is the well-known port for submitting encrypted mail to a server, and uses STARTTLS. Some email service providers allow their customers to use the SMTPS protocol to access a TLS-encrypted version of the "submission" service on port 465. This is a different service from what the original IANA-registration dedicated the port to.

RFC 8314 aims to rectify this problem and integrate the use of port 465 as a TLS-encrypted "submission" port into the well-known port registrations published by IANA. The proposed service name is "submissions".

commented

I see. I could not get it to work on port 465. Have you? I will play with it this weekend to see if I can get it to work and if I can I will update the guide.

commented

Try this link from the exim documentation. I have not tested it myself, however.

The history of port numbers for TLS in SMTP is a little messy and has been contentious. As of RFC 8314, the common practice of using the historically allocated port 465 for "email submission but with TLS immediately upon connect instead of using STARTTLS" is officially blessed by the IETF, and recommended by them in preference to STARTTLS.

The name originally assigned to the port was “ssmtp” or “smtps”, but as clarity emerged over the dual roles of SMTP, for MX delivery and Email Submission, nomenclature has shifted. The modern name is now “submissions”.

This approach was, for a while, officially abandoned when encrypted SMTP was standardized, but many clients kept using it, even as the TCP port number was reassigned for other use. Thus you may encounter guidance claiming that you shouldn’t enable use of this port. In practice, a number of mail-clients have only ever supported submissions, not submission with STARTTLS upgrade. Ideally, offer both submission (587) and submissions (465) service.

Exim supports TLS-on-connect by means of the tls_on_connect_ports global option. Its value must be a list of port numbers; the most common use is expected to be:

tls_on_connect_ports = 465

The port numbers specified by this option apply to all SMTP connections, both via the daemon and via inetd. You still need to specify all the ports that the daemon uses (by setting daemon_smtp_ports or local_interfaces or the -oX command line option) because tls_on_connect_ports does not add an extra port – rather, it specifies different behaviour on a port that is defined elsewhere.

There is also a -tls-on-connect command line option. This overrides tls_on_connect_ports; it forces the TLS-only behaviour for all ports.

commented

Thanks. I have played with this for a bit and tried to Google around but can't figure it out. It doesn't appear that anyone is using 465 with exim4 and Gmail. I might try posting to SE.

commented

https://wiki.debian.org/Exim seems more up to date and uses the tls_on_connect_ports option. I will test it out in GCE and report back.

commented

Alright so I managed to get it working using a combination of the advice from https://wiki.debian.org/Exim and https://wiki.debian.org/GmailAndExim4. First:

dpkg-reconfigure exim4-config

Select:

  • mail sent by smarthost; no local mail
  • System mail name: localhost
  • IP-addresses to listen on: 127.0.0.1
  • Other destinations for which mail is accepted: leave blank
  • Visible domain name for local users: localhost
  • Outgoing smarthost: smtp.gmail.com::465
  • Dial-on-Demand: No
  • Split configuration files: No (personal preference)

Then check host smtp.gmail.com to see what hostnames we need to add to /etc/exim4/passwd.client. Then we edit it to have:

*.google.com:your-email:password

For TLS:

Generate a local cert: bash /usr/share/doc/exim4-base/examples/exim-gencert. I used localhost for the domain name.

Under 30_exim4-config_remote_smtp_smarthost add: protocol=smtps

In /etc/exim4/exim4.conf.localmacros add:

MAIN_TLS_ENABLE = 1 
REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS = *
TLS_ON_CONNECT_PORTS = 465 
REQUIRE_PROTOCOL = smtps

In /etc/exim4/exim4.conf.template, after .ifdef REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS ... .endif, add:

    .ifdef REQUIRE_PROTOCOL
        protocol = REQUIRE_PROTOCOL 
    .endif

Add the following after .ifdef MAIN_TLS_ENABLE:

    .ifdef TLS_ON_CONNECT_PORTS
        tls_on_connect_ports = TLS_ON_CONNECT_PORTS 
    .endif

Reload/generate the configuration from the template:

update-exim4.conf
systemctl restart exim4

Test it with echo "test" | mail -s "Test" your-email. And check the logs to see if it worked: sudo tail /var/log/exim4/mainlog

commented

Wow! This is great. I will test this and then accept the pull.

commented

In /etc/exim4/exim4.conf.template, CTRL+F for 30_exim4-config_remote_smtp_smarthost then add protocol=smtps.

Where exactly should protocol=smtps be added in the file?

commented

If I recall correctly, I put it under the comment header. If it's a split configuration, probably at the top of the file. If you run into problems I'll test it again in GCE.

commented

I think it might not be needed. I didn't set that part and followed the rest of it and it seems to have worked. I'll test more again in a new VM.

They sure don't make it easy to be secure, do they?

commented

According to the doc:

If this option is set to “smtps”, the default value for the port option changes to “smtps”, and the transport initiates TLS immediately after connecting, as an outbound SSL-on-connect, instead of using STARTTLS to upgrade.

The Internet standards bodies used to strongly discourage use of this mode, but as of RFC 8314 it is perferred over STARTTLS for message submission (as distinct from MTA-MTA communication).

So it might actually be needed. I will do some debugging to see whether or not STARTTLS is being used if this option is not set.

commented

Wasn't able to do much comprehensive testing but a port scan shows:

PORT    STATE SERVICE
22/tcp  open  ssh
25/tcp  open  smtp
465/tcp open  smtps

I will make minor modifications to the PR.

commented

I committed your changes and then made some slight updates/modifications. I also added a note with a link to your GitHub page. I hope that is okay. Thanks so much!