Using SSL on a mail server
-
If I am using an SSL cert on a mail server, behind a pfSense firewall, is there the need for a rule for outbound enrypted email? I have rules in for all the ports that are inbound, but cannot send mail when the SSL cert has been put in place and all the POP3 and IMAP accounts are using either Explicit or Implicit SSL.
-
A mail server sending email to another mail server will use port 25, regardless of whether or not it is encrypted. It is only encrypted by the virtue of the fact that the sending server will attempt a STARTTLS negotiation if the destination mail server advertises that it supports it during the initial handshake.
You can check this by telnetting to the server on port 25, and sending "EHLO moo". If it responds with 250-STARTTLS it supports TLS and can encrypt the channel.
Note that just because it advertises STARTTLS doesn't mean it will work, for example it hasn't been configured properly.# telnet smtp.gmail.com 25 Trying 173.194.206.108... Connected to smtp.gmail.com. Escape character is '^]'. 220 smtp.gmail.com ESMTP f124sm2992878qkj.57 - gsmtp EHLO moo 250-smtp.gmail.com at your service, [65.39.219.79] 250-SIZE 35882577 250-8BITMIME 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250 SMTPUTF8Next, you can check that the certificate is good using openssl as follows:
# openssl s_client -starttls smtp -connect smtp.gmail.com:25 CONNECTED(00000003) depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = smtp.gmail.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority --- Server certificate -----BEGIN CERTIFICATE----- MIIEgDCCA2igAwIBAgIITF4+kNtdf9AwDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE ... -----END CERTIFICATE----- subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2 --- No client certificate CA names sent Server Temp Key: ECDH, prime256v1, 256 bits --- SSL handshake has read 4032 bytes and written 408 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: FABE7EA050F0D455B63C9EDCD4F3A106AD4E547B9165F67D6DD5044940C80CFB Session-ID-ctx: Master-Key: 8B023A07D04A951D421CA2B556C401CDEA60FDF177ACBD74A72EC5878707FDF09E9BE4F3AB751DFA3BD18A331696DE2E Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None TLS session ticket lifetime hint: 100800 (seconds) TLS session ticket: 0000 - d5 4c f8 d7 f3 c5 6b 41-b1 c5 5e da a6 53 4e fb .L....kA..^..SN. ... 00a0 - 56 47 3d 65 VG=e Start Time: 1498222563 Timeout : 300 (sec) Verify return code: 0 (ok) --- 250 SMTPUTF8If you are having issues getting it to send using STARTTLS, I'd suggest you check your certificate configuration on your mail server.
-
POP and IMAP are mail reading protocols, they have absolutely nothing to do with SMTP which is the mail transport and delivery protocol.
Check that you're not enforcing SSL/TLS on outgoing SMTP on your server, that is never going to work on the current internet where the vast majority of the mail servers are not yet SSL/TLS ready.
-
So the only thing I need to apply the SSL to is the SMTP, not IMAP, POP3 or Outgoing Mail services?
-
That depends on what you are trying to accomplish, but based on your question, I suspect there is a fundamental misunderstanding of how mail works.
SMTP is used to deliver mail between servers, and from clients to mail servers. This IS the outgoing mail service.
POP and IMAP are mail fetching/reading protocols used pretty much exclusively by mail reading clients.If you want to prevent casual eavesdropping then SSL/TLS support is a good idea on all protocols.
Only, as kpa said, do not enforce it on SMTP or you will have delivery problems. -
@kpa:
Check that you're not enforcing SSL/TLS on outgoing SMTP on your server, that is never going to work on the current internet where the vast majority of the mail servers are not yet SSL/TLS ready.
Both Yahoo and Google require SSL/TLS on port 465 or 587 for SMTP. Many others are forcing users to SSL/TLS for both sending and receiving mail. Also, there are security issues with StartTLS, which may be why we're now seeing SSL/TLS required instead of it.
-
So the only thing I need to apply the SSL to is the SMTP, not IMAP, POP3 or Outgoing Mail services?
The world is moving to SSL/TLS for both sending and receiving email. Without it or StartTLS, everything is sent in plain text. However, StartTLS has other security issues.
-
@kpa:
Check that you're not enforcing SSL/TLS on outgoing SMTP on your server, that is never going to work on the current internet where the vast majority of the mail servers are not yet SSL/TLS ready.
Both Yahoo and Google require SSL/TLS on port 465 or 587 for SMTP. Many others are forcing users to SSL/TLS for both sending and receiving mail. Also, there are security issues with StartTLS, which may be why we're now seeing SSL/TLS required instead of it.
Please stop talking rubbish. First of all I'm talking about the standard mail transport from mail server to mail server that always uses port 25, regardless of SSL/TLS or not. When it comes to mail submission (user sending mail) you see either port 465 (being obsoleted, see below) with forced SSL/TLS or port 587 with StartTLS or even port 25 with StartTLS.
Secondly you have some very wrong information about StartTLS, there are no "security issues" known anymore than with forced SSL/TLS like you have on port 465 mail submission and the forced SSL/TLS methods are already being deprecated heavily. Hell, even HTTPS is moving towards StartTLS because everyone would like to have HTTP/HTTPS on single port 80 to simplify firewalling.
-
To summarize what you need to do to get the most effective protection for your mail services while keeping compatibility with the rest of the world.
-
Use SSL/TLS for your mail reading and mail submission services, these are the POP3 and IMAP services for reading mail and the SMTP service in form of your users submitting mail to your server for delivery. For POP3 and IMAP you have the choice of using the "forced" SSL/TLS (port 995 for POP3 and port 993 for IMAP) or use StartTLS with the standard ports (110 for POP3 and 143 for IMAP). You'll probably find that your users don't have clients that support StartTLS on POP3 and IMAP and that might be a good reason to just stick to the forced SSL/TLS ports if you don't want to keep both sets of ports open to the internet. Mail submission is similar with the forced SSL/TLS on port 465 (not recommended, being phased out) and the StartTLS version on port 587 (recommended) or 25 (not recommended because of complicated access control with the same port being the receive port for the incoming mail coming in from the internet).
-
For mail transport from your mail server to other mail servers and back to your server you want to enable SSL/TLS but you don't want to enforce it in any direction. For example the Postfix server has a setting "smtpd_tls_security_level" and the official documentation recommends you to set it at "may" setting but no more:
http://www.postfix.org/TLS_README.html
The reason is what I already explained above is that in either direction your server will talk to other mail servers that just can not use SSL/TLS in any form and if you enforce the use of SSL/TLS your server can't deliver mail destined to those servers or receive mail coming to you from those servers.
HTH
-
-
@kpa:
@kpa:
Check that you're not enforcing SSL/TLS on outgoing SMTP on your server, that is never going to work on the current internet where the vast majority of the mail servers are not yet SSL/TLS ready.
Please stop talking rubbish. First of all I'm talking about the standard mail transport from mail server to mail server that always uses port 25, regardless of SSL/TLS or not. When it comes to mail submission (user sending mail) you see either port 465 (being obsoleted, see below) with forced SSL/TLS or port 587 with StartTLS or even port 25 with StartTLS.
Secondly you have some very wrong information about StartTLS, there are no "security issues" known anymore than with forced SSL/TLS like you have on port 465 mail submission and the forced SSL/TLS methods are already being deprecated heavily. Hell, even HTTPS is moving towards StartTLS because everyone would like to have HTTP/HTTPS on single port 80 to simplify firewalling.
Weaknesses and mitigations
Opportunistic TLS is an opportunistic encryption mechanism. Because the initial handshake takes place in plain text, an attacker in control of the network can modify the server messages via a man-in-the-middle attack to make it appear that TLS is unavailable (called a STRIPTLS attack). Most SMTP clients will then send the email and possibly passwords in plain text, often with no notification to the user. In particular, many SMTP connections occur between mail servers, where user notification is not practical.
In September 2014, two ISPs in Thailand were found to be doing this to their own customers.[7][8] In October 2014, Aio Wireless, then a subsidiary of Cricket Wireless, was found to be doing this to their customers.[9][10]
STRIPTLS attacks can be blocked by configuring SMTP clients to require TLS for outgoing connections (for example, the Exim Message transfer agent can require TLS via the directive "hosts_require_tls" [11]). However, since not every mail server supports TLS, it is not practical to simply require TLS for all connections.
An example of a STRIPTLS attack of the type used in Thai mass surveillance technology:[12]
220 smtp.gmail.com ESMTP mail.redacted.com - gsmtp
ehlo a
250-smtp.gmail.com at your service, [REDACTED SERVICE]
250-SIZE 35882577
250-8BITMIME
# The STARTTLS command is stripped here
250-ENHANCEDSTATUSCODES
250-PIPELINING
250 SMTPUTF8220 smtp.gmail.com ESMTP - gsmtp
ehlo a
250-smtp.gmail.com at your service
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250 SMTPUTF8This problem is addressed by DNS-based Authentication of Named Entities (DANE), a part of DNSSEC, and in particular by RFC 7672 for SMTP. DANE allows to advertise support for secure SMTP via a TLSA record. This tells connecting clients they should require TLS, thus preventing STRIPTLS attacks. The STARTTLS Everywhere project from the Electronic Frontier Foundation works in a similar way. However, DNSSEC due to deployment complexities and peculiar criticism,[13] faced a low adoption rate and a new protocol called SMTP Strict Transport Security or SMTP STS has been drafted by a group of major email service providers including Microsoft, Google and Yahoo - that got more fine-tuned in its superseded versions. SMTP STS does not requires the use of DNSSEC to authenticate DANE TLSA records but relies on the certificate authority (CA) system and a trust-on-first-use (TOFU) approach to avoid interceptions. The TOFU model allows a degree of security similar to that of HPKP, reducing the complexity but without the guarantees on first use offered by DNSSEC. In addition, SMTP STS introduces a mechanism for failure reporting and a report-only mode, enabling progressive roll-out and auditing for compliance.
https://en.wikipedia.org/wiki/Opportunistic_TLS#Weaknesses_and_mitigationsEmail encryption
Until recently, there has been no widely implemented standard for encrypted email transfer.[2] Sending an email is security agnostic; there is no URI scheme to designate secure SMTP.[3] Consequently, most email that is delivered over TLS uses only opportunistic encryption.[4] Since DNSSEC provides authenticated denial of existence (allows a resolver to validate that a certain domain name does not exist), DANE enables an incremental transition to verified, encrypted SMTP without any other external mechanisms, as described by RFC 7672. A DANE record indicates that the sender must use TLS.[3]
Additionally, a draft exists for applying DANE to S/MIME,[5] and RFC 7929 standardises bindings for OpenPGP.[6]
https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#Email_encryptionSeems to me someone else thinks there are issues with StartTLS in that they came up with a secure method to ensure TLS is used when possible.