On 2017-01-12 09:45, Cory Benfield wrote:
On 11 Jan 2017, at 21:23, Christian Heimes <christian@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