Hi, intrigeri wrote: > Hi, > > first, thanks a lot to everyone who contributed to this thread! > > s7r: >> mithrandi is of course interested into continuing to maintain Electrum >> in Debian and will do so, but we should find other people also to work >> as a team so he doesn't become the single point of failure, like it >> happened this time. > > Sounds good. I'm elaborating on this below (option B). > >> Unfortunately, I personally don't know how to do it >> all by myself, but I'm willing to help with monetary payments for the >> hours spent on this as well as donate testing infrastructure. > > This is good to know. If we go this way in the end, I think we'll > greatly appreciate any kind of support you can provide :) > > I've just had a meeting with 2 of my Foundations Team colleagues > (hefee & segfault), aiming at providing input regarding the available > options, guidance regarding the next steps, and information regarding > what the Tails Foundations Team feels we could do on our side. > Only the first two options below (A and B) seem doable. > > Option A: use a trusted onion server and keep 3.1.3-1~bpo9+1 for now > ==================================================================== > > If that's sufficient to fix the most critical issues on the short > term, then we need to know: > > - Are there such servers available? Are they reliable enough > for Tails? What configuration change do we need to do to use them?
I run 2 (two) .onion servers, accessible via v3 onion hostnames (new generation onion services). They run on own hardware and have plenty of resources and bandwidth so, they should be reliable. But the situation gets complicated because the servers can be abused (DOSed) by clients at application level (ask expensive historic data for addresses that consume high CPU and disk I/O resources) and make the server unavailable. This is unrelated to bandwidth, I have 10 gbps for example, but the bandwidth limits of the servers are not hit by the attacker, simply subscribes some addresses that do not break the threshold limit but produce expensive CPU and I/O disk operations, then disconnect and connect immediately asking again. This leads to CPU usage 200% - 300% (on a single core of course, but it's python you know). Doesn't help no matter how many cores you have on the server. Actually at this moment ALL servers on the default list shipped by Electrum (including mine) are severely DOSed. They tried to DoS them by bandwidth but the ones on stable and high speed connections did not die, so it lead to this second attack that is an application level attack where CPU and disk I/O is saturated, so all (if not all really most of) public servers are DOSed and being inaccessible for clients. We are working on something, but it won't help our threat model (Tor) where we see all the requests coming from 127.0.0.1: https://github.com/kyuupichan/electrumx/pull/785 (see my comments as well regarding .onion servers) This is a huge problem at the moment for Electrum. This is happening since it was decided to cut off clients earlier than 3.3 which are vulnerable to the phishing message rich text display. In order to use a particular server in Tails by default, we should add it in the default config file located in ~/.electrum and also set oneserver": true, in the same config file. There is a downside for this: Electrum connects to other 10 random servers to verify headers of blockchain so it knows at what height the network is, so the server cannot lie to the client about height and also about particular transactions. If we decide to do this, it means users MUST have a higher level of trust in this server, rather than any public Electrum server. To clarify, the server cannot spend users funds, cannot steal coins but can censor transactions (discard them instead of broadcasting to the bitcoin network), keep clients behind at a lower height (do not update and notify clients with new blocks), hide incoming unconfirmed transactions for clients or show incoming unconfirmed transaction to clients that is not broadcasted to the rest of the network and might never get mined / confirmed. These are not critical and direct attacks, but are VERY serious, so, if we choose this option we should only do it if one (or more) of us are the ones and only controlling the server. > > I'm not sure I understood this comment right: > https://redmine.tails.boum.org/code/issues/16564#note-10 What I wanted to say here is that, ElectrumX server implementation version 1.10 cuts off clients earlier than 3.3. I did not upgrade just yet and continue to run 1.9.5 version on my servers, which uses the blacklist method (does not announce malicious server peers to clients) but does not disconnect clients earlier than 3.3, instead it just warns them that they are running and out of date version and they should upgrade. To make this less annoying, I can modify the code and patch to not print this warning, but I didn't do this until now nor planning to do it unless we find it really useful. > > - How much do we need to trust this server? (Ideally, we need > pointers to some authoritative document, rather than claims made by > the very person who runs this server :) > See above about trust of the server. I have briefly explained all aspects in simple terms understandable for anyone, not only people developing cryptocurrencies. What the server can do: - hide an incoming unconfirmed transaction; - hide the real height (keep the client behind at a lower height by not publishing new blocks); - censor client transactions by not broadcasting them further to the bitcoin network; - display a "dummy" incoming unconfirmed transaction that is not broadcasted to the rest of the bitcoin network, thus making it impossible to be included in a block by a miner (confirmed). All attacks described above imply a _targeted_ victim, and not just any victim, which is pretty hard to do in Tails without other side channel attack because all Tails clients look the same to the server (127.0.0.1) -- the problem is if the attacker owns the server and also knows victim's wallet / pool of addresses and what they are going to do. What the server can't do: - steal client funds; - modify recipient of funds (payee); - alter transactions in any way (other than censoring them entirely); So, the server cannot be any server as you can see. Those attacks are mitigated under a normal Electrum by having it connect to other, 10 random servers and get headers from them to verify height, etc. I hope to saved some time and effort for whoever is reading this, but here are some authoritative documents: http://docs.electrum.org/en/latest/protocol.html http://docs.electrum.org/en/latest/faq.html#does-electrum-trust-servers http://docs.electrum.org/en/latest/spv.html#spv To be frank, I don't know what will happen after this application level DOS attack where servers are becoming inaccessible because we allow free and anonymous clients. It might lead to changes where users will need to subscribe and get some credentials to access the server, so we can identify and cut off whoever is doing the abuse. If it comes to this, we will have the only option to run a good Tails server that will require subscription fees and forward everything to the foundation. This is another problem on top of the client version problem we have :(. > Option B: find co-maintainers for the Debian package > ==================================================== > > We have the skills at Tails to become co-maintainers but if there's > a way to find some other co-maintainers, it would be sweet. Ideally we > would not have to be part of it but worst case we can, at least for > a while. > > s7r, how about you ask the Debian Cryptocoin Team¹ if they want to > co-maintain Electrum with mithrandi and/or with some Tails folks, > under the umbrella of their team? > > [1] > https://qa.debian.org/developer.php?email=team%2Bcryptocoin%40tracker.debian.org I have sent some emails, but I have to admit I didn't have time to stay quite on top of this. I plan to further discuss it and look for solutions. > > If needed, there's now a formal package salvaging process in Debian: > https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#package-salvaging > > For Tails 3.x, if fetching the package from sid or experimental > doesn't work, it would be OK to ship a custom, Tails-only backport > from whatever is in sid or experimental. But for Tails 4.0 (Buster) we > would prefer shipping a package that's in buster-backports. > mithrandi told me that he will get it in buster-backports, but no time to get it in buster. So, I hope soon we'll be ok with this. > The FT would be ready to help s7r with maintaining the integration of > Electrum into Tails, if needed. > > If we go this way, we would try this out for a while and invest as > little as possible into it, e.g. we would not bother about the > optional dependencies if they are not readily installable. Then, 6-12 > months later, we would re-evaluate to check how much of our resources > this work takes, and Tails as a project can make a strategic decision > wrt. whether we should keep doing this work or focus our limited > resources elsewhere. Sounds good, thanks for this and thanks to the entire FT for taking this into discussion. As you can see I try by myself to solve as much as I can, to avoid having the FT spending their limited resources. I thought I could keep things out of control by spending my own time, resources and money for this purpose but unfortunately things happened so fast now that I couldn't keep up (maintainer delay, phishing attack, server update to cut off older clients, now server DOS attack). > > Option C: remove Electrum > ========================= > > This would be sad. We would like to evaluate options A and B first. > > Doing a poll to learn how much people use Electrum in Tails might help > us better understand what the impact of this option would be. I don't even want to comment on this option. Even if we have to run our own subscription based server, we should still not remove. There are many projects relying on it, I know a news agency from a really aggressive regime country whom I helped get some obfs4 bridges - all their team uses Tails and all their funding is in BTC... > > Option D: AppImage > ================== > > segfault and I have documented on this thread and on #16564 various > reasons why we think it's not an acceptable option for Tails at the > moment, and could easily require more work from all affected parties > than option B. I endorse all the downsides described on the thread and think it's not an acceptable solution for Tails, at least not at this moment, and Option B is by far better and does not alter Tails trust chain and pattern. Thanks!
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tails-dev mailing list [email protected] https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
