[Python-Dev] [ssl] The weird case of IDNA (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Sat Dec 30 05:28:37 EST 2017
- Previous message (by thread): [Python-Dev] [ssl] The weird case of IDNA
- Next message (by thread): [Python-Dev] [ssl] The weird case of IDNA
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 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.
Regards
Antoine.
- Previous message (by thread): [Python-Dev] [ssl] The weird case of IDNA
- Next message (by thread): [Python-Dev] [ssl] The weird case of IDNA
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]