Nickez/fix u2f safari #1474
Nickez/fix u2f safari #1474
Conversation
U2F is typically a stateless protocol, so between two transactions
(request+response) there is not supposed to be any lock held. It was
assumed that the "FIDO Client" (typically web browser) would keep
sending only U2F `register` or `authenticate` messages when it had started
doing so. But it is also legal to send for example a new U2FHID `init`
message in between. (the U2F reference test cases do this for example).
Before this commit we held a "lock" while the confirm screen was active
until the user had confirmed and didn't allow any other messages in
between. This breaks the U2F protocol as explained above.
After this commit we instead only hold the "lock" for the transaction
(request + response), which is the correct way according to the u2f
reference:
The application channel that manages to get through the first
initialization packet when the device is in idle state will keep the
device locked for other channels until the last packet of the
response message has been received. The device then returns to idle
state, ready to perform another transaction for the same or a
different channel. Between two transactions, no state is maintained
in the device and a host application must assume that any other
process may execute other transactions at any time.
NickeZ
force-pushed
the
nickez/fix-u2f-safari
branch
from
b601b64 to
f5d3c49
Compare
src/u2f.c
Outdated
|
|
||
| // Give the user 5s to respond to u2f requests (the FIDO Client in u2f is not required to ping | ||
| // every 200ms like the BitBoxApp does even though most implementations do). | ||
| usb_processing_timeout_reset(-50); |
There was a problem hiding this comment.
If it times out the confirm screen just disappears?
Do you know of a browser that does not ping to keep it alive?
There was a problem hiding this comment.
If it times out the confirm screen just disappears?
Yeah, the USB stack is unlocked and the workflow cancelled.
Do you know of a browser that does not ping to keep it alive?
Safari
There was a problem hiding this comment.
Isn't 5s seems a bit too short. I'd bump it to at least 10s, maybe 15s. Would be frustrating to miss it. Do you know what timeout Yubikey uses?
There was a problem hiding this comment.
Now that I test some more it seems like macos/safari actually is sending more often. The issue was probably that we didn't follow the protocol initially and then macos/safari just ignored us.
Now that I look closer at the working behavior it also seems like macos/safari is using a new CID for every request. I'll have to look into what that means.
There was a problem hiding this comment.
So we can probably remove this timeout, even if 5s is what I found in other open source implementations.
(btw it wouldn't actually mean that the user would only have 5s. because I guess all FIDO clients try again within that 5s.) I think FIDO clients typically retry up to at least 30s. maybe longer
No description provided.