Bug 1520364
| Summary: | perl-LDAP not to default to TLS 1.0 in an explicit STARTTLS LDAP protocol upgrade | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Petr Pisar <ppisar> | ||||||||||||
| Component: | perl-LDAP | Assignee: | Petr Pisar <ppisar> | ||||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Branislav Náter <bnater> | ||||||||||||
| Severity: | urgent | Docs Contact: | Lenka Špačková <lkuprova> | ||||||||||||
| Priority: | unspecified | ||||||||||||||
| Version: | 7.4 | CC: | amitkuma, bgollahe, bnater, jorton, mlstarling31, perl-maint-list, ppisar, psabata, qe-baseos-security | ||||||||||||
| Target Milestone: | rc | Keywords: | FutureFeature, Patch | ||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | x86_64 | ||||||||||||||
| OS: | Unspecified | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Fixed In Version: | perl-LDAP-0.56-6.el7 | Doc Type: | Release Note | ||||||||||||
| Doc Text: |
The *Net::LDAP* Perl module no longer defaults to TLS 1.0
Previously, when the *Net::LDAP* Perl module module was used for upgrading an unsecured LDAP connection to a TLS-protected one, the module used the TLS protocol version 1.0, which is currently considered insecure. With this update, the default TLS version has been removed from *Net::LDAP*, and both implicit (LDAPS schema) and explicit (LDAP schema) TLS protocols rely on the default TLS version selected in the *IO::Socket::SSL* Perl module. As a result, it is no longer necessary to override the TLS version in the *Net::LDAP* clients by passing the `sslversion` argument to the `start_tls()` method to preserve security.
|
Story Points: | --- | ||||||||||||
| Clone Of: | 1519080 | Environment: | |||||||||||||
| Last Closed: | 2018-10-30 07:54:46 UTC | Type: | Bug | ||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||
| Documentation: | --- | CRM: | |||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
| Embargoed: | |||||||||||||||
| Bug Depends On: | |||||||||||||||
| Bug Blocks: | 1549616, 1551025, 1562205 | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Petr Pisar
2017-12-04 11:11:59 UTC
Also implicit TLS defaults to SSLv23. This does not causes any issues now, but for consistency, it's good to remove the perl-Net-LDAP specific override too. Created attachment 1362657 [details]
1st upstream fix
Created attachment 1362658 [details]
2nd upstream fix ported to 0.56
How to test:
(1) Configure openldap-servers' slapd daemon to use TLS 1.2 only. E.g. add into /etc/openldap/slapd.conf:
TLSCACertificatePath /etc/openldap/certs
TLSCertificateFile localhost
TLSCertificateKeyFile /etc/openldap/certs/password
TLSProtocolMin 3.3
and import the certificate and key into slapd's NSS database (it must be readable by ldap group) and start the slapd:
# /usr/sbin/slapd -h 'ldap:/// ldaps:/// ldapi:///' -u ldap -d Args,Conns,Config -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
(2) Run a Net::LDAPS client:
$ perl -Ilib -MNet::LDAPS -e 'my $c=Net::LDAPS->new(q{localhost}, version=>3, port =>636) or die qq{$@\n}'
Before: It should connect.
After: It should still connect.
(3) Run a Net::LDAP client with explicit STARTTLS:
$ cat /tmp/test
#!/usr/bin/perl
use strict; use warnings; use diagnostics;
use Net::LDAP;
my $ldap_master = Net::LDAP->new('localhost',
port => '389',
version => 3,
);
$ldap_master->start_tls()
or die "start_tls() failed: $@\n";
my $msg = $ldap_master->search(base => "dc=example,dc=com",
filter => "(&(objectclass=posixaccount)(uid=*))",
scope => "sub")
or die "search() failed: $@\n";
Before: It fails:
$ perl /tmp/test
syswrite() on closed filehandle GEN0 at
/usr/share/perl5/vendor_perl/Net/LDAP.pm line 806, <DATA> line 522 (#1)
(W closed) The filehandle you're writing to got itself closed sometime
before now. Check your control flow.
and the server logs:
TLS: error: accept - force handshake failure: errno 11 - moznss error -12279
TLS: can't accept: TLS error -12279:Peer using unsupported version of security protocol..
After: It connects.
Hello, //Business Justification from Customer// 1. Why does the customer need this? (List the business requirements here). We have a very large RHEL6 infrastructure and TLSv 1.0 is no longer acceptable for PCI compliance. 2. Is there already an existing RFE upstream or in Red Hat Bugzilla? NO 3. Does the customer have any specific timeline dependencies? ASAP 4. Is the sales team involved in this request and do they have any additional input? NO 5. List any affected packages or components? As far as I can see through testing it appears perl-LDAP and possibly some versions of openLDAP are both affected. 6. Would the customer be able to assist in testing this functionality if implemented? Absolutely. Thanks Amit Created attachment 1363575 [details]
2nd upstream fix
Created attachment 1363581 [details]
1st upstream fix ported to 0.56
Created attachment 1363582 [details]
2nd fix ported to 0.56
The test with Net::LDAP client with explicit TLS does not check errors properly. This one should be better:
#!/usr/bin/perl
use strict;
use warnings;
use Net::LDAP qw(LDAP_NO_SUCH_OBJECT);
my $ldap_master = Net::LDAP->new('localhost',
port => '389',
version => 3,
);
my $retval = $ldap_master->start_tls();
$retval->code and die "start_tls() failed: " . $retval->error;
$retval = $ldap_master->search(base => "dc=example,dc=com",
filter => "(&(objectclass=posixaccount)(uid=*))",
scope => "sub");
$retval->code and $retval->code != LDAP_NO_SUCH_OBJECT
and die "search() failed: " . $retval->error;
The unpatched build should report the error like this:
$ perl test.pl; echo $?
start_tls() failed: SSL connect attempt failed because of handshake problems SSL wants a read first at test.pl line 10, <DATA> line 747.
255
Patched build should be silent:
$ perl test.pl; echo $?
0
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/RHEA-2018:3038 |