As of etcd-io/etcd#5541, etcd now requires that TLSv1.2 be the minimum allowable TLS version for communicating with etcd. This is fine: it's a good security decision, and I'm glad they made it.
However, this module incorrectly configures the TLS settings such that it cannot actually talk to that new etcd version. This is because, on line 160 of client.py, it sets ssl_version to ssl.PROTOCOL_TLSv1. This is wrong, and in fact has always been wrong: it should only ever be set to ssl.PROTOCOL_SSLv23, and frankly should probably just be left unset entirely so that urllib3 can make a good decision for you.
When using any setting other than PROTOCOL_SSLv23, OpenSSL will clamp its minimum and maximum TLS versions to that version. That is, if you pass PROTOCOL_TLSv1_1, that will force OpenSSL to only allow TLSv1.1. Clearly, this behaviour is absolutely stupid. Worse, it means that the current settings cannot negotiate TLSv1.2, which means they cannot talk to etcd.
PROTOCOL_SSLv23, despite its absolutely terrible name, means "please negotiate the TLS version by telling the remote server what the lowest version you support is, and what the highest one you support is". Any remotely modern OpenSSL will correctly do this. This is the only sensible value to pass here, except in weird edge cases with crappy servers (which should never happen with etcd).
For this reason, that line should probably be outright removed from the code base, or at least replaced by setting PROTOCOL_SSLv23.
As of etcd-io/etcd#5541, etcd now requires that TLSv1.2 be the minimum allowable TLS version for communicating with etcd. This is fine: it's a good security decision, and I'm glad they made it.
However, this module incorrectly configures the TLS settings such that it cannot actually talk to that new etcd version. This is because, on line 160 of
client.py, it setsssl_versiontossl.PROTOCOL_TLSv1. This is wrong, and in fact has always been wrong: it should only ever be set tossl.PROTOCOL_SSLv23, and frankly should probably just be left unset entirely so that urllib3 can make a good decision for you.When using any setting other than
PROTOCOL_SSLv23, OpenSSL will clamp its minimum and maximum TLS versions to that version. That is, if you passPROTOCOL_TLSv1_1, that will force OpenSSL to only allow TLSv1.1. Clearly, this behaviour is absolutely stupid. Worse, it means that the current settings cannot negotiate TLSv1.2, which means they cannot talk to etcd.PROTOCOL_SSLv23, despite its absolutely terrible name, means "please negotiate the TLS version by telling the remote server what the lowest version you support is, and what the highest one you support is". Any remotely modern OpenSSL will correctly do this. This is the only sensible value to pass here, except in weird edge cases with crappy servers (which should never happen with etcd).For this reason, that line should probably be outright removed from the code base, or at least replaced by setting
PROTOCOL_SSLv23.