Enhancement request: lnd-grpc onion address in lnd tls cert to enable Heroku LND integration

[trbouma]

I was success in integrating lnme directly in umbrel (see issue here: bumi/lnme#25 ).
The issue boiled down to not having the onion address in the tls cert which I rectified by the following.

1. retrieved the lnd-grpc hostname onion value from the /tor/data/lnd directory.
2. added to lnd.conf tlsextradomain=
3. removed tls.cert and tls.key from /lnd
4. docker stopped and started lnd to regen the certs.

After that change my integration started working.

So adding the onion address to the umbrel lnd.conf is an enhancement for consideration. There are other configurations that need to be done, but the above is the only required change to the umbrel lnd instance.

You can see my integration in action here: http://lnme-yow3.herokuapp.com/

[bumi]

It seemed that the umbrel onion address is not by default a tlsextraip in LND. This result in the following error:

transport: authentication handshake failed: x509: certificate is valid for localhost, umbrel.local, unix, unixpacket, bufconn, not xxxxxx.onion"

shouldn't umbrel somehow tell LND the onion address used for the LND gRPC connection automatically? (as tlsextraip?)

[lukechilds]

Hey guys. Are you saying you need to add the LND gRPC Tor hidden service added to tlsextraip to enable connecting a remote (to Umbrel) lnme instance to a local (to Umbrel) LND instance?

Maybe this problem would be better resolved by packaging lnme as an Umbrel app so the lnme<>LND communication is all local?

[trbouma]

I think it would be great to have lnme packaged so communication is all local. But I do really like the option where I can keep my umbrel completely behind the scenes with a hosted frontend end. So I think both options are feasible. I really like the latter because my umbrel node is one further step away from prying eyes, and the only who can access it is the hosted server with the TLS cert, onion address and macaroons as part of its secret variables. I consider my umbrel a valuable jewel, and even exposing an onion address makes me uncomfortable. Having a hosted front end with a back-end secret TLS/onion connect is super-important if you need to punch through adversarial networks.

@lukechilds, I see from the screenshot that you tried to do a payment. My umbrel node got contacted to generate the invoice, but not sure why it didn't go through. I have been experimenting and I have been having this problem from time to time.

[trbouma]

Also, @lukechilds - you can see from the screenshot that the lightning address works (can you give it a whirl trbouma@lnme-yow3.herokuapp.com ). I am trying out a custom domain trbouma@lnpay.ca - it doesn't work yet because I need a cert for that domain and I have to use a heroku paid tier to try that out. I hope to have that ready in a couple of days.

Bottom line, I am pretty excited about this integration because it enables my umbrel server to punch above its weight in the retail payment ecosystem. All the more to protect it, as there will be even more motivation to dox the operator or shut it down.

[trbouma]

I added it as tlsextradomain with [MY lnd-grpc ADDRESS] (my real address removed) and regenerated the cert (described earlier) I did not use tlsextraip. It worked after that.

[Application Options]
listen=0.0.0.0:9735
rpclisten=0.0.0.0:10009
restlisten=0.0.0.0:8080
maxpendingchannels=3
minchansize=10000
accept-keysend=true
tlsextraip=10.21.21.9
tlsextradomain=umbrel.local
tlsextradomain=[MY lnd-grpc ADDRESS].onion
tlsautorefresh=1
tlsdisableautofill=1

[lukechilds]

Awesome, just tried a few payments with both the web interface and Lighting address, so cool!

Just re this:

I consider my umbrel a valuable jewel, and even exposing an onion address makes me uncomfortable.

Yeah, I get that. I think there's an argument to be made to run both together otherwise you are leaking LND authentication data to Heroku. I guess if you only use your invoice macaroon it should be ok, although I would imagine there's still a potential small DoS risk?

If you ran lnme + LND on Umbrel, you could run a clearnet Heroku => Tor lnme proxy to acheive the same clearnet UX you have currently, without any authentication data ever touching Heroku. Heroku would just be being used as a dumb proxy.

But of course, if you prefer to let Heroku do the heavy lifting running lnme, and leave Umbrel to just core LND things, all good too!

[trbouma]

Thank you, sir! See screenshot below.

FWIW, yesterday I tested this on a locked-down enterprise asset, bolted to a VPN behind a super-hardened firewall and it worked.

'Viva la decentralione!' (I just made that up)

[trbouma]

Finally to add - the payment seems goes directly into my Lightning Wallet, not into an intermediate 'hub' wallet, like LNDHub.

This is what the transaction looks like from Thunderhub (note: secret is left out of screenshot

)

[trbouma]

Oh wow, that was easy! I upraded to the paid tier, a cert was put in place and I am in business with trbouma@lnpay.ca

[bumi]

Hey guys. Are you saying you need to add the LND gRPC Tor hidden service added to tlsextraip to enable connecting a remote (to Umbrel) lnme instance to a local (to Umbrel) LND instance?

I think this is independent of LnMe and should be generally the problem when trying to connect to the LND on Umbrel through the gRPC interface on Tor. (I had the issue)
LNDs TLS cert currently seems to not work with the onion address. Or am I missing something?

Regarding LnMe: The goal was to have it independent of any node-system and to be able to directly connect to LND (without much other setup). It only needs invoices permissions, which should be fine. esp. as one typically also somewhat trusts the hoster. Any lightning address / LNURL system has a DoS problem. (LnMe defines for that a request limit)

There are plans to package LnMe for umbrel then it is possible to use a HTTP -> Tor proxy. (do you have any ideas what could be used for that to proxy a clearnet domain to it?)

[lukechilds]

I think this is independent of LnMe and should be generally the problem when trying to connect to the LND on Umbrel through the gRPC interface on Tor. (I had the issue)
LNDs TLS cert currently seems to not work with the onion address. Or am I missing something?

I believe most clients don't verify the SSL cert when connecting over Tor since it's redundant. At least this is how both Zap and Zeus behave. If they are connecting to LND via a Tor hidden service, the Tor hidden service is already providing the identity verification, so the SSL certificate is not verified.

Regarding LnMe: The goal was to have it independent of any node-system and to be able to directly connect to LND (without much other setup). It only needs invoices permissions, which should be fine. esp. as one typically also somewhat trusts the hoster. Any lightning address / LNURL system has a DoS problem. (LnMe defines for that a request limit)

Sure, makes sense.

There are plans to package LnMe for umbrel

Music to my ears!

[bumi]

hmm... thanks... I had issues with zeus, too. that's why I thought it is related.
shouldn't the hostnames still match? - it is not actually validating the cert or the the signing certificate authority.

[lukechilds]

Ah ok don't quote me on that. I know Zap bypasses it, I thought Zues did too since I seem to remember testing connecting it and it worked but maybe I was mistaken on that.

Regarding adding the onion address to tlsextradomain, this is not trivial for us to add right now since LND (currently) starts before the Tor hidden services have been generated. We're planning to migrate LND to the app store very soon which will mean we can then easily pass in it's hidden service addresses.

Maybe in the meantime it's ok for lnme users who want remote to connect to an external LND to manually add this line to their lnd.conf? And we can support this natively in Umbrel once we've refactored LND into an app.

[trbouma]

In order for me to get my own Lightning address to work from various wallets, it failed until I got a certificate for my hosted site. In turn, lnme makes a request over TLS/Onion to my umbrel node. This second part might not be absolutely necessary, but I would like to err on the side of security. Likely, Onion is good enough for most apps, but I still feel a bit nervous without the extra layer of TLS with a cert I directly generate and control. This might not be an issue now, but if this takes off, umbrel nodes will be targets for some pretty motivated agents - not so much to breach, but to determine who the actors/operators are and showing up at their houses. Better to harden the security now.

[trbouma]

In the meantime. we can provide some advice on hardening Umbrel, if this does not make it into an enhancement. The key thing is that it can be done quite easily after an install, so not really necessary to be an enhancement.

[trbouma]

Ah ok don't quote me on that. I know Zap bypasses it, I thought Zues did too since I seem to remember testing connecting it and it worked but maybe I was mistaken on that.

Regarding adding the onion address to tlsextradomain, this is not trivial for us to add right now since LND (currently) starts before the Tor hidden services have been generated. We're planning to migrate LND to the app store very soon which will mean we can then easily pass in it's hidden service addresses.

Maybe in the meantime it's ok for lnme users who want remote to connect to an external LND to manually add this line to their lnd.conf? And we can support this natively in Umbrel once we've refactored LND into an app.

I'm cool with that. It's actually pretty straightforward. I tried it out on my test node, before doing on my production. Anyone who wants to harden their Umbrel should already have the technical chops to do this.I documented in the issue, but I can write up a brief note, if you want.

[blastshielddown]

I also have a use case that requires LND's onion hostname be included in the tls.cert file, though it has nothing to do with Heroku. The site I am working on, wavlake.com, allows artists to connect their nodes to the site in order to receive payments for tracks directly from listeners. This requires a connection to LND's gRPC interface. The Node library I am using (grpc) will only establish a connection if the hostname is valid in the cert. Currently I have an onboarding process that works, but it requires an artist 1) manually update the lnd.conf file with the onion hostname, 2) restart, and then 3) download the regenerated tls.cert.

We're planning to migrate LND to the app store very soon which will mean we can then easily pass in its hidden service addresses.

This sounds like a great start to making the process simpler @lukechilds. Is there also any way to enable a user to access the cert file from the UI? I would be interested in contributing a new app or a wallet connection type to help enable this but am not sure what is the best way to approach this in the Umbrel environment. Our users also need a custom macaroon, which is easy enough to bake in ThunderHub or the CLI, but having an all-in-one solution would be ideal. Appreciate any guidance you can provide.

[KayBeSee]

Bumping this issue because I am running into the same problem as @blastshielddown trying to connect to my node over Tor using grpc-js.

Without the onion hostname in the tls cert I have to either update the lnd.conf file and restart or run the application using NODE_TLS_REJECT_UNAUTHORIZED='0' which isn't ideal for other application traffic.

I believe now that Umbrel 0.5 is out, some refactoring should allow LND to generate the TLS cert with the onion hostname.