[Security-sig] Lack of IDNA 2008 support

[Cory Benfield]

> On 11 Oct 2016, at 16:41, Christian Heimes <christian at 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'))
> '72.52.4.119'
> 
> Correct:
>>>> import idna
>>>> idna.encode(u'straße.de')
> 'xn--strae-oqa.de'
>>>> socket.gethostbyname(idna.encode(u'straße.de'))
> '81.169.145.78'
> 
> 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).

Cory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/security-sig/attachments/20161012/3a7748ae/attachment.html>