[Python-Dev] [ssl] The weird case of IDNA (original) (raw)

Christian Heimes christian at python.org
Sat Dec 30 08:34:04 EST 2017

On 2017-12-30 11:28, Antoine Pitrou wrote:

On Fri, 29 Dec 2017 21:54:46 +0100 Christian Heimes <christian at python.org> wrote:

On the other hand ssl module is currently completely broken. It converts hostnames from bytes to text with 'idna' codec in some places, but not in all. The SSLSocket.serverhostname attribute and callback function SSLContext.setservernamecallback() are decoded as U-label. Certificate's common name and subject alternative name fields are not decoded and therefore A-labels. The must stay A-labels because hostname verification is only defined in terms of A-labels. We even had a security issue once, because partial wildcard like 'xn*.example.org' must not match IDN hosts like 'xn--bcher-kva.example.org'. In issue [2] and PR [3], we all agreed that the only sensible fix is to make 'SSLContext.serverhostname' an ASCII text A-label. What are the changes in API terms? If I'm calling wrapsocket(), can I pass serverhostname='straße' and it will IDNA-encode it? Or do I have to encode it myself? If the latter, it seems like we are putting the burden of protocol compliance on users.

Only SSLSocket.server_hostname attribute and the hostname argument to the SNI callback will change. Both values will be A-labels instead of U-labels. You can still pass an U-label to the server_hostname argument and it will be encoded with "idna" encoding.

sock = ctx.wrapsocket(socket.socket(), serverhostname='www.straße.de')

Currently:

sock.serverhostname 'www.straße.de'

Changed:

sock.serverhostname 'www.strasse.de'

Christian

More information about the Python-Dev mailing list