Ports allocation for SMTP, POP and IMAP
| Protocol | Port | Allow Encryption? | Allow Plain? | STATUS | NOTE |
|---|---|---|---|---|---|
| SMTP | 25 | YES – explicit encryption: after connection is opened … using (command) STARTTLS | YES | RG | relay server2server |
| SMTP | 587 | YES – explicit encryption: after connection is opened … using (command) STARTTLS | YES | RG | submission client2server rfc2487 |
| SMTP | 465 | YES – implicit: as soon as connection is opened | NO | WK + CF | Read here more information |
| IMAP4 | 143 | YES – explicit encryption: after connection is opened … using (command) STARTTLS | YES | RG | rfc2595 |
| IMAPS | 993 | YES – implicit: as soon as connection is opened | NO | RG | |
| POP3 | 110 | YES – explicit encryption: after connection is opened … using (command) STARTTLS | YES | RG | rfc2595 |
| POP3S | 995 | YES – implicit: as soon as connection is opened | NO | RG |
WK: well-know (is not registered but is de facto used and well-know)
CF: conflict between RG e WK using this port (there different protocols that use the same port)
Implicit encryption:
use of this port requires use of encryption when connection is established (so there isn’t any in clear traffic)
Explicit encryption:
connection starts in clear and after, at some point, is upgraded to encrypted (with command STARTTLS) Note about the meaning of : STARTTLS/143&110 :
I mean protocols (IMAP/POP) over 143 and 110 using STARTTLS
SSL/993&995:
I mean protocols (IMAP/POP) IMAP/POP over port 993 and 995 (encryption as soon as connection is established)
Considerations :
SSL TLS (Vs.)
SSL is frequently used as synonym for SSLV2, SSLV3 and TLSV1.x (read here) : SSL and TLS are versions of the same protocol (read here and wiki). The version of encryption protocols (TLS or SSL) is decided in HELLO handshake between client and server.
Example :
[Server] ssl-srv-supports:SSLV2,SSLV3,TLSV1.0,TLSV1.1,TLSV1.2->MAX(ssl-srv-supports) is TLSV1.2
(Client) ssl-cli-supports:SSLV2,SSLV3->MAX(ssl-cli-support) is SSLV3
(Client) -- HELO MAX(ssl-cli-supports) -->[Server]
>[Server] MIN(SSLV3 ,MAX(ssl-srv-supports))=SSLV3
(Client) <-----HELO OK for SSLV3 --------[Server]
So connection is established in SSLV3 despite its depreciation and the server supports TLSV1.2
Are SSLV2/SSLV3 and 993/995 deprecated?
Do I have to use STARTTLS since SSL is deprecated?
SSLV2/SSLV3 -> YES this versions are deprecated for security issues
SSL/993&995 -> NO are not deprecated (*1) you can use, if you want, TLS on this ports.
(*1) Really ports 993 and 995 should be abandoned in advantage of STARTTLS/143&110 btw this is not happening.
So deprecation of SSL doesn’t mean that SSL/993&995&465 are deprecated too: from point of view of security 993/995 and 143/110 (after STARTTLS) are the same.
Ports 993 and 995 are not limited to use with version SSLV2/SSLV3 : if client and server agree they can use TLS version/
STARTTLS
STARTTLS is not related to the cryptographic protocols so it is not part of SSL/TLS specifications but is related to IMAP, POP, SMTP (and HTTP…) protocols:
https://tools.ietf.org/html/rfc2487
https://tools.ietf.org/html/rfc2595
STARTTLS is a command over an in clear () connection that asks to sever to upgrade the connection to encrypted () .
STARTTLS is not necessarily related to version TLS (cryptographic protocols) but connection after STARTTLS could be upgraded to SSLVx (and not necessarily to TLSVx.y)
Implicit Vs. Explicit
Explicit: the client issues STARTTLS command but, from users side can’t be verified if the connection continues in clear or encrypted.
Generally the 143&110 ports are associated (by the users) to in clear connection (so not secure )
Configuration could confuse the user: do 143&110 ports require or not encryptions?
Generally the 993&995 ports are associated (by the users) to the encrypted connections (secure ).
Configuration could be simpler : 993&995 requires for sure encryption.
STARTTLS isn’t protocol agnostic
Filtering
some issues if you want to close in clear traffic. There are ways in order to prevent use 143&110 in clear on server side. If you want to block, on user/company side, in clear traffic on 143&110 then this it is quite tricky: ports STARTTLS/143&110 can be used for both in clear and encrypted.
Proxying
Connection proxying (Stunel , proxy, nginx …): proxy of the connections can’t be protocol agnostic. STARTTLS has to be detected by the proxy in order to upgrade the connection to encrypted.
Termination of encryption
Termination of encryption on Balancer (with STARTTLS)… you might want to terminate the encrypted connection on the balancer… for example for load/performance reasons.
With use of implicit ports (e.g. 993,995 and 465) the Balancer is sure that connection is encrypted as soon as connection is established.
With use of explicit ports (e.g 143, 110…) the Balancer can’t figure out if connection has to be encrypted or not (only on the ports that are used).
With explicit encryption connection can be promoted to encrypted after that the connection is opened.
Balancer can’t be, in this case, protocol agnostic: it has to inspect the traffic and upgrade to encrypted connection when STARTTLS is issued by the client (only when STARTTLS is related to a SMTP/IMAP/POP command and not email data)
Authenticate
Authentication (login/password) should take its place only after the upgrade of the channel to secure (so after STARTTLS in case of explicit port).
Deployment
You might want to split, for some legacy matters, traffic to FrontEnds (FE): deploy dedicated accelerated instances of SMTP/IMAP/POP FrontEnd isn’t so easy.
Example split of traffic in order to:
– reserve some new (SSL accelerate) instances of FronEnd dedicated to the encrypted traffic
– some others FronEnd (old legacy and slow FronEnd) dedicated to in clear traffic
If there are requirements about the split of traffic based on use of encryptions: using of STARTTLS/143&110 can run in troubles .
Users adoption and growth curve
If you are switching to encryption for million of users then you would like to grow bit by bit for encryption adoption.
If you are adding new ports (implicit ports) dedicated to encryption (SSL/993&995) then “old” users have to proactively configure their email client in order to use new ports:
probably only new users and few old users will adopt encryption.
If you are switching to STARTTLS on (existing) 143 and 110 then “old” users could unawares switch to adopt encryption.
Therefore the SSL adoption using STARTTLS/143&110 could be potentially higher than using SSL/993&995
Security STARTTLS/143&110
There are security concerns related to use STARTTLS.
The first part of connection is in clear and a Man-in-the-Middle attack could force to continue the connection in clear (rejecting STARTTLS). Is not possible discover if server support STARTTLS without ask… and you are not sure if the the answer (“NO please continue in clear”) is from the right server.
http://www.postfix.org/CVE-2011-0411.html
How much emails & who encrypts
Source of data : https://www.google.com/transparencyreport/saferemail/
Add Comment