-
-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
TLS SNI Support #749
Comments
Not posisble in Python 2.x on top of the stdlib's ssl module. |
Twisted has it, right? Perhaps time to depend on pyopenssl or some other ssl module? |
There's a pull request for urllib3 adding SNI support for Py32+, but still needs test coverage. urllib3/urllib3#89 |
shzow: Thanks for the pointer. I'm unfortunately using Twisted/Flask, which means I'm stuck to 2.7. Twisted it seems can do something like this, but i've not seen examples, and it would need pyopenssl + twisted decoding to do this. Am not an expert in either to pull this off. At this point, just thinking of wrapping some command line utility like wget... :( |
PyOpenSSL should be able to do it on 2.x. So there is hope. |
I could make it work with pyopenssl. But I still am having a hard time getting it done in twisted correctly. http://pbin.be/show/719/ -- kind of works. But then one has to build an API on it for it to be any useful. I still cant figure out how to pass the correct context to Agent. |
Lukasa: was this resolved? |
No. We're blocked on urllib3/urllib3#89. |
Merged. Carry on. :) |
Note that it's only supported on Py32+ for now. Should be enough to get started though. |
Another fair warning: Some tests on Py32 are failing on urllib3 master right now. Some help resolving this would be greatly appreciated (and might affect this functionality): urllib3/urllib3#128 |
works for me on archlinux x64 on py26, py27, py32, py33 |
Ah I should have qualified that this is on OSX. Scumbag OSX. |
t-8ch: Are the sni tests passing on py26/27/32 and 33 for you? |
The SNI tests aren't even run on py2, but on py32 and py33 it works. |
@shazow: Presumably you have no interest in making urllib3 depend on PyOpenSSL? |
I'd be happy to have a separate library which adds SSL via PyOpenSSL support to urllib3. |
It looks like @t-8ch is knocking it out of the park with the work on urllib3. I'll let him tell us when this can be closed. |
urllib3 has optional support for SNI with python2, though with a few optional dependencies. (See urllib3#156). I belive this should work using:
After adding this to
Note that the There are basically two alternatives to enable SNI in requests:
I've no problem implementing any of both alternatives, though I'd prefer to know which would be the prefer one for requests. I personally vote for the second alternative. BTW: can we reopen the issue, now that we have support from urllib3? |
I actually prefer the former because the people who need it are the ones who know they'll need it and they're few enough that it won't cause too many complaints. However, if we're going to be consistent with the existing API, the latter would be the way to implement it. Currently, urllib3 (and requests) will provide the API to send HTTPS requests without the ssl module present but will fail in the case where the ssl module is not available. In other words, the API is there and you can use it but it just won't work and that is indicated by an exception. As to re-opening this, that's up to @kennethreitz. The issue of course (with all of this) is that we're currently under a feature freeze (#1165, #1168) so I'm not sure if the work is even worth doing because it might not be accepted. |
Let me be a bit clearer: what I meant by the second alternative was "Try to use SNI if the optional deps are available, but still use SSL as we always have it they aren't.". This shouldn't break anything existing up to now. As for reopening (or not) the issue, IMHO, this issue shouldn't be taken lightly. requests can become useless without SNI support for many scenarios. In particular, multiple domains on a single IPv4 host without SNI become impossible. And additional IPv4 addresses are out of the questions for many users (due to their cost). In any case, this is half feature, half bug, though I'll await @kennethreitz's reply regarding reopening the issue. |
Hugo: I just did pip install -U requests, and when I can't import contrib. On Fri, May 3, 2013 at 1:12 PM, Hugo Osvaldo Barrera <
|
request's setup.py doesn't include that package (the source it's there, but it's excluded when installing/packaging), so it's not installed, that's why I mentioned:
You'll basically need to install from source. |
SSL is not always there though. That was my point. Currently we try and use it but fail hard and fast if we don't have it and a user tries to make an https request. The way you had described it though, I was under the impression SNI would require the user to pass some extra notion to urllib3 and you were focusing on just the set-up for it. If all that is necessary is #1347 then I'm 100% behind this. |
It would be really nice if this was the default (SNI Support) and requests On Fri, May 3, 2013 at 10:43 PM, Ian Cordasco [email protected]:
|
Because urlgrabber is being dropped by many significant software projects in Fedora, Pykickstart can't keep depending on it once it is converted to Python 3 (rhbz#985310). This commit replaces the dep with requests with SSL verification turned on by default. This could pose trouble in Python 2 if proper underlying packages aren't installed [1]. In case this becomes a problem, the SSL_VERIFY constant in constants.py may be switched to False. [1] https://github.com/kennethreitz/requests/issues/749#issuecomment-19187417
Because urlgrabber is being dropped by many significant software projects in Fedora, Pykickstart can't keep depending on it once it is converted to Python 3 (rhbz#985310). This commit replaces the dep with requests with SSL verification turned on by default. This could pose trouble in Python 2 if proper underlying packages aren't installed [1]. In case this becomes a problem, the SSL_VERIFY constant in constants.py may be switched to False. [1] https://github.com/kennethreitz/requests/issues/749#issuecomment-19187417
Because urlgrabber is being dropped by many significant software projects in Fedora, Pykickstart can't keep depending on it once it is converted to Python 3 (rhbz#985310). This commit replaces the dep with requests with SSL verification turned on by default. This could pose trouble in Python 2 if proper underlying packages aren't installed [1]. In case this becomes a problem, the SSL_VERIFY constant in constants.py may be switched to False. [1] https://github.com/kennethreitz/requests/issues/749#issuecomment-19187417
Because urlgrabber is being dropped by many significant software projects in Fedora, Pykickstart can't keep depending on it once it is converted to Python 3 (rhbz#985310). This commit replaces the dep with requests with SSL verification turned on by default. This could pose trouble in Python 2 if proper underlying packages aren't installed [1]. In case this becomes a problem, the SSL_VERIFY constant in load.py may be switched to False. [1] https://github.com/kennethreitz/requests/issues/749#issuecomment-19187417
Because urlgrabber is being dropped by many significant software projects in Fedora, Pykickstart can't keep depending on it once it is converted to Python 3 (rhbz#985310). This commit replaces the dep with requests with SSL verification turned on by default. This could pose trouble in Python 2 if proper underlying packages aren't installed [1]. In case this becomes a problem, the SSL_VERIFY constant in load.py may be switched to False. [1] https://github.com/kennethreitz/requests/issues/749#issuecomment-19187417
Because urlgrabber is being dropped by many significant software projects in Fedora, Pykickstart can't keep depending on it once it is converted to Python 3 (rhbz#985310). This commit replaces the dep with requests with SSL verification turned on by default. This could pose trouble in Python 2 if proper underlying packages aren't installed [1]. In case this becomes a problem, the SSL_VERIFY constant in load.py may be switched to False. [1] https://github.com/kennethreitz/requests/issues/749#issuecomment-19187417
Fixes * Fix #1196 * Fix #1398 Along with the self contained agent (pyopenssl etc) it will support SNI. See https://github.com/kennethreitz/requests/issues/749 for more information
* Fix #1196 * Fix #1398 Along with the self contained agent (pyopenssl etc) it will support SNI. See https://github.com/kennethreitz/requests/issues/749 for more information
According to https://github.com/kennethreitz/requests/issues/749#issuecomment-19187417 there is no need to install pyasn1-modules.
According to https://github.com/kennethreitz/requests/issues/749#issuecomment-19187417 there is no need to install pyasn1-modules.
I am running Python 2.7.6 and can not install pyOpenSSL. I have tried the work arounds in the htis post -> https://stackoverflow.com/questions/18578439/using-requests-with-tls-doesnt-give-sni-support/18579484#18579484 I can not also upgrade by Python. Any other solutions? |
I'm requesting we reconsider the unconditional use (if present) of "inject_into_urllib3()". Added 7 years ago, the goal was to "add SNI support for Python 2" "urllib3.contrib.pyopenssl.inject_into_urllib3()" is described to "Monkey-patch urllib3 with PyOpenSSL-backed SSL-support.": Justification: 2: Unnecessary: As of Dec. 10, 2014, the entirety of Python 3.4's ssl module has been backported for Python 2.7.9. See PEP 466 for justification. https://www.python.org/downloads/release/python-279/. This enables SNI support in the standard library for > v2.7.9 3: Inflexible: As implemented, there is no way to disable this behavior. The only option to prevent |
Hi guys. Sorry to rehash an old thread but this just became relevant for a lot of users again, because python2.7 support has reached end-of-life and specifically SSLv2 cert and non-SNI requests are being dropped from a lot of servers this year. I'm now getting this error with my python2.7.6 stack: Sadly, nothing I'm trying is working, including installing various versions of requests and requests[security] via pip. Is there some way to recover SNI support in python2.7.6 / pip and get past this TLS handshake failure? Upgrading to a different version of python or a different operating system are not an option for me right now. |
It seems I'm having problems using requests with servers that need TLS SNI support. When will requests have this feature? Is this something that is planned?
Thanks,
--Ram
The text was updated successfully, but these errors were encountered: