[webkit-gtk] Support for PKCS11 / Smartcard?

mailto428496 mailto628496 at cox.net
Sun Dec 2 22:37:29 PST 2018


Michael,

I ignored testing GIO_USE_TLS=gnutls-pkcs11 because I thought you were
saying that it would not be implemented in webkit but I just tested now
and it does appear to change the behavior!  I ran MiniBrowser with
strace remotely on a machine with a card reader (no card in reader
though so I couldn't fully test, will tomorrow though) and it does
appear to cause it to access the opensc/coolkey libraries and the card
reader!

Running MiniBrowser with/without "export GIO_USE_TLS=gnutls-pkcs11"

Without:

> egrep "cool|opensc" /tmp/out1

With:

[pid 171854] stat("/usr/share/p11-kit/modules/coolkey.module", 
<unfinished ...>
[pid 171854] open("/usr/share/p11-kit/modules/coolkey.module",
O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 171854] stat("/usr/share/p11-kit/modules/opensc.module", 
<unfinished ...>
[pid 171854] open("/usr/share/p11-kit/modules/opensc.module",
O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 171854] open("/usr/lib64/pkcs11/libcoolkeypk11.so",
O_RDONLY|O_CLOEXEC) = 15
[pid 171854] open("/usr/lib64/pkcs11/opensc-pkcs11.so",
O_RDONLY|O_CLOEXEC) = 15
[pid 171854] open("/usr/lib64/webkit2gtk-4.0/libopensc.so.4",
O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 171854] open("/lib64/libopensc.so.4", O_RDONLY|O_CLOEXEC) = 15
[pid 171854] mkdir("/var/cache/coolkey", 01777) = -1 EEXIST (File exists)
[pid 171854] open("/var/cache/coolkey/coolkeypk11tDell Dell Smart Card
Reader Keyboard 00 00-4609", O_RDWR|O_CREAT|O_EXCL|O_APPEND, 0600) = -1
EEXIST (File exists)
[pid 171854] open("/var/cache/coolkey/coolkeypk11tDell Dell Smart Card
Reader Keyboard 00 00-4609", O_RDWR|O_NOFOLLOW) = 16
[pid 171854] open("/etc/opensc-x86_64.conf", O_RDONLY) = 19

So, maybe it actually will work!

I will test tomorrow and let you know!

Thanks,


Jim



On 12/02/2018 02:58 PM, Michael Catanzaro wrote:
>
> On Sat, Dec 1, 2018 at 6:01 PM, mailto428496 <mailto628496 at cox.net>
> wrote:
>> I am testing this on CentOS 7 and it appears that the server cert ca
>> verification is working (we have the CA stores installed locally), at
>> least it doesn't complain that the site cert is invalid, but I suppose
>> it could just not be checking at all (which wouldn't be so great
>> either...).
>
> It definitely checks TLS certificates. That's only impressive if you
> have the server cert stored on your smartcard, though, which I assume
> is probably not what you're doing, right?
>
> (Beware that the version of WebKit shipped by CentOS is always old and
> doesn't receive security updates.)
>
>> I think there would need to be an interface to the opensc or coolkey
>> libraries in order for it to access the smartcard.  It sounds like it is
>> a bit more complicated where there are multiple layers and packages
>> involved that would all need to support each other in order for this to
>> work.
>
> I've never heard of these libraries before today, but I don't think
> so. From
> https://fedoraproject.org/wiki/Changes/Replace_Coolkey_with_OpenSC I
> gather that p11-kit wraps these libraries. And GnuTLS uses p11-kit as
> its default trust store (looks like since CentOS 7.3). Did you try
> GIO_USE_TLS=gnutls-pkcs11?
>
>> There has been discussion of contracting a developer to help with this
>> (if we can get funding, etc.) and if that happened I would hope that any
>> result could be contributed back to the open source community (but given
>> that it's the government that is another whole process).
>>
>> I wanted to be sure that I wasn't missing something and that support was
>> not already included - which it sounds pretty clear that it isn't yet,
>> but maybe some of the groundwork is getting there?  And I wanted to get
>> an idea of what it might take to implement - which sounds non-trivial
>> but doable for someone willing to dig into the weeds and figure out how
>> all the pieces need to work together.
>
> It's not clear to me at all. Until a couple months ago, we had tons of
> code for PKCS#11 in glib-networking. It didn't write itself for no
> reason. The problem is that I wound up inheriting all the code,
> without knowing if it's still important, or if anyone at all is using
> it with smartcards, and with nobody to test it or tell me if it's
> working, and every indication that it's obsoleted by GnuTLS-level
> support for PKCS#11, and with the code having never been enabled
> except behind a secret environment variable, I decided to delete it
> (in glib-networking 2.58; you have 2.56 if you have CentOS 7.6). For
> the code to have remained, I needed someone interested to come forward
> and tell me that it was both working and also not redundant with the
> GnuTLS-level PKCS#11 support, and that didn't happen.
>
> So set aside the WebKit-level client authentication issue, which will
> be solved soon regardless. Take WebKit out of the picture. We have
> support for PKCS#11 in GnuTLS. Your main concern right now is to make
> sure that the gnutls-pkcs11 backend I just removed from
> glib-networking is not important for you, because if so we just took a
> lot of steps backwards. That can be undone now far more easily than a
> e.g. year from now. So you want to be sure that glib-networking's
> gnutls backend can do everything the gnutls-pkcs11 backend could. In
> CentOS 7.6, you are in a good spot to do this, because you have
> glib-networking 2.56, which is the first version of glib-networking
> that uses GnuTLS's default trust store and also the last version that
> has the gnutls-pkcs11 backend built by default. (In 2.58 it's disabled
> by default at build time. And in 2.60 it will be gone.)
>
> Once TLS client authentication is working, there should be zero code
> in WebKit required to support smartcards. All of that code lives at
> the glib-networking and GnuTLS levels (and maaaybe libsoup, but I
> don't think so). So you can test whether this works today... just not
> using WebKit. (Not sure how exactly you would test it without WebKit,
> though. Without any support for client auth at the WebKit level, I'm
> really not sure what the code was written for.)
>
> Michael
>
>



More information about the webkit-gtk mailing list