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] Releasing automated tests
Hi, bertagaz wrote (03 Dec 2015 15:40:09 GMT) : > On Tue, Dec 01, 2015 at 09:28:13PM +0100, intrigeri wrote: >> * the list of scenarios that shall be tagged @doc: at least the one >>anonym mentioned earlier in this thread; plus "check all PO files" >>I guess; the WhisperBack tests once they have been written; more? > I've added a ticket (#10706) and a branch containing what I've found to > be relevant to be tagged as such. Cool! Merged, and added a note on #10270 :) >> * some process to make sure we tag scenarios @doc whenever relevant; >>I think we'll forget from time to time, and it's fine, because >>we'll be adding such scenarios very rarely; so perhaps a yearly >>check by the RM (e.g. 1st release of the year) is good enough? > Added that to the RM role in commit 4b176e2. Thanks. I felt that the room for interpretation (and for skipping this task forever) the phrasing left was way too big so I made it much smaller ⇒ please review recent changes I did on that page. >> * and finally, some Redmine tickets describing this decision and the >>timeline of its implementation. > I've also added #10707 which is about the actual implementation of this > feature. It has a dedicated branch with a commit doing so. Replied on the ticket, let's follow-up there. > I don't see what other tickets we may want to add for this. OK (⇒ closed #10492! :) Cheers, -- intrigeri ___ 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] problems creating usb stick for tails 1.7
Here is a update log to my previous post showing more deatils.
I followed the set up of tails on a usb drive as per the tails web site ,
however since I have a UFEI BIOS-(windows 10) then the universal usb installer
will not work
The alternative it seems is to use a software called Rufus 2.5.799
Here are the options that I think may be correct. please find log at foot of
this email.
Divce:
maas 8gb
Partition scheme and target system type:
MBR partition scheme for BIOS or UFEI
File system:
FAT32(default)
Cluster size:
4096 bytes (default)
new volume label
tails 1.7
create a bootable disk using:
ISO image
there are other options to choose from which I did not take advantage of just
yet
Here is the log which stops at the last entry for some reason:
Found USB 2.0 device 'Lexar USB Flash Drive USB Device' (05DC:A81D)
1 device found
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 974, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x0031A317
Drive has a Syslinux Master Boot Record
Partition 1:
Type: FAT32 (0x0b)
Size: 7.5 GB (8015314944 bytes)
Start Sector: 2048, Boot: No, Recognized: Yes
Scanning image...
ISO analysis:
Image is an ISO9660 image
Will use '/isolinux/isolinux.cfg' for Syslinux
Detected Syslinux version: 6.03/20150326 (from '/EFI/BOOT/isolinux.bin')
Disk image analysis:
Image has an unknown Master Boot Record
Image is a bootable disk image
ISO label: 'TAILS 1.7 - 20151103'
Size: 1052835840 bytes
Has a >64 chars filename: No
Has Symlinks: No
Has a >4GB file: No
Uses Bootmgr: No
Uses EFI: Yes
Uses Grub 2: No
Uses Grub4DOS: No
Uses isolinux: Yes (6.03)
Uses KolibriOS: No
Uses ReactOS: No
Uses WinPE: No
Using image: tails-i386-1.7.iso
Computing checksum for 'C:\Users\akincana\Downloads\tails-i386-1.7.iso'...
MD5: dfbc1337a118a2fc87e7bfeaf8e8870e
SHA1: b53fb15773da339a16595c047b71ffd9a88255da
SHA256: 372ba423c46ce76393f5e8cd64136e5e9c4a806def993951fe8dbf7d93be2546
Downloading 'ldlinux.sys' from
http://rufus.akeo.ie/files/syslinux-6.03/20150326/ldlinux.sys
Unable to access file: 404
Extended version was not found, trying main version
Downloading 'ldlinux.sys' from
http://rufus.akeo.ie/files/syslinux-6.03/ldlinux.sys
File length: 68599 bytes
Successfully downloaded 'ldlinux.sys'
Downloading 'ldlinux.bss' from
http://rufus.akeo.ie/files/syslinux-6.03/20150326/ldlinux.bss
Unable to access file: 404
Extended version was not found, trying main version
Downloading 'ldlinux.bss' from
http://rufus.akeo.ie/files/syslinux-6.03/ldlinux.bss
File length: 512 bytes
Successfully downloaded 'ldlinux.bss'
Format operation started
Requesting disk access...
Opened drive \\.\PHYSICALDRIVE1 for write access
Will use 'G:' as volume mountpoint
I/O boundary checks disabled
Analyzing existing boot records...
Drive has a Syslinux Master Boot Record
Volume has an unknown Partition Boot Record
Deleting partitions...
Clearing MBR/PBR/GPT structures...
Erasing 128 sectors
Partitioning (MBR)...
Closing existing volume...
Waiting for logical drive to reappear...
Formatting (FAT32)...
Using cluster size: 4096 bytes
Slow format was selected
Creating file system...
Format completed.
Writing master boot record...
Drive has a Zeroed Master Boot Record
Set bootable USB partition as 0x80
Using Syslinux MBR
Found volume GUID \\?\Volume{ac77ce43-9b11-11e5-9bef-0c5b8f279a64}\
Installing Syslinux 6.03...
Using existing './rufus_files/syslinux-6.03/20150326/ldlinux.sys'
Using existing './rufus_files/syslinux-6.03/20150326/ldlinux.bss'
Successfully wrote 'ldlinux.sys'
Opened drive \\?\Volume{ac77ce43-9b11-11e5-9bef-0c5b8f279a64} for write access
Successfully wrote Syslinux boot record
Successfully remounted Volume{ac77ce43-9b11-11e5-9bef-0c5b8f279a64}\ on G:\
Copying ISO files...
Extracting files...
libcdio: Found Extension: Joliet Level 3
Image is an ISO9660 image
This image will be extracted using Joliet extensions (if present)
Extracting: G:\.disk\archive_trace (1 bytes)
Extracting: G:\.disk\info (80 bytes)
Extracting: G:\EFI\BOOT\bootia32.efi (294.5 KB)
Extracting: G:\EFI\BOOT\bootx64.efi (175.1 KB)
Extracting: G:\EFI\BOOT\bootx64.png (7.1 KB)
Extracting: G:\EFI\BOOT\cat.c32 (2.3 KB)
Extracting: G:\EFI\BOOT\chain.c32 (27.7 KB)
Extracting: G:\EFI\BOOT\cmd.c32 (1.8 KB)
Extracting: G:\EFI\BOOT\cmenu.c32 (5 KB)
Extracting: G:\EFI\BOOT\config.c32 (2.1 KB)
Extracting: G:\EFI\BOOT\cptime.c32 (5.2 KB)
Extracting: G:\EFI\BOOT\cpu.c32 (5.5 KB)
Extracting: G:\EFI\BOOT\cpuid.c32 (2.4 KB)
Extracting: G:\EFI\BOOT\cpuidtest.c32 (3.5 KB)
Extracting: G:\EFI\BOOT\debug.c32 (2.2 KB)
Extracting: G:\EFI\BOOT\dhcp.c32 (5.2 KB)
Extracting: G:\EFI\BOOT\disk.c32 (2.7 KB)
Extracting: G:\EFI\BOOT\dmi.c32 (10 KB)
Extracting: G:\EFI\BOOT\dmitest.c32 (14.1 KB)
Extracting: G:\EFI\BOOT\elf.c32 (4.2 KB)
Extracting: G:\EFI\BOOT\ethersel.c32 (3.7 KB)
Extracting: G:\EFI\BOOT\f1.txt (841 bytes)
Extracting: G:\EFI\BOOT\f10.txt (728 bytes)
