Plugging the metadata leaks in the Ethereum ecosystem by Péter Szilágyi (Devcon4)

if you essentially the a theorem ecosystem has been growing at a very steady pace in the last couple of years but if you look at some of these ether noes websites which track the number of full nose you'll see that that one is kind of constant or maybe even decreasing and why is that well first up because running a full-out sucks but and even though we're trying to solve that the issue is that people will always prefer having a light client opposed to running a full client or running in fostering a light client or even just using a RESTful API versus actually connecting to infra and this is kind of fine people are kind of more or less aware of the implications security-wise that okay if use a light client and the security is not the same if using fluid and you kind of trust them you can maybe make a few proofs but you still trust them and if you something like ether scan then you know that you cannot trust them but yeah you kind of trust them so people can make balanced decisions however one thing that people don't really talk much about is what happens for example to metadata what happens when you actually go from running a full node down to running a restful service and how that actually changes the behaviors or the the traits that you leave behind you and that's exactly what I would like to talk about a bit in this talk specifically let's start with web 2.0 interfaces now my talk is relevant for almost any depth that uses a restful service as a background the reason I'm picking ether scan is not to pick on them rather because it's everybody knows what if the scan is how ether scan works so what is either scan just a quit in a two-word summary basically that allows you to check your balances your tokens transactions events etc and apart from that it also allows you to comment on certain accounts if you like now this is the surface what happens behind the scenes well whatever you for example you want to check your balance or ether scan you try to load this Afghan website which goes through cloud fair because class there is ether scanned accelerator ether scan returns the balance and everything plus it also returns a tracker code for Google Analytics I'm better discuss forum and this might sound like a really nice design really elegant not too many external things included but if we start digging a bit into the HTTP protocol we'll see a few surprises notably HTTP has a concept of referrer every time you visit a webpage from another web page you get a Stinney extra header saying that you came from this website the same happens if you embed something every time you embed an iframe into your own little website that iframe will get the ping that you were actually coming from another website and why is this bad well when you actually load for example in this page it's a ether scan dot io / address / 0 X whatever when you load that Google Analytics will actually have a ping that you this particular IP address loaded that particularly theorum address similarly this case also gets a similar ping that this IP address loaded that particularly theorum address and is that bad well if we explore what discussed loads the things start to get a bit weird particularly discussed has three types of integrations has social logins to Facebook Google and Twitter which means that this cuss actually reveals the IP - if the address mapping to Facebook Twitter and Google+ and it also has these other weird trackers kind of like people market a I might mining market and all kinds of weird I can't read this bit time here but you get the picture so it it loads a lot of trackers and not only that but it also loads a lot of I think disgust has 11 integrations with YouTube Vimeo and all kinds of other services and this is an issue because you are essentially associating your IP to a theorem address mapping and you're revealing that to a whole lot of external services and again this is not to pick on ether scan here and adapt is vulnerable to the same thing it's just a bit clearer to use with either scan and ok now we know that there's a problem but what can we do to actually fix it so one of the possibilities is first of all if your provide or any kind of that poor service provider first stop do not integrate legacy web 2.0 services and this might sound like a no-brainer but if you think about it in either scan ether scan has this possibility to comment on account is that genuinely a useful feature for a block Explorer but if you look through the comments it's pretty noisy it's pretty spammy there are a few scams going around on and off so it's not not the best feature so maybe it would be worth to cut it out the second thing is that if you even if you don't integrate external services or try to keep it to the minimum you should always wonder whether it is worthwhile to reveal identifying information in the URL you should always consider that anyone can access the URL let's suppose any if anyone can access the IP to URL mapping do you want your customers data to be leaked that way or not maybe for a block Explorer maybe this is cannot be circumvented but for other that maybe it should be and last of last but not least please do use HTTP referer policy restrictions I for example ethers can use as a policy whereby HTTP to HTTPS forbid the referral header from being forwarded there are much more stricter policies which actually forbid everything being forwarded ok we can do that and ether scan is actually they are trying to fix these issues original ether scan integrated an external ad network that they replaced an eternal with an internal one originally now currently they are using Google Analytics but they want to replace that so they are really open to fixing issues however the issue is that providers fixing it is not really enough because we can get ether scan to fix it but can we get random that number 2000 to fix it probably not so users need to protect themselves too and the obvious choices here are browser extensions that block all kinds of checkers or if you're on a mobile device you could for example use a brave browser but these can only block so many things for example if I have you to be integrated no none of the extensions or browsers will block YouTube which gets us to the second point let's let's suppose we managed to block all the external service even YouTube's not supposed to handle it HTTP refers directly and everything even then we have this fairly complex flow of information whereby whenever we want to access anything related to our data either by meta mask adapt or via my crypto or my sir wallet we still reach out to either scan or infra or CloudFlare in between and what this means is that ether scan in front clouds there still have access to the exact same information the exact same IP address to a theorem account mappings now you may trust them or you may not trust them that is up to you it's an issue and unfortunately the only current solution that you can do is if use an anonymizer service kind of like tor which is willing to hide your IP address behind their mixing Network but kind of that's your best chance currently so bottom line is using restful services is not the best thing so and if you think now my my conclusion would be to please use light clients yeah that's going to get even more messy so let's dig into life crisis forget trustful services all together all kinds of depths and web stuff a live clients supposed to be the way to access aetherium so that you don't have to run a full node you can just run this really nice little thing which is essentially kind of feels like a full node just it's not and it has actually two significant problems one of them is in the discovery protocol I'm not sure how many of you are aware of how the discovery protocol discovery layer works in aetherium or in peer-to-peer networks in general but in short you have a few boot notes hard-coded into the client when you boot up your node it reaches out to a few seed nodes gets a whole bunch of peers in the network and then boom you're connected now in reality what happens under the hood is that these boot nodes aren't some magical special databases that track the entire network rather they the network itself boot nodes included and all the other peers included they maintain so-called routing table or academia DHT which is kind of a fancy way of putting that everyone knows little piece about the network so nobody knows the entire network but we know little pieces of it and if you reach out to enough of them then eventually you can discover and you can you can discover enough nodes to have good connections and and have a stable stable connectivity test essentially the issue here is that in order to do that so essentially a routing table requires to be able to tell that this this particular machine is at this particular IP address that's what the routing table does the problem is what happens if my IP address is changing what happens if I have a laptop and not I'm not running a theorem on my home server rather on my laptop and I keep connecting to this theorem network from all over the world so if I for example go last month I was in San Francisco last week I was in Berlin now I'm in Prague next week I'll be in I don't know London the month afterwards in Shanghai and I keep connecting to this theorem network via light client be that mobile device be that laptop or whatever or I can even run a full note on my laptop and do the same thing that's completely equivalent what the result will be is that every time I connect to the network I am actually revealing to the network that this machine which last week was in Berlin this week is in Prague and next month I will reveal that this machine which last month was in Prague this month is in Shanghai and this is an issue because this public information so anyone in the fear network can at any moment in time see where certain IDs are and not only that but if you are willing to do this for example every day just try to scan the network every day then actually you can create an extremely accurate history of where each individual ëthere node was moving over time and just nicely plotted on the world map now I'm not sure most people here will be comfortable having their three years of history usage mapped out on a world map but how can we solve this again it's not an obvious solution one of the simplest thing is that as I said the domain vulnerability is that machines have a fixed IP address assigned to them and if you move the machine around and that ID ID is essentially the global tracker so we kind of made a cookie tracking on top of this discovery protocol so the obvious solution let's get rid of the IDS so just minute now we cannot really pin it because it's part of the etherium protocol but what we can do is make it as ephemeral so that every time we restart the machine we get a new IP and insert a new ID and this has certain implications one of the implication is that obviously if I'm running a boot node the ID cannot change so boot nodes need have special functionality whereby the IV remains the same what happens however if I run a full node and I just restarted I did the update I restarted it normally if the IV changes that's not such a big problem in practice last minute we told in the network that this IP address belongs to a certain ID and now we're telling conflicting information and currently the theorem discovery protocol cannot handle that so if you keep sending in that you restart your machine four times and you're standing in for completely conflicting information into the discovery protocol then discovery protocol will just go haywire and you will have a very hard time do this to connect to the network yes eventually maybe five minutes ten minutes everything will settle down but it is an issue and last mother last but not least if we actually do the same thing with live clients then we're breaking projects that rely on this behavior for example one of them is VIP node and they are essentially trying to incentivize running full nodes by providing light servers for payment and then live clients can pay a bit and then they get the light server services the issue here is that the authentication mechanism they use is that their payment is associated with their node ID so take away their node ID and we just blew up the VIP node business model and this is I'm not saying that this is cannot be solved what I'm trying to say here is that these really trivial issues and trivial fixes can have very very heavy vacations on certain players in the network and often we as declined developers don't want to ruin people's days and people's projects anyway so that's the discovery it is an interesting interesting problem to solve now if we go further deep into the light clients then how do light clients work last I suppose we forget about discovery let's suppose we somehow fix discovery well that clients essentially they connect with full nodes full servers which actually have all the blocks and instead of downloading the blocks and processing them they are just randomly picking the block headers which are kind of is a nice enough proof that the chain is valid but they do not download the state and then when we start mist or any other deck that we really care about then the light client will actually fetch the balance for example if I have three accounts in mist then every time a new block arrives mist will actually fetch those balances for those three accounts I care about and again this seems like completely logical this is the most optimal way to reduce latency reduce bandwidth and just make all the traffic useful except now all of a sudden the light server knows that I am this IP address is interested in that particular account oh and one more I think I want to be the head so two more things that I wanted to say about how the light clients work so one of them was that they are obviously synchronizing header and then retrieving data on demand only interesting data another really interesting aspect of the light kind that I think apart from protocol developers most people are unaware of is that light clients cannot verify the state so they are verifying the proof of work but they blindly trust that so every time you get a new block you just assume if the proof of work is valid then whatever state that block is associated with will be valid and this works because if you have a good connectivity to the network and you have many people sending you blocks then it's really hard for somebody to forge a block because yet they could forge a block but the internet where the rest of the network won't accept it so after this after a few more blocks it will just get reeled out of your so nobody can really keep attacking you as long as your connectivity is valid so what happens yeah I went a bit previously with the head but essentially with the light clients and on-demand retrieval the issue is that whenever if I have missed connected and it every whenever I have an updated lock it keeps requesting the same balance for the same account over and over and over and over again the light servers will be able to create a statistically map out that this particular IP address is interested in one particular address and that's a problem because we got back to the exact same issue an exact same behavior that we had with the discovery protocol only now we don't have a map world map of moving IDs now we have a world map of moving etherium addresses and again similarly for the discovery protocol this can be done exactly the same way publicly by everyone it's a bit more expensive because you need to run a light server so at least you're having the network so please if you want to attack it and do this and not the other fund so how can how can we solve this and again it's a it's a hard question to answer because it's not it's kind of this is how the protocol was meant to be this is the optimization so we're trying to somehow obfuscate the optimization and one of them is again similarly to how we try to hide our IP address from ether scan or from centralized the restful services we can try to do the same thing and maybe run live clients of over tor but what happens if I have an embedded device so about two weeks ago no sorry two years ago you've already had raspberry pi zeros as live clients on may not somebody even had this little Intel and buy the chips put on may not and they were really happy that they could they can use the light client but these devices aren't really compatible with tours so tour has a huge overhead cryptographic overhead that's one problem the other problem is that if we start adding this these IP mixers into the soup and trying to just create trying to just tunnel light client traffic all over the place the issue is that you will have connectivity issues so again maybe you will find less peers maybe the latency will go up the bandwidth will go down you will keep dropping peers but the issue here is that as I said previously live clients depend on relatively good connectivity if you have a an application layer that essentially kills your connectivity then all of a sudden you kind of raise your vulnerability against these kinds of eclipsed attacks so again although it seems that there would be a simple enough solution in practice it's not so trivial so with that said I think this was the first talk that I did where I kind of raised more questions than talks and then solutions but I still I figured that I would like I would like to formulate a few takeaways for for you yes so that you don't don't leave with with the concept that ok theorem sucks and essentially the three things that I would really like to highlight as the summary of this talk is that although people don't feel like full notes full notes are actually the best anonymizer in a theorem ecosystem if you are running a full note then nobody knows what data you're interested in you can't poke in whatever contract you want you can check your balance as many times per second as you want and nobody from the outside will know that you're actually doing it secondly privacy on this theorem is bad really really bad and that but this doesn't mean that it's an impossible task to solve so there have been existing projects that it's two major ones the Tor network The Onion Routing Network I mean and I to pee and both these networks try to solve this exact problem of how to anonymize data so that you don't reveal too much about yourself now I'm not saying that we should all of a sudden put a theorem on top of these networks these networks have a very very broad scope and it might be too much but nonetheless there have been 20 years of research going going to how to do this properly so let's try to at least learn from their results and try to fix it and last but not least I've seen it many times in the community and I see it many times even with myself that as a developer it's all too easy to just say that well the users are doing it wrong and for example it would be nice to say that well just you store figure it out and that's a problem because most users don't know what tories and most users will probably never in their lives you store even though that would be the obvious solution and it's kind of up us up to us to as the app and platform developers to figure it out and to fix it and we don't really want to fix it to protect the users from not only from external attacks I think it's really important to also highlight that we want to protect users from ourselves too because I just give you a really nice example I don't think Facebook was created to gather user data it wasn't created to to abuse elections that one just kind of happened when there was too much so with that I conclude my talk so thank you very much and I guess we have a few possible questions a few minutes for questions if I may hasn't doesn't look like we have any hey could you talk more about helpful notes are the most powerful and atomizers and network with that takeaway so essentially all these metadata leaks as are possible because you are doing something in your optimizing your traffic in the network the only way to optimize your traffic is to request only data that interests you so every time you are only requesting data that interests you it means that the network itself knows that that particular data for some reason is interesting for that particular IP address and this thing you can completely hide the phone out because the FEU node essentially gets everything yes so that's an again another interesting question that while we are just reading the chain this completely solves it a fool node but when we are trying to transact with the chain then then if for example somebody manages if I'm let's say I run a thousand full nodes and I start monitoring where certain transactions are coming from then that can be used to eventually statistically hone in on a certain IP address that this IP address is usually originating some ID some transaction and here here my solution as I think for example ipfs is also looking into exactly the same problem and their solution or let's suppose their their ideas are all all revolve around the I to P protocol because it's essentially a message based protocol that does tries to somehow makes the transaction a bit in the network before popping it out somewhere and as far as I know Manero does the same thing for the same reasons so that's a that's possibly that's again something that many people before us did and people are doing concurrently with us so it's not an unsolvable research problem it's just an engineering problem that we have to pay attention to thanks for your thought it was really good I think probably most people in this room have done all the bad things that you mentioned throughout the talk so is there anything you recommend aside from running your full no to either like go forward or perhaps anonymize things with these services more yeah well I guess my recommendation I can only recommend what I already recommended within the within the slides that if you are running if you are accessing block Explorers I think browser extensions are the single most important thing if you if you are really paranoid then tor network is also an essential thing so that with with the Tor network you can completely protect yourself against Brau typical browser-based app that's from tracking you if you if you are actually willing to run a light client that's a hard problem that's up to the client developers will you recommend us like general rule to regularly clean out the node key so if as long as your server is stable the node key is fine I mean yes so if you are on the laptop I think that that would be the first no-brainer solution that we have to do is we have to keep every so for example if you run a light client every time you run a light client you we should reset the node because we should use a firmer latkes even even better I would suggest that maybe even four full nodes we can use it from our own node keys and just if we restart them yeah maybe it will have a bit harder time connecting to the network for the first couple minutes so I think apart from booth knows no nothing in the network really requires stable keys okay can we please another round of applause for Peter thank you very much [Applause] you