Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
DescriptionAlexander Todorov
2015-11-24 13:11:23 UTC
Description of problem:
The latest ssl.py file tries to validate hostnames vs certificates but includes a faulty regexp which causes any wildcard domains (e.g. *.s3.amazonaws.com) to fail validation.
Version-Release number of selected component (if applicable):
python-libs-2.7.5-34.el7.x86_64
How reproducible:
Always
Steps to Reproduce:
1. I'm using the s3cmd tool which tries to establish an SSL connection to Amazon S3:
s3cmd sync -c ./data/s3.cfg -v -m text/css -P /tmp/svplanet/english/html/*.css s3://planet.sofiavalley.com/
however this can be even more easily reproduced.
>>> import ssl
>>> ssl._dnsname_match("*.s3.amazonaws.com", "planet.sofiavalley.com.s3.amazonaws.com")
>>>
2.
3.
Actual results:
Expected results:
<_sre.SRE_Match object at 0x1474030> - the function should match the provided domain and hostname.
Additional info:
The following patch fixes the issue:
# diff -u ssl.py.orig ssl.py
--- ssl.py.orig 2015-11-24 14:22:58.490693826 +0200
+++ ssl.py 2015-11-24 14:57:35.777738043 +0200
@@ -214,7 +214,7 @@
if leftmost == '*':
# When '*' is a fragment by itself, it matches a non-empty dotless
# fragment.
- pats.append('[^.]+')
+ pats.append('^.+')
elif leftmost.startswith('xn--') or hostname.startswith('xn--'):
# RFC 6125, section 6.4.3, subitem 3.
# The client SHOULD NOT attempt to match a presented identifier
From Python's documentation:
[]
Used to indicate a set of characters. In a set:
...
Special characters lose their special meaning inside sets. For example, [(+*)] will match any of the literal characters '(', '+', '*', or ')'.
^^^^^^^^^ this is the cause of the error
The code is actually correct as is -- see RFC 6125, section 6.4.3, subitem 2:
If the wildcard character is the only character of the left-most
label in the presented identifier, the client SHOULD NOT compare
against anything but the left-most label of the reference
identifier (e.g., *.example.com would match foo.example.com but
not bar.foo.example.com or example.com).
http://tools.ietf.org/html/rfc6125#section-6.4.3
Comment 2Alexander Todorov
2015-11-24 14:46:29 UTC
Matej,
indeed you are right, sorry for the false alarm. I've managed to track down the issue further. There's also a change in httplib.py and the calling code wasn't aware of that. I've managed to create a fix for the caller:
https://github.com/s3tools/s3cmd/pull/668
Probably this one should be closed.
Description of problem: The latest ssl.py file tries to validate hostnames vs certificates but includes a faulty regexp which causes any wildcard domains (e.g. *.s3.amazonaws.com) to fail validation. Version-Release number of selected component (if applicable): python-libs-2.7.5-34.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. I'm using the s3cmd tool which tries to establish an SSL connection to Amazon S3: s3cmd sync -c ./data/s3.cfg -v -m text/css -P /tmp/svplanet/english/html/*.css s3://planet.sofiavalley.com/ however this can be even more easily reproduced. >>> import ssl >>> ssl._dnsname_match("*.s3.amazonaws.com", "planet.sofiavalley.com.s3.amazonaws.com") >>> 2. 3. Actual results: Expected results: <_sre.SRE_Match object at 0x1474030> - the function should match the provided domain and hostname. Additional info: The following patch fixes the issue: # diff -u ssl.py.orig ssl.py --- ssl.py.orig 2015-11-24 14:22:58.490693826 +0200 +++ ssl.py 2015-11-24 14:57:35.777738043 +0200 @@ -214,7 +214,7 @@ if leftmost == '*': # When '*' is a fragment by itself, it matches a non-empty dotless # fragment. - pats.append('[^.]+') + pats.append('^.+') elif leftmost.startswith('xn--') or hostname.startswith('xn--'): # RFC 6125, section 6.4.3, subitem 3. # The client SHOULD NOT attempt to match a presented identifier From Python's documentation: [] Used to indicate a set of characters. In a set: ... Special characters lose their special meaning inside sets. For example, [(+*)] will match any of the literal characters '(', '+', '*', or ')'. ^^^^^^^^^ this is the cause of the error