multi: Add support for dcrwallet client auth #110
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
matheusd
force-pushed
the
wallet-client-auth
branch
from
906d079
to
a716fd2
Compare
This will allow dcrlnd instances running in remote wallet mode to be unlocked by providing an appropriate client key and certificate via the WalletUnlocker service's Unlock() method.
This adds CLI options to configure the client key and certificate files for use with dcrlnd instances running in remote wallet mode. These will be needed when connecting to a remote wallet that requires client authentication.
matheusd
force-pushed
the
wallet-client-auth
branch
from
758c3fd
to
e77d06e
Compare
matheusd
force-pushed
the
wallet-client-auth
branch
from
e30d84e
to
3541a98
Compare
This adds support for authenticating using client certificates when connecting to a remote dcrwallet instance that requires them. dcrwallet now requires client certificates for authentication when connecting to its gRPC interface, so this commit modifies the wallet unlocker service to use an appropriate combination of key and cert when connecting to the wallet. There are two possible sources for the key+cert pair: either specified via CLI args or directly during an Unlock() call to the WalletUnlocker service. The first alternative is used on dcrlnd instances that have been manually configured to use the remote wallet mode. The second alternative is used on Decrediton-initialized wallets, where an ephemeral key+cert pair is generated and passed from dcrwallet to Decrediton via IPC messages and is then relayed to dcrlnd during startup. The itest harness was also updated to reflect the need for client certs when testing the remotewallet implementation. For simplicity, the existing rpc.key and rpc.cert are used for client authentication as well.
This fixes itest flakes that happen when a payment is attempted that ends up causing a channel closure. completePaymentRequests() attempts to monitor the open channels after a payment is attempted in order to identify that payment was actually dispatched to a remote node before returning. However, when the payment actually causes a channel closure (for example, because the receiver sent an incorrect preimage) this logic fails in that the channel will no longer the found in the list of open channels. This could cause a flake when there was enough time for the channel to close before performing the check. One example of such a flaky test is failing_link. This fixes the issue by also checking whether the total number of channels was reduced, which indicates (assuming itest operations are being executed serially) that one of the attempted payments affected at least one channel.
This prevents fast nodes from being banned from eachother.
matheusd
force-pushed
the
wallet-client-auth
branch
from
3541a98
to
2d6d340
Compare
fguisso
approved these changes
Oct 16, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
rebased on top of #109This adds support for authenticating using client certificates when
connecting to a remote dcrwallet instance that requires them.
dcrwallet now requires client certificates for authentication when
connecting to its gRPC interface, so this PR modifies the wallet
unlocker service to use an appropriate combination of key and cert when
connecting to the wallet.
There are two possible sources for the key+cert pair: either specified
via CLI args or directly during an Unlock() call to the WalletUnlocker
service.
The first alternative is used on dcrlnd instances that have been
manually configured to use the remote wallet mode.
The second alternative is used on Decrediton-initialized wallets, where
an ephemeral key+cert pair is generated and passed from dcrwallet to
Decrediton via IPC messages and is then relayed to dcrlnd during
startup.
The itest harness was also updated to reflect the need for client certs
when testing the remotewallet implementation. For simplicity, the
existing rpc.key and rpc.cert are used for client authentication as
well.