Use built-in ssl module

[jessaustin]

I had some issues trying to get SSL/TLS to work with python version 3.3. Consistent with this experience, test_ssl_context_adhoc fails for me on that version. #434 reports one of several issues I saw.

To fix this, I've ripped out all direct dependence on OpenSSL.SSL, and replaced that with python's built-in (since v2.6) ssl module. The _SSLConnectionFix class is gone completely, and a few related functions use ssl.SSLContext instead of OpenSSL.SSL.Context. I've left in everything from OpenSSL.crypto, since that seemed not to cause any problems. All tests pass on v3.3 with this update.

I don't know if this is the sort of thing the maintainers want. There are a few issues with what I've done here. First, the API has changed, since ssl.SSLContext is not a direct replacement for OpenSSL.SSL.Context. Also, load_ssl_context() now takes an additional (optional) parameter, protocol. This parameter may be one of the PROTOCOL_SSLv23 (the default), PROTOCOL_SSLv3, or PROTOCOL_TLSv1 constants defined in ssl.

The existing code used the OpenSSL.tsafe.Connection class. Thread safety is probably important to someone who is using werkzeug to serve SSL, and I think I'm breaking that. tsafe is not the best-supported of modules, however, since it still has an apply() call, and apply() has been deprecated since v2.3. I'm open to suggestions: should we just rip off the tsafe code and drop it directly in werkzeug? Or should we not worry about it and tell everyone not to share any particular SSLContext instance among multiple threads?

[ghost]

@jessaustin Thank you for incredible effort. 👏 +1 for merging.
Just a single annotation: someone who's using Werkzeug to serve SSL in production didn't understand that you shouldn't use builtin server except for testing. So don't care about thread safety ;-)

OT: I would completely remove SSL support from Werkzeug. Useful for testing but complicating things too much and giving a false sense of security.

[untitaker]

I think the rudimentary SSL support might be really useful for development.

[untitaker]

I don't know if this is making the SSL support better in the dev server, if yes, i am certainly +1 for getting it merged.

[jessaustin]

@Gioi of course you're right that the included server is not suitable for production, but I have to agree with @untitaker that it's quite handy for development.

[ghost]

Ok, just a provocation ;-)

[depassp]

+1 for merging this. I made basically the same patch and was about to open a pull request.

[Ivoz]

Did the maintainers have anything against merging this?

[untitaker]

No, it's just that they're pretty inactive.

[untitaker]

See https://github.com/pocoo/metaflask/issues/6

[untitaker]

Any thoughts on this @mitsuhiko ?

[untitaker]

FWIW this fixes the Python3 testfailures i have in pimutils/vdirsyncer#106

[untitaker]

Closing this in favor of #565