Re: [Tails-dev] Tails cert warning
Hi Steve, I am from a different project — CC'ing Tails ML. :) Best regards, Maxim On Wed, Nov 13, 2013 at 12:31 AM, Steve Weis stevew...@gmail.com wrote: Hey Jake and Maxim. Just FYI I was getting a certificate warning for the Tails site (http://tails.boum.org/), but now it's suddenly returning the right certificate. It might be because the office building I'm in is using OpenDNS, since the bad cert CN=*.opendns.com. Here's the bad cert that was returned: http://pastebin.com/y02MsmNm -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Removing the clock applet from the desktop
On Sun, Oct 6, 2013 at 2:04 PM, intrigeri intrig...@boum.org wrote: Sorry my sentence was not clear and doesn't make sense now that I realized that this widget was setting the locale I prefer, and not the country where I am. Sorry if I'm getting you confused again: it *does* specify the region where you are, in broader sense than just fine-tuning the language being used. I'll let you digest this, rethink the whole thing and draw new hypothesis proposals, if you wish :) I suggest that you guys take a look at how the Language and Time Zone applet works in Liberté, especially the system files that are used to construct the menus. https://github.com/mkdesu/liberte/blob/master/src/root/helpers/gen-locale-menu https://github.com/mkdesu/liberte/blob/master/src/usr/local/bin/customize-locale -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails Feature Highly requested - Very Important
On Thu, Oct 3, 2013 at 9:40 PM, adrelanos adrela...@riseup.net wrote: With persistence it could work? Not saying this makes the integration work any easier. I have looked into such integration last year. It's not hard, but I don't think that a live distribution is suitable for a Bitcoin node. See my replies at https://forum.dee.su/topic/how-to-install-bitcoin. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Removing the clock applet from the desktop
On Fri, Sep 20, 2013 at 5:35 PM, intrigeri intrig...@boum.org wrote: Someone just suggested a quite simpler solution that I had missed: to run the clock applet with TZ set accordingly to the region chosen in the greeter. This thread is too painful to watch. Next thing you will “discover” is that the default clock applet is actually a shared library plugin for gnome-panel, and that setting TZ for gnome-panel won't work because the variable propagates to launched applications. You will then possibly think of running a distinct applet via a wrapper, like this: https://github.com/mkdesu/liberte/blob/master/src/home/anon/bin/wrappers/epiphany Hopefully, I saved you guys some time in navigating through the complex and not too newbie-friendly world of Linux. Good luck! :) -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [tor-talk] secure and simple network time (hack)
On Thu, Apr 18, 2013 at 1:18 AM, Jacob Appelbaum ja...@appelbaum.net wrote: Whenever a less friendly person gives me a hard time about the obvious futility of tlsdate, I think: Let me know how your ntp replacement project goes and I'll gladly use it when my shitty one trick pony isn't beating the pants off of your arm chair hacking. I'd say I'm kidding but really, we need a secure network time client and we need one badly. If we don't have one, we can't hold certain assumptions to be correct and entire systems can be broken. There is also the attack surface and architecture of other ntp/ntp-like clients. There are now apparently enough openly accessible and stable authenticated NTP servers around to rely on them in a distro. The problem is that authenticated NTP protocol (more precisely, its asymmetric crypto Autokey variant) does not support NAT traversal in either the server *or* the client, since both IP addresses are signed. I guess the reason is that NTP has no clear distinction between client and server. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [tor-talk] secure and simple network time (hack)
On Fri, Jul 20, 2012 at 3:07 AM, Jacob Appelbaum ja...@appelbaum.net wrote: Allow me to be very explicit: it is harder to parse an HTTP Date header than properly than casting a 32bit integer and flipping their order. The attack surface is very small and easy to audit. Just discovered that tlsdated in tlsdate-0.0.6 is dying with a segmentation fault after a while. Not surprised after seeing the code — my experimentation with this gimmick is finally over. Turns out that “throw something together and wait for patches” is not a sound development approach. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review merge bugfix/less-aggressive-hard-disk-APM-on-AC
On Wed, Mar 13, 2013 at 9:50 PM, Alan a...@boum.org wrote: I don't buy this position, as this branch is here to fix issues appearing for some people that are fixed by -B254 but happening with -B128. You don't understand the issue then. -B128 does not prevent spindown, whereas -B254 most likely does. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review merge bugfix/less-aggressive-hard-disk-APM-on-AC
On Fri, Mar 1, 2013 at 7:34 PM, intrigeri intrig...@boum.org wrote: commit 65c78a5594ba7fff98683959d46bf431a065b77d Author: Tails developers amne...@boum.org Date: Fri Mar 1 13:17:54 2013 +0100 Enable laptop-mode-tools hard drive power management settings. Set APM level to 127 on battery, and to 254 on AC power, as a Wheezy desktop system does. 254 is chosen to avoid causing excessive head load/unload cycles. 127 is chosen because the head parking is very useful for shock protection. Don't use 127, see commit 4686bd8a in Liberté's git. https://github.com/mkdesu/liberte/commit/4686bd8a Note that NOLM_AC_HD_POWERMGMT=254 is there since the beginning — as usual, bottom-up approach produces better results. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review merge bugfix/less-aggressive-hard-disk-APM-on-AC
On Sat, Mar 2, 2013 at 6:45 PM, Maxim Kammerer m...@dee.su wrote: Note that NOLM_AC_HD_POWERMGMT=254 is there since the beginning — as usual, bottom-up approach produces better results. Although LM_AC_HD_POWERMGMT=128 — oh well, I guess users who experience issues can stop laptop_mode service. Having 254 for everyone on AC is unreasonable, in my opinion. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails Mac support
On Mon, Feb 25, 2013 at 3:33 PM, intrigeri intrig...@boum.org wrote: not only are you completely dependent on an upstream distro's features implementation cycle I've no idea what misconceptions about Tails and Debian make you think this, but this is incorrect in practice. I really don't know why the moment I mention something about Debian, people get very defensive and assume I don't know something. Debian is nothing special, it's just a binary distro that requires no understanding to use — the reason it's a base for so many forks, including Ubuntu. The only reason people get defensive is pure rationalization due to being vested in Debian — like with that certificates fiasco, which, were it to happen to any less popular project or company, would result in its ridicule and eventual death (e.g., DigiNotar). Now, of course what I wrote is correct. For instance, you don't, and won't have UEFI support until Debian community decides to implement it in a way they see fit. Moreover, due to not gathering experience while working on said support, you will have nothing to do with the solution, once it's ready. Same with so many other things. You accept bug reports and maintain related bug / todo pages, knowing full well in advance that this leads nowhere. This also misleads users, e.g., I have seen someone on Twitter mention your earlier message about UEFI, applauding the apparent progress, while in reality you are just rehashing the same old information. First, I fail to see what compiling binaries yourself buys you, in terms of your level of dependency on upstream distro's features implementation cycle. Gentoo is not about “compiling binaries yourself”. Gentoo is a source-based highly flexible meta-distribution, each component of which can be easily changed and adapted to specific needs. Gentoo is as close as one gets to LFS, without having to actually do everything manually and while keeping decent package management. You wouldn't understand the advantages just from the description, because in boring distributions like Debian the developer is still a “user” — you need to go out of your way to modify system behavior. Debian does not encourage understanding and experimenting. E.g., I remember you, or one of the other Tails people asking on IRC: what good is ASLR? Indeed, how would you know, if the distro you use discourages users from deviating from stock kernels, to the point where you would initiate a long bureaucratic process for changing a single trivial kernel setting that is needed for Tails? [contentless propaganda skipped] So, yes, e.g. having UEFI support added to Debian Live makes sense to me, as opposed to implementing in a Tails-only way and maintaining it forever. Sure, it sometimes means we get the feature a bit later (which is not that clear in this specific case). You have no idea what you are talking about. Whenever you *do stuff*, instead of waiting for someone else to do it, while engaging in useless “community relationships”, that someone will usually end up actually using the results of your labor. With UEFI, it's just too funny — you will likely end up using sbsigntool directly or indirectly (which is already used in Ubuntu), which contains my patches, which I added because I needed sbsigntool working properly in Liberté. Oh, and I learned something new, which was great. But I guess that waiting for stuff to happen is just as exciting. If you intend to go on writing such bold public statements about Tails, then I'd rather give you first-hand information that you can base your affirmations on. Here we go, then. My experience absolutely does not match your assumption. I'm personally quite happy with how I've been learning new things when implementing features for Tails, be it when writing Tails-specific software, or when implementing the feature upstream, or when working to make Debian an awesome platform to build the next Tails generation upon. Without being able to quantify that statement, it is just another politically correct contentless propaganda. I have read some Tails monthly reports, and items they are composed of are of the kind that I usually don't even copy from git commit messages to the changelog file in Liberté. I mean, it's nice to see people touting Tails features that were copied from Liberté (like unsafe browser [1], or memory erasure on boot media removal, or clock setting / whatever else), but from my point of view, you don't do anything interesting (so I nearly stopped following your project), which is a shame, hence my replies ITT. Think about what benefits your project. If you do hard stuff, you attract other people who can do hard stuff, whereas otherwise you attract people who know how to tweak settings / apply patches, and not much else. [1] https://lists.torproject.org/pipermail/tor-talk/2012-July/024964.html -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list
Re: [Tails-dev] Tails Mac support [Was: Training Journalists in Istanbul]
On Fri, Feb 22, 2013 at 6:58 PM, intrigeri intrig...@boum.org wrote: The remaining part of the problem will be solved by adding UEFI support [3] to Tails. We're currently making plans with Debian Live upstream so that this support is added there, and benefits all Debian Live systems. [3] https://tails.boum.org/todo/UEFI/ Don't you already regret basing Tails off a binary distro like Debian? I mean, updating TODO lists once in a while and making “plans” sounds fun and all, but not only are you completely dependent on an upstream distro's features implementation cycle — you are missing the opportunity to learn new things while implementing those features yourself. I mean, Liberté was the first Linux distro to ship with a UEFI Secure Boot-based trusted boot chain — do you think you will ever be able to say something of the sort about Tails? Open Source development is supposed to be exciting, not this… bureaucracy. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Let's share username, /etc/hostname and /etc/host among all anonymity distributions
On Tue, Jan 22, 2013 at 8:00 PM, Maxim Kammerer m...@dee.su wrote: (/etc/conf.d/hostname in Liberté) can be potentially disclosed via DHCP requests, but dhcpcd has been configured to avoid that Just recalled another place while updating configuration: default Bluetooth adapter name (/etc/bluetooth/main.conf). -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Let's share username, /etc/hostname and /etc/host among all anonymity distributions
On Mon, Jan 21, 2013 at 5:25 PM, intrigeri intrig...@boum.org wrote: Adding Maxim to the list of recipients (Maxim: in case you don't read tails-dev anymore, please go read the email I'm replying to in the list archives :) Hi, I'm subscribed to the list, just a bit busy lately. I intended to reply, but you were first to do so. :) My problem with adrelanos' proposal is that it goes with the system-as-a-blackbox approach, resulting in too many patch possibilities like this one. It is suitable to Whonix, because it does more or less treat the “inner” OS as a blackbox, but Liberté uses a bottom-up approach, where every utility and application is vetted and (hopefully) properly configured. So /etc/hostname (/etc/conf.d/hostname in Liberté) can be potentially disclosed via DHCP requests, but dhcpcd has been configured to avoid that (and I actually had to update its configuration between 4 and 5 branches for that reason). Username can be disclosed by SSH, but Liberté has “User root” in ~/config/ssh/config. I don't think hostname in /etc/hosts can leak somewhere, but will be glad to be proven wrong on that. So in summary, I am all for making leaked information homogeneous, but only if there is actual possibility of leaks. Otherwise, it hurts usability. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Attribution mistake in The Metadata Anonymization Toolkit paper (arXiv:1212.3648v1)
Hi, The following passage from [1] has been brought to my attention [2]: “Liberté Linux [4] was a similar project in all aspect, but based on Gentoo instead of Debian. The main developer has abandoned the project to join his forces with the Tails team.” This is incorrect (see [2]) — please fix in final paper version! [1] http://arxiv.org/abs/1212.3648 [v1] [2] https://forum.dee.su/topic/liberté-linux-maxim-kammerer-is-this-fact-or-fiction Thanks, Maxim -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Support EntropyKey?
On Mon, Nov 26, 2012 at 5:40 PM, Jacob Appelbaum ja...@appelbaum.net wrote: On a recently installed laptop, I found that it had essentially zero sources of entropy beyond the keyboard, the clock and the hostname. You forgot the CPU. Haveged makes all other approaches to gathering entropy pretty much irrelevant — for instance, try exhausting /proc/sys/kernel/random/entropy_avail on a system with running haveged. It is used in Tails since Apr 2010, and in Liberté since Apr 2011 (I think I added haveged after reading the PELD spec). HAVEGE is one of those really underappreciated academic projects. “HAVEGE can reach an unprecedented throughput for a software unpredictable random number generator: several hundreds of megabits per second on current workstations and PCs.” http://www.irisa.fr/caps/projects/hipsor/ http://www.irisa.fr/caps/projects/hipsor/misc.php http://www.irisa.fr/caps/projects/hipsor/publi.php -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
On Sat, Oct 13, 2012 at 5:18 AM, Maxim Kammerer m...@dee.su wrote: On Sat, Oct 13, 2012 at 5:04 AM, Steve Weis stevew...@gmail.com wrote: I think the kernel is working as expected. Debian and Ubuntu are both also vulnerable by default, since FireWire modules are loaded automatically. From Documentation/debugging-via-ohci1394.txt: “The alternative firewire-ohci driver in drivers/firewire uses filtered physical DMA by default, which is more secure but not suitable for remote debugging.” There is some more information in 1394 OHCI Spec v1.1 [1, §5.14.2]. drivers/firewire/ohci.c doesn't touch OHCI1394_PhyReqFilter* registers at all if CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set, so physical request DMA should be forwarded to asynchronous request DMA. Could it be that the kernel does not implement AR DMA correctly? There is also something strange when the spec is compared to the older v1.0 spec [2, §5.13.2]. The older spec does not have a clarification wrt. what happens on a bus reset, in Table 5-21 (whether it has such a clarification in §5.13.1, for instance). It has such a clarification in the newer v1.1 spec, in Table 5-22. Is it possible that when implementing OHCI 1.0, vendors did not know what to do, and kept the physReq* registers values even over a soft reset? This is quite unlikely, of course, but did you try to power off the computer completely before performing the test? [1] http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/ohci_11.pdf [2] ftp://ftp.microsoft.com/bussys/1394/OHCI/Released_Specs/OHC1.0.pdf -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
On Sun, Oct 14, 2012 at 9:57 PM, Steve Weis stevew...@gmail.com wrote: There are two alternative driver stacks (e.g. ieee1394 and firewire-core) and the docs talk about them both interchangeably. It's a bit confusing. The CONFIG_FIREWIRE_OHCI_REMOTE_DMA kernel hacking option may only be relevant to the legacy ohci1394 module. Indeed, the doc is confusing, but it's easier to look at the source files. CONFIG_FIREWIRE_OHCI_REMOTE_DMA is used by the new stack, and I was actually wrong previously when saying that physReq* registers are only written to if the option is disabled (missed an #else in an #ifdef). The ohci_enable_phys_dma() function in drivers/firewire/ohci.c enables physical DMA for a specified node, and this function is called by none other than the sbp2 module (via a wrapper), in sbp2_probe() and sbp2_update(). So: One thought is that it the sbp2 module might be allowed to circumvent whatever filtering is happening. Sbp2 enables full DMA access, and I haven't been able to carry out Firewire DMA attacks via Inception without it. This must be exactly the case. Sbp2 actually uses DMA filtering — it “filters” physical DMA to a specific Firewire node. blacklist firewire_sbp2 This (or disabling CONFIG_FIREWIRE_SBP2) should be enough to prevent physical DMA attacks on Firewire — there is currently no other way to enable physical DMA in Firewire than via firewire_sbp2 or via unfiltered physical DMA (enabled by CONFIG_FIREWIRE_OHCI_REMOTE_DMA). Of course, there is also asynchronous DMA, but its accessible memory regions are kernel's responsibility. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
On Sun, Oct 14, 2012 at 11:38 PM, Maxim Kammerer m...@dee.su wrote: there is currently no other way to enable physical DMA in Firewire than via firewire_sbp2 or via unfiltered physical DMA (enabled by CONFIG_FIREWIRE_OHCI_REMOTE_DMA). Ah, there is also CONFIG_PROVIDE_OHCI1394_DMA_INIT + ohci1394_dma=early, which enables unfiltered physical DMA during early boot, but the effects will be reverted by card soft reset during normal firewire_ohci initialization. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
On Sat, Oct 13, 2012 at 1:30 AM, Jacob Appelbaum ja...@appelbaum.net wrote: I would add Thunderbolt to the list as well: http://www.breaknenter.org/2012/02/adventures-with-daisy-in-thunderbolt-dma-land-hacking-macs-through-the-thunderbolt-interface/ As far as I can see, all these attacks (PCMCIA, ExpressCard, Thunderbolt) rely on attaching to a FireWire interface one way or another, and then accessing arbitrary memory via DMA. But such ability is (or can be) disabled by default in the newer firewire-ohci module, as described in debugging-via-ohci1394.txt, and even discussed on the relevant Tails TODO page. So why disable the interfaces? Looks like an overkill to me. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] from sdmem to memtest, and testing procedures
On Thu, Dec 29, 2011 at 12:53 AM, intrigeri intrig...@boum.org wrote: Maxim Kammerer wrote (26 Dec 2011 17:59:44 GMT) : But best option, of course, is if kernel developers fix the kernel Sure. Ah, by the way, they won't fix memtest. Nobody cares [1]. [1] https://bugzilla.kernel.org/show_bug.cgi?id=42630 -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
On Sat, Oct 13, 2012 at 5:04 AM, Steve Weis stevew...@gmail.com wrote: I think the kernel is working as expected. Debian and Ubuntu are both also vulnerable by default, since FireWire modules are loaded automatically. From Documentation/debugging-via-ohci1394.txt: “The alternative firewire-ohci driver in drivers/firewire uses filtered physical DMA by default, which is more secure but not suitable for remote debugging.” Isn't this supposed to limit DMA? I can send some fix suggestions if you like. Not being a kernel developer, I am not sure I will be able to act on them. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Block/unblock wireless devices?
On Tue, Sep 25, 2012 at 9:53 AM, Ague Mill a...@mailoo.org wrote: Bluetooth can be problematic. Some systems use Bluetooth to communicate with their keyboards and mouses. True, see, e.g., https://forum.dee.su/topic/wireless-mouse-french-keyboard. AFAIU, that is one of the reason why most Bluetooth enabled systems will always powerup the radio during first stage of the boot process, so one with a Bluetooth keyboard can reach firmware settings. Systems boot in all kinds of crazy states, some apparently relying on initialization by Windows drivers. The main reason I added rfkill calls during boot is that some systems turn wireless radio off on boot: https://forum.dee.su/topic/wireless-problem. I also think that having Bluetooth off by default is the optimal choice, but there are still problems with it, as you noted. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] PGP Smart Cards
On Tue, Aug 28, 2012 at 1:19 AM, Patrick Bx patric...@gmail.com wrote: Ran into those same issues myself. Root is necessary unless the amnesia user is added to the pcscd group. This shouldn't be the case when pcsc-lite is installed, since scdaemon uses libpcsclite.so by default, and libusb interface is secondary (although, on Debian GnuPG might be compiled differently). The pcscd group exists only for pcsclite, see http://ludovicrousseau.blogspot.com/2010/09/pcscd-auto-start.html: “The group pcscd should be used only by pcsc-lite so only pcscd has access to smart card readers. The pcscd process has only gained the minimum rights needed to do its job (instead of gaining root access).” -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] PGP Smart Cards
On Sat, Aug 25, 2012 at 10:35 PM, Patrick Bx patric...@gmail.com wrote: I can't say i'd be the best person to make the back ports as I have no experience with that, but I'd be more then happy to help test them. Let me how I can help and I will get back pretty fast about things. Hi, what's the big deal about having support for PGP SmartCards? Liberté had ccid + pcsc-lite and some other packages (engine_pkcs11) since forever, and the latest snapshot has gnupg-pkcs11-scd. Maybe you can test this support [1] and tell what's missing? I don't have the hardware, unfortunately (although I think that at one point I considered asking some guy who would send evaluation USB tokens for a free one, but it turned out as too much trouble). [1] https://forum.dee.su/topic/a-new-snapshot-has-been-released-20120825 -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [tor-talk] secure and simple network time (hack)
On Wed, Jul 18, 2012 at 7:31 AM, intrigeri intrig...@boum.org wrote: Thoughts? After pondering about extending tlsdate for a while, I see no reason to use tlsdate instead of htpdate at the moment (or, possibly, ever). There is a difference between thinking of and experimenting with a gimmick, and using it as a replacement for a robust method of time setting. Motivation behind tlsdate is incorrect: 1. Extracting the HTTP Date: header is not a “nightmare” — it is easy, standards-compliant, and safe. If anything, TLS is much harder to get right (see issue #16 on GitHub, for instance — tlsdate is currently susceptible to a MITM attack). 2. The latency due to receiving HTTP headers is negligible when compared to the latency of a TLS handshake. 3. Nothing is gained by restricting the application layer to TLS — the reverse is true, since, e.g., using HTTP instead of HTTPS to reduce latency is not possible anymore. 4. tlsdate either leaks local clock in ClientHello, or is not standards-compliant (currently, it leaks the local clock); the user cannot disable TLS to avoid that. Additionally, tlsdate lacks important features: 6. It cannot run as a daemon with clock skewing and hosts rotation. 7. There is no explicit proxy support. Once / if these features are implemented, tlsdate will only provide part of the functionality of htpdate (since TLS is forced), and will not have any advantages over it (perhaps besides the possibility of using non-HTTP(S) servers). I also wonder whether Chrome OS's usage of tlsdate is confirmed by Google, or this information comes from a single pull request on GitHub. In any case, I suspect that Chrome OS developers did not properly explore the available time setting options. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Why doesn't Tails use tlsdate? (htp replacement)
My take on tlsdate: On Wed, Jun 6, 2012 at 4:15 AM, pro...@secure-mail.biz wrote: Wouldn't it be a good replacement for htp? No, since tlsdate has no features: see TODO items 5 and 6, for instance (daemonization and clock skewing), and also items 9 and 1 (proxy support and leaking local clock). The claim about “parsing the header with questionable code”, on the other hand, is silly — see my reply to the email that you referenced. Granted, I wrote about C code, and Tails uses Perl HTPDate version, so YMMV. Even without https support in C HTPDate, it seems more attractive to me than current tlsdate. With all that said, I actually intend to fork tlsdate at some point and implement the required features, but it's quite low priority. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Has Tails joined Open Invention Network?
Hi, People from OIN [1] continue to send me requests to join (I think I mentioned it on #tails-dev a year ago), and today they mentioned that Tails has recently joined the network. Could you perhaps expand on the rationale? I can't find a discussion anywhere. To me joining OIN seems like surrendering part of project's independence for some vague American thing in return. Maybe I'm wrong, though. Debian is not on the list, by the way (although Gentoo is). [1] http://www.openinventionnetwork.com/licensees.php -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Building without a proxy?
On Wed, May 9, 2012 at 1:31 PM, Ague Mill a...@mailoo.org wrote: Does anyone around build Tails with using a local HTTP proxy and setting the http_proxy environment variable? FWIW, Liberté's enter script passes the following through: RSYNC_PROXY http_proxy https_proxy ftp_proxy no_proxy and copies host's /etc/resolv.conf over (which is later excluded from the build). -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Building without a proxy?
On Wed, May 9, 2012 at 6:01 PM, Ague Mill a...@mailoo.org wrote: Does anyone around build Tails *without* using a local HTTP proxy and setting the http_proxy environment variable? Note the mention of /etc/resolv.conf above. I found that bug at the end of 2010 (commit 54d9702), when a user without *_proxy variables had builds failing due to non-working DNS. It could be the reason for failing builds in your case. -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Switch to Privoxy?
On Sun, Mar 25, 2012 at 17:40, intrigeri intrig...@boum.org wrote: Could you please share a Privoxy configuration you trust to be safe using with Tor? I still don't understand why would anyone trust Tor developers to correctly configure Privoxy. E.g., on https://trac.torproject.org/projects/tor/wiki/doc/TorFAQ#WhydoweneedPolipoorPrivoxywithTorWhichisbetter: it needs to see the entire page to parse it, before sending it on to the browser. This incorrect remark can mean only one thing: whoever wrote that sentence didn't read the manual. For a decent configuration, see src/etc/privoxy in Liberté's git, which includes Referer/Host header rewriting for .exit notation support, for instance. -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review and test feature/tordate
On Sat, Jan 28, 2012 at 20:52, anonym ano...@lavabit.com wrote: When Tor shuts down it writes the consensus to the data dir even if it is unverified. When Tor starts it will load the saved consensus, and now it will find that it's valid, and hence *NOT* download a new consensus. All should be well from here on. It will download a new consensus after an hour. If htpdate fails, that's where Tor stops working. Also, won't other nodes treat another Tor node with clock time before their consensus differently? -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review and test feature/tordate
On Fri, Jan 27, 2012 at 17:39, Maxim Kammerer m...@dee.su wrote: When writing and testing that script, I noticed that the incoming valid-after is never more than an hour earlier from the current (correct) time, but at that point it was all kind of black magic, and I didn't know that (as you say) the reason is that the directory authorities agree on a new consensus each hour. I think I now recalled the actual reason that stopped me from doing more research on whether it is possible to rely on hourly new consensus: fringe conditions. Say at 13:59 (correct time), Tor gets a 13:00-14:00-16:00 (valid-after, fresh-until, valid-until) consensus, the computer's time is off, and tordate sets the time to 13:30. But shortly after (maybe even before Tor has established a circuit — not sure whether that matters), the directory authorities agree on a new 14:00-15:00-17:00 consensus, and 13:30 is now out of that window, so Tor won't work (will it? The consensus is not yet valid — i.e., unverified), and htpdate will fail. With 14:30 estimate that problem wouldn't have happened. -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] tordate: why is it safe to set time from unverified-consensus?
Hi, On Thu, Jan 19, 2012 at 23:09, intrigeri intrig...@boum.org wrote: Early October, we were pondering setting the Tails system time from unverified-consensus in case cached-consensus is not present; long story short, we refrained to do so in a hurry at pre-release time; eventually, we did not take the time yet to investigate how safe it would be to do so, and why. Yes, I remember reading that discussion [1], the bug filed by anonym [2], and Tor's source code [3]. On October 9th, a commit of yours (58cc2dd) in Liberté Linux Git repository made the very move we were unsure of. So I guess this approach seemed safe enough to your eyes. May we know why? Well, as I see it, the difference between verified and unverified consensus matters to Tor, but not to the distribution that already decided to set the time from the consensus header. By setting the time from cached-consensus, you are risking a replay attack on Tor, fine — but by setting the time from unverified-consensus, you are additionally risking — what exactly? Tor will handle bad signatures, after all (which are the reason for consensus being unverified — e.g., expired certificates), so the additional risk is letting an adversary set an incorrect time on the system? But time is only critical to Tor, because of the risk of replay attacks, which we are already ignoring. Maybe I am missing something, but for a distribution, both verified and unverified consensus are of equal value — getting some (not necessarily trusted) idea of what to set the clock to, if Tor says that the clock is wrong. Both cached and unverified consensus could be the result of an attack, but I don't see how setting the time from unverified consensus allows for new attack vectors. Best regards, Maxim [1] https://mailman.boum.org/pipermail/tails-dev/2011-October/000571.html [2] https://trac.torproject.org/projects/tor/ticket/4187 [3] https://gitweb.torproject.org/tor.git/blob/HEAD:/src/or/networkstatus.c -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] PROBLEM: memtest tests only LOWMEM
Well, it seems that even with the reminder sent about 8 days ago, no one on the linux-mm mailing list cares. I tried OFTC/#mm several times as well, but never saw any response. I think I will stay with the 32/64-bit KEXEC split in the meanwhile. Will also ask memtest86+ author about the difficulties of adapting it for the task. Best regards, Maxim On Mon, Dec 26, 2011 at 04:18, Maxim Kammerer m...@dee.su wrote: 1. On 32-bit x86, memtest=n tests only LOWMEM memory (~ 895 MiB), HIGHMEM is ignored 2. On 3.0.4-hardened-r5, HIGHMEM memory (HIGHMEM64G in my tests) is apparently ignored during memtest. Looking at arch/x86/mm/memtest.c, no special mapping is performed (kmap/kunmap?), so it seems that at most ~895 MiB can be tested in 32-bit x86 kernels. This might not appear like an important issue (as there are other memory testing tools available), but memtest is extremely useful for anti-forensic memory wiping on shutdown/reboot in security-oriented distributions like Liberté Linux and Tails, and there is no other good substitute. See, for instance, some background in Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646361. 3. Keywords: memtest, highmem, mm, security 4. Kernel version: 3.0.4-hardened-r5 (Gentoo) x86 32-bit with PAE -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
