Archived

This forum has been archived. Please start a new discussion on GitHub.

IceSSL: Additional failure info accessible from the low level SSL engine?

13»

Comments

  • xdm
    xdm La Coruña, Spain

    Hi Fábio,

    Glad you get it to work with the new certificate, I'm pretty sure there was some problem with the old one, I check with openssl and Windows mmc and extensions didn't show up

    Cheers,
    Jose

  • Hi Jose,

    During an Ice connection/disconnect we are observing a total of three callbacks to our certificate verifier we have installed. We observe 2 of these up front when the connection is established. The first being the initial connect to the remote system (expected), and then another once credentials are provided (not expected). Then when we close the connection, we see yet another callback to the verify() routine, which is really unexpected. I tried enabling all ice tracing to see if it would help us understand this, but there's not much additional info there. The Ice documentation for a certificate verifier doesn't mention any other reasons for a callback other than the initial connection. I didn't see anything in the information provided to the verify() routine that would help us determine a reason for callback. Do you have any thoughts on this?
    Thanks
    Jeremy

  • xdm
    xdm La Coruña, Spain

    Hi Jeremy,

    There should be only one call to verify after SSL handshake, can you enable tracing to see what is going on while this happens:

    Ice.Trace.Network=3
    Ice.Trace.Protocol=1
    Ice.Trace.Retry=2
    IceSSL.Trace.Security=1
    

    I will try to reproduce the issue with our test suite.

  • Hey Jose,
    I think this might be something on our end . We do open up two connections on start for different reasons which would explain those verifications. And something in our shutdown for our program might be errantly trying to re-establish the connection. I should have done a bit more debugging before reaching out. I got additional feedback from another developer right after I posted this to you.
    thanks
    Jeremy

  • Hi Jose,
    I probably should be opening new topics for my questions, and if that's preferable to you let me know.
    We are adding support for certificate purpose in our self signed and CA signed certs. I'm pretty sure that there's some verification that Ice does for this if we set VerifyPeer to 1, but as you are aware we are setting this to 0, and allowing additional verification to be done in our cert verifier. I don't see any methods on the IceSSL certificate class related to purpose. Currently we use only Ice methods to do our additional cert verification and I was hoping to not have to bring in other dependencies, but we might need to do so if there isn't a common way to verify purpose. If there's anything you can think of from your end that might help us, let me know.
    Thanks
    Jeremy

  • xdm
    xdm La Coruña, Spain

    Hi Jeremy,

    This is currently not supported with Ice::Certificate class, IceSSL doesn't explicitly validate the certificate purpose it relies on the underlying SSL library chain validation for this, I assume you want to get the key usage and extended key usage, or are you thinking of anything else?

    Not sure how easy would be to add this to the Certificate API and if it would be possible without additional dependencies.

  • Yes, just key usage / extended key usage is what we needed. We added support to our creation of self-signed certs to set the extended key usage to "server authentication", as we were expecting most CA signed certs created by our customers to have this set as well. It's not a must-have, but would be desirable for sure. Thanks!

  • xdm
    xdm La Coruña, Spain

    Added to our TODO issues here https://github.com/zeroc-ice/ice/issues/1298 seems like something we can add in the next patch release but I didn't yet check if is supported on all platforms.

  • Thanks! Our story for implementing this will depend on something from you guys as we decided today we didn't want to bring in the OpenSSL dependency just for this. Platforms we care about are Mac/Linux/Windows. We will keep track of this issue on your TODO list.

  • Hi Jose,
    How do we build Ice for Apple ARM? I think the default is Intel x86. I didn't see anything about this in the readme, other forum posts, or just searching online. It's probably a command line to "make", or potentially an edit to Makefile/Make.rules.
    Thanks
    Jeremy

  • xdm
    xdm La Coruña, Spain

    Hi Jeremy,

    We use the compiler default arch, for Apple Silicon is arm64, for 3.7 you don't need to set anything, we recently pushed a fix included in 3.7.6 to pick the correct dependencies

    https://github.com/zeroc-ice/ice/commit/4cfc616971da45e1d549db6818e4b9d014fc31cd#diff-e857c2a3e764c7ed213b415ede36e7ed0d2a5257c2f3e2fe1d9dcc4d7b6e75d9

    Before you have to manually set MCPP_HOME and LMDB_HOME to point to the arm64 homebrew install

  • That makes sense.
    One more (hopefully not stupid) question: For the life of me I can't get the Ice tests to run using "python allTests.py". This is on Windows, but I have the same issue on Linux too. I've built all the code in Release mode. I can see in the cpp/test/Ice/ folders that I have a /client/x64/Release and Cpp11-Release folders. They appear to have the exe in there. When I run "python allTests.py" it just errors out saying [WinError 2] The system could not find the file specified. I've tried passing a --config=Release or --config=Cpp11-Release to it, thinking that might be the issue, but it still doesn't run. I've tried to unwind how the python test script is doing things but am getting a bit lost. I must be doing something wrong or have something not configured correctly, but I've just followed the instructions for this in the Ice README file.
    Thanks
    Jeremy

  • xdm
    xdm La Coruña, Spain

    On Windows try

    python allTests.py --config=Release --platform=x64
    

    Or for C++11

    python allTests.py --config=Cpp11-Release --platform=x64
    

    On Linux and macOS you can use

     make print V=supported-configs
    

    This prints the supported configurations, the default is shared to run C++ 11 test on Linux you can do

    python allTests.py --config=cpp11-shared
    

    If you still have issues add --debug argument and this will print the command that is run, and some additional info, and we will hopefully be able to figure the issue from the output.

    Cheers,
    Jose

  • Ok, ah-ha moment here. I've been running the tests out of the icelivesocket repo that you created for us. We have a copy that's probably not up to date with yours. I don't have access to it. Anyway, I've been running my tests out of the root of that folder, and not down in src/ice/cpp. If I build ice source there, it does actually build more of the tests then it did if done from the root of icelivesocket. And yes, I did need to add the --platform=x64 and that got it going further. I'm not sure why doing this from icelivesocket isn't working, but I don't know much about our agreement on that repo, and keeping it up to date.
    Thanks
    Jeremy

  • I'm seeing test failures on both Windows and Mac, in the same spot. I did switch to 3.7.6 to make sure it wasn't something with our patched 3.7.5 version (we haven't moved over to the 3.7.6 branch/tag yet). Here's my failure:
    testing property inheritance... ok
    *** [61/92] Running cpp/Glacier2/application tests ***
    [ running client/server test - 07/19/21 16:56:51 ]
    starting Glacier2 router... "/System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python" /Users/jeremycook/github/icelivesocket/src/ice/scripts/icehashpassword.py failed:
    Traceback (most recent call last):
    File "/Users/jeremycook/github/icelivesocket/src/ice/scripts/icehashpassword.py", line 6, in
    import sys, getopt, passlib.hash, passlib.hosts, getpass
    ImportError: No module named passlib.hash

    test in Glacier2/application failed:
    "/System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python" /Users/jeremycook/github/icelivesocket/src/ice/scripts/icehashpassword.py failed:
    Traceback (most recent call last):
    File "/Users/jeremycook/github/icelivesocket/src/ice/scripts/icehashpassword.py", line 6, in
    import sys, getopt, passlib.hash, passlib.hosts, getpass
    ImportError: No module named passlib.hash

    Known issue we can ignore?

  • xdm
    xdm La Coruña, Spain
    edited July 2021

    Hi Jeremy,

    Regarding Glacier2 failures, you need to install passlib python module for running the Glacier2 tests. You can also ignore it if you are not using Glacier2 component.

    See https://github.com/zeroc-ice/ice/tree/3.7/cpp#running-the-test-suite

    Were you able to run the tests from icelivesocket repository?

  • Hi Jose,

    I don't think my last comment made it through - maybe it was too long as it had compiler output. I got through the passlib stuff with the steps you suggested.

    We are currently not able to build and test directly out of the icelivesocket repo. We can build just fine, but when we run the allTests.py script, it fails right away. This is on both Mac and Windows. It does look as if the Ice binaries and dependencies aren't being found when the tests run. On Mac it complains about libLiveSocket.so, and and Windows its iceLiveSocket37.dll. If the binaries are manually copied we can get it to work but we shouldn't have to do that. Is your expectation that those tests run without additional steps out of the icelivesocket repo?
    Thanks
    Jeremy

  • xdm
    xdm La Coruña, Spain

    Hi Jeremy,

    Can you provide us access to the livesocket library you are using for testing, Greg sent us a link back in May but the credentials no longer work. Please send this to support@zeroc.com and I will look at it.

    Cheers,
    Jose