GitHub does not work with U2F Proxy

[Demi-Marie]

Qubes OS version Qubes release 4.0 (R4.0)

Affected component(s) or functionality U2F Proxy

Brief summary GitHub cannot register itself with the U2F proxy

To Reproduce Try to use a proxied YubiKey for GitHub

Expected behavior The registration works

Actual behavior The registration fails

Screenshots N/A

Additional context Google works eventually, but it takes several tries

Solutions you've tried Unplugging and replugging the YubiKey and restarting sys-usb does not help

Relevant documentation you've consulted https://www.qubes-os.org/doc/u2f-proxy

Related, non-duplicate issues none

[marmarek]

Hmm, I do use U2F proxy specifically with Github and it works for me. I have just tried registering another key and it also works for me. Anything specific about your setup? Some error messages in the logs?

[Demi-Marie]

I am using the “advanced” configuration as I use the same YubiKey across trust boundaries. Which logs should I be looking at?

[marmarek]

First of all, check journalctl in dom0 to see if u2f.* qrexec calls are made. There should be:

• u2f.Register (from client vm to sys-usb) - possibly multiple of them
• policy.RegisterArgument+u2f.Authenticate (from sys-usb to client vm, redirected to dom0) - just one

Another thing you can try is take a look at qu2f-proxy in your client vm, stop it and start it with a few -v added.

[Demi-Marie]

u2f.* qrexec calls are indeed being made, and I get the following failure every time I try to register a key with GitHub:

Apr 01 21:06:09 dom0 qrexec[1568]: u2f.Authenticate+cf9d987506116ee0e48f10f722ef07bb: parity -> sys-usb: denied: no matching rule found

The date and hash, of course, are different every time.

My sys-usb is a DispVM, in case this matters.

[Demi-Marie]

I am using a YubiKey 5 NFC (latest from https://www.yubico.com) which might be relevant. No matching policy file exists in dom0 when the error is thrown.

[marmarek]

u2f.Authenticate calls are about github searching for already registered key(s). The hash actually identifies your registered key (generated separately on yubikey for each service), so you should get only as many different hashes, as you have keys registered in github. There should be u2f.Register call. If there isn't it doesn't even reach the state where actual type of U2F token would matter. In that case - try verbose output of qu2f-proxy.

[marmarek]

I have done clean test on a test account: On Firefox:

1. Registered one U2F key (got in the log u2f.Register call as expected)
2. Tried to login - got as expected one u2f.Authenticate call (noted the hash)
3. Tried to register the second key - got one u2f.Authenticate call with the same hash, then u2f.Register call(s) and operation succeeded.
4. Removed the second key.

Then switched to Chromium:

1. Logged in with Yubikey (first one registered above) without any issue.
2. Tried to register the second key:
3. got multiple u2f.Authenticate calls for the first key and one u2f.Authenticate call with a hash I haven't seen before,
4. then, after ~10s got u2f.Register call(s) and operation succeeded.
5. Looked at policy created by policy.RegisterArgument call and the hash is different than the weird one above.
6. Tried again and got yet another hash on u2f.Authenticate

Chromium is doing something weird. Maybe it's related to FIDO2?

Anyway, in the end it worked in both Firefox and Chromium. I don't have Yubikey 5 NFC specifically, but another Yubikey.

[Demi-Marie]

u2f.Authenticate calls are about github searching for already registered key(s). The hash actually identifies your registered key (generated separately on yubikey for each service), so you should get only as many different hashes, as you have keys registered in github. There should be u2f.Register call. If there isn't it doesn't even reach the state where actual type of U2F token would matter. In that case - try verbose output of qu2f-proxy.

I get multiple u2f.Register calls, which succeed.

[Demi-Marie]

I do get an APDUConditionNotSatisfiedError from qu2f-proxy. Not sure if that is relevant. I also get that the device was successfully registered. Attestation problem?

[marmarek]

I do get an APDUConditionNotSatisfiedError from qu2f-proxy.

It means button is not pressed yet (U2F protocol requires polling, not simply waiting for the button to accept).

I also get that the device was successfully registered. Attestation problem?

I would say it's unlikely. Maybe you can try on demo.yubico,com? It gives much more feedback.

[Demi-Marie]

I do get an APDUConditionNotSatisfiedError from qu2f-proxy.

It means button is not pressed yet (U2F protocol requires polling, not simply waiting for the button to accept).

I also get that the device was successfully registered. Attestation problem?

I would say it's unlikely. Maybe you can try on demo.yubico,com? It gives much more feedback.

demo.yubico.com works fine, as does Google.

[marmarek]

In that case, I'm inclined to say it is a github issue, not U2F proxy. You can also try attaching Yubikey as a USB device directly to that VM (but keep in mind security consequences - possibly malicious USB device, but also the browser could try to access different key).

[Demi-Marie]

In that case, I'm inclined to say it is a github issue, not U2F proxy. You can also try attaching Yubikey as a USB device directly to that VM (but keep in mind security consequences - possibly malicious USB device, but also the browser could try to access different key).

You are probably correct. I suspect that GitHub simply isn’t compatible with the hardware.

[Demi-Marie]

In that case, I'm inclined to say it is a github issue, not U2F proxy. You can also try attaching Yubikey as a USB device directly to that VM (but keep in mind security consequences - possibly malicious USB device, but also the browser could try to access different key).

I did this, judging it reasonably safe due to the security of the YubiKey, and after deregistering it from other accounts that I use in different VMs. It worked, so the problem is in Qubes. Reopening.

[Demi-Marie]

Setting /etc/qubes-rpc/policy/u2f.Authenticate to <sourcevm> sys-usb allow also fixed the problem.

[Demi-Marie]

After the key is registered, I can delete that line and it still works.

[marmarek]

Just to confirm - I assume it happens specifically in Chrome/Chromium, right? Have you tried Firefox?

[Demi-Marie]

Just to confirm - I assume it happens specifically in Chrome/Chromium, right? Have you tried Firefox?

No, this happens in Firefox. I have not tested other browsers.

[github-actions[bot]]

This issue is being closed because:

• This issue is on the "Release 4.0 updates" milestone.
• Qubes OS 4.0 reached EOL (end-of-life) over one year ago.
• There has not been any activity on this issue in over one year.

If anyone believes that this issue should be reopened and reassigned to an active milestone, please leave a brief comment. (For example, if a bug still affects Qubes OS 4.1, then the comment "Affects 4.1" will suffice.)