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!
