On 2017-01-12 09:45, Cory Benfield wrote: > >> On 11 Jan 2017, at 21:23, Christian Heimes <christ...@cheimes.de> wrote: >> >> * Do we need to define blocking / non blocking state of the socket? > > I think we want to support both. I’m not sure we need to expose it in the > API: the implementation can check by asking the socket directly if it cares.
Do we need to support both? I thought that wrap_buffers() is the preferred way for non-blocking TLS with an event loop. You are the expert, do SChannel and SecureTransport work with non-blocking sockets and WantRead/WantWrite? > >> * What about STARTTLS support, do we need to define how to deal with >> data that has been transmitted before? > > Hrm. I’m inclined to want to hold off on that to begin with, though you’re > welcome to propose an API extension if you have a concrete idea of how to do > it. Not really, just add it to the ToDo pile :) >> OpenSSL's hostname verification code accept IDN A-labels. SubjecAltNames >> are encoded as IA5String containing IDN A-labels, too. For most >> flexibility the wrap functions should accept server_hostnames as both >> U-label and A-label. If you add an encode_hostname() method to the >> context, than users can easily override the method to switch between >> IDNA 2003, 2008 or perform custom checks to prevent homoglyphic >> confusion attacks. > > My question here is: do we need to pursue this in the abstract API? Or can it > be left up to concrete implementations to worry about? I see some merit to either have a formal encoding hook on the context or to limit server_hostname to punycode. But before we decide, we need to study TLS implementations. OpenSSL requires IDN A-labels. NSS' CERT_VerifyCertName() consumes IDNA, too. InitializeSecurityContext() pszTargetName has no encoding specification. I'm not familiar with SecureTransport. Christian _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
