On 12/5/2015 6:30 PM, Michael English wrote:
> My main goal with the documentation is informing users of the
> vulnerabilities of Electrum in Tails to promote secure practices.
>
> I don't think that Bitcoin should be installed in Tails in the
> first place for the following reasons: Bitcoin is unstable
> software/protocol Tails runs off of memory We have to trust a
> remote server Tor traffic can be manipulated
>
> Would you log in to your bank over Tor even if it was encrypted
> with SSL? Money can't be stolen with Electrum, but the SPV
> verification can cause servers to withhold information from their
> clients leading to an incorrect balance.
>
Yes, I would log in to my bank over Tor if it's encrypted with SSL. I
login into my email accounts and service provider accounts using SSL
and sometimes where possible two factor authentication.
If you don't want to include Bitcoin in Tails, that's ok, I am not
qualified to decide this, but your arguments are not convincing at all.
1. Bitcoin is not unstable, in fact it is quite solid. Every change /
improvement was applied with the highest ethical and security
standards and was carried out with no unwanted events. From my point
of view it is only as unstable as any "under constant development and
improvement" software/protocol. Somethings get fixed, somethings get
improved, etc. Just like Tor - that's not unstable, right? It's the
core of Tails and most important part in it.
2. You do not have to trust _a_ remote server. More the proof of work
in the bitcoin network, which is how bitcoin works anyway. So far it
has done a fine job securing about 4 billion USD of market
capitalization (estimated).
3. Tor traffic can be manipulated - this requires more context as I am
not sure what you mean, but it sounds like it affects Tails entirely,
not just Bitcoin. The "Bitcoin over Tor is not a good idea" document
is proven not to be 100% accurate and also it's related to the p2p
design and the peer-banning mechanism used by full nodes running
Bitcoin Core. Unrelated to Electrum. There's no sense going through
the arguments again.
The second part is correct, a server can in theory withhold
information from the client/user, it is just a limitation of the SPV
protocol. But Electrum checks the headers with other servers also,
users doesn't just blindly trust the server he is connected to.
So for such an attack to work, the attacker would have to:
a) make sure the user (victim) connects to his malicious server;
b) isolate the user from all the other non-malicious electrum servers.
This is kind of hard to do, because Electrum will not proceed in this
case. Servers are p2p advertised, and some trusted ones (run by wallet
developers) are hardcoded, which means one cannot Sybil, an user will
always get at least 1 honest server to connect to and verify the block
headers. It will detect this and disconnect from that server, or not
proceed at all if it cannot verify this for itself with other servers.
So the attacker is left with:
c) make sure the user (victim) connects to his malicious server and
make sure the other servers randomly selected by that user for header
verification are also his and lie along with the master malicious server.
I do take security _very_ seriously, but you have to admit that the
scenario above is *very* hard to pull off and *very* expensive.
> Until we can get the prefnet=tor option, I would like to recommend
> that the user manually selects a trusted onion server in place of
> the SPV documentation to protect against an out-of-date bitcoin
> balance. Then, the user would have a strongly encrypted connection
> exchanging accurate information about the bitcoin network.
>
prefnet=tor will take some time, a lot of things need to be changed
for that. We have to leave it aside for the time being.
How would an user get a trusted onion server? He will select based on
what criteria? Who decides which servers are trusted or not? There's
no better mechanism here rather than connecting to other servers as
well and verifying yourself - this is already done by Electrum with no
user action required.
Why do you think a .onion server is better than a clearnet server? Why
doesn't the user select a trusted clearnet server? If Tor traffic can
be manipulated, it also affects hidden services as well as exit
circuits. If the server is malicious, it can be malicious even if
accessed over clearnet or hidden service, it's not relevant. Why do
you think a .onion server is a major fix? From my point of view it
only makes better use of resources in the network, that we don't have
to put load on the exit nodes, but this is not a problem otherwise. To
be frank I don't see huge security benefits. I would like to use only
.onion servers for the reason stated, but by no means this should be a
blocker for us upgrading electrum in Tails and allowing our user base
to use a wallet which includes security fixes and signs valid
transactions, as opposite to 1.9.8.
Even if you connect to a clearnet server, or hidden service server,
you are still anonymous because you are behind Tor. So the server will
either see the exit node IP address either 127.0.0.1. Good in both
cases. So, I don't see a major issue from anonymity point of view also
in this context.
> Also, we should include the change of default base unit and link
> to https://en.bitcoin.it/wiki/Units .
>
This can be changed with just a setting in the config file, if you
would like so (If you refer to the client gui).
If you refer to the documentation, of course, we should include the
change of default base unit, an explanation about mBTC / BTC ratio and
a link to the units.
> I have a few small grammar edits and clarifications to the first
> few lines of the existing documentation: Remove comma after
> passphrase, put a comma after seed, and change so to lowercase.
> Also, change the period after blockchain to a comma and change the
> so to lowercase again. Add “for extra security” after “offline
> working session.”
>
> If you disagree, please tell me what specific information should
> be written instead.
>
I agree with this. You know better how the documentation should look
like. My older email with documentation suggestion was indeed too
specific and probably too much information, unrelated to Tails. Maybe
there are some parts from that email which we can include after all? A
little education doesn't hurt, probably we have users using bitcoin
for the first time.
