Building secure distributed Webhooks

Transcript

foreign hi everyone for those of you who don't know me my name is Harry I'm a distributed systems engineer at wallet connect as well as working on other open source stuff in my spare time both web through related and not you might have seen me around Super Bass maybe and today I'm here to talk to you about the distributed webhook solution that we've started working on at wallet connect and are continuing to work on now as a quick intro for people who don't know what wallet connect is with a QR code you see when you need to connect your mobile wallet to your desktop dap we're on we're in major daps like openc pancake Swap and others like that as well as integrated by over 150 wallets now we'll get on to what web hooks are

I know some of you here may already know what they are but so that everybody's on the same page let's imagine we have two servers or just two computers in general and one needs to send an asynchronous message to the other where it has no way of knowing if the other's on and it has no way of knowing the state of the other so it can send a payload like this for example this is for a new address being registered on one and it needs to send it to the other it normally sends over HTTP so a post request from my server to yours and it's something like slash hook or some people name them a bit smarter so slash wallet connect or whatever you need but there are some inherent problems with webhooks first of all I have my laptop here I find out what your server

is and then I start sending web hooks to it so I send this this new address one over and over with random addresses and your servers then flooded you then have the inherent security problem of what can this server Trust before we go on to how we can secure these why am I even talking about web hooks a wallet connect we use them currently for push notifications with our new well newish push API where your desktop daps so openc and others like that will be able to send notifications to your mobile wallet for example you have a new offer or you need more liquidity or something like that in openc secondly web hooks have less load than websockets traditional wallet connect uses websockets between each client so

your wallet has a web hook no your wallet has a websocket to us to the relay in V2 and so does the DAP which is two websockets for one connection so there's less load involved when we can just send them to servers and they can be managed individually and finally there's more opportunities with webhooks we no longer have the requirement for Nic based limits with web sockets there's no required long-living TCP connections and there's more security opportunities we obviously don't plan to remove the websocket feature at any point soon but we are obviously building this out with security in mind as options for people in the future so how can we make this secure

internally we had a few options so I'll go over three of them they were obviously so many more that we would be here for hours if I went over them all and the meetings where we brainstorm them all were probably not the most interesting but the first and probably worst option was we just left it alone we'll have no security on it and we just hope that nobody abused him obviously with no security we would lose trust if people start sending you push notifications pretending to be open c it looks bad on us it looks bad on Open Sea and of course worst of all it looks bad on the wallet so the first thing we looked at was signatures with ed25519 and there's actually two implementations we um explored the first one here is where the relay just has one public key each relay

has a public key as shown there and we get a link between both servers where my server or yours would request the relays public key store it somewhere and then each time something came in a signature will be sent with it so that you could verify that the payload you received was valid of course there are still some flaws with this so we iterated on this for a second time hoping that we can make it a little bit better so here's our our second and of course the chosen implementation so you might ask what was wrong with the first one well there are three main issues first of all with decentralization as an as a

constant goal of wallet connect that solution doesn't work imagine we now have six providers we have to share the private key amongst them all and that completely defeats the point of the security then we might as well have just kept no security at all and if we had no security we go back to the old point of no trust secondly it's a single point of failure then there is only one node well one private key that can sign everything if I was to compromise it you as a compromiser or anybody else was to even accidentally compromise it the entire security system is then broken and finally as I focus on single node support even though in theory there might be multiple nodes inside of the current video Network they all act like one

so there's a strong focus on that which goes back to point one of no decentralization support so what did we actually change first of all the relay would now look after in theory multiple public keys they could be the same but the spec now supports multiple and each webhook has its own public key so your web hook would have a separate one to mine and then each time you send the relay sign something it signs it with a specific one to that webhook therefore defeating the first point of decentralization not working because each Relay can look after its own public he's now on a per webhub basis so you might ask you want to integrate a

service with webhooks what responsibilities do you have first of all you need to store the key the relay gives you if you were to at any point lose it you would then have to go back to your first option of no security secondly you need to validate incoming requests of course this is optional but the security is there for a reason if you're not using it you're just as insecure as I was not sending it third and finally you need to decode and pass the messages we send you we're sending now the traditional websocket web socket messages you would get that are now sent but now over web hooks instead so everything you would get over a websocket you go over a web hook we keep the same end-to-end encryption as well as the signatures and the only person who can decrypt the message would

be the wallet at the end of course we strive to constantly improve if you see anything glaringly wrong with it now you can speak to me here over Etc and of course as always any security reports we welcome at securitywallconnect.com thank you so much for listening and if there's any questions I'm happy to take them now or around the conference [Applause] so I was waiting for the the third slide

where you build a distributed system to distribute those key is there any heading are you planning on doing that as in the future decentralization of wallet connect or so as an uh assistant to manage those keys is out so the creators are actually managed within the relay um we're working through implementations at the moment and it's uh it's quite ongoing system we had a few implementations that we've then scrapped but the general consensus is that each client's ID has its own public key or each webhook ID which is another which is like a derivative of client ID as well as a few things has its own public key which is then returned to the client and then the client can send that on to the service that it registers with but

it's ongoing and we hope to publish full specs soon but there's the initial drafts are already up where's that it should be a docs.walletconnect.com I can get a link for you afterwards any other okay well thank you very much for having me and I hope you enjoyed the talk of course any other questions please feel free to ask them here and I'll be around the conference for the rest of the week [Laughter] [Music]