Re: [Tails-dev] Update Electrum documentation for Tails 1.8 …

Supprimer ce message

Répondre à ce message
Auteur: Michael English
Date:  
À: s7r, The Tails public development discussion list
Sujet: Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
You have thoroughly criticized my documentation to help users secure
Electrum in Tails. I ask you again what would you change in the current
documentation where it warns about SPV. Would you remove it entirely,
replace it, or add something on to the end? What specific wording would
you use?

s7r:
>
> 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.
>
>