GNOME Bugzilla – Bug 507802
Certificate validation is too strict for some use cases
Last modified: 2010-11-09 16:17:43 UTC
In Empathy we are using X.509 certificates to validate user identity when communication or transferring files via HTTP. This work when we use autogenerated certificates but we want to allow our users to use their own public certificate if they have one. Unfortunately libsoup checks that the common name or DNS alt name match the host name of the machine which is not the case when using personal certificates. We would need a more sophisticated way to decide what to check or to use a custom validation function called by libsoup using a signal or a callback but this is not currently possible.
I want to make sure I understand this. You are talking to an HTTP server that is using a user certificate, rather than a host certificate, as its identity. (Is this a SoupServer, or some other HTTP server?) Then you're connecting to that server via client-side libsoup, and you would like to verify that the certificate matches what you're expecting, but you're running into problems, because libsoup only lets you do validation if you're validating against a hostname. Right? I've been pondering libsoup's SSL interfaces, with respect to this bug, bug 507801, bug 334021, and the Fedora Crypto Consolidation Project ("port everything to NSS"), which causes problems because it's hard to make NSS work in an API-compatible way with the current GnuTLS API. I'm thinking I'm going to end up defining "SoupSSLClient" and "SoupSSLServer" classes, with GnuTLS and NSS implementations of each, and the way it would work (on the client side) would be something like: ssl = soup_ssl_client_gnutls_new (optional_ca_file); soup_ssl_client_set_server_verification_callback (ssl, verify_callback, data); soup_ssl_client_set_client_certificate_callback (ssl, creds_callback, data); session = soup_session_async_new_with_options (SOUP_SESSION_SSL_CLIENT, ssl, NULL); etc, with the old SOUP_SESSION_SSL_CA_FILE property being reimplemented in terms of this.
Yes, we're tying to connect to an HTTP server using a user certificate instead of a host one, failing the hostname check. In Empathy this is a SoupServer, as we both provide the client and the server for direct P2P file transfers. We only need to make sure that the HTTPS server certificate is the same used for the XMPP connection used to offer the file transfer. Your proposal seems very good, with the client providing its credentials with creds_callback() and verifying the server ones with verify_callback(), of course assuming there will be something similar for the server side. :) How do you plan to create and store the in-memory credentials? Do you plan to expose the objects from the underlying crypto library or to store the raw data in a normalized form (e.g. DER for certificates)?
(In reply to comment #2) > How do you plan to create and store the in-memory credentials? > > Do you plan to expose the objects from the underlying crypto library or to > store the raw data in a normalized form (e.g. DER for certificates)? I need to investigate this some more. One issue that came up with the Exchange Connector smart card patches (bug 334021) is that if the user's certificate is on a smart card, you usually can't access the raw certificate data. Instead, the crypto library just gives you an identifier for the certificate, and if you pass that identifier to an encryption/ssl routine, it causes the crypto library to ask the smart card to do the encryption operation, rather than using the crypto library's own encryption routines. So I think the way it will work is that the application won't work directly with raw certificate data. Instead, there'll be a "SoupSSLCertificate" type, that includes certain identifying information about the certificate, but doesn't directly expose the raw data. And you can get a SoupSSLCertificate either by handing raw DER data to the SoupSSLClient (either via a file or a buffer), or by asking it what certificates it already knows about (which, depending on the ssl provider you're using might come from NSS's secmod.db, or a smart card, or the gnome-keyring cryptoki provider, etc). And then the creds_callback and verify_callback would work in terms of SoupSSLCertificate objects, and you wouldn't need to worry at that point about exactly where it had come from and how the crypto library was manipulating it.
This will be possible to some extent in 2.32/3.0 when we port to the new GIO TLS APIs (bug 588189). You can connect to the "accept-certificate" signal of GTlsConnection to do your own certificate identity verification. At the moment, GTlsCertificate does not have any methods for getting data about the certificate, so you'd have to extract the raw data as above and parse it with your favorite TLS library. (My concerns in comment 3 aren't entirely relevant; you can always access the certificate data, it's just the private key data that may be unavailable, and you don't need that here.) At any rate, I've made a note about figuring out what sorts of additional get methods we should add to GTlsCertificate. *** This bug has been marked as a duplicate of bug 634425 ***