Traceback (most recent call last):
  File "client.py", line 10, in <module>
    conn.send(b'')
  File "/usr/lib/python3.6/ssl.py", line 941, in send
    return self._sslobj.write(data)
  File "/usr/lib/python3.6/ssl.py", line 642, in write
    return self._sslobj.write(data)
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:2074)

This error is not what I expected. I expected a noop instead.

My guess is, that python calls SSL_write (3.6 branch, _ssl.c:2038) with that empty buffer.
The manpage states: "When calling SSL_write() with num=0 bytes to be sent the behaviour is undefined."

This undefined behaviour should either be documented in python, or defined to either raise an exception (ValueError?) or defined as a noop. I'd prefer the latter.

It's a bit too late to change the behavior of send(). Let's document the issue instead.

If openssl says the behavior is undefined, then don't we have to first make it defined before we can document it?

And if we're going to detect this case and guarantee some behavior, making it a no-op like it is on regular sockets seems the way to go...

The message "EOF occurred in violation of protocol" is set by Python. Python maps SSL_ERROR_SYSCALL with SSL error code == 0 and len == 0 to that error message.

https://github.com/python/cpython/blob/master/Modules/_ssl.c#L682-L689
https://github.com/python/cpython/blob/master/Modules/_ssl.c#L2263

I don't know why the code was implemented that way.

My point is that SSL_write(3ssl) says "WARNING: When calling SSL_write() with num=0 bytes to be sent the behaviour is undefined."

Apparently on the particular openssl you're looking at, it gives SSL_ERROR_SYSCALL with error code == 0 and len == 0, but the openssl devs claim this is some arbitrary thing that shouldn't be depended on.

Just as a general principle it would be nice if performing ordinary operations on an SSLSocket from Python did not invoke undefined behavior :-)

Are there any possible next steps on this?

This issue is very counterintuitive and challenging to debug --- it commonly presents as a nondeterministic edge case, and it appears to be a failed system call but doesn't show up in strace.

Thanks for your time.

Manpage (openssl 1.1.1d) now states:

You should not call SSL_write() with num=0, it will return an error. SSL_write_ex() can be called with num=0, but will not send application data to the peer. SSL_write_ex was added in 1.1.1

So it looks like openssl cleaned up another mistake by defining SSL_write_ex's behaviour to be a noop.

Thanks to PEP-644 the issue will be fixed in 3.10 by using SSL_read_ex and SSL_write_ex() functions. I couldn't use the functions earlier because Python had to support older OpenSSL versions and LibreSSL.

See #25468 and bpo-42854