[MlMt] 143 or 993 . . . and security

[Bill Cole]

WARNING: CIVIL DISAGREEMENT AHEAD!

TL;DR version: Read RFC8314 at https://tools.ietf.org/html/rfc8314

On 23 Jan 2020, at 5:18, Benny Kjær Nielsen wrote:

> On 23 Jan 2020, at 10:35, Marc ARC wrote:
>
>> At first we thought we’ll use port 993 since this is secure. But 
>> then we realised that port 143 can also be secure with StartTLS.
>> Or is 993 better since it secures before communicating and is it 
>> future proof ?
>
> Port 993 mainly exists for historical reasons.

I understand that point of view, and might have totally agreed a decade 
ago, but I think it has been overtaken by events, experience, and 
RFC8314.

Port 993 (and 995 for POP3: everything I say in this message about 
143/993 for IMAP4 also applies to 110/995 for POP3 if you support it.) 
were nearly the last cases of SSL/TLS 'wrapper' ports established in 
IETF standards, and they generated concern about the proliferation of 
such port reservations exhausting the supply of ports traditionally 
reserved for binding by "root" processes and deemed more trustworthy. In 
the same "SSL 3" draft specification which proposed those ports, port 
465 for SMTP was proposed but by the time that became the TLS 1.0 
specification, 465 was dropped as unjustifiable. HOWEVER, 465 as 
TLS-wrapped mail submission (NOT transport) has more recently been 
revived as a best practice: see below.

The reason that 993 remained is that unlike SMTP transport, which 
largely occurs between servers with no relationship more enduring than a 
single message handoff and without live human interaction, IMAP has a 
clear fixed client/server model with a presumption that the client 
software is being tended by a human customer of the server operator. 
Both sides of IMAP maintain confidential persistent state about their 
partner by necessity, so it is reasonable for a client to require an 
explicit port and session encryption configuration for each of the small 
number of servers it needs to communicate with.

> Personally, I would keep both ports open and make sure that the use of 
> STARTTLS is required for port 143. If you close one of these ports 
> then it'll likely affect users at some point when configuring an email 
> client which either defaults to 143 or 993 (or it might even not 
> support both).

This is reasonable advice for server operators who have a diverse set of 
legacy customers who use whatever client software they personally 
prefer. For more controlled environments (e.g. workplace mail systems) 
it is reasonable to abandon port 143 and STARTTLS and only support 993, 
because there are marginal security risks with making initial 
connections unencrypted and using STARTTLS. Whether to close port 143 
when you've been supporting it for existing users is a question that can 
only be answered by understanding your users and your support capacity. 
FWIW, there are no IMAP clients that support STARTTLS over port 143 but 
don't support TLS wrapper mode on port 993. However, If you have allowed 
a broad range of encryption & authentication options in the past, 
existing client configs may need radical change to work with a 993-only 
server.

>> And with SMTP we are confronted with a choice 25 or 465 or 587 ? We 
>> prefer 587 since it requires AUTH . . . but what about the security
>
> Port 587 is the standard for email submission (email client sending an 
> email) and is equivalent to 143 for IMAP (it uses STARTTLS). Port 465 
> is a mess (Microsoft), but some email clients might still expect it to 
> work (Microsoft).

The best practices for initial mail submission have changed. Port 465 
has been a mess but the way in which it remained a mess for 2 decades 
made RFC8314 a reasonable solution for making submission more

> Port 465 is kind of equivalent to port 993, but in practice I've seen 
> servers using port 465 with STARTTLS making it behave like port 587.

Yeah... That's bad and wrong to the point where nothing should 
accommodate a server doing it. Clients detecting that behavior should 
fail and alert with a message mocking the dubious competence and lineage 
  of the server admins involved. (Your mother was a hamster, and your 
father smelt of elderberries!)

> You'll also need port 25 because this is the standard port used when 
> SMTP servers talk to eachother.

Correct.

Port 25 is for SMTP *transport* not *submission*. Any mail server 
handling outbound transport might need to connect to any other mail 
server handling inbound transport anywhere on the Internet. SMTP has to 
start in cleartext because it always has and because it is hard to make 
sure that random SMTP servers on the Internet can always negotiate 
encryption that works. Similarly, while it is wise to prefer strong 
encryption protocols and ciphers for SMTP/STARTTLS, it is actually 
counter-productive to disallow all weaker encryption modes because SMTP 
servers will ultimately fall back to clear text transport if they can't 
make any encryption work. In simple terms: any encryption that can't be 
easily decrypted in real time by anyone who can capture it is safer than 
cleartext.

A common historical error has been to offer SMTP AUTH on port 25 to 
support submission. In the modern world this should never be needed and 
supporting submission and transport on the same channel make securing 
each function more error-prone.


> In a perfect world, only ports 25, 143 and 587 would exist.

I dissent!

In a perfect world, we'd have 25 (SMTP with lenient STARTTLS and no 
AUTH,) 465 (SMTP-like submission wrapped in TLS with mandatory AUTH,) 
and 993 (IMAP4 wrapped in TLS with mandatory AUTH.)

In the real world, the only things preventing that are widespread legacy 
configurations of capable clients and servers, a tiny population of 
legacy clients that can't do any encryption and/or any authentication, 
and a surprisingly large population of horrible firewalls (primarily 
Cisco PIX & ASA) which sit in front of clients or servers and break 
every extension to email since ~1990.

>> We have been googling but can’t seem to find the mail between the 
>> ports

I'm unclear on the meaning of this sentence...


> You'll probably get other opinions, but the important part is to 
> ensure that it's not possible to communicate on any port without 
> encryption enabled (with or without STARTTLS).

As stated, that is infeasible. See above my discussion of SMTP on port 
25. Obsolete mail servers and stupid firewalls will always be with us. 
Fully disabling cleartext as the last resort on port 25 will cause the 
loss of email until everyone gets working mail systems deployed in this 
century...

Demanding TLS (i.e. ports 465 and 993) is ideal. Requiring it via 
STARTTLS (ports 143 and 587) if you can't force the use of wrapped ports 
is essential.

> Security-wise, it is more important that you look into which TLS 
> protocols you allow on the server, but I'm not qualified to make any 
> recommendations on that: 
> https://en.wikipedia.org/wiki/Transport_Layer_Security

That's ONLY important for submission and IMAP4. For SMTP, it is safe and 
reasonable to disallow SSLv2 and SSLv3 but there are still sending 
machines out there which can't do anything better than TLSv1.0, which is 
still better than cleartext. Worse yet, many of those will attempt 
STARTTLS on servers that support it, but if they can't negotiate TLSv1.0 
they simply fail and never even try cleartext.

-- 
Bill Cole
bill at scconsult.com or billcole at apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)