-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PyOpenSSL for SNI-support on Python2 #156
Conversation
This gives us SNI goodies on all Python versions.
The SNI/subjectAltName tests have a one big problem: They access the great big, bad Internet, because I am not sure how to create the correct certificates for this. Also, this only works in all cases if pyasn1 and ndg-httpsclient are installed (parsing DER-encoded binary data extracted from X.509 extensions is not my idea of fun.)
Hmm I'd be -1 on merging this as-is. I'm not a fan of environment flags for libraries if we can avoid it, and this seems to depend on a lot of fragile things. Perhaps a better strategy would be to refactor the API to allow you to plug in your own Does anyone else have feelings on this? (@wolever @wallunit @t-8ch, anyone else?) |
Has PyOpenSSL any significant drawbacks? Otherwise I would prefer to automatically pick it, if it is installed, and the built-in ssl module doesn't support SNI. I don't like the environment variable approach either. |
+1 for removing the env variables @shazow: Wouldn't @kirkeby: With the following patch this PR could also use the fingerprint
|
|
||
return dns_name | ||
|
||
class wrapped_socket(object): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this classname should use camelcase.
The environment variables are gone now, and the I'm open to attempt to refactor the API to allow pluggable Regarding drawbacks with PyOpenSSL, I can only think of one: This implementation has not been tested as much as the stdlib-backed one. |
Looking better. Alright, let's do this as a first step:
Once we have this, then the next step would be to refactor how How does that sound? |
Sounds good. |
This makes the SNI-test raise SkipTest if SNI is not supported, so it can be reused by test.contrib.test_pyopenssl even when the stdlib does not support SNI. It also tests the urllib3.contrib.pyopenssl module when its dependencies are installed, by re-exporting HTTPS test-cases and using module-level setup/teardown code to monkey patch urllib3.
How does it look now? |
Looks decent for a contrib module. :) Should we revert the changes to If you'd like to add a Sphinx docs section on the contrib module, specifically about your PyOpenSSL addition and how to use it, I would be +1 to that. Could do that later though. |
+1 for pulling in the changes to |
@t-8ch Do you mean |
|
Ah fair enough. Let's keep it. |
Okay. I hope I found the right place to add that contrib section :) |
Now there's a ready-to-use code snippet in the module's doc-string, which is auto-moduled into the contrib page, is that okay? |
Optional PyOpenSSL for SNI-support on Python2.
Merged. :) |
Yay! Thanks :) |
This adds optional SNI-support for Python2, if pyOpenSSL, pyasn1 and ng-httpsclient are installed (pyasn1 and ng-httpsclient are used to parse the subjectAltName of certificates).