Skip to content

[WIP] [DON'T MERGE] Use ssl.PROTOCOL_SSLv23 constant by default under Python >= 2.7.9 < 3 and >= 3.4 - #683

Closed
Kami wants to merge 3 commits into
apache:trunkfrom
Kami:use_sslv23_constant_in_newer_versions_of_python
Closed

[WIP] [DON'T MERGE] Use ssl.PROTOCOL_SSLv23 constant by default under Python >= 2.7.9 < 3 and >= 3.4#683
Kami wants to merge 3 commits into
apache:trunkfrom
Kami:use_sslv23_constant_in_newer_versions_of_python

Conversation

@Kami

@Kami Kami commented Jan 16, 2016

Copy link
Copy Markdown
Member

Note: This pull request is W.I.P. and not yet ready to be reviewed and merged.

This pull request updates the code to use ssl.PROTOCOL_SSLv23 constant for ssl_version attribute when establishing SSL / TLS connection when using Python >= 2.7.9 < 3 and Python >= 3.4.

This constant offers the best security and compatibility since it will pick between TLS v1.0, TLS v1.1 and TLS v1.2 depending on the version supported / requested by the server. This is only done under aforementioned Python versions since un-secure SSL v3.0 is disabled by default in those versions.

In other versions where SSL v3.0 is not disabled we still use TLS v1.0 (ssl.PROTOCOL_TLSv1) which means nothing has changed - that's the same as the old / existing behavior.

Another thing to keep in mind is that user can also explicitly specify which version they want to use using libcloud.security.SSL_VERSION variable and this value has precedence over dynamically obtained values.

Ideally, if users know that the server supports TLS v1.2 they should explicitly specify and use that aka the highest supported versions (that's also mentioned in the documentation).

Kami added 3 commits January 16, 2016 14:26
… 2.7.9 and

Python >= 3.4 by default.

In those versions SSL v3.0 is disabled by default so it's safe to use this
constant and it results in the best compatibility since it will use TLS v1.0 /
v1.1 / v1.2 based on the versions supported by the server.

Also refactor exception wrapping functionality into a separate function.
@Kami

Kami commented Jan 16, 2016

Copy link
Copy Markdown
Member Author

I'm still contemplating if it's worth to finish this or if we should just switch to requests

Switching to requests is of course quite a bigger and potentially breaking in some places change, but I don't want us to maintain security critical code.

@jimbobhickville

Copy link
Copy Markdown

I'd vote for moving to requests. Let libcloud focus on the multi-cloud aspect and let requests handle the http heavy lifting. We'd have to drop Python 2.5 support, but I think that's ok.

@tonybaloney

Copy link
Copy Markdown
Contributor

we don't support py 2.5 anymore @jimbobhickville so thats ok.

@Kami

Kami commented Apr 17, 2016

Copy link
Copy Markdown
Member Author

I'm closing this.

Hopefully we can move to requests in the near future and we don't need this code anymore.

@Kami Kami closed this Apr 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants