RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1711885 - postfix uses MD5 by default for TLS
Summary: postfix uses MD5 by default for TLS
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: postfix
Version: 8.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: 8.0
Assignee: Jaroslav Škarvada
QA Contact: Patrik Moško
Lenka Špačková
URL:
Whiteboard:
Depends On:
Blocks: 1771008 1894575
TreeView+ depends on / blocked
 
Reported: 2019-05-20 09:59 UTC by Ondrej Moriš
Modified: 2024-03-25 15:18 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
.Postfix TLS fingerprint algorithm in the FIPS mode needs to be changed to SHA-256 By default in RHEL 8, `postfix` uses MD5 fingerprints with the TLS for backward compatibility. But in the FIPS mode, the MD5 hashing function is not available, which may cause TLS to incorrectly function in the default postfix configuration. To work around this problem, the hashing function needs to be changed to SHA-256 in the postfix configuration file. For more details, see the related Knowledgebase article link:https://access.redhat.com/articles/5824391[Fix postfix TLS in the FIPS mode by switching to SHA-256 instead of MD5].
Clone Of:
Environment:
Last Closed: 2020-12-07 10:38:19 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Ondrej Moriš 2019-05-20 09:59:27 UTC
Description of problem:

When postfix is configured to use TLS it uses MD5 digest algorithm by default. When FIPS mode is enabled, it causes disabling TLS support because MD5 is not allowed. I would suggest to use SHA1 by default.

Version-Release number of selected component (if applicable):

postfix-3.3.1-8.el8

How reproducible:

100% only in FIPS mode

Steps to Reproduce:

1. Enable FIPS mode (fips-mode-setup --enable && reboot).
2. Configures postfix to use TLS.
3. Start postfix service.

Actual results:

postfix/smtpd[16390]: initializing the server-side TLS engine
postfix/smtpd[16390]: warning: Digest algorithm "md5" not found
postfix/smtpd[16390]: warning: disabling TLS support

TLS is disabled.

Expected results:

TLS is enabled.

Additional info:

When FIPS mode is disabled, MD5 is allowed. This issues only happens when FIPS mode is enabled. When SHA1 is used, everything works flawlessly.

Comment 1 Jaroslav Škarvada 2019-05-20 10:04:10 UTC
MD5 is used by default by upstream for backward compatibility. I think we can downstream patch it to use something better in our default config like sha1. Changing it is simple:

# postconf -e smtpd_tls_fingerprint_digest=sha1
# systemctl restart postfix

Comment 2 Paulo Andrade 2020-06-05 13:21:27 UTC
  Looks like a related issue:

Core was generated by `smtp -t unix -u'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007f1fa40e9bf7 in tls_data_fprint (buf=buf@entry=0x5648a5948920 "0\202\006G0\202\004/\240\003\002\001\002\002\002>\a0\r\006\t*\206H\206\367\r\001\001\v\005", len=len@entry=1611, mdalg=mdalg@entry=0x5648a585c430 "md5")
    at tls_fprint.c:299
#2  0x00007f1fa40e9ce3 in tls_cert_fprint (peercert=peercert@entry=0x5648a594afb0, mdalg=0x5648a585c430 "md5") at tls_fprint.c:323
#3  0x00007f1fa40ef9b8 in verify_extract_print (props=0x7ffffd63b120, props=0x7ffffd63b120, peercert=0x5648a594afb0, TLScontext=0x5648a592fd20) at tls_client.c:1097
#4  tls_client_start (props=props@entry=0x7ffffd63b120) at tls_client.c:1097
#5  0x00005648a39b295b in smtp_start_tls (state=state@entry=0x5648a592a8f0) at smtp_proto.c:910
#6  0x00005648a39b24ad in smtp_helo (state=state@entry=0x5648a592a8f0) at smtp_proto.c:790
#7  0x00005648a39ae428 in smtp_connect_inet (state=state@entry=0x5648a592a8f0, nexthop=nexthop@entry=0x5648a58e1ca0 "[<<<example.com>>>]", def_service=0x5648a585d280 "smtp") at smtp_connect.c:966
#8  0x00005648a39af033 in smtp_connect (state=0x5648a592a8f0) at smtp_connect.c:1169
#9  0x00005648a39acf3c in deliver_message (request=0x5648a592f820, service=0x7ffffd63bf8c "smtp") at smtp.c:1029
#10 smtp_service (client_stream=0x5648a586acb0, service=0x7ffffd63bf8c "smtp", argv=<optimized out>) at smtp.c:1061
#11 0x00007f1fa42fcd3a in single_server_wakeup (fd=<optimized out>, attr=0x0) at single_server.c:287
#12 0x00007f1fa3a64788 in event_loop (delay=<optimized out>) at events.c:1186
#13 0x00007f1fa42fdd7a in single_server_main (argc=<optimized out>, argv=<optimized out>, service=0x5648a39acea0 <smtp_service>) at single_server.c:790
#14 0x00005648a39acd50 in main (argc=4, argv=0x7ffffd63bd68) at ../../include/mail_server.h:87
(gdb) f 1
#1  0x00007f1fa40e9bf7 in tls_data_fprint (buf=buf@entry=0x5648a5948920 "0\202\006G0\202\004/\240\003\002\001\002\002\002>\a0\r\006\t*\206H\206\367\r\001\001\v\005", len=len@entry=1611, mdalg=mdalg@entry=0x5648a585c430 "md5")
    at tls_fprint.c:299
299	    digest_data(buf, len);
(gdb) p mdctx
$1 = (EVP_MD_CTX *) 0x5648a5938550
(gdb) p *mdctx
$2 = {digest = 0x0, engine = 0x0, flags = 0, md_data = 0x0, pctx = 0x0, update = 0x0}

  Any suggestion about the issue?

# rpm -q postfix
postfix-3.3.1-12.el8.x86_64
# cat /etc/redhat-release 
Red Hat Enterprise Linux release 8.2 (Ootpa)

Comment 10 Jaroslav Škarvada 2020-11-23 16:39:01 UTC
From the upstream documentation:

The default algorithm is sha256 with Postfix ≥ 3.6 and the compatibility_level set to 3 or higher. With Postfix ≤ 3.5, the default algorithm is md5.

The best-practice algorithm is now sha256. Recent advances in hash function cryptanalysis have led to md5 and sha1 being deprecated in favor of sha256. However, as long as there are no known "second pre-image" attacks against the older algorithms, their use in this context, though not recommended, is still likely safe.

Comment 11 Jaroslav Škarvada 2020-11-23 16:42:34 UTC
The postfix-3.6 is not yet stable.

Changing the hash to sha256 mid-release could break several customers, i.e. change of the hash will require updating any associated lookup table keys with the "sha256" digests of the expected client certificate or public key. This is something we cannot do automatically.

Comment 17 Jaroslav Škarvada 2020-12-07 10:38:19 UTC
It's risky to change the defaults during lifetime of the product (see comment 10 and comment 11), we will document it in the KB article and change the default settings in the next major RHEL release, so closing as wontfix.


Note You need to log in before you can comment on or make changes to this bug.