Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security scan fresh install of iRedmail #22

Closed
takenek opened this issue Apr 5, 2020 · 20 comments
Closed

Security scan fresh install of iRedmail #22

takenek opened this issue Apr 5, 2020 · 20 comments

Comments

@takenek
Copy link

takenek commented Apr 5, 2020

Hello,
I just do security scan of fresh install iRedmail and this is report:
TLS Version 1.0 Protocol Detection on ports:
25, 110, 143, 587, 993, 995
Solution:
Enable support for TLS 1.2 and 1.3, and disable support for TLS 1.0.
Description
The remote service accepts connections encrypted using TLS 1.0. TLS 1.0 has a number of cryptographic design flaws. Modern implementations of TLS 1.0 mitigate these problems, but newer versions of TLS like 1.2 and 1.3 are designed against these flaws and should be used whenever possible.
As of March 31, 2020, Endpoints that aren’t enabled for TLS 1.2 and higher will no longer function properly with major web browsers and major vendors.

TLS Version 1.1 Protocol Detection on ports:
25, 110, 143, 587, 993, 995
Solution:
Enable support for TLS 1.2 and/or 1.3, and disable support for TLS 1.1.
Description
The remote service accepts connections encrypted using TLS 1.1.
TLS 1.1 lacks support for current and recommended cipher suites.
Ciphers that support encryption before MAC computation, and authenticated encryption modes such as GCM cannot be used with TLS 1.1
As of March 31, 2020, Endpoints that aren’t enabled for TLS 1.2 and higher will no longer function properly with major web browsers and major vendors.

SSL/TLS Protocol Initialization Vector Implementation Information Disclosure Vulnerability (BEAST) on ports:
25, 587
Solution:
Configure SSL/TLS servers to only use TLS 1.2 if supported.
Description
A vulnerability exists in SSL 3.0 and TLS 1.0 that could allow information disclosure if an attacker intercepts encrypted traffic served from an affected system.
TLS 1.1, TLS 1.2, and all cipher suites that do not use CBC mode are not affected.

@takenek
Copy link
Author

takenek commented Apr 5, 2020

Change in configs:
/etc/postfix/main.cf
smtpd_tls_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1
smtp_tls_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1
lmtp_tls_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1
lmtp_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1

/etc/dovecot/dovecot.conf
ssl_min_protocol = TLSv1.2

Best Regards
TaKeN

@iredmail
Copy link
Owner

iredmail commented Apr 5, 2020

TLSv1/1.1 are enabled on purpose to support old mail client applications and old MTAs.

I think it's ok to force TLSv1.2 for POP3/IMAP, HTTPS and smtpd_tls_* (for end users), but may be not good for smtp_tls_ (used to connect to other MTAs).

@takenek
Copy link
Author

takenek commented Apr 5, 2020

More security for ngnix to get A+ in https://www.ssllabs.com/ssltest/analyze.html

File: /etc/nginx/templates/ssl.tmpl
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384;
ssl_ecdh_curve secp384r1;
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 1.1.1.1 valid=300s;
resolver_timeout 5s;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";

@iredmail
Copy link
Owner

iredmail commented Apr 5, 2020

More security for ngnix to get A+ in https://www.ssllabs.com/ssltest/analyze.html

It would be better if you can show me the different settings compared to default iRedMail settings. :)

iredmail added a commit that referenced this issue Apr 5, 2020
fixes #22 (partly)
@skid9000
Copy link

Hello,
I checked default configurations and here are my recommendations :

Global :

  • Make the default certificate RSA 4096 bits (the ANSSI in France recommend at least 3072 bits in RSA, so 4096 in practice.)
  • Change the mention of "TLS" to "StartTLS" where it is needed.

For Amavis

  • Make the DKIM key RSA 2048 bits by default.

For PostFix :

  • Add TLSv1.3 support
  • Disable Diffie-Hellman support and only keep Elliptic-curve Diffie–Hellman ciphers.
  • Enable port 465 for "SSL only" connections and keep 587 for StartTLS.

For Dovecot :

  • Disable StartTLS and close port 110 and 143. (most of the POP3 and IMAP clients support proper "SSL").
  • Disable Diffie-Hellman support and only keep Elliptic-curve Diffie–Hellman ciphers.

For nginx :

  • Add TLSv1.3 support
  • Disable Diffie-Hellman support and only keep Elliptic-curve Diffie–Hellman ciphers.
  • Change elliptic curves order to : ssl_ecdh_curve X25519:P-384:P-256:P-521;
  • Enable SSL Stapling and use /etc/resolv.conf to check what resolver to use, if no resolver, ask the user at installation.

@iredmail
Copy link
Owner

  • Make the default certificate RSA 4096 bits (the ANSSI in France recommend at least 3072 bits in RSA, so 4096 in practice.)

Fixed.

  • Make the DKIM key RSA 2048 bits by default.

Not all DNS vendors support key length >= 2048, so we stick to 1024.

For PostFix :

  • Add TLSv1.3 support
  • Enable port 465 for "SSL only" connections and keep 587 for StartTLS.
  • TLSv1.3 requires OpenSSL 1.1.1 or later releases, not all distro releases have it. If it's available, Postfix will enable it automatically. For example, CentOS 7 ships openssl-1.0.2k, ubuntu 18.04 ships 1.1.0g.
  • Port 465 has been deprecated. FYI: https://docs.iredmail.org/enable.smtps.html

For Dovecot :

  • Disable StartTLS and close port 110 and 143. (most of the POP3 and IMAP clients support proper "SSL").

Why disable TLS? TLS is recommended over SSL.

@skid9000
Copy link

Why disable TLS? TLS is recommended over SSL.

Please take note that StartTLS and TLS are not the same thing which confuse a lot of people.

In a some of popular mail clients we can find the following pattern :

  • SSL, which actually mean SSL/TLS that is implicit encryption with no possible fallback to plaintext.
  • TLS, is badly used to mean StartTLS, which is explicit encryption, so fallback to plaintext is possible.

This is why i recommend to stop using the "TLS" term to mean StartTLS and recommend using "SSL" (which will be "real" TLS in practice but whatever).

Not all DNS vendors support key length >= 2048, so we stick to 1024.

For DKIM, then please let the user choose between 1024 or 2048 at the installation, depending of the situation.

@iredmail
Copy link
Owner

  • OK, we should use stronger DKIM key length by default, so i switch DKIM key length to 2048 by default. If some DNS vendor doesn't support 2048, sysadmin has to re-generate a key with 1024.
  • Do you have some particular files/documents which i should update the "TLS" term?

@skid9000
Copy link

This email :
image

@iredmail
Copy link
Owner

@skid9000 FYI: 74348c2

@skid9000
Copy link

For port 465, RFC8314 (January 2018) recommend to support both protocols for SMTP
image

@iredmail
Copy link
Owner

For port 465, RFC8314 (January 2018) recommend to support both protocols for SMTP

This is suggestion for the transition period (slowly drop SSL). We disable it by default, but leave tutorial to sysadmin to enable it if needed by their organization.

Conclusion: no plan to enable it by default. Sorry.

@skid9000
Copy link

skid9000 commented Apr 23, 2020

Could you please include the link to this tutorial in one the mails you get with the first setup domain then ? :)

Like in the same mail i mentioned earlier :

"If SMTPS (port 465) is required, please checkout this tutorial :"

iredmail added a commit to iredmail/docs that referenced this issue Apr 23, 2020
@skid9000
Copy link

There is also the mention of "TLS" in
en_US/mua/_summary.md
and
html/index.html

in the "docs" repository.

iredmail added a commit to iredmail/docs that referenced this issue Apr 23, 2020
@skid9000
Copy link

Hello,

I'm reusing this issue to point out that i think we both misread RFC8314 at that time :
image

https://twitter.com/bortzmeyer/status/1272957636368007168

"The RFC explains it. Basically, the security weaknesses of STARTTLS are well known (vulnerability to SSL striping) and therefore systematic TLS is required."

So i still suggest that port 465 should be enabled using SSL/TLS (aka implicit encryption) by default.

@skid9000
Copy link

Also from the Wikipedia page you quote :

https://docs.iredmail.org/enable.smtps.html
https://en.wikipedia.org/wiki/SMTPS

image

@iredmail
Copy link
Owner

iredmail commented Nov 22, 2020

Are we talking about RFC 8314 in your twitter thread? IF yes, and if i understand the RFC document correctly, what the RFC recommends is disable cleartext services. To achieve the goal, suggested steps are:

  • Implement TLS/STARTTLS (and the existing SSL) support on ports 993/995/465 "for a transition period of several years", so that MUAs can discover the TLS/STARTTLS support on existing SSL ports and switch to it automatically (negotiated and decided by the MUAs). That's what the "Implicit TLS" means.
  • Disable cleartext services
  • Retiring SSL on mail servers (POP3 - 993, IMAPS - 995, SMTPS - 465)

STARTTLS is the RECOMMENDED one, and dedicated port with SSL support is DEPRECATED. It doesn't mention smtps/465 is the future at all.

@iredmail
Copy link
Owner

"The RFC explains it. Basically, the security weaknesses of STARTTLS are well known (vulnerability to SSL striping) and therefore systematic TLS is required."

Any related document of "the security weaknesses of STARTTLS"?

@iredmail
Copy link
Owner

btw, with default iRedMail settings, POP3/IMAP/SMTP/HTTPS connections between server and end user / MUA are forced to be secure connections:

  • POP3: 110 + STARTLS
  • POP3S: 995 + SSL
  • IMAP: 143 + STARTTLS
  • IMAPS: 993 + SSL
  • SMTP: 587 + STARTTLS
  • NO SMTPS (port 465)
  • HTTP: 80 (all traffic redirected to 443)
  • HTTPS: 443 (self-signed ssl cert with default installation, sysadmin should grab a valid one immediately after installation)

@skid9000
Copy link

Are we talking about RFC 8314 in your twitter thread?

yes.

Implement TLS/STARTTLS (and the existing SSL) support on ports 993/995/465 "for a transition period of several years", so that MUAs can discover the TLS/STARTTLS support on existing SSL ports and switch to it automatically (negotiated and decided by the MUAs). That's what the "Implicit TLS" means.

No, the term "Implicit TLS" is clearly defined at section 2 from rfc8314 :

The term "Implicit TLS" refers to the automatic negotiation of TLS
whenever a TCP connection is made on a particular TCP port that is
used exclusively by that server for TLS connections. The term
"Implicit TLS" is intended to contrast with the use of STARTTLS
and
similar commands in POP, IMAP, SMTP Message Submission, and other
protocols, that are used by the client and the server to explicitly
negotiate TLS on an established cleartext TCP connection.

From section 3 :

With
STARTTLS, the client establishes a cleartext application session and
determines whether to issue a STARTTLS command based on server
capabilities and client configuration.

STARTTLS is by definition an "explicit TLS" solution since you have to execute the STARTTLS command to use TLS.

Retiring SSL on mail servers (POP3 - 993, IMAPS - 995, SMTPS - 465)
STARTTLS is the RECOMMENDED one, and dedicated port with SSL support is DEPRECATED. It doesn't mention smtps/465 is the future at all.

Also no, now that we have a clear definition of "implicit TLS", section 3.3 from the rfc contradict your argument.

The STARTTLS mechanism on port 587 is relatively widely deployed due
to the situation with port 465 (discussed in Section 7.3). This
differs from IMAP and POP services where Implicit TLS is more widely
deployed on servers than STARTTLS. It is desirable to migrate core
protocols used by MUA software to Implicit TLS over time
, for
consistency as well as for the additional reasons discussed in
Appendix A. However, to maximize the use of encryption for
submission, it is desirable to support both mechanisms for Message
Submission over TLS for a transition period of several years. As a
result, clients and servers SHOULD implement both STARTTLS on
port 587 and Implicit TLS on port 465 for this transition period.
Note that there is no significant difference between the security
properties of STARTTLS on port 587 and Implicit TLS on port 465 if
the implementations are correct and if both the client and the server
are configured to require successful negotiation of TLS prior to
Message Submission.

Also the IANA registry has been modified with that in mind : https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

image

Any related document of "the security weaknesses of STARTTLS"?

https://www.kb.cert.org/vuls/id/555316

As stated in the RFC, if STARTTLS is implemented correctly, there shouldn't be any problem at the time being, tho it is recommended to use "Implicit TLS" which you can be sure, won't have this type of issue since there is no plaintext phase at all.

If you can read French (or have a good translator), i highly recommend Bortzmeyer's blog post on this subject : https://www.bortzmeyer.org/8314.html

So the recommended configuration, based on RFC8314 would be at that time :

  • POP3: 110 + STARTLS
  • POP3S: 995 + SSL
  • IMAP: 143 + STARTTLS
  • IMAPS: 993 + SSL
  • SMTP: 587 + STARTTLS
  • SMTP(S)/ SMTP over TLS : 465 + SSL
  • HTTP: 80 (all traffic redirected to 443)
  • HTTPS: 443 (self-signed ssl cert with default installation, sysadmin should grab a valid one immediately after installation)

and then in an ideal future :

  • POP3S: 995 + SSL
  • IMAPS: 993 + SSL
  • SMTP(S)/ SMTP over TLS : 465 + SSL
  • HTTP: 80 (all traffic redirected to 443)
  • HTTPS: 443 (self-signed ssl cert with default installation, sysadmin should grab a valid one immediately after installation)

As stated in section 1 :

In brief, this memo now recommends that:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants