Home Comments

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

2»

Comments

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

    To be clear, will we also face this issue too with the CheckTrust step? I'm actually not even sure what that is -- our cerificate verifier doesn't deal with anything trust related today.

    IceSSL has a TrustManager that can be configured throw properties and yes you will face the same issue if the trust manager rejects a connection the verifier will not be called

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

    Hi Jose,
    We had a meeting today to discuss our certificate verification strategy. We are planning on supplementing our own certificate verification with the error code(s) we get back from getTrustError(). Just a few more clarification questions around this;
    1) I understand that the getTrustError() more or less just relays the lower level SSL/engine errors to us. We're hoping that it helps us find the harder ones (e.g. Revocation) that we don't deal with . I assume there's no guarantee of order? Do you know if it starts verificate at the root cert and works its way down the chain, or vice versa?
    2) In our certificate verifier, we get the connection object that provides the chain and other information . There's a verified flag. If that is true, then all low level checks have passed, along with any other IceSSL parameter checks too. Correct? And the chain we get - can we safely assume that everything in that chain has passed all low level verification checks? An incomplete chain would mean that the Ice verification failed and did not include a cert that caused the failure, correct?
    3) If we get an incomplete chain, in your opinion, is that a fatal error that we should not allow a connection to proceed? What about a chain that's just missing the root CA ? Obviously a signing failure on a given cert should be fatal as it would be assumed a 3rd party modified.

    Our goal here is to present cert failures to a customer, and allow them to proceed with a connection for "warning" type ones (e.g. hostname mismatch), but deny continuing for "failure" types.

    Thanks again
    Jeremy

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

    Hi Jeremy,

    1) I understand that the getTrustError() more or less just relays the lower level SSL/engine errors to us. We're hoping that it helps us find the harder ones (e.g. Revocation) that we don't deal with . I assume there's no guarantee of order? Do you know if it starts verificate at the root cert and works its way down the chain, or vice versa?

    This depends on the engine, in general, I think first the chain is built and trust is checked, then other checks follow (extensions, validity, ...) for OpenSSL this documented in detail in https://www.openssl.org/docs/man1.1.1/man1/openssl-verify.html see "VERIFY OPERATION" in the linked doc

    2) In our certificate verifier, we get the connection object that provides the chain and other information . There's a verified flag. If that is true, then all low level checks have passed, along with any other IceSSL parameter checks too. Correct? And the chain we get - can we safely assume that everything in that chain has passed all low level verification checks? An incomplete chain would mean that the Ice verification failed and did not include a cert that caused the failure, correct?

    if IceSSL::ConnectionInfo::verified is set to true, all checks passed, that is correct. If the SSL engine cannot build the complete chain this would be reported as an error, verified would be false and TrustError would be PartialChain.

    3) If we get an incomplete chain, in your opinion, is that a fatal error that we should not allow a connection to proceed? What about a chain that's just missing the root CA ? Obviously a signing failure on a given cert should be fatal as it would be assumed a 3rd party modified.

    If the root is missing, you cannot verify the chain this results in TrustError::UntrustedRoot, the root CA is required to verify the signature of the previous CA in the chain which is either the peer cert or an intermediary CA, I would never trust a partial chain as you cannot verify the last cert in this partial chain

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

    Hi Jose,
    In the certificate verifier callback, there doesn't seem to be any way to obbain the actual hostname/IP address provided for the connection in the first place. I examined the ConnectionInfoPtr class and all the members, and did not see a reference to that. We've been using some ugly logic all along to try to determine which connection a particular cert verifier callback refers to -- since our app can support many connections at once. Do you know of a way we can obtain this information from within the verifier callback directly?
    Thanks
    Jeremy

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

    Hi Jeremy,

    ConnectionInfo uses composition to provide info about the different transports, you can get the IPConnectionInfo by checking the underlying ConnectionInfo, something like:

    shared_ptr<IPConnectionInfo>
    getIPConnectionInfo(const shared_ptr<ConnectionInfo>& info)
    {
        for(shared_ptr<ConnectionInfo> p = info; p; p = p->underlying)
        {
            auto ipInfo = dynamic_pointer_cast<IPConnectionInfo>(p);
            if(ipInfo)
            {
                return ipInfo;
            }
        }
        return nullptr;
    }
    

    IPConnectionInfo is a local class defined in Slice see https://github.com/zeroc-ice/ice/blob/aa9ebdb49eda8392a86bcc49c509cb8f15f67f6b/slice/Ice/Connection.ice#L426 remoteAddress will contain the resolved address to which the connection was made.

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

    Hi Jose,
    We do use that IPConnectionInfo to get the IP address currently. The issue is that we don't know the actual hostname (in case a user typed a hostname rather than an IP address). So we have to do some ugly logic to make the association from hostname to IP address. Does Ice have the actual hostname that was presented to it in the connection in addition to the resolved IP address?
    Thanks
    Jeremy

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

    Hi Jeremy,

    The actual hostname is currently not available with the connection info object passed to the verifier, the hostname is part of the Endpoint used to create the connection and IceSSL uses the name for IceSSL.CheckCertName.

    Do you need this only on the client side? one option would be to add a host field to the ExtendedConnectionInfo object and a getHost method to retrieve it, would this help?

Sign In or Register to comment.