Georg Brandl added the comment:
Since it's been out in 3.2.x for so long, I won't apply this for 3.2 since at
this point a behavior change might do more harm than good.
--
resolution: - fixed
status: open - closed
versions: +Python 3.3, Python 3.4 -Python 3.2
Mark Lawrence added the comment:
For future reference how do I find out if this has been applied to 3.2?
--
nosy: +BreamoreBoy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17997
___
Changes by Jakub Wilk jw...@jwilk.net:
--
nosy: +jwilk
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17997
___
___
Python-bugs-list mailing list
Martin v. Löwis added the comment:
Just to clarify the status of this issue: it *only* blocks 3.2.
--
priority: release blocker - normal
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17997
Changes by Martin v. Löwis mar...@v.loewis.de:
--
priority: normal - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17997
___
___
Christian Heimes added the comment:
Python 3.2 hasn't been fixed yet.
Should acquire a CVE for the issue?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17997
___
Roundup Robot added the comment:
New changeset 10d0edadbcdd by Georg Brandl in branch '3.3':
Issue #17997: Change behavior of ``ssl.match_hostname()`` to follow RFC 6125,
http://hg.python.org/cpython/rev/10d0edadbcdd
--
nosy: +python-dev
___
Python
Georg Brandl added the comment:
Also merged to default.
--
versions: -Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17997
___
Christian Heimes added the comment:
Yes, it's a security issue. But the patch would changes the behavior of the
function. The current function conforms to RFC 2818. The patch implements RFC
6125, which is more restrictive.
--
nosy: +georg.brandl, larry
priority: normal - release
Toshio Kuratomi added the comment:
So, is this a security issue? I've been wondering if I should apply the
attached patch to the backports-ssl_match_hostname module on pypi. I was
hoping there'd be some information here as to whether this will be going into
the stdlib in the future.
Thus
Changes by Thomas Weißschuh tho...@t-8ch.de:
--
nosy: +t-8ch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17997
___
___
Python-bugs-list mailing
Christian Heimes added the comment:
Affected versions:
- Python 3.2 ( 3.2.5)
- Python 3.3 ( 3.3.3)
- Python 3.4a1
- requests 1.2.3
https://pypi.python.org/pypi/requests
- backports.ssl_match_hostname (3.2a3)
https://pypi.python.org/pypi/backports.ssl_match_hostname/
- urllib3 1.6
Christian Heimes added the comment:
Ryan Sleevi of the Google Chrome Security Team has informed us about another
issue that is caused by our failure to implement RFC 6125 wildcard matching
rules. RFC 6125 allows only one wildcard in the left-most fragment of a
hostname. For security reasons
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17997
___
___
Python-bugs-list mailing
Changes by Ben Darnell ben.darn...@gmail.com:
--
nosy: +Ben.Darnell
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17997
___
___
Python-bugs-list
Changes by Antoine Pitrou pit...@free.fr:
--
priority: critical - normal
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17997
___
___
Christian Heimes added the comment:
I finally found the correct RFC for wildcard matching. I think our
implementation violates some recommendations.
http://tools.ietf.org/html/rfc6125#section-6.4.2
http://tools.ietf.org/html/rfc6125#section-6.4.3
--
Martin v. Löwis added the comment:
As a policy, the standard library should accept non-ASCII host names
(U-labels) wherever possible. I.e the hostname parameter of match_hostname
should allow for U-labels (as well as A-labels).
When returning names, it should always return the data as-is,
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17997
___
Antoine Pitrou added the comment:
Actually, I don't this is a bug: match_hostname() expects str data, and
therefore IDNA-decoded domain names:
bxn--gtter-jua.example.de.decode(idna)
'götter.example.de'
Doing the matching on the decoded domain name should be safe.
Then it very much depends on
Christian Heimes added the comment:
It's called internationalized domain name for APPLICATIONS. ;) It's up to the
application to interpret the ASCII text as IDNA encoded FQDNs. As far as I know
DNS, SSL's CNAME and OS interfaces etc. always use ASCII labels. It's an
elegant solution. Just the
Antoine Pitrou added the comment:
It's called internationalized domain name for APPLICATIONS. ;) It's
up to the application to interpret the ASCII text as IDNA encoded
FQDNs. As far as I know DNS, SSL's CNAME and OS interfaces etc. always
use ASCII labels. It's an elegant solution. Just
New submission from Christian Heimes:
Python's ssl.match_hostname() does sub string matching as specified in RFC 2818:
Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., *.a.com matches foo.a.com but
23 matches
Mail list logo
