[issue10441] some stdlib modules need to be updated to handle SSL certificate validation
Nicolas Bareil added the comment: Martin v. Löwis writes: >> what do you think about a DeprecationWarning at runtime? > > What API exactly should this deprecate? Ooops, lapsus. I was thinking about a RuntimeWarning raised on HTTPS request (in httplib.HTTPSConnection.connect for instance). -- ___ Python tracker <http://bugs.python.org/issue10441> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10441] some stdlib modules need to be updated to handle SSL certificate validation
Nicolas Bareil added the comment: Hello, Your patch about SSLContext is great! But what can we do about python 2.x? I understand that we have to keep backward compatibility but something has to be done for improving current situation, even Paypal API (*) recommends using urllib.urlopen() to check sensitive things on HTTPS :( If backporting SSLContext into python 2.x is not an option, what do you think about a DeprecationWarning at runtime? Thanks, (*) https://www.x.com/devzone/articles/getting-started-paypal-django And even the popular Django paypal module uses urllib2 https://github.com/johnboxall/django-paypal -- nosy: +nbareil ___ Python tracker <http://bugs.python.org/issue10441> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12000] SSL certificate verification failed if no dNSName entry in subjectAltName
Nicolas Bareil added the comment:
Hello Mads
> Until now Python failed to the safe side by not matching on
> subjectAltName iPAddress but also not falling back to commonName
> if they were specified. AFAICS, with this change it is possible to
> create strange certificates that Python would accept when an IP
> address matched commonName but other implementations would reject
> because of iPAddress mismatch.
Good point! But I think we already have this issue with a certificate
like this one:
cert = { 'subject': ((('commonName', '192.168.1.1'),),)}
ok(cert, '192.168.1.1')
Do you think this test should fail?
--
___
Python tracker
<http://bugs.python.org/issue12000>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12000] SSL certificate verification failed if no dNSName entry in subjectAltName
Nicolas Bareil added the comment:
Hello Antoine, Steffen,
You are absolutely right about removing the 'not san' part. Here is the
new patch, with tests :
diff -r c22d5b37f6a4 Lib/ssl.py
--- a/Lib/ssl.pyFri May 06 09:31:02 2011 +0300
+++ b/Lib/ssl.pyFri May 06 12:47:14 2011 +0200
@@ -122,8 +122,9 @@
if _dnsname_to_pat(value).match(hostname):
return
dnsnames.append(value)
-if not san:
-# The subject is only checked when subjectAltName is empty
+if not dnsnames:
+# The subject is only checked when there is no dNSName entry
+# in subjectAltName
for sub in cert.get('subject', ()):
for key, value in sub:
# XXX according to RFC 2818, the most specific Common Name
diff -r c22d5b37f6a4 Lib/test/test_ssl.py
--- a/Lib/test/test_ssl.py Fri May 06 09:31:02 2011 +0300
+++ b/Lib/test/test_ssl.py Fri May 06 12:47:14 2011 +0200
@@ -277,6 +277,24 @@
(('organizationName', 'Google Inc'),))}
fail(cert, 'mail.google.com')
+# No DNS entry in subjectAltName but a commonName
+cert = {'notAfter': 'Dec 18 23:59:59 2099 GMT',
+'subject': ((('countryName', 'US'),),
+(('stateOrProvinceName', 'California'),),
+(('localityName', 'Mountain View'),),
+(('commonName', 'mail.google.com'),)),
+'subjectAltName': (('othername', 'blabla'), )}
+ok(cert, 'mail.google.com')
+
+# No DNS entry subjectAltName and no commonName
+cert = {'notAfter': 'Dec 18 23:59:59 2099 GMT',
+'subject': ((('countryName', 'US'),),
+(('stateOrProvinceName', 'California'),),
+(('localityName', 'Mountain View'),),
+(('organizationName', 'Google Inc'),)),
+'subjectAltName': (('othername', 'blabla'),)}
+fail(cert, 'google.com')
+
# Empty cert / no cert
self.assertRaises(ValueError, ssl.match_hostname, None, 'example.com')
self.assertRaises(ValueError, ssl.match_hostname, {}, 'example.com')
Steffen, I will submit a bug report to Mercurial as soon as this patch is
expected to be integrate in py3k.
--
versions: +Python 3.4
___
Python tracker
<http://bugs.python.org/issue12000>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12000] SSL certificate verification failed if no dNSName entry in subjectAltName
New submission from Nicolas Bareil :
When connecting to a SSL server, the certificate verification failed if
it has a subjectAltName extension without any dNSName entry inside: it
should fallback to the Common Name.
Example:
>>> cert = conn.getpeercert()
>>> cert
{'notAfter': 'May 15 14:31:42 2011 GMT',
'subject': ((('countryName', u'FR'),),
(('stateOrProvinceName', u'Ile-de-France'),),
(('localityName', u'Paris'),),
(('organizationName', 'xxx'),),
(('organizationalUnitName', 'xxx'),),
(('commonName', 'foobar.corp'),),
(('emailAddress', u't...@test.net'),)),
'subjectAltName': (('email', t...@test.net'),)}
This certificate is valid according to RFC 2818:
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
Even if the use of CommonName is deprecated, we should not break
existing systems.
Current revision of Lib/ssl.py :
108 def match_hostname(cert, hostname):
...
119 san = cert.get('subjectAltName', ())
120 for key, value in san:
121 if key == 'DNS':
122 if _dnsname_to_pat(value).match(hostname):
123 return
124 dnsnames.append(value)
125 if not san:
126 # The subject is only checked when subjectAltName is empty
127 for sub in cert.get('subject', ()):
128 for key, value in sub:
129 # XXX according to RFC 2818, the most specific Common
Name
130 # must be used.
131 if key == 'commonName':
132 if _dnsname_to_pat(value).match(hostname):
133 return
134 dnsnames.append(value)
...
Proposed patch is:
diff -r 513f6dfd3173 Lib/ssl.py
--- a/Lib/ssl.pySun May 01 20:24:59 2011 -0500
+++ b/Lib/ssl.pyMon May 02 11:16:46 2011 +0200
@@ -122,8 +122,9 @@
if _dnsname_to_pat(value).match(hostname):
return
dnsnames.append(value)
- if not san:
- # The subject is only checked when subjectAltName is empty
+ if not san and not dnsnames:
+ # The subject is only checked when there is no dNSName entry
+ # in subjectAltName
for sub in cert.get('subject', ()):
for key, value in sub:
# XXX according to RFC 2818, the most specific Common Name
--
components: Library (Lib)
messages: 135119
nosy: nbareil
priority: normal
severity: normal
status: open
title: SSL certificate verification failed if no dNSName entry in subjectAltName
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue12000>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
