Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve qubes-u2f-proxy documentation #4661

Open
jrsmiley opened this issue Dec 27, 2018 · 17 comments

Comments

Projects
None yet
4 participants
@jrsmiley
Copy link

commented Dec 27, 2018

Qubes OS version:

4.0.1-rc2

Affected component(s):

qubes-u2f-proxy


Steps to reproduce the behavior:

Following the installation steps described here:
https://www.qubes-os.org/news/2018/09/11/qubes-u2f-proxy/

In dom0:
Insall qubes-u2f-dom0
qubes-u2f-dom0-install.log

The next step in the doc says to enable the qubes-u2f-proxy service in the work qube, but this doesn't make sense since it hasn't been installed in the template yet. So my next step was to install qubes-u2f in the fedora-29 template, which is step three in the doc.

In the Fedora-29 template:
Install the qubes-u2f package
qubes-fedora-29-template-qubes-u2f-install.log
Shutdown the template

The work qube isn't running on my box, but if it was, it would need a restart to pick up the changes to the template. The doc is silent on this point.

In dom0, enable the qubes-u2f-proxy service in the work qube:
[admin@dom0 Desktop]$ qvm-service --enable work qubes-u2f-proxy
[admin@dom0 Desktop]$ qvm-service --list work
qubes-u2f-proxy on

From here the doc's instructions are to "Repeat the qvm-service --enable) for all qubes that should have the proxy enabled... restart sys-usb and all qubes that use the proxy." Well, which qubes are they? It is implied that sys-usb might be one of them, but it's not clear. Certainly all qubes based on fedora-29 template will have the ability to run the proxy since they now have the proxy package. And we know that something has to be running in sys-usb to act as the browser as shown in the diagram. Maybe the proxy service fills dual roles (backend on sys-usb acting as a browser and frontend on the qube actually running the browser acting as the HID device) depending on where it's running. so let's enable the service there and restart sys-usb.

[admin@dom0 Desktop]$ qvm-service --enable sys-usb qubes-u2f-proxy
[admin@dom0 Desktop]$ qvm-service --list sys-usb
qubes-u2f-proxy on
network-manager off
[admin@dom0 Desktop]$ qvm-shutdown sys-usb
[admin@dom0 Desktop]$ qvm-start sys-usb
[admin@dom0 Desktop]$ qvm-service --list sys-usb
qubes-u2f-proxy on
network-manager off
[admin@dom0 Desktop]$ qvm-start work
[admin@dom0 Desktop]$ qvm-service --list work
qubes-u2f-proxy on

That should be it. Let's open Firefox in the work qube. I used the pre-defined Firefox shortcut from the Application Menu on Domain: work

Firefox starts. This version of Firefox is Quantum 64.0 as shown by selecting Help->About Firefox. This version of Firefox does not have U2F enabled by default, so we enable it by opening about:config and setting the security.webauth.u2f property to True.

Now let's sign in to a service that we've configured to use U2F (Dropbox). Navigate to https://www.dropbox.com and enter username and password. A window pops up prompting me to insert my previously registered Yubikey and press the gold button.

I insert one of the YubiKeys and up a window showing that the system sees it as a USB device.

Making sure the focus is in the work qube where dropbox is waiting for me to insert my Yubikey, I press the button on the Yubikey

Expected behavior:

Authentication string is populated, I click Authenticate, and gain access to my Dropbox.

Actual behavior:

Nothing happens. No output shows up in the authentication box.

General notes:

If I connect the YubiKey USB device directly to the work qube and repeat the authentication sequence, it works just fine, but then we've bypassed the U2F proxy.

I could find no information on troubleshooting this issue. There was a Reddit post by someone having a problem that looked like the same one I'm having and his final post indicates he solved this by enabling keyboard USB functionality. I know that the YubiKey looks like a keyboard device to the USB stack, but a) there's no mention of needing to do this in the proxy doc and b) the proxy should be able to recognize and use the YubiKey without needing USB keyboard support. Maybe I'm wrong about that last part, but it seems like that dependency would be mentioned somewhere if it were needed.

It seems odd to expect the U2F proxy package to fill the dual roles of frontend and backend without telling it which role to play. It also doesn't make sense that there would be a dependency on the name of the cube providing USB proxy services to tell it which role to play. The USB proxy qube could be named anything. I could have more than one for different USB hubs, and so forth. So it seems like there is a fundamental piece missing from the docs.

I also tested adding a Yubikey to my Twitter account as a new security key. That worked as expected.

So it seems the proxy works when it is involved in the key registration process, but doesn't for keys registered outside of the proxy


Related issues:

@jrsmiley

This comment has been minimized.

Copy link
Author

commented Dec 27, 2018

I wanted to try adding a couple of Yubikeys to my Google account, but even though U2F was enabled on my Firefox browser, Google said I needed to use Chrome. It is also known that the Firefox Quantum implementation of U2F doesn't work with all services (ex: Facebook), so I decided to switch to Chrome, which seems to have the best support for U2F of any browser and is enabled by default. I cloned the fedora-29 template to fedora-29-test, installed google-chrome-stable on it and shut it down (it already had the qubes-u2f package installed since it was installed on the base fedora-29 template prior to cloning).

I created a new Qube VM based on the new fedora-29-test template named personal-test
qvm-create --template fedora-29-test --label orange personal-test

Enabled the U2F proxy service on the new qube:
qvm-service --enable personal-test qubes-u2f-proxy

Added a shortcut to launch Google Chrome to the new qube and then launched Chrome. Help -> About reports my version of Chrome as "Version 71.0.3578.98 (Official Build) (64-bit)"
As first step, I open a tab to https://demo.yubico.com/u2f/ test the U2F functionality
After entering a username and password a window pops up asking to press the button on my Yubikey. I insert a YubiKey 5 NFC into a USB port and note that Qubes sees the device on the USB bus. The demo says that the button should flash. It doesn't. I press the button. Nothing happens. I repeat a few times, sometimes with the key inserted before running the test and sometimes after. It makes no difference.
I login to my Google account as usual. I have 2FA enabled already via Google Prompt, Google Authenticator, and backup codes. I complete the login via Google Prompt via my iPhone. My Google account Home is displayed and I select Security from the left side menu. In the "Signing in to Google" box I select 2-Step Verification, which is already "on". Re-enter my password at the prompt, and then select "ADD SECURITY KEY" from the "Set up alternative second step" box.
A new window asks "Have your Security Key?" and says that it should not be connected to the computer yet. It isn't. I select NEXT. Now at the "Register your Security Key" box, I insert a Yubikey 5 NFC, note that Qubes has seen it on USB, wait a second, then press the button on the key. Nothing happens. I repeat this several times without success.

Next I assign the YubiKey to the personal-test Qube, bypassing the proxy. I repeat the "ADD SECURITY KEY" process, press the button on the YubiKey, and get a pop up asking for permission to use the device. I grant access and the key is registered successfully.

@jrsmiley

This comment has been minimized.

Copy link
Author

commented Dec 27, 2018

Having had some success registering a Yubikey via the proxy under Firefox with my Twitter account, I launch a Firefox window in the Personal Qube just as before. I navigate to Twitter and sign in. After entering my username and password, I'm prompted to enter the code from Google Authenticator (again, I have multiple 2FA methods on most accounts). I want to test the Yubikey I've registered previosuly so I select "Choose a different verification method".

I remember to check to see if the proxy service is running in this qube. It isn't, so I exit from Firefox, shutdown the qube, enable the proxy service, verify that it's enabled, and restart the qube (the docs aren't clear on whether or not enabling the proxy service requires a reboot and I was surprised to see that it wasn't enabled since I had enabled it on this qube previously. Don't know if this is expected behavior or not).
The point of the above is that the docs should make it clear what the expected behavior is.

With the qube freshly restarted, I recheck to verify that the u2f proxy service is on. It is, so I launch Firefox and try again. This time I also check to see if U2F is enabled in Firefox. It isn't. Another surprise. I re-enable it. I am able to log in using the YubiKey via the U2F proxy, so this worked as expected except for having to re-enable the proxy and re-enable U2F in Firefox. Are these not expected to persist across restarts for a template-based qube?

@jrsmiley

This comment has been minimized.

Copy link
Author

commented Dec 27, 2018

At the very least, I have demonstrated that the Redditor's post about needing to install keyboard USB support is incorrect. Good!

@jrsmiley

This comment has been minimized.

Copy link
Author

commented Dec 27, 2018

I'm tempted to move on to the advanced configurations with specific qubes granted access to specific keys, but would like to hear back from someone there about the issues I had with Chrome before attempting more complex configurations. There are things I don't understand (as noted above) that you may be able to clear up for me and help me avoid misconfiguration.

@jrsmiley

This comment has been minimized.

Copy link
Author

commented Dec 27, 2018

From the same browser session I just used to login to Twitter using the proxy, I was able to run the demo at https://demo.yubico.com/u2f/ successfully.

@jrsmiley

This comment has been minimized.

Copy link
Author

commented Dec 27, 2018

I was able to register a Yubikey via the proxy to my GitHub account, log out, and back in using the key. It took several button presses to activate the key. I was unable to register a second key.

@jrsmiley

This comment has been minimized.

Copy link
Author

commented Dec 27, 2018

Rebooted the "personal" qube that I just registered a key with GitHub with. Noted that both the proxy service and the u2f Firefox setting persisted across the bounce. Logged in with the registered key. Behavior is slow to respond. Had to press the button on the key multiple times. Re-attempted to register a second key. Still won't take it. Is there something the proxy is doing that prevents a second key from being registered with the same account. It works fine outside of Qubes: logged into Win10, launched Chrome, logged into GitHub using the first key. Registered the second key without trouble.

@jrsmiley

This comment has been minimized.

Copy link
Author

commented Dec 27, 2018

After shutting Win10 down and booting back into Qubes (this is a dual boot machine) and noting that the proxy service was still enabled on my Personal qubue (so it does persist - don't know why it wasn't persisted the first time), I launched Firefox and logged into GitHub with the first key. Attempts to use the second key were not successful. Even with the first key, there were times that I thought it had failed and was about to retry when it would finally log me in.

I also found that the proxy stopped working if I directly connected the key to the qube using the Qubes Devices manager (I needed to get a password from Lastpass and it needed OTP). After disconnecting the qube from the key using the Devices manager, attempts to use the key via the proxy always failed. I resolved this by restarting the qube. After that, the proxy worked again.

Also note that my problems with Dropbox had nothing to do with the proxy. I used a different set of keys for it and was using the wrong key.

@woju

This comment has been minimized.

Copy link
Member

commented Dec 27, 2018

@jrsmiley

[admin@dom0 Desktop]$ qvm-service --enable sys-usb qubes-u2f-proxy
[admin@dom0 Desktop]$ qvm-service --list sys-usb
qubes-u2f-proxy on

This is wrong. The service qubes-u2f-proxy should only be enabled in vms which hold the browser (work in your case). Enabling this in sys-usb breaks the proxy backend. Disable it, restart sys-usb and try again.

@jrsmiley

This comment has been minimized.

Copy link
Author

commented Dec 27, 2018

The first few times I tried configuring the proxy, I didn’t start it in sys-usb since it doesn’t say to do that on the doc. However, none of those attempts worked. In desperation I tried enabling it there and started having limited success.
I’ll turn it off and see what happens. You’ll note above that it didn’t make a lot of sense to me to do this, but I didn’t see what was handling the backend,, so I thought, strange as it might be, that the proxy played both roles depending upon where it was installed.
If the proxy isn’t it, what is acting as the backend?

@marmarek

This comment has been minimized.

Copy link
Member

commented Dec 27, 2018

If the proxy isn’t it, what is acting as the backend?

Qrexec service allowed in policy by installing qubes-u2f-dom0 package in dom0. The service itself (backend) is part of qubes-u2f package, but it doesn't need to be separately enabled.

@jrsmiley

This comment has been minimized.

Copy link
Author

commented Dec 27, 2018

Thanks for the information. I'm writing this from a different Qubes host after logging into GitHub using the U2F key that I registered on the other Qubes box yesterday. This is after turning off the proxy service in sys-usb and restarting it and also ensuring that the proxy service was enabled and on in the Qube I'm currently in. Other than it taking repeated attempts to get the browser to see the button press on the key, it's working.

The main question I have now is about the apparent inability to use more than one key with the same account. As mentioned above, I was able to register and use a second YubiKey with GitHub on Win10, but the second key isn't recognized by the qubes-u2f-proxy - only the first key is recognized. Is this expected behavior?

@jrsmiley

This comment has been minimized.

Copy link
Author

commented Dec 27, 2018

I think the thing to do now is to update the docs to make them clearer. I don't have access to the Announce page. I might be able to update the Readme in GitHub, but I would need to go through the process of registering with you as a dev, generate some signing keys, etc. Bottom line is that I'm willing to help improve the docs, but it will take some time to get setup and I will only be able to update the GitHub readme. Someone else will have to sync that to the Announcement unless I can also gain edit perms for that page.

Also, those two docs should say exactly the same thing and right now there are some minor differences.

In the meantime, I'm going to move on to the more advanced configurations available in Qubes 4 to limit the keys a given browser/Qube has access to, as described in the U2F proxy doc.

And don't forget that we still have at least one outstanding issue on the question of multiple keys for a single account. Either it's a bug and needs to be fixed or it's expected behavior and needs to b changed (or I'm doing something else wrong).

@jrsmiley

This comment has been minimized.

Copy link
Author

commented Dec 27, 2018

Well, I just logged out and back in using the second key. Again, it took some time for it to recognize the button press, but it did work, so maybe there is no issue with multiple keys and I was just doing something wrong until now. I'll try this with other accounts to verify.

Docs still need updating though :).

@jrsmiley

This comment has been minimized.

Copy link
Author

commented Dec 28, 2018

As another quick test of basic functionality (no Qubes 4 features used), I cloned the fedora-29 template to fedora-29-test-1. Installed google-chrome-stable in the clone, Created a qube named personal-test-1 using the new template. Ensured that the qubes-u2f-proxy service was enabled and on in personal-test-1, and then logged into GitHub using U2F proxy in both Firefox and Chrome.

It took a little while for the key to be recognized by the new persona-test-1 qube (it had only been used in the personal qube before and now I was trying to use it in the personal-test-1 qube, but it did eventually recognize the key in personal-test-1. I had several timeouts from GitHub waiting for the key, but I kept retrying and it eventually worked. I ended up shutting down the personal qube to ensure that it was not competing for the key. Not sure if this was necessary or not. It should not have been.

This raises some new questions:

  1. How does the proxy know when to switch from one qube to another for the same key? I would expect that it gets that information from the requesting qube as part of the information passed between the proxy's frontend and backend. If so, why does it take so long to respond?

  2. Is there a log that shows what the proxy is doing and/or a status showing the mapping of keys to qubes currently in use?

@jrsmiley

This comment has been minimized.

Copy link
Author

commented Dec 28, 2018

Just validated the Twitter example in the proxy doc by making the changes to the policy files in dom0 as described in the doc, de-registering my YubiKey on my Twitter account, cloning the personal-test-1 qube to "twitter", launching Chrome in the twitter qube, registering the Yubikey with my Twitter account from there, and then tried to log in with the key in the personal-test-1 qubue and the twitter qube. Only the Twitter qube was able to get the key, exactly as described in the doc. Huston, we are go for launch.

@andrewdavidwong

This comment has been minimized.

Copy link
Member

commented Dec 29, 2018

Thank you for your willingness to help improve the documentation, @jrsmiley!

I don't have access to the Announce page.

You should be able to submit a PR against this repo:

https://github.com/QubesOS/qubes-posts

I might be able to update the Readme in GitHub, but I would need to go through the process of registering with you as a dev, generate some signing keys, etc.

Those steps aren't necessary. This is all you have to do:

https://www.qubes-os.org/doc/doc-guidelines/#how-to-contribute

Also, those two docs should say exactly the same thing and right now there are some minor differences.

No, the differences are intentional, because announcements and documentation serve two different purposes.

@andrewdavidwong andrewdavidwong changed the title qubes-u2f-proxy either not working or docs incorrect Improve qubes-u2f-proxy documentation Dec 29, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.