trio.ssl handling for Unicode (IDNA) domains is deeply broken

trio.ssl relies on the stdlib ssl module for hostname checking. Unfortunately, when it comes to non-ASCII domain names, it's totally broken. Which means that trio.ssl is also totally broken. In other ways, trio handles IDNA well (better than the stdlib). But this is hard to work around.

We don't have a lot of great options here. We could:

• Substantially rewrite trio.ssl to use PyOpenSSL instead. But this requires adding a bunch of tricky code, and also would break our API. (We currently take a stdlib ssl.SSLContext object as input, and it's impossible to read the SNI callback and other critical attributes off of an ssl.SSLContext object, which means that it's impossible to correctly convert a stdlib SSLContext into a PyOpenSSL equivalent. See bpo-32359.)

• Hope that upstream ssl gets better, or fix it ourselves. Not impossible, but maybe not a thing to hold our breath on either.

• Hope that PEP 543 comes along and saves us.

• ....?

I'm not sure what to do, but at least now we have a bug to track the problem...

Original text:

IDNA support in trio.socket

Help I have no idea what I'm doing here.

Probably also touches on TLS support, #9.

Start by reading the trio.ssl and trio.socket handling described in this issue, then review the linked stdlib ssl and PEP 543 discussions. Compare the PyOpenSSL, upstream ssl, and API-compatibility options; the work is done when Unicode IDNA hostname checking is correct without breaking the existing SSLContext API.