I initially filed this ticket against the ldap3 library, as this is where I first encountered the issue: https://github.com/cannatag/ldap3/issues/356

I've attached a file which reproduces the issue using the standard library - it makes both a HTTP and HTTPS request to a link that should return a HTTP response after 10 seconds, but we set the socket option SO_RCVTIMEO to 2 seconds. This should result in a read timeout while waiting for a response.

On my 64 bit Ubuntu 16.04 machine, the HTTP connection times out as expected, but the HTTPS connection doesn't time out at all (and so ends up reading the HTTP response).

It doesn't seem to be an issue specific to HTTPS - I ran into the original issue while using TLS for an LDAP connection using the ldap3 library. If you follow the comments in the ticket, a connection with SO_RCVTIMEO set to 3 seconds ended up taking 1076 seconds to timeout, while on an OSX machine, it took 148 seconds to timeout. On a Windows machine, it seems to work just fine (it timed out after the desired 3 seconds).

Is this option fully supported for SSL sockets?

SO_RCVTIME0 works only with operating system level sockets. A SSLSocket is not an OS level. It's a high level abstraction layer that wraps either a file descriptor or a memory BIO. A read operation on a SSLSocket can perform write, a write operation can perform read. For the initial handshake, it will do both.

This means that SO_RCVTIME0 is not supported. Either you have to use the SSLSocket's timeout feature or do your own socket io and use a memory BIO. The internal timeout feature is build around select()/poll() syscall and low level OpenSSL calls.