> On 11 Oct 2016, at 16:41, Christian Heimes <christ...@python.org> wrote:
> Hi,
> Python has only IDNA 2003 support (international domain names). I'm
> starting to consider Python's lack of IDNA 2008 support a security issue
> for DNS lookups and for cert validation. Applications may connect to the
> wrong IP address and validate the hostname, too. IDNA 2008 is mandatory
> for German .de domains. See https://bugs.python.org/issue17305
> Wrong:
>>>> import socket
>>>> u'straße.de'.encode('idna')
> 'strasse.de'
>>>> socket.gethostbyname(u'straße.de'.encode('idna'))
> ''
> Correct:
>>>> import idna
>>>> idna.encode(u'straße.de')
> 'xn--strae-oqa.de'
>>>> socket.gethostbyname(idna.encode(u'straße.de'))
> ''
> I neither have time nor expertise to implement IDNA 2008. The ticket
> 17305 is more than three years old, too.

It should be noted that the security vulnerability here is really only related 
to “connect to the wrong IP address”, not to “validate the hostname”. The cert 
validation is not wrong: the user asked to connect to “straße.de 
<http://strasse.de/>" and was connected to “strasse.de <http://strasse.de/>”. 
The server must still present a certificate that is valid for “strasse.de 
<http://strasse.de/>”: if it presents one that is valid for "xn--strae-oqa.de 
<http://strae-oqa.de/>” then validation will fail. It is not possible to use 
this as a MITM vector in that sense, though it is clearly still possible to 
catch unsuspecting users, in the same way that registering goggle.com 
<http://goggle.com/> and getting a cert for it may confuse users who mis-type 
google.com <http://google.com/>. To the best of my knowledge there is no ASCII 
domain name such that Unicode domain name X encodes to it under IDNA 2003 while 
a different Unicode domain name Y encodes to it under IDNA 2008, which is the 
only way I can see there being a security hole with cert validation.

This is nevertheless an annoying bug that does pose some security risks, though 
I’d consider them minor, and it’s one that I’d like to see fixed for Requests 
if nothing else. Any users monitoring this list who would like to mitigate it 
today should IDNA-encode their domain names before passing them to any Python 
HTTP client that does not depend on the PyPI IDNA library (which is to say, all 
of them).


Security-SIG mailing list

Reply via email to