Home Comments

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

fish4lifefish4life Member Jeremy CookOrganization: HP IncProject: Remote Boost - remoting software

We are looking to enhance the user experience around certification validation failures in our application. IceSSL::verify() does provide verification for a number of items ( e.g. cert chain provided, chain valid, chain depth, and trust ), and potentially more. But if any of those fail, the return is simply a true/false. We understand that we could write our own logic to do these verifications up front, but if Ice already has this logic build in, it would be nice to be able to access it so we don't have to have our own. Currently we do install a certificate verifier as well, which we use to do extra validation, but that also won't be called unless the low level Ice SSL checks pass. If this information could be obtained, we could enhance our certificate dialog prompt back to the user that might help them more accurately understand the failure and how to fix it.
Thanks!

Comments

  • xdmxdm La Coruña, SpainAdministrators, ZeroC Staff Jose Gutierrez de la ConchaOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff

    Hi Jeremy,

    I see two ways you can do this, disable the IceSSL verification with IceSSL.VerifyPeer=0 and
    handle all the verification in your custom certificate verifier.

    An alternate way would be to catch the SecurityException throw by IceSSL and inspect the "reason"
    member. Your own certificate verifier can also throw SecurityException to indicate failures so you
    would be able to handle both the low-level IceSSL checks and your custom certificate verifier checks
    in the same way.

    Cheers,
    Jose

  • FabioMoreiraFabioMoreira Member Fábio MoreiraOrganization: HPProject: Remote Desktop solution

    Hi Jose,

    Some additional information:

    We do have our own certificate verifier installed. When a certificate issue happens during a connection, we display a warning dialog. We then allow the user to either proceed with or deny the connection.

    For the user to do that, we need to inform him about the certificate issues. By inspecting the object provided by Ice we can see if the Ice certificate validation failed or not but we don't know why it failed.

    We could write code that finds the certificate issue by checking the certificate expiration date, the certificate chain structure, etc. We could also write code to call SChannel / SecureTransport / OpenSSL to do this validation for us.

    We would like to avoid writing that code if we could simply get the certificate issues from ice. It seems you do have that information, since that is available when the exception is thrown.

    However, inside the certificate verifier I don't think we have access to this information because no exception has been thrown yet.

    Thanks for the help.
    Fábio

  • xdmxdm La Coruña, SpainAdministrators, ZeroC Staff Jose Gutierrez de la ConchaOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
    edited March 25

    Hi Fábio,

    If you can work with an updated version of Ice, we can patch IceSSL to provide some kind of error code,
    this can be the native SSL library error code, or we can map these errors to a new IceSSL error code that
    is independent of the native SSL library, and then make it accessible to the verifier by either adding a
    new field to the IceSSL::ConnectionInfo object (this is a binary incompatible change) or using a thread
    static variable.

    With the Ice 3.7 API, there is no way to get this error information. You can use the native APIs of each SSL
    library to validate the certificates again and get the reason for the failure, but this is not trivial. We
    can help you write this code if required.

    Let us know what would be a better fit for your project and we can work from there.

    Cheers,
    Jose

  • FabioMoreiraFabioMoreira Member Fábio MoreiraOrganization: HPProject: Remote Desktop solution

    Hi Jose.

    Creating a new IceSSL error code and making it accessible from IceSSL::ConnectionInfo would be perfect for us. Is this something that can be implemented on a future Ice release (3.7.6)?

    We are currently using 3.7.2 and we build it, so it if is possible to patch it that would work for us as well. If making the error code accessible from a static variable is simpler to implement, that would be fine.

    Thanks again,
    Fábio

  • xdmxdm La Coruña, SpainAdministrators, ZeroC Staff Jose Gutierrez de la ConchaOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff

    Hi Fabio,

    I going to implement this and I will get back to you as soon as I have something working.

    Cheers,
    Jose

  • FabioMoreiraFabioMoreira Member Fábio MoreiraOrganization: HPProject: Remote Desktop solution

    That's awesome.

    Thanks so much.

    Fábio

  • xdmxdm La Coruña, SpainAdministrators, ZeroC Staff Jose Gutierrez de la ConchaOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
    edited March 31

    Hi Fabio,

    I opened a PR with the required changes for 3.7 https://github.com/zeroc-ice/ice/pull/1270
    feel free to post any comments there, it is still going throw review and subject to changes.

    Cheers,
    Jose

  • FabioMoreiraFabioMoreira Member Fábio MoreiraOrganization: HPProject: Remote Desktop solution

    Hi Jose.

    It looks good.

    I see there will be an option to get an error description string as well. That will be pretty useful.

    I'm assuming it will only be possible for the certificate verification routine to return a single error. Is that correct?

    Thanks again.

    Fábio

  • fish4lifefish4life Member Jeremy CookOrganization: HP IncProject: Remote Boost - remoting software

    Hi Jose,
    I'm having trouble building the branch that has your patch. Any chance you have any built binaries for these changes that we could just try out? Only need them for Windows for now.
    Thanks
    Jeremy

  • fish4lifefish4life Member Jeremy CookOrganization: HP IncProject: Remote Boost - remoting software

    Never mind, I was able to build it after installing the Windows UCRT SDK dependency. I can't use the branch directly in our code as it looks like headers might have changed? We're running on 3.7.2 now. Regardless, the number of files modified was small enough that I just patched our 3.7.2 source and got that to go.
    I see now that there's an ExtendedConnectionInfo class that derives from ConnectionInfo, and it addes the TrustError member. What I don't see is how to use it. That class is defined in PluginI.h, which looks to be an internal header? Our code only references Plugin.h and ConnectionInfo.h from IceSSL, and neither of those look to have this reference. I'm probably missing something obvious here. Anyway, do you have an example of a program that would use these changes with the certificate verifier?
    Thanks
    Jeremy

  • xdmxdm La Coruña, SpainAdministrators, ZeroC Staff Jose Gutierrez de la ConchaOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff

    Sorry for the delay, the notification ended in my spam folder, and I didn't saw your replies

    Anyway, do you have an example of a program that would use these changes with the certificate verifier?

    The internal ExtendedConnectionInfo class is to avoid breaking binary compatibility, to get the error code you can call getTrustError with the info object provided to the verifier. For the next major release we can move trustError member directly to IceSSL::ConnectionInfo but for a patch release we cannot break binary compatibility.

    I'm assuming it will only be possible for the certificate verification routine to return a single error. Is that correct?

    Yes that is correct

    I see there will be an option to get an error description string as well. That will be pretty useful.

    If that is useful we can keep it in the public API

  • xdmxdm La Coruña, SpainAdministrators, ZeroC Staff Jose Gutierrez de la ConchaOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff

    The changes have been merge into the 3.7 branch, let me know if you find any issues.

    Cheers,
    Jose

  • fish4lifefish4life Member Jeremy CookOrganization: HP IncProject: Remote Boost - remoting software

    Hey Jose,
    I finally got a build to work so I could test this. I was able to verify that it didn't report errors for a valid cert and chain, and that it reported "partial chain" when I removed a root CA.
    Questions:

    • What other certificate error cases did you test?
    • What errors should we be looking for?
    • I see you've merged it into the 3.7 branch. I think we're interested in picking up in whatever your next release would be. We're currently at 3.7.2, but would have no issues with moving forward. When could we pick this up in an official release?

    Thanks
    Jeremy

  • xdmxdm La Coruña, SpainAdministrators, ZeroC Staff Jose Gutierrez de la ConchaOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff

    Hi Jeremy

    In our test suite, we have checked

    TrustError::HostNameMismatch
    TrustError::PartialChain
    TrustError::UntrustedRoot
    TrustError::InvalidTime
    

    You might want to also check TrustError::InvalidPurpose you can get this if the certificate is used for a purpose other than what it was created for, for example, CA certificates need to be marked as so, and the same for client and server certificates.

    The updates will be part of the 3.7.6 patch release, we do a patch release once every 6 months, 3.7.5 was released the last January, so expect 3.7.6 around July this year.

    Cheers,
    Jose

  • fish4lifefish4life Member Jeremy CookOrganization: HP IncProject: Remote Boost - remoting software

    Hi Jose,
    Good to hear!
    As I previously stated, we're at 3.7.2. Waiting for 3.7.6 in July is a bit too far out for us. We are considering either (1) patching our 3.7.2 and using that, or (2) going to 3.7.5 and patching that. I'm not aware of what changes were made between these versions. Which option would you recommend based on your knowledge of what has changed? There's always risk with moving to a newer version, but it's still 3.7.x so maybe that is minimal.
    Thanks again!
    Jeremy

  • xdmxdm La Coruña, SpainAdministrators, ZeroC Staff Jose Gutierrez de la ConchaOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff

    There a no major changes between 3.7.2 and 3.7.5, it is mostly minor bug fixes and support for new compilers, so either option should work. One thing that changed in 3.7.5 is the handling of class cycles that are now disallowed by default, you can set Ice.AcceptClassCycles to 1 to use the old behavior and accept class cycles.

    I would say that patching 3.7.5 would be a bit simpler, as there have not been many changes since the release, getting the additional bug fixes shouldn't hurt.

Sign In or Register to comment.