Bug 1660204

Didn't mean to touch assignee, sorry.

We had a discussion about this on webkit-gtk. The first comment is in November so the archive is split unfortunately:

https://lists.webkit.org/pipermail/webkit-gtk/2018-November/003378.html
https://lists.webkit.org/pipermail/webkit-gtk/2018-December/003379.html

Two steps required:

 (1) Implement client auth support in WebKit, https://bugs.webkit.org/show_bug.cgi?id=164509. (In the mailing list thread I mentioned we were already working on this, but unfortunately that got deprioritized for the time being.)

 (2) Implement smartcard support in glib-networking, if needed. Not sure if needed. We need to figure out whether glib-networking's gnutls-pkcs11 backend (which I have removed upstream, but it's still present in RHEL 7.7) is important for this to work, see https://gitlab.gnome.org/GNOME/glib-networking/issues/7. I asked Dan Winship and he didn't know either; this code was all written by Stef. But hopefully it's no longer needed: "Also note that, as part of bug #753260, the non-PKCS#11 backend will now be using the p11-kit trust store by default on systems where that is configured as GnuTLS's default trust store, such as Fedora [and RHEL]." But I'm not sure if that means it will automagically use the smartcard or not.

Also not sure if any UI will be needed in Evolution itself.

Could we get an update on this? Its been 6 months with no activity.

Yes, sorry, my fault, I neglected this.
Certainly there won't be an OAuth2 implementation for rhel-7.7
My suggestion would be to close this and either wait until OAuth2 support will be implemented in webkit and maybe the smartcard support in glib (see comment 5), or retarget or file a new RFE against a later rhel-version.

Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.

At customer's request, reopening for RHEL 8.

(If anyone is going to work on this, check with me first to avoid potential overlap.)

Nice timing. Stuff's happening now in https://gitlab.gnome.org/GNOME/glib-networking/merge_requests/65.

Resetting the devel_flag as it was provided for the RHEL 7.

All the glib and glib-networking work has landed so now the only thing left to do is land the patch in https://bugs.webkit.org/show_bug.cgi?id=200805 and then update Evolution to use the new API. Testing welcome....

Preliminary upstream patch is available in https://bugs.webkit.org/show_bug.cgi?id=200805. Better late than never....

(In reply to Michael Catanzaro from comment #18)
> Preliminary upstream patch is available in
> https://bugs.webkit.org/show_bug.cgi?id=200805. Better late than never....

So the GLib and WebKit side of this is now handled afaik, via:

https://github.com/WebKit/WebKit/commit/1e5a9791388c8e05e165a8c9168f280440301fe3

The remaining work would be in Evolution to (a) handle the new WebKitWebView::authenticate signal, (b) get a PKCS #11 URI for a certificate from the smartcard somehow (??? how ???), (c) use g_tls_certificate_new_from_pkcs11_uris(), (d) pass that to webkit_credential_new_for_certificate(). I will ask for more info about step (b).

Note this depends on libsoup 3, so it's not likely to be supported in RHEL 8 or 9. I would reassign the product to RHEL 10, but there's no Bugzilla product for it.

(In reply to Michael Catanzaro from comment #20)
> I will ask for more info about step (b).

I'm told that gcr might have APIs to help with this, but I'm not actually sure if that's true.

If I understand this correctly, then the OAuth2 window needs to listen to WebKitWebView::authenticate signal and handle the WEBKIT_AUTHENTICATION_SCHEME_CLIENT_CERTIFICATE_REQUESTED and WEBKIT_AUTHENTICATION_SCHEME_CLIENT_CERTIFICATE_PIN_REQUESTED, where it may return webkit_credential_new_for_certificate() and webkit_credential_new_for_certificate_pin() when the user provides those. I do not see how to know what certificate look for; it also looks like the last resort is to provide the user with a list of found certificates and he/she will just pick one.

With respect of the URIs passed to the g_tls_certificate_new_from_pkcs11_uris(), there's PK11_GetTokenURI() in NSS (the evolution-data-server uses NSS for the certificates). I currently do not see how the NSS provides the private key URI, but maybe it's not needed, as that argument can be NULL for the GTls function.

My main problem is testing. I do not have a hardware key/certificate, neither I have a server to test a certificate login with. Any hints in this regard are welcome.

(In reply to Milan Crha from comment #22)
> If I understand this correctly, then the OAuth2 window needs to listen to
> WebKitWebView::authenticate signal and handle the
> WEBKIT_AUTHENTICATION_SCHEME_CLIENT_CERTIFICATE_REQUESTED and
> WEBKIT_AUTHENTICATION_SCHEME_CLIENT_CERTIFICATE_PIN_REQUESTED, where it may
> return webkit_credential_new_for_certificate() and
> webkit_credential_new_for_certificate_pin() when the user provides those. I
> do not see how to know what certificate look for; it also looks like the
> last resort is to provide the user with a list of found certificates and
> he/she will just pick one.

I think the normal workflow would be: if user has configured a particular certificate to use, use that; otherwise, let user choose from a list. But I'm not sure how to display that list. I guess there are PKCS #11 APIs that can be used to list available certificates?
 
> With respect of the URIs passed to the
> g_tls_certificate_new_from_pkcs11_uris(), there's PK11_GetTokenURI() in NSS
> (the evolution-data-server uses NSS for the certificates). I currently do
> not see how the NSS provides the private key URI, but maybe it's not needed,
> as that argument can be NULL for the GTls function.

I'm not sure whether it's needed or not. The private key is part of the certificate, so a certificate URI is probably enough for NSS to reference the private key as well. But remember that it's impossible to ever get the private key off the smartcard device (that's the whole point), so you can never actually get the bytes of the private key.

> My main problem is testing. I do not have a hardware key/certificate,

That's the easiest part! Most Yubikeys or Nitrokeys or similar devices will do. There are a bunch of companies selling these, and they're generally pretty inexpensive. You just need one that acts as a PKCS #11 smartcard: all the "full" versions of the devices do, but they also sell cheaper products which are less expensive and do not have this functionality (notably YubiKey Security Key or Nitrokey FIDO2) which won't work here.

> neither I have a server to test a certificate login with. Any hints in this
> regard are welcome.

This will be harder. Don't know about this.

Okay, I figured getting the private key is a nightmare with NSS even with locally stored certificates. I can get close to the private key only after I log in to the certificate database (which makes perfect sense), but I fail to extract the private key, to be able to pass it to the GTlsCertificate structure. The g_tls_certificate_new_from_pkcs11_uris() has two URI arguments, one for the certificate and one for the private key. Maybe a list can be used for hardware tokens/slots and a file open for public and private keys (in PEM format) for other cases. I'll try more, but I'd need help from someone whom knows the NSS internals. Or I'd need to use other library, which would be a pita due to the new dependency with duplicated functionality for the evolution-data-server.

I managed to setup an httpd server, which can access a folder only with the certificate login. It wasn't that hard, after all (searching on the internet helped a lot). I am able to access the directory with a certificate using the `curl` command, but I cannot make it open in the WebKitGTK, it errors with "Error performing TLS handshake: An unexpected TLS packet was received." when I pass the same certificate to it (I know it, because without the certificate or with only the public part there is shown a different error message).

I test this with Fedora Rawhide (to get the latest bits), having installed:
   glib2-2.73.3-2.fc38.x86_64
   glib-networking-2.74~alpha-4.fc37.x86_64
   webkit2gtk4.1-2.37.91-1.fc38.x86_64
   gnutls-3.7.7-1.fc37.x86_64
   httpd-2.4.54-5.fc37.x86_64
   mod_ssl-2.4.54-5.fc37.x86_64

I can share my config files for testing.

It's likely not to be the same as with the OAuth2, the server can behave differently than the Apache server, but it can help to debug basic things at least.

I filled https://gitlab.gnome.org/GNOME/glib-networking/-/issues/198 upstream, the GnuTLS backend is not able to authenticate with a certificate, but the OpenSSL backend can do it just fine. The GnuTLS backend is the default backend.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.