Bug 1284916 - [PATCH] Latest ssl.py breaks certificate validation for wildcard domains, e.g. *.s3.amazonaws.com
[PATCH] Latest ssl.py breaks certificate validation for wildcard domains, e.g...
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: python (Show other bugs)
Unspecified Unspecified
low Severity low
: rc
: ---
Assigned To: Matej Stuchlik
BaseOS QE - Apps
Depends On:
Blocks: 1284930
  Show dependency treegraph
Reported: 2015-11-24 08:11 EST by Alexander Todorov
Modified: 2016-01-31 21:16 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1284930 (view as bug list)
Last Closed: 2015-11-24 09:50:31 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Python 25722 None None None Never

  None (edit)
Description Alexander Todorov 2015-11-24 08:11:23 EST
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):

How reproducible:

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")


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
Comment 1 Matej Stuchlik 2015-11-24 09:05:36 EST
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).

Comment 2 Alexander Todorov 2015-11-24 09:46:29 EST
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:

Probably this one should be closed.
Comment 3 Matej Stuchlik 2015-11-24 09:50:31 EST
Cool, good to hear that Alexander. :)

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