BTCPay integration: Ajax calls limited to trezor.io?

[NicolasDorier]

From the doc:

trezord-go starts a HTTP server on http://localhost:21325. AJAX calls are only enabled from trezor.io subdomains.

However, in BTCPay the browser, on the BTCPay server website, need to communicate with TrezorD to ask it to sign any transaction. So how should I do?

Any other supported protocol like U2F or WebUsb?

[szymonlesisz]

for web integration use trezor-connect

[NicolasDorier]

User interface is presented in a secure popup window served from https://connect.trezor.io/7/popup.html

Nop.

[NicolasDorier]

Connect trezor is:

1. A third party website
2. Reveal my addresses to Trezor

So this is not an option.

[szymonlesisz]

Ad 1. From Trezor point of view BTCPay is a third party website Ad 2. What do you mean? You need to send this address to Trezor anyway to sign transaction? What do you want to hide? Ad 3. ('Nop.') - I don't get it...

[NicolasDorier]

Ledger Wallet supports WebUSB and U2F, so the user does not have to contact them to get their money back.

BTCPay Servers have all the utxos, all the the keypaths and all the parent transactions necessary to sign without the need of third party, so we should not need a third party.

You need to send this address to Trezor anyway to sign transaction?

No, I want to send an unsigned transaction + keypaths + parent transactions. Also, I don't want any of such data to pass by your server.

Reveal my addresses to Trezor

I mean I don't want to reveal my addresses to Trezor as a company. Of course my hardware wallet knows the addresses, but I should not have to contact your servers.

[szymonlesisz]

Trezor also have WebUsb support but it's limited only for chrome users. You can sign transaction using own utxos without using our backend servers (if you provide those data as method parameters in proper format).

You do not reveal any information to our company, connect is an opensource project running 100% on client side (except for "blockchain operiations" like, getting account utxo or broadcasting transaction), so you can convince yourself that we do not store any of this information anywhere.

Since you do not trust us, there is no reason to trust you and whitelisting your url in our bridge. Therefore you will need to create your own WebUsb integration, protobuf message parsing etc.

[NicolasDorier]

@szymonlesisz it is running client side but served from your server. You can be compelled to use it maliciously. And if your server go down, my users will bother me for something that is not my problem.

there is no reason to trust you and whitelisting your url in our bridge

There is no URL to whitelist, all users have their own server with different urls, so you can't use whitelist to solve my problem even if you wanted to.

Therefore you will need to create your own WebUsb integration, protobuf message parsing etc.

Actually there is another solution: building my own trezord without the AJAX restriction, and distributing that to my users.

Also, if I can do all what Trezord do with WebUsb, what is the point of the AJAX restriction? On top of it, a hardware wallet should not assume that even the cable connecting to my PC is trusted, so trezord AJAX whitelist just make no sense.

Either the wallet don't need to trust the transport and user's PC and the AJAX whitelist is useless, or the wallet need to trust the transport and user's PC and in which case you need no hardware wallet at all.

[szymonlesisz]

trezord has nothing to do with webusb, trezord is a webusb alternative for those who are using client other than chrome. In matter of fact trezord was here before chrome released webusb.

There is no URL to whitelist, all users have their own server with different urls, so you can't use whitelist to solve my problem even if you wanted to.

Yes there is, to allow http requests from domains other that localhost or trezor.io you need to whitelist it here, but we will not do it anyway for security reasons (not only for you, but for anyone else who ask for that)

Actually there is another solution: building my own trezord without the AJAX restriction, and distributing that to my users.

be our guest, do whatever you want, it's an opensource project

Also, if I can do all what Trezord do with WebUsb, what is the point of the AJAX restriction?

Security reasons, as a Trezor user you don't want to any thirdparty website be able to enumerate your device without your knowledge/permission. Then you can become a potential phishing target (since attacker already know that you have Trezor connected)

In WebUsb case you have to explicitly pair device with given website (so you are aware that this page will somehow communicate with it) In Bridge case you can quietly send http request without user knowledge and then prepare some phishing site which looks like our product and ask user for seed (and if user is not smart enough he will give it to you)

also this statement:

You can be compelled to use it maliciously.

can be applied to you, right?

[slush0]

Hello Nicolas, the motivation for restricting access to Trezor from random site is to protect users from using malicious/phishing sites impersonating legit products. For this reason we've built Connect, so people have an ability to check what information is asked by the site in the environment provided by Trezor.

Of course, if the attacker is able to install modified Bridge with whitelisted domains, this won't help. But we're talking about generic phishing which we're targeted every day.

Although I understand your concerns, we're not going to change the architecture. There's nothing particularly wrong with it from privacy perspective; the Connect API works in-browser and we can prove the address is not sent/logged anywhere on our servers.

Connect is A third party website

Open source website.

Reveal my addresses to Trezor

No, addresses are not sent to Trezor servers, as you can check in the code as well as in the browser network activity log.

[NicolasDorier]

can be applied to you, right?

No, the user which use Ledger wallet never communicate anything to third parties, not even me. The user owns his own server and only communicate with it.

@slush0 so it seems my best bet is to pass by WebUSB? Do you have any code to share where you use this method? Are the messages the same as what I would send to trezord ?

Being limited to chrome is not an issue.

[szymonlesisz]

No, the user which use Ledger wallet never communicate anything to third parties, not even me. The user owns his own server and only communicate with it.

But then again, you need to put your address into (from your point of view) 3rd party app (LedgerWallet), process the transaction inside of it and get the result (signed tx) In this case you should have exactly the same concerns like you have with connect, that the address you are trying to protect could be stored and sent to their server (not immediately, but let say later on) The only difference here is that LedgerWallet is a desktop app and connect is webapp.

Back to your question, webusb implementation could be found in trezor-link project. Massages are the same, but they needs to be parsed from json to protobuf format

[NicolasDorier]

@szymonlesisz no. BTCPay does not need to have the user using the LedgerWallet desktop app. It just connect to the Ledger via U2F directly from the browser on a page controlled by the user's server. There is nothing to be installed by the user.

Their WebUSB interface is still buggy though, I will use WebUSB on chrome as soon as it works.

Actually the user can't even use the LedgerWallet app (ledger live) to manage his wallet, because it not even see the whole balance of the user because of gap limit issues.

[szymonlesisz]

Ok, get it, i was thinking that by LedgerWallet you meant desktop app not the device itself

[slush0]

The fact Ledger device can be talked to via U2F silently by any unknown site is rather alarming and nothing we want to replicate. I understand that your use case is legit, but internet has dark corners and we have to be extremely cautious.

Yes, using WebUSB directly will work. It is nothing I'm happy about, as origin checks were withdrawn from WebUSB specs at the last moment, in my opinion without proper discussion.

[NicolasDorier]

The point of a HW is that even if the channel between the screen and the HW is compromised, the security of the HW should not be compromised.

WebUSB is specially good as you need to validate manually access to the device.

[szymonlesisz]

I think we are talking about two different things now.

HW is not compromised in any way in this case, but "5$ wrench attack" is still an issue since you know that someone has HW wallet and you are able to find him and hit him on the head. Or use remote phishing to trick him to put his seed to verification, like @slush0 said, we are struggling with those attacks almost every day

[NicolasDorier]

So basically we have no way to integrate Trezor without either leaking stuff to your servers, to some random servers on Electrum, or making a fork of trezord and asking user to use this instead of the official one. All those options are pretty bad from privacy and security point of view.

WebUSB is the only way, but there is no code or documentation I could find about it in your repos.

[szymonlesisz]

Once again, you do not send anything thru our server, javascript once downloaded is working on your local machine. Therefore connect method doesn't send its params anywhere, just process them locally. I see it's pointless to have further discussion about it.

I've pasted link with trezor-link project before, this is the place where all the magic happens (device enumeration, messages translation, etc.) trezor-connect or trezor.js libraries are using trezor-link, by looking at code you can get inspired how it's done exactly.

Anyway, if you don't want to do that by your self (because it's a lot of work, and it's not well documented) you can always build your own connect or trezor.js instance (with a little modifications) and host it on your own server (or localhost). In this case communication with trezord will be blocked (because of script origin) but WebUSB will work. But again, then you will have to handle all UI events all by yourself (modals for entering pin/passphrase/permissions/confirmations/button request/not supported firmware/not readable device/ and many more)

[NicolasDorier]

Thanks a lot, trezor-link seems to be exactly what I need.

[szymonlesisz]

I suggest you to look at implementation in trezor.js or connect to see how does those projects working with trezor-link

trezor.js is basically precursor of trezor-connect. It is simpler so it could be easier to read

[NicolasDorier]

Thanks! Will take a look. @szymonlesisz I see that https://github.com/trezor/connect is actually supporting webusb.

Does it mean I can serve the popup (https://connect.trezor.io/7/popup.html) from the user's BTCPay Server (not from your server)?

It would limit the Trezor support to Chrome, but that would be ok.

[prusnak]

@NicolasDorier yes

[szymonlesisz]

not quite, actually webusb intergration in chrome 72+ and "popup mode" is intentionally disabled.

They've made some changes in their api and integration stops working. I didn't have time to fix it, and by fix it i mean totally change the way how to pair device within 3rd party website