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 1740070 - TLS setup should not fall back to matching CN if there is a SAN that does not match the server's host name
Summary: TLS setup should not fall back to matching CN if there is a SAN that does not...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: openldap
Version: 8.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Matus Honek
QA Contact: RHDS QE
URL:
Whiteboard:
Depends On:
Blocks: 1510124
TreeView+ depends on / blocked
 
Reported: 2019-08-12 08:55 UTC by Jakub Hrozek
Modified: 2020-08-21 12:41 UTC (History)
16 users (show)

Fixed In Version: openldap-2.4.46-10.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-05 22:37:19 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 4783381 0 None None None 2020-04-03 14:02:24 UTC
Red Hat Product Errata RHBA-2019:3674 0 None None None 2019-11-05 22:37:21 UTC

Internal Links: 1788572

Description Jakub Hrozek 2019-08-12 08:55:49 UTC
Description of problem:
When a server certificate contains an EKU with a subjectAltName that does NOT match the server host name, but the CN is the certificate DN does match the server host name, openldap-libs currently falls back to using the CN.

This is contrary to:
https://tools.ietf.org/html/rfc6125#section-6.4.4

Which says:
   As noted, a client MUST NOT seek a match for a reference identifier
   of CN-ID if the presented identifiers include a DNS-ID, SRV-ID,
   URI-ID, or any application-specific identifier types supported by the
   client.

   Therefore, if and only if the presented identifiers do not include a
   DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types
   supported by the client, then the client MAY as a last resort check
   for a string whose form matches that of a fully qualified DNS domain
   name in a Common Name field of the subject field (i.e., a CN-ID).

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

How reproducible:
always

Steps to Reproduce:
1. set up a certificate that matches the server in the CN, but has a SAN EKU that does not match
2. Use that cert with an LDAP server
3. ldapsearch the server or set up sssd and let it establish the connection


Actual results:
TLS established

Expected results:
TLS is not established

Additional info:
openssl s_connect does not establish the connection if the -verify_hostname flag is set. So perhaps doing what -verify_hostname is doing would be enough in this case.

Comment 1 Jakub Hrozek 2019-08-12 08:58:16 UTC
Ugh, sorry, I was thinking about another use-case when I created the bug report and wrote EKU with a subjectAltName. Of course subjectAltName is not part of the EKU..

Comment 16 errata-xmlrpc 2019-11-05 22:37:19 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:3674

Comment 20 Quanah Gibson-Mount 2020-07-24 17:26:58 UTC
Both of these patches should be dropped: https://git.centos.org/rpms/openldap/c/2ba5f0fe973f7ab0311beafc90fa2a0f7ffd7f52?branch=c8


The LDAP protocol *specifically* follows RFC4513.

If you read RFC6125 section 1.4, it *specifically* states:

 This document also does not supersede the rules for verifying service
   identity provided in specifications for existing application
   protocols published prior to this document, such as those excerpted
   under Appendix B

and if you go even FURTHER and read appendix B (https://tools.ietf.org/html/rfc6125#appendix-B) section B.3 calls out the LDAP protocol as being an exception.

Comment 21 Quanah Gibson-Mount 2020-07-24 17:27:25 UTC
Or I should say, the "new" patch using OpenSSL should be dropped, and the other one was correctly dropped already.

Comment 22 Steve Grubb 2020-07-24 17:50:58 UTC
Thanks for pointing that out. What is the effect that the patches are having? Have problems been reported?

Comment 23 Quanah Gibson-Mount 2020-07-24 17:58:10 UTC
The effect is that RedHat builds of libldap from the OpenLDAP software version 2.4.46-10 and later directly violate the LDAP RFCs and do incorrect cert verification.

CVE-2020-15719 needs to be retracted, the patches dropped, and a new CVE filed for builds 2.4.46-10 and 2.4.46-11 that they violate certificate matching as pertains to the LDAP protocol.

Comment 24 Christian Heimes 2020-07-24 18:04:44 UTC
My new patch follows the rules of RFC 6125 appendix B.3 for LDAP protocol, specifically:

   o  If a subjectAltName extension of type dNSName is present in the
      certificate, it SHOULD be used as the source of the server's
      identity.

and

   The server's identity may also be verified by comparing the reference
   identity to the Common Name (CN) [LDAP-SCHEMA] value in the last
   Relative Distinguished Name (RDN) of the subject field of the
   server's certificate (where "last" refers to the DER-encoded order,
   not the order of presentation in a string representation of DER-
   encoded data).  This comparison is performed using the rules for
   comparison of DNS names in Section 3.1.3.1, below, with the exception
   that no wildcard matching is allowed.  Although the use of the Common
   Name value is existing practice, it is deprecated, and Certification
   Authorities are encouraged to provide subjectAltName values instead.
   Note that the TLS implementation may represent DNs in certificates
   according to X.500 or other conventions.  For example, some X.500
   implementations order the RDNs in a DN using a left-to-right (most
   significant to least significant) convention instead of LDAP's right-
   to-left convention.

The RFC has a strong **SHOULD** for SAN dNSName check and a weak **may** for CN. It also lists CN checks as deprecated and encourages the use of SAN dNSName entries.

I'm consider that libldap's default behavior a violates the spirit of RFC 6125. Cedric reported the issue as potential security issue to OpenLDAP a couple of months ago. Howard turned it down. My patch also turns a long C function into a trivial function call and lets OpenSSL deal with gritty details of hostname verification. In doubt there is also the flag X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT to restore the (IMHO broken) behavior to always fall back to Subject CN.

Comment 25 Christian Heimes 2020-07-24 18:23:43 UTC
(In reply to Quanah Gibson-Mount from comment #23)
> The effect is that RedHat builds of libldap from the OpenLDAP software
> version 2.4.46-10 and later directly violate the LDAP RFCs and do incorrect
> cert verification.

From a practical point of view all public CAs that participate in WebPKI / CAB forum assume that clients follow the baseline requirements for certificates. That means that these CAs and their intermediate CAs always generate end-entity certificates with a proper SAN extension. Our own PKI software like Dogtag PKI and FreeIPA do the same. Legacy certs don't have a SAN extension. OpenSSL's X509_check_host() will automatically fall back to Subject CN check. You are talking about an edge case when a cert has a CN hostname entry and a disjunct set of SAN dNSName entries.

Comment 26 Howard Chu 2020-07-24 19:06:25 UTC
RFC 6125 is at best misguided. SAN is subject*Alternative*Name - it is meant to be used for *aliases*. The canonical name still must be in the cn. The language in 6125 is so jumbled clearly its authors/editors didn't know wtf they're talking about.

DNs are hierarchical names, so talking about left-to-right or right-to-left RDN ordering is just nonsense. RDNs in a DN are sequenced from root to leaf. The only order that matters is their top-down ordering, and the only CN that matters is the one in the leaf RDN.

Perpetuating misunderstanding of DNs, instead of promoting their correct use, serves no one. RFC6125 specifically precludes the use of *aliases* in certs. E.g., with the procedure it prescribes, a cert with SANs mail.openldap.org and www.openldap.org with a CN=openldap.org would be rejected for clients attempting to connect to "openldap.org" because the SANs don't match the request. This is plain nonsense.

OpenLDAP libldap correctly implements the letter and spirit of RFC4513. RFC6125 explicitly states it does not supersede it. 

LDAP spec aside, RFC6125's procedures are clearly broken.

Comment 27 Quanah Gibson-Mount 2020-07-24 23:42:23 UTC
(In reply to Christian Heimes from comment #24)
> My new patch follows the rules of RFC 6125 appendix B.3 for LDAP protocol,
> specifically:

Appendix B.3 simply cut and pastes the relevant text from RFC 2830 and RFC 4513.  Thus it explicitly excludes any changes to be made to LDAP based off of RFC6125.

> I'm consider that libldap's default behavior a violates the spirit of RFC
> 6125. Cedric reported the issue as potential security issue to OpenLDAP a
> couple of months ago. Howard turned it down. My patch also turns a long C
> function into a trivial function call and lets OpenSSL deal with gritty
> details of hostname verification. In doubt there is also the flag
> X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT to restore the (IMHO broken) behavior
> to always fall back to Subject CN.

So you're noting explicitly here that your patch changes the behavior of libldap, in violation of RFC4513 and what RFC6125 explicitly sets out.  Nothing here should be honoring the "spirit" of RFC6125 outside of there being no behavior breaking change to RFC4513.  Cedric's issue report was correctly rejected since the proposed changes violate the LDAP RFCs and there is no security issue present.


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