[Bug] LND REST Proxy stop working if gRPC is exposed on 0.0.0.0

[NicolasDorier]

Background

When I added rpclisten=0.0.0.0:10009, then the rest endpoint sends me error 500:

Config:

restlisten=0.0.0.0:8080
rpclisten=0.0.0.0:10009
bitcoin.node=bitcoind
bitcoind.rpchost=bitcoind:43782
bitcoind.zmqpath=tcp://bitcoind:28332
externalip=testlnd1.btcpayserver.com:9735
alias=
noencryptwallet=1
notls=1
bitcoin.active=1
bitcoin.mainnet=1

Error:

{"error":"connection error: desc = \"transport: authentication handshake failed: x509: certificate is valid for 127.0.0.1, ::1, 172.18.0.6, not 0.0.0.0\"","code":13}

Workaround

Adding an unused rpclisten endpoint fix the situation.

restlisten=0.0.0.0:8080
rpclisten=127.0.0.1:10008
rpclisten=0.0.0.0:10009
bitcoin.node=bitcoind
bitcoind.rpchost=bitcoind:43782
bitcoind.zmqpath=tcp://bitcoind:28332
externalip=testlnd1.btcpayserver.com:9735
alias=
noencryptwallet=1
notls=1
bitcoin.active=1
bitcoin.mainnet=1

[Roasbeef]

noencryptwallet=1

Please don't run with this setting on mainnet. As is, it means you won't get a recovery phrase and also the contents on disk will be encrypted with a default passphrase.

[NicolasDorier]

I might change it later. I am currently working with Zap wallet guys to get something working.

If Zap wallet can handle the initialization of the recovery phrase, I will do this. I can't ask BTCPay users to use command line.

[Roasbeef]

Why would they have to use the command line? It's possible to do it all programmatically over the REST interface. If Zap is skipping this all together, that's pretty dangerous... (users have no way to recover on chain funds)

[NicolasDorier]

They probably do already, need to check.

[Roasbeef]

Also this is the Let's Encrypt cert right? Not the default cert that lnd generates?

[NicolasDorier]

Yes. Technically it is possible to initialize the wallet from Zap. I just don't know if they do it now. (they probably do, I just need to ask)

But anyway for this issue, it is unrelated to all of that. In my case, the REST Proxy just seem to connect to gRPC server by using 0.0.0.0, which obviously fail.

This is completely unrelated to how btcpay do things.

[NicolasDorier]

I think keeping noencryptwallet=0.

The reason is that I don't want the user to manually enter a password if his server restart for some reason.

I could unlock it automatically via the API, but what is the point? If the server get pwnd the password will also leak and thus the attacker can unlock himself.

[Roasbeef]

Do you understand that the user doesn't get a backup phrase with that a option?

…

On Fri, Jul 27, 2018, 2:03 AM Nicolas Dorier ***@***.***> wrote: I think keeping noencryptwallet=0. The reason is that I don't want the user to manually enter a password if his server restart for some reason. I could unlock it automatically via the API, but what is the point? If the server get pwnd the password will also leak and thus the attacker can unlock himself. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1567 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA87LuvwLfI95O9J5N0Wrj7uNq0vQtAlks5uKq1NgaJpZM4VSCay> .

[NicolasDorier]

@Roasbeef nop, this is problematic indeed. I need to think more about it.

[Roasbeef]

How do you handle the password for bitcoind?

…

On Fri, Jul 27, 2018, 8:41 AM Nicolas Dorier ***@***.***> wrote: @Roasbeef <https://github.com/Roasbeef> nop, this is problematic indeed. I need to think more about it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1567 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA87LqWYrVC24gYFmfuIOLRuB7HmjF_Gks5uKwpqgaJpZM4VSCay> .

[NicolasDorier]

I don't BTCPay does not need to sign any transaction as the money goes directly into the Ledger Wallet of the user.

[NicolasDorier]

I got an idea where I can set it up which would fit well in the UX... The passphrase to unlock the wallet will be saved in BTCPay, but at least the user would be able to restore.

[zwarbo]

@NicolasDorier Thanks for the workaround.
Your post has helped me get past a point I was stuck with this following guide: Auto Unlock Guide, where I kept getting this cert error from the curl command:

{"error":"connection error: desc = \"transport: authentication handshake failed: x509: certificate is valid for 127.0.0.1, not 0.0.0.0\"","code":13}

Once I added the rpclisten=127.0.0.1:10008 line and restarted lnd the script fired and the wallet unlocked.

[dennisreimann]

I encountered the same issue. For me adding this line fixed it, though I don't think this is the appropriate way to handle it:

tlsextraip=0.0.0.0

[vindard]

I ran into this exact problem too and was messing around with different ways for quite some time. Nicolas's "add an extra line with rpclisten=127.0.0.1:10008" didn't quite work for me and @dennisreimann's suggestion didn't work at first until I also deleted the tls.cert file and restarted lnd so that a new cert file would be generated with the new tlsextraip setting. Works perfectly now.

tl;dr: add tlsextraip=0.0.0.0 to the lnd.conf file, delete the tls.cert file, and then restart lnd.

[wereHamster]

I've just tested this and it still doesn't work, even with the fix #2247 which is now in master.

Version: 0.5.2-99-beta commit=queue/v1.0.1-106-g9143067014bcde14f1e8f7eb515bae1ccccb97c5, build=development, logging=default (which is master as of right now).

./lnd-debug --bitcoin.active --bitcoin.testnet --bitcoin.node=btcd --btcd.rpcuser=u --btcd.rpcpass=p --restlisten=0.0.0.0:8080 --rpclisten=0.0.0.0:10009

And then trying to unlock the wallet via the rest api fails with:

{"error":"all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: authentication handshake failed: x509: certificate is valid for 127.0.0.1, ::1, fe80::1, 172.20.10.3, not 0.0.0.0"","code":14}

Yes I've deleted the certificate and key before starting lnd.

[wereHamster]

I see. #2247 only fixed the issue with the rpc server, but the password rpc server is started somewhere else (in lnd.go instead of rpcserver.go), and probably requires the same changes.

[NicolasDorier]

I probably don't have this error because my fork of LND disable SSL.