Re-enable wireguard key rotation (WIP) #10855
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
We have couple of issues with regular wireguard key rotation: the server response is not very fast, and the client can attempt to connect while the key is being regenerated. This PR addresses the latter problem.
We have three places where key is regenerated currently:
Both
KeyRegeneratorandmaybeRegenerateDeviceKeyschedule a TaskAddDevice to replace current device keys, and the server reply can take a few seconds to arrive (i've got as much as 7-8 seconds in my tests sometimes). VPN activation clears the task queue, so we may end up in a situation when the keys are updated on the server and not updated in the client.This PR is one way to solve it by removing cases 1 and 3 above and moving the timer logic from KeyRegenerator under 2, which becomes a single point where key is regenerated immediately before connecting if required (see update
maybeRegenerateDeviceKey()below). Failure to regenerate the key will abort connection.There's a new controller state - RegeneratingKey - that updates the main screen (otherwise it's possible to trigger multiple key updates by repeatedly pushing the toggle).
One alternative solution I can think of would be locking guardian access (at least for adddevice and connection tasks), but that would require implementing some sort of locking mechanism.
Raising this mainly for discussion of the approach now, not for detailed review. More testing is probably needed around state changes (and some functional tests as well). One problem that I've discovered while working on this is that keys aren't updated when CLI command
mozillavpn activateis used, that also seems to affect current stable version (no maybeRegenerateDeviceKey check?). Baku has also hinted that experimenting with cancelable flag for the affected tasks could result in a simpler fix.Reference
VPN-2693
Checklist