[Python-Dev] [ssl] The weird case of IDNA

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.server_hostname attribute and callback function
>> SSLContext.set_servername_callback() 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.server_hostname' an ASCII text A-label.
> 
> What are the changes in API terms?  If I'm calling wrap_socket(), can I
> pass `server_hostname='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.wrap_socket(socket.socket(), server_hostname='www.straße.de')

Currently:
>>> sock.server_hostname
'www.straße.de'

Changed:
>>> sock.server_hostname
'www.strasse.de'

Christian



More information about the Python-Dev mailing list