-
Notifications
You must be signed in to change notification settings - Fork 38
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
Server uses a self signed CA, plist set to ignore, still showing issues. #9
Comments
I may have stumbled on to a suspicious character. |
And this makes it seem unavoidable. |
Two different issues here. For some reason it really does seem to be ignoring the JSS_VERIFY_SSL setting. It shouldn't bother with it at all. I suppose if you're up for it, you could double-check and do this in terminal:
(Replace the URL, user, and password parameters with the correct data ;) As for the actual SSL issue, I suggest looking here: and adding/upgrading the packages mentioned to see if the problem magically vanishes. I don't know if that will help, but based on the requests issue #2022, it may. Just in case you're like, "huh?":
Feel free to use pip if you have it. |
Even after I install each of the recommended easy_installs, I get the following result in terminal: Traceback (most recent call last): |
?Geez. So it looks like it's not ignoring the verify settings. From: lucid772 notifications@github.com Even after I install each of the recommended easy_installs, I get the following result in terminal: Traceback (most recent call last): Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-61284113. This communication (including any attachments) is intended for the use of the intended recipient(s) only and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Any views or opinions presented are solely those of the author. |
Can you verify the session verify setting is True (after setting up the JSS object as per the above instructions):
|
As you can likely guess, it is returning False. Note that I tried this by direct JSS IP, CNAME, and FQDN with the same result. |
What... That's definitely an issue with Requests then. I'll see if there's an update that needs to get applied or any issues filed on that. As you can imagine, with verify=False it should be ignoring SSL entirely. Or at least that was my understanding of it. |
I agree with you, which makes it even worse when I get that silly "SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure" error after it tells me that. Additionally, while I am the one working on this, I know three others that are having the same issue personally. Is there a better way, IE simply apply an SSL cert to tomcat? I am able to do this, but I am worried about that meaning I will need to re-enroll all my devices as well :( Thanks again for all the help. |
?Having to re-enroll all of your devices is not trivial! That being said, I would think you would want SSL on just to be safe. I think the safest thing to do is to set up a testing server and ensure that adding the cert would solve it. I wouldn't force a re-enrollment unless you were sure that you wanted to go that route. From: lucid772 notifications@github.com I agree with you, which makes it even worse when I get that silly "SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure" error after it tells me that. Additionally, while I am the one working on this, I know three others that are having the same issue personally. Is there a better way, IE simply apply an SSL cert to tomcat? I am able to do this, but I am worried about that meaning I will need to re-enroll all my devices as well :( Thanks again for all the help. Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-61289513. This communication (including any attachments) is intended for the use of the intended recipient(s) only and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Any views or opinions presented are solely those of the author. |
Sorry if I implied somehow it was trivial... but yes I would setup a test environment first. I do think this issue may need to be solved for other though, as it appears to clearly be ignoring the plist settings as mentioned prior. I should note that this is not constant... Autopkgr DID run complete twice in the past without issue. Maybe I should reinstall and see if I get any difference in the result? |
These two seem to indicate that the issue is server side not client side https://github.com/kennethreitz/requests/issues/2022 |
@lucid772 I'm at a loss on this one. It looks like it's an issue with Requests, as @eahrold has referenced above. Now, that being said, while developing python-jss I used to have each API call perform a single GET, rather than what it is doing now, which is to use a session. When I would pull, for example, the full data on all of our policies (a ton of repeated GET requests), I would get the same SSL handshake error that you're experiencing, intermittently. I used to handle it by just waiting a couple of seconds and retrying, until it worked. However, once I started to use a session, it went away. Of course, that was with verify=True. Also, in those circumstances, it was definitely a 1/100 thing. It sounds like it happens every time you run. |
This issue is called by the fact that JAMF has disabled SSLv3 on JSS 9.61 to address the Poodle Attack. To fix that, simply go to |
Great news! Thank you everyone for looking into this. Do you know the file path on linux for these changes? (Ubuntu specifically if that helps). |
?So that worked? That would be great news! From: lucid772 notifications@github.com Great news! Thank you everyone for looking into this. Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-61496848. This communication (including any attachments) is intended for the use of the intended recipient(s) only and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Any views or opinions presented are solely those of the author. |
Found it at /usr/local/lib/python2.7... Will update with results as soon as I am finished. |
Correction, I appear to have no idea where the file you are referencing is located in linux. If anyone can advise that would be great. The file I did locate is at /usr/lib/python2.7/ssl.py However, the changes you have asked me to make do not exist (The return statements do not exist) |
@lucid772 You're not looking on your server, your looking on the mac where autopkg/AutoPKGr is running |
This is now solved. Thanks again for all the help (Yes, changing the local files repaired the issue). I will note that I updated from Casper 9.31 to 9.61 while using this product, which would explain the mid use break. I am glad we are able to flag the issue so that we can possibly repair this for future versions without requiring the manual change. |
@ocoda |
I also recently updated to 9.61, and experienced the same issue. The above fix worked for me too. Thanks! |
@sheagcraig |
I'm using Casper 9.52 and experiencing the same errors on every run. Updating /Library/Python/2.7/site-packages/jss/contrib/requests/packages/urllib3/util/ssl_.py with ocoda's fix (#9 (comment)) did not address it. |
as JAMF disabled SSLv3 on 9.61, I'm pretty sure, that your are have another issue. Could you send a stack trace (i.e. run autopkg from shell) please? |
I also received the following error: jss.contrib.requests.exceptions.SSLERROR: [ERRNO 1] _ssl.c:504 error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure. I followed @ocoda steps to edit ssl_.py to resolve the error but I now receive the following when testing with "autopkgr run -v Firefox.jss" UnboundLocalError: local variable 'password' referenced before assignment Any thoughts? |
In fact, I was having another issue. Bad recipe was causing the error to be thrown. Now that the recipe is fixed, no more errors. |
Here is where the file is now
|
Maybe this isn't the place, but could someone point me in the right direction for re-packaing the egg once I open to switch back to TLS? |
Hey @krispayne: First off, sweet beard. So I changed the way python-jss was getting packaged up. I failed to test fully on a clean install, and the egg is basically zipped up. I have since replaced the original installer package with a new one that installs the egg unzipped. Further, @ocoda pointed out that just yesterday Requests added the relevant urllib3 release that solves the SSL/TLS issue. I can't yet comment on whether it will ultimately solve your issue, but I'm going to update everything and release it this morning. Please let me know if it works! |
Thanks @sheagcraig! Do you know when you expect to publish the update? |
Well, I thought it was going to be about 4 hours ago... Then I started fixing more stuff. Definitely this afternoon. |
Alright folks-update is out with requests 2.5, which should hopefully solve all of your 9.61 TLS/SSL woes. Please report back with your findings! |
Do I still need to go into the ssl_.py and edit the TLS settings? |
|
|
Looks like we might have to reach in anyways? @ocoda? |
@krispayne Quick question: Did you notice whether you had multiple python-jss egg files in your site packages folder after the new installer? I can see where the old, "orphaned" one might get in the way, and I might need to clean it out with the postinstall script. Also, can you just be extra doubly sure and do this from the python interpretor:
Should be '2.5.0'. |
Python 2.7.5 (default, Mar 9 2014, 22:15:05)
In my first attempt, installing over the previous, like an upgrade, the older, 0.4.3 python-jss was orphaned. I removed it and it still didn't fly. So that's when I removed all the aspects, and installed it again, but still, no dice. |
I've just spun this up in a fresh Mavericks VM, same error. --J. t: @james_ridsdale Sent from my iPhone. On 3 Dec 2014, at 21:01, Kris Payne notifications@github.com wrote: Python 2.7.5 (default, Mar 9 2014, 22:15:05) import jss In my first attempt, installing over the previous, like an upgrade, the older, 0.4.3 python-jss was orphaned. I removed it and it still didn't fly. So that's when I removed all the aspects, and installed it again, but still, no dice. — |
I would like this to go away. Can you give the suggestion from @ocoda above a go: "This issue is called by the fact that JAMF has disabled SSLv3 on JSS 9.61 to address the Poodle Attack. To fix that, simply go to /Library/Python/2.7/site-packages/jss/contrib/requests/packages/urllib3/util/ssl_.py and import PROTOCOL_TLSv1 in addition to PROTOCOL_SSLv23. Now go to line 86 and change return PROTOCOL_SSLv23 to return PROTOCOL_TLSv1." The path is a little different, but should be easy to locate nestled within the egg. Specifically, with this version of requests:
line 149 should read
If this works I'll roll with it just to make these issues go away IF it doesn't impact < 9.61 users. Otherwise, we'll have to craft a way to switch based on JSS version. |
JSS 9.61 |
@sheagcraig sidenote, did you used to live in Massachusetts? |
I had the same results as krispayne, though with Casper 9.62 instead of 9.61. Once I edited ssl_.py to replace PROTOCOL_SSLv23 with PROTOCOL_TLSv1, I was good to go. |
damn! really hoped it could be that easy. For now I would hardcode the PROTOCOL_TLSv1 into urllib3. When anyone in here got some time you could try one of these: https://github.com/kennethreitz/requests/issues/749#issuecomment-17406518 The solution mentioned by hobarrera seems reasonable, but I haven't tested it. |
Agreed @ocoda. I'm going to just add it to the release checklist from now on to make sure that it's in place. I need to set up a few different test environments so I can automate all of this prior to releasing. If anyone can figure out a way using introspection or parameters to requests to configure away the need to actually change the requests code, I'd be much obliged. Seems like an icky way to do things. @krispayne I was wondering if you were that Kris Payne. Small world! |
kennethreitz/requests#749 looking at hobarrera's solution executes on my machine. Don't know yet whether it solves anything. I need to try on a clean machine and see if it works. The second link you provided seems like another way to do this, although again, way over my head. I'm going to do a release with the edits you proposed just to get this working for folks, and then set up some tests and test environments to dig into the above options. |
Take a look at the bottom at the syntax error. This popped up when I hardcoded TLS_v1.
|
Yep: somehow the underscore got removed from "wrap_socket". Add that back in and you should be good to go. py2.7.egg/jss/contrib/requests/packages/urllib3/util/ssl_.py", line 15 from ssl import wrap socket, CERT_NONE, PROTOCOL_TLSv1 ...and I can see why. You cut and pasted my comment above. Sorry about that. I've corrected it above too. |
Thanks, but check out the code you put in above. |
@jzwg Thanks-caught that and edited it. We ran out of coffee at work today! The next release will add this in for you too, so hopefully nobody else will have to goof around editing deep into the python morass. |
@sheagcraig The one and only! Very small world. |
@ocoda Just wanted to let you know that I discovered there is a built-in way in requests to use TLS over SSLv23: http://docs.python-requests.org/en/latest/user/advanced/#transport-adapters Here is python-jss' usage of it: |
@sheagcraig Thanks for pointing out, that will make things a lot easier in some of my scripts! |
Please see the comments and issue at lindegroup/autopkgr#178 (comment)
The text was updated successfully, but these errors were encountered: