Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
s7r: > I have reviewed the branch - very nice work; plain and simple. From my > point of view it's perfect, explicit and also in reasonable length. Cool, I'm glad you both like it! > I just have one single addition to make sure we avoid confusion and > panic among the less techy users. Only if you are fine with this > addition also, it's not something critical (maybe I'm just trying to > be too explicit). > > Replace: > +Do not blindly trust the bitcoin balance that class="application">Electrum displays. > +Wait for transactions to be confirmed. > > With: > +Do not blindly trust the bitcoin balance that class="application">Electrum displays as *unconfirmed*. > +Wait for transactions to be confirmed. Good idea. I'll do this and merge the branch soon. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
Michael English: > Yes, waiting for block confirmations is an easier way to protect against > an out-of-date bitcoin balance than manually connecting to a trusted > onion server. I still hold my opinion that the Electrum networking > settings are the best way to protect against DoS, but it unnecessarily > complicated for little risk. I actually recommended that we document > block confirmations in March of this year when we first installed > Electrum in Tails: > “For my documentation, I already explained the concept of a > double-spending attack to you. In the case of the Electrum DoS attack, > the double-spend would be a 0 confirmation transaction. The solution is > to wait for block confirmations to make sure that you actually have the > money. Remember: 'An SPV node cannot be persuaded that a transaction > exists in a block when the transaction does not in fact exist. The SPV > node establishes the existence of a transaction in a block by > requesting a merkle path proof and by validating the proof of work in > the chain of blocks.'” I think I remember this from March. But at that time I didn't know that Electrum presented you clearly transactions as unconfirmed or confirmed. I'm not using Electrum myself, so in this case I need a lot of insight and guidance as I can't really figure out things myself. Thanks for your help, and I'm glad we made it in the end! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello I have reviewed the branch - very nice work; plain and simple. From my point of view it's perfect, explicit and also in reasonable length. I just have one single addition to make sure we avoid confusion and panic among the less techy users. Only if you are fine with this addition also, it's not something critical (maybe I'm just trying to be too explicit). Replace: +Do not blindly trust the bitcoin balance that Electrum displays. +Wait for transactions to be confirmed. With: +Do not blindly trust the bitcoin balance that Electrum displays as *unconfirmed*. +Wait for transactions to be confirmed. Thanks for taking care of this sajolida and happy I could help in getting Electrum tuned upstream to work better in Tails. On 12/21/2015 12:27 PM, sajolida wrote: > I worked on an update to the current documentation in branch > doc/9713-electrum-2.5. I tried to combined everybody's input while > sticking to the minimum as per our guidelines. > > I'm sorry I won't reply inline to the different topics raised in > this thread, but here is a summary: > > 1. Give more emphasis on external backup of the seed in addition > to using persistence, as suggested by s7r. 2. Apply the grammar > fixes and phrasings suggested by Michael. 3. Make the warning about > SPV less scary and more useful by focusing on transaction > confirmation. I was quite convinced by the details provided by s7r > but tell me if I misinterpreted something. 4. Add a tip about > mBTC. > > I didn't include s7r's suggestion to explain better what an > Electrum server is, what it can do and what it cannot do. I think > this is out of the scope in the Tails doc, while it clearly fits > better in the upstream doc. I understand that some of your points > were specific to Tails, but still, I think we found a configuration > in Tails that doesn't make the security discussion radically > different than outside of Tails (which was the goal). If we think > this discussion about the Tails context is worth been written > somewhere it should be done in our design documentation. But > honestly, I feel very lazy to do this and I'm not sure it's worth > it. > > Tell me what you think or if I missed anything. And thanks for > your patience and for doing the research and discussion without > me. > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJWeXiDAAoJEIN/pSyBJlsRdW0H/1Z9OQna7ck+Rmw+N76zq6Io FZY8aQ2GRZymD2oGbzQx5RNGevl8xCLVzZyYeukq11C6sHsx3Kr85r4edrpDqYPY MJrOHjB4tFB7PIBbeDD44KG3+ODEEhluMMdjdjnAWmzdQGd6/LDntkbtksJd0e4O bqjY1ZFEQpl/3RanKkzHezAySA6ErniUT6Ef4Nvmwn/yNiH6fMM1eNVdYgC/O+Lk /naqKPDvqNO3XjHg38BwETx+V4FaT7aWiUZLd9rimoryQct9ethuKZnzlhaVGS7O PYewy4g690JmPuTufPd5NN8aoKcK3pF5YwiyVHfw4bliUxDVzyKzZygDisHlt94= =0vG3 -END PGP SIGNATURE- ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
I worked on an update to the current documentation in branch doc/9713-electrum-2.5. I tried to combined everybody's input while sticking to the minimum as per our guidelines. I'm sorry I won't reply inline to the different topics raised in this thread, but here is a summary: 1. Give more emphasis on external backup of the seed in addition to using persistence, as suggested by s7r. 2. Apply the grammar fixes and phrasings suggested by Michael. 3. Make the warning about SPV less scary and more useful by focusing on transaction confirmation. I was quite convinced by the details provided by s7r but tell me if I misinterpreted something. 4. Add a tip about mBTC. I didn't include s7r's suggestion to explain better what an Electrum server is, what it can do and what it cannot do. I think this is out of the scope in the Tails doc, while it clearly fits better in the upstream doc. I understand that some of your points were specific to Tails, but still, I think we found a configuration in Tails that doesn't make the security discussion radically different than outside of Tails (which was the goal). If we think this discussion about the Tails context is worth been written somewhere it should be done in our design documentation. But honestly, I feel very lazy to do this and I'm not sure it's worth it. Tell me what you think or if I missed anything. And thanks for your patience and for doing the research and discussion without me. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
Yes, waiting for block confirmations is an easier way to protect against an out-of-date bitcoin balance than manually connecting to a trusted onion server. I still hold my opinion that the Electrum networking settings are the best way to protect against DoS, but it unnecessarily complicated for little risk. I actually recommended that we document block confirmations in March of this year when we first installed Electrum in Tails: “For my documentation, I already explained the concept of a double-spending attack to you. In the case of the Electrum DoS attack, the double-spend would be a 0 confirmation transaction. The solution is to wait for block confirmations to make sure that you actually have the money. Remember: 'An SPV node cannot be persuaded that a transaction exists in a block when the transaction does not in fact exist. The SPV node establishes the existence of a transaction in a block by requesting a merkle path proof and by validating the proof of work in the chain of blocks.'” If we make the documentation too long, users might not actually read it. Also, Tails purpose is to provide a secure operating system and not to provide a complete security guide. I completely agree with focusing on documentation that is specific to Tails and then linking elsewhere for more information. Otherwise, we would have imbalanced priorities. Cheers, Michael English sajolida: > I worked on an update to the current documentation in branch > doc/9713-electrum-2.5. I tried to combined everybody's input while > sticking to the minimum as per our guidelines. > > I'm sorry I won't reply inline to the different topics raised in this > thread, but here is a summary: > > 1. Give more emphasis on external backup of the seed in addition to > using persistence, as suggested by s7r. > 2. Apply the grammar fixes and phrasings suggested by Michael. > 3. Make the warning about SPV less scary and more useful by focusing on > transaction confirmation. I was quite convinced by the details provided > by s7r but tell me if I misinterpreted something. > 4. Add a tip about mBTC. > > I didn't include s7r's suggestion to explain better what an Electrum > server is, what it can do and what it cannot do. I think this is out of > the scope in the Tails doc, while it clearly fits better in the upstream > doc. I understand that some of your points were specific to Tails, but > still, I think we found a configuration in Tails that doesn't make the > security discussion radically different than outside of Tails (which was > the goal). If we think this discussion about the Tails context is worth > been written somewhere it should be done in our design documentation. > But honestly, I feel very lazy to do this and I'm not sure it's worth it. > > Tell me what you think or if I missed anything. And thanks for your > patience and for doing the research and discussion without me. > ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
Michael English: > My main goal with the documentation is informing users of the > vulnerabilities of Electrum in Tails to promote secure practices. Hi Michael, thanks a lot for moving this forward. I'm swamped with tons of other things right now, and since the upgrade to 2.5.x is still a work in process (#9713) I'll look at your work later on when I have more time... ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/5/2015 10:38 PM, Michael English wrote: > 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? > Didn't mean to criticize anything, but saw you are considering everything way more vulnerable and risky than it really is and only provided more information, which you can of course verify for yourself as well as anyone reading this list. The already existent warning about SPV which is now included in the documentation is fine. There is a link with a description about the weaknesses of SPV on an official page. I would include the fact that an user should ignore unconfirmed payments until they are confirmed, that's all, but I am not totally sure if this is really necessary given the fact that Electrum already displays the unconfirmed balances separately from the confirmed ones which makes it obvious. Example: Balance: 2.4221 BTC [+1.24864 unconfirmed] "In SPV mode, a good practice is to consider received payments as clear after they are confirmed." -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJWY3spAAoJEIN/pSyBJlsR+fkH/RSVhUNXAu+SC42S3S2cwVQv E+4894prRYfKd+s87Niyur0H3enda0TzwWZi9aUZbzlyo0T+DNPsZjx9TF7m3hGJ udzRWT5yZ6SPGxzDX2DgdeBy+MKrEClzZvZjxIo3XF4WWqGuxQdECYQyFUwXrv3a 9GKfX0oigCloM5Eo4havsTbNRIHFop2ZiZZ6pPQxbU0Vmxonz87jM8c9T55X2a4E dVvkUYuEA3/f1Xnmry0hrhQTccHOT2+9yMhNzC4UeKKU7qTDfxJ+fFxweiyr/550 T73PEMTPkJ+/y1i0Z3B7PUydgofauxD5zCi6ivesJdqZUVrTUxOaBH0SJqGs6IU= =EPIA -END PGP SIGNATURE- ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
Sajolida, s7r thinks that the SPV documentation that I wrote earlier should not be changed. You had stated at one point that you did not want to document the change of default base unit. Could you state your current opinions based on the conversation so far? Perhaps you could add the small non-controversial changes that I listed at the bottom of my previous email until we can come to a consensus about the other proposals. Cheers, Michael English Michael English: > 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. > > 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. > > Also, we should include the change of default base unit and link to > https://en.bitcoin.it/wiki/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. > > Cheers, > Michael English > ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
s7r, Please see my replies that follow. >> The main debate is over the DoS documentation. This is a good >> summary by anonym of a worst case scenario: “Thanks to SPV, the >> server can spoof the wallet balance. Hence the server operator can >> scam Tails users, e.g. s/he can buy stuff from a Tails user, and >> then bump their balance with that exact amount so it looks like >> they've received payment.” >> > > I don't exactly understand what you mean when you say DoS and not sure > what would you like to include in the documentation. Obviously an user > shouldn't trust an unconfirmed transaction, but this recommendation > usually goes for full wallets as well not only SPV. This is already > written everywhere and that's why Electrum shows the unconfirmed > balance separately. Full wallets do not suffer from the same vulnerabilities of SPV. I am used to using Bitcoin in the most decentralized way, so, when I see an SPV client using centralized servers run by strangers, I become nervous especially when it is over Tor. That is a bad combination shown in the example of “Bitcoin over Tor is not a good idea.” Security is not black and white. There is a probability of risk that is assessed based on the environment that the software is in. Perhaps I am too paranoid and you are too confident. I hope that we can find a middle ground. > >> I strongly disagree. DoS should be mentioned as it has a >> possibility (although unlikely) to have a devastating effect on >> Tails users. > > How exactly? Can you explain me detailed where you think the DoS risk > is? Again, the linked research paper has nothing to do with Electrum. > The fact that an electrum server runs on top of bitcoin core which is > mentioned in that research paper cannot be taken into consideration > (how do we even know if the bitcoin core running on the electrum > server we are connected to uses Tor for its peer to peer connections > with other nodes). > > The problem here is that I don't know how you define DoS in this > context. From my point of view an Electrum Server lying about an > unconfirmed balance until first block is mined cannot be called DoS. > (Also, in this case, the server has to OWN the coins apparently spent > and target a certain user which is behind Tor (so anonymous) which is > highly unlikely.). The first mined block could never reach the client essentially putting the user offline. Yes, it is unlikely, but this is Tails where we take security seriously. >>> - An Electrum server could not broadcast an outgoing transaction >>> (payment) sent by you; >> I'm not sure what you mean by this. > > When you send a transaction from Electrum, it's sent do the Electrum > server to which you are connected. The server automatically feeds it > to bitcoin core via cli command which broadcasts it to the peers (and > into the network). The Electrum server could skip this step and drop > your transaction, never send it to the network. Wouldn't this be proof of DoS? ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
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. 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. Also, we should include the change of default base unit and link to https://en.bitcoin.it/wiki/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. Cheers, Michael English ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
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
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/24/2015 9:00 PM, Michael English wrote: > Sajolida: > > “If I understand correctly, the main issue here is about the > *change* (and not about the behavior itself), then this should be > mentioned most of all in the release notes. If you think that the > behavior itself might be confusing, then I guess that this should > be solved upstream (in their documentation or the software > directly).” S7r and I disagree. Simply noting the change of default > base unit could have a big impact in avoiding confusion. > > “If they have to perform a specific action, then this should be > documented. If they don't have to perform a specific action, then > maybe we need to adapt the current warning about 'Do not blindly > trust the bitcoin balance'.” Yes, they do have to perform a > specific action to select the onion Electrum server at the moment. > Why do you think it's mandatory to use an .onion server with Electrum in Tails? All these were not a problem until now in 1.9.8 and it worked in Tails very good. 2.5.4 is not that different. > s7r: > > The mistake that you are making is being too specific with your > documentation proposal. Please see the Tails documentation > contributors page: > https://tails.boum.org/contribute/how/documentation/ . I also > proposed specific documentation like yours here: > https://mailman.boum.org/pipermail/tails-dev/2015-March/008302.html > and found out that it belonged in the Electrum wiki instead of > Tails. > Ok sorry my mistake - I wasn't aware of the Tails documentation guidelines. I basically included as much as I could so you can select only what's necessary and knife the rest. > The main debate is over the DoS documentation. This is a good > summary by anonym of a worst case scenario: “Thanks to SPV, the > server can spoof the wallet balance. Hence the server operator can > scam Tails users, e.g. s/he can buy stuff from a Tails user, and > then bump their balance with that exact amount so it looks like > they've received payment.” > I don't exactly understand what you mean when you say DoS and not sure what would you like to include in the documentation. Obviously an user shouldn't trust an unconfirmed transaction, but this recommendation usually goes for full wallets as well not only SPV. This is already written everywhere and that's why Electrum shows the unconfirmed balance separately. > The DoS problem is difficult to solve. The best solution would be > for Tails to sponsor its own onion Electrum server. > I don't like this too much, making a decentralized service partially centralized, but I also don't oppose it until we fix upstream the auto-connect synchronization issue reported by anonym. I am already on it but don't know how much time it'll take - hopefully not too much. > Documenting what an Electrum server is is completely off topic for > the Tails documentation. OK. Thought it's important for user to know what an Electrum server can or cannot do. > I strongly disagree. DoS should be mentioned as it has a > possibility (although unlikely) to have a devastating effect on > Tails users. How exactly? Can you explain me detailed where you think the DoS risk is? Again, the linked research paper has nothing to do with Electrum. The fact that an electrum server runs on top of bitcoin core which is mentioned in that research paper cannot be taken into consideration (how do we even know if the bitcoin core running on the electrum server we are connected to uses Tor for its peer to peer connections with other nodes). The problem here is that I don't know how you define DoS in this context. From my point of view an Electrum Server lying about an unconfirmed balance until first block is mined cannot be called DoS. (Also, in this case, the server has to OWN the coins apparently spent and target a certain user which is behind Tor (so anonymous) which is highly unlikely.). >> There's no current setting for this, but I made a note for this. >> Some option like prefernet=tor. > Good idea. You should propose this feature to Github > https://github.com/spesmilo/electrum so that it can be included in > Tails in the future. Will do. Noted it down. > I absolutely agree. This is the best long-term solution although > it requires cost in hosting and maintenance. Your server should not > be trusted unless merged into Tails developers' exclusive control. I completely agree. If you arrange for a server and need help in setting it up or maintaining it and you think I could help do let me know. >> - An Electrum server could not broadcast an outgoing transaction >> (payment) sent by you; > I'm not sure what you mean by this. When you send a transaction from Electrum, it's sent do the Electrum server to which you are connected. The server automatically feeds it to bitcoin core via cli command which broadcasts it to the peers (and into the network). The Electrum server could skip this step and drop your
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Sajolida, Michael, See inline. On 11/22/2015 2:00 PM, sajolida wrote: > Michael English: >> Sajolida, please forward this message to s7r. > > Done. > Thanks! >> s7r, >> >> If you do not have any specific ideas for updating the Electrum >> documentation, I volunteer to take the lead. Otherwise, you can >> draft an updated version of the documentation and I can update >> where necessary. The goal is to document Electrum specifically >> for Tails and not duplicate the existing Electrum wiki. > > Thanks for the offer. > >> Most of the updates like wallet format happen automatically in >> the background, so they do not need to be documented. I only >> recommend making two additions. >> >> The most obvious change to the user when updating Electrum >> versions is that the default base unit changes which can be >> confusing. No, I do not think that we should manually change the >> default base unit with a config file. That decision should be >> made upstream. However, users should be aware that the appearance >> of their Bitcoin balances changes especially when sending >> Bitcoins. > Right, the current page is pretty good: https://tails.boum.org/doc/anonymous_internet/electrum/index.en.html I will include few more additions, especially to highlight how important the seed is and that is also important to have it backed up even in case you use a persistent Tails install (since that particular install can break or etc.). mBTC as default unit should of course be explained. I also want to include some answered questions about what an Electrum server is, what it can do and what it cannot do. >> DoS refers to the SPV vulnerability of servers withholding >> information from their clients leading to an incorrect balance. >> Connecting to a trusted .onion server protects against DoS. Yes, >> it is not a bug, but it is a well-known limitation of SPV that is >> specifically relevant for Tor users. Pleas read “Bitcoin over Tor >> is not a good idea” http://arxiv.org/pdf/1410.6079.pdf . > This is unrelated to electrum. It applies to Bitcoin Core (the software implementing bitcoin protocol - full nodes). Bitcoin core has a peer-ban-score, where the ban score of a peer (remote server that you are connected to) increases if that peers feeds you trash data or tries to DoS you. The attack described in that paper takes advantage of the scarce exit power in the Tor network (~1000 IP addresses) and speaks from the point of view where an attacker runs few Tor exit nodes that allow bitcoin exit traffic, and then uses the other exits to feed enormous amount of trash data to the bitcoin network, hoping the majority of bitcoin nodes will ban the other exits which are not under the control of the attacker. Then, you can only connect to a bitcoin peer via Tor using one of attacker's exit nodes. Hope this explains - it's just a summary. Electrum servers don't have such banning mechanism, they only have limits of requests per wallet and per address (100/1). So, I think it's not worth it to confuse the users and make reference to this anywhere. >>> - How would people "manually select a trusted .onion server"? We shouldn't recommend a particular .onion server. I host some and we could make it the initial default one, but then the user should be free to select any server (.onion or not). Also, to ensure a high quality service and total reliability for Tails users, I would be happier if I could provide a SSD server for this purpose. >>> - Where can people find "a trusted .onion server"? Exactly. People should only trust the server list in Preferences -> Network because those are servers which are advertised and their utxo set hash is checked. If one of them has a broken database or database not matching the other servers it'll get banned. >>> - How should our current warning about SPV be adapted? See below. > > - Would it be possible to configure Electrum in Tails to use the > existing onion servers on top of the usual servers? instead of the > usual servers? There's no current setting for this, but I made a note for this. Some option like prefernet=tor. > - In that case, do we need to trust them all? - What happens if > some of them go down? I am not sure I understand the q. We can provide one .onion server for when connecting for the first time. After that the user can change if they want. It would be nice if we could attract some funding for this and have a SSD server for this (normal hard disks are slower for leveldb). My server is: 3ffk7iumtx3cegbi.onion but it's not SSD :( from time to time lags for 2-3 seconds, but reliable (99% uptime). == Here are my proposed additions to the doc. page. Feel free to add/remove/rephrase where you think it's needed: 1. Define 'seed', after first line: "- Your wallet can be recovered [...]". Add these lines: - - The seed is the string of words generated by Electrum when
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
Sajolida: “If I understand correctly, the main issue here is about the *change* (and not about the behavior itself), then this should be mentioned most of all in the release notes. If you think that the behavior itself might be confusing, then I guess that this should be solved upstream (in their documentation or the software directly).” S7r and I disagree. Simply noting the change of default base unit could have a big impact in avoiding confusion. “If they have to perform a specific action, then this should be documented. If they don't have to perform a specific action, then maybe we need to adapt the current warning about 'Do not blindly trust the bitcoin balance'.” Yes, they do have to perform a specific action to select the onion Electrum server at the moment. s7r: The mistake that you are making is being too specific with your documentation proposal. Please see the Tails documentation contributors page: https://tails.boum.org/contribute/how/documentation/ . I also proposed specific documentation like yours here: https://mailman.boum.org/pipermail/tails-dev/2015-March/008302.html and found out that it belonged in the Electrum wiki instead of Tails. The main debate is over the DoS documentation. This is a good summary by anonym of a worst case scenario: “Thanks to SPV, the server can spoof the wallet balance. Hence the server operator can scam Tails users, e.g. s/he can buy stuff from a Tails user, and then bump their balance with that exact amount so it looks like they've received payment.” The DoS problem is difficult to solve. The best solution would be for Tails to sponsor its own onion Electrum server. Please see my inline replies that follow. > Hello Sajolida, Michael, > > See inline. > > On 11/22/2015 2:00 PM, sajolida wrote: >> Michael English: >>> Sajolida, please forward this message to s7r. > >> Done. > > > Thanks! > >>> s7r, >>> >>> If you do not have any specific ideas for updating the Electrum >>> documentation, I volunteer to take the lead. Otherwise, you can >>> draft an updated version of the documentation and I can update >>> where necessary. The goal is to document Electrum specifically >>> for Tails and not duplicate the existing Electrum wiki. > >> Thanks for the offer. > >>> Most of the updates like wallet format happen automatically in >>> the background, so they do not need to be documented. I only >>> recommend making two additions. >>> >>> The most obvious change to the user when updating Electrum >>> versions is that the default base unit changes which can be >>> confusing. No, I do not think that we should manually change the >>> default base unit with a config file. That decision should be >>> made upstream. However, users should be aware that the appearance >>> of their Bitcoin balances changes especially when sending >>> Bitcoins. > > > Right, the current page is pretty good: > https://tails.boum.org/doc/anonymous_internet/electrum/index.en.html > > I will include few more additions, especially to highlight how > important the seed is and that is also important to have it backed up > even in case you use a persistent Tails install (since that particular > install can break or etc.). You should link to existing documentation if it is general knowledge that is not specific to the Tails configuration. > > mBTC as default unit should of course be explained. I also want to > include some answered questions about what an Electrum server is, what > it can do and what it cannot do. Documenting what an Electrum server is is completely off topic for the Tails documentation. > >>> DoS refers to the SPV vulnerability of servers withholding >>> information from their clients leading to an incorrect balance. >>> Connecting to a trusted .onion server protects against DoS. Yes, >>> it is not a bug, but it is a well-known limitation of SPV that is >>> specifically relevant for Tor users. Pleas read “Bitcoin over Tor >>> is not a good idea” http://arxiv.org/pdf/1410.6079.pdf . > > > This is unrelated to electrum. It applies to Bitcoin Core (the > software implementing bitcoin protocol - full nodes). Bitcoin core has > a peer-ban-score, where the ban score of a peer (remote server that > you are connected to) increases if that peers feeds you trash data or > tries to DoS you. > > The attack described in that paper takes advantage of the scarce exit > power in the Tor network (~1000 IP addresses) and speaks from the > point of view where an attacker runs few Tor exit nodes that allow > bitcoin exit traffic, and then uses the other exits to feed enormous > amount of trash data to the bitcoin network, hoping the majority of > bitcoin nodes will ban the other exits which are not under the control > of the attacker. Then, you can only connect to a bitcoin peer via Tor > using one of attacker's exit nodes. Hope this explains - it's just a > summary. > > Electrum servers don't have such banning mechanism, they only have > limits of requests per wallet and per address
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
Michael English: > Sajolida, please forward this message to s7r. Done. > s7r, > > If you do not have any specific ideas for updating the Electrum > documentation, I volunteer to take the lead. Otherwise, you can draft an > updated version of the documentation and I can update where necessary. > The goal is to document Electrum specifically for Tails and not > duplicate the existing Electrum wiki. Thanks for the offer. > Most of the updates like wallet format happen automatically in the > background, so they do not need to be documented. I only recommend > making two additions. > > The most obvious change to the user when updating Electrum versions is > that the default base unit changes which can be confusing. No, I do not > think that we should manually change the default base unit with a config > file. That decision should be made upstream. However, users should be > aware that the appearance of their Bitcoin balances changes especially > when sending Bitcoins. If I understand correctly, the main issue here is about the *change* (and not about the behavior itself), then this should be mentioned most of all in the release notes. If you think that the behavior itself might be confusing, then I guess that this should be solved upstream (in their documentation or the software directly). > DoS refers to the SPV vulnerability of servers withholding information > from their clients leading to an incorrect balance. Connecting to a > trusted .onion server protects against DoS. Yes, it is not a bug, but it > is a well-known limitation of SPV that is specifically relevant for Tor > users. Pleas read “Bitcoin over Tor is not a good idea” > http://arxiv.org/pdf/1410.6079.pdf . That's what I thought. Thanks for the clarification. I'm not a Bitcoin user myself but we discussed this back when we added Electrum to Tails. >> Thanks for the input. I'd like to see whoever is working on the update >> to 2.5.4 propose patches to the current documentation [1]. Then I don't >> mind editing and polishing it but I won't have time to do the >> investigation part myself. So thanks for starting it. >> >> - How would people "manually select a trusted .onion server"? >> - Where can people find "a trusted .onion server"? >> - How should our current warning about SPV be adapted? ^ You're not answering this. I'm also wondering whether we should instead configure Electrum in Tails to connect to the existing onion servers automatically instead. So: - Would it be possible to configure Electrum in Tails to use the existing onion servers on top of the usual servers? instead of the usual servers? - In that case, do we need to trust them all? - What happens if some of them go down? ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
Sajolida, please forward this message to s7r. s7r, If you do not have any specific ideas for updating the Electrum documentation, I volunteer to take the lead. Otherwise, you can draft an updated version of the documentation and I can update where necessary. The goal is to document Electrum specifically for Tails and not duplicate the existing Electrum wiki. Most of the updates like wallet format happen automatically in the background, so they do not need to be documented. I only recommend making two additions. The most obvious change to the user when updating Electrum versions is that the default base unit changes which can be confusing. No, I do not think that we should manually change the default base unit with a config file. That decision should be made upstream. However, users should be aware that the appearance of their Bitcoin balances changes especially when sending Bitcoins. DoS refers to the SPV vulnerability of servers withholding information from their clients leading to an incorrect balance. Connecting to a trusted .onion server protects against DoS. Yes, it is not a bug, but it is a well-known limitation of SPV that is specifically relevant for Tor users. Pleas read “Bitcoin over Tor is not a good idea” http://arxiv.org/pdf/1410.6079.pdf . Cheers, Michael English sajolida: > Michael English: >> Please see https://labs.riseup.net/code/issues/9713 for context. >> >> Recommend users to manually select a trusted .onion server to protect >> against DoS after note about SPV vulnerability. >> >> Make a note that Electrum uses mBTC as the default base unit. 1 mBTC = >> 0.001 BTC. It can be changed in preferences. > > Thanks for the input. I'd like to see whoever is working on the update > to 2.5.4 propose patches to the current documentation [1]. Then I don't > mind editing and polishing it but I won't have time to do the > investigation part myself. So thanks for starting it. > > - How would people "manually select a trusted .onion server"? > - Where can people find "a trusted .onion server"? > - How should our current warning about SPV be adapted? > > [1]: > https://git-tails.immerda.ch/tails/tree/wiki/src/doc/anonymous_internet/electrum.mdwn > ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
Michael English: > Please see https://labs.riseup.net/code/issues/9713 for context. > > Recommend users to manually select a trusted .onion server to protect > against DoS after note about SPV vulnerability. > > Make a note that Electrum uses mBTC as the default base unit. 1 mBTC = > 0.001 BTC. It can be changed in preferences. Thanks for the input. I'd like to see whoever is working on the update to 2.5.4 propose patches to the current documentation [1]. Then I don't mind editing and polishing it but I won't have time to do the investigation part myself. So thanks for starting it. - How would people "manually select a trusted .onion server"? - Where can people find "a trusted .onion server"? - How should our current warning about SPV be adapted? [1]: https://git-tails.immerda.ch/tails/tree/wiki/src/doc/anonymous_internet/electrum.mdwn ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
Please see https://labs.riseup.net/code/issues/9713 for context. Recommend users to manually select a trusted .onion server to protect against DoS after note about SPV vulnerability. Make a note that Electrum uses mBTC as the default base unit. 1 mBTC = 0.001 BTC. It can be changed in preferences. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
