Re: [Tails-dev] Fwd: Re: Reducing attack surface of kernel and tightening firewall/sysctls

On 2/14/16, intrigeri wrote: > Jacob Appelbaum wrote (14 Feb 2016 13:04:58 GMT) : >> I feel a bit sad to see this rehashed. Please just drop all packets on >> the floor? > >> People who use Tails and expect it to keep them safely torified are >> likely still vulner

Re: [Tails-dev] Fwd: Re: Reducing attack surface of kernel and tightening firewall/sysctls

On 2/12/16, intrigeri wrote: > Hi, > > Jurre van Bergen wrote (11 Feb 2016 16:46:47 GMT) : >> Forwarding e-mail. > > Thanks :) > >> Date:Thu, 11 Feb 2016 12:28:35 +0100 >> From:Cornelius Diekmann > >> A conservative change to the tails config would be to keep an RELATED >> rule bu

Re: [Tails-dev] Pond in Tails

On 11/17/15, u wrote: > Hi, > > >> Pond recently got accepted into Debian (sid). > > Indeed. > >> Do you plan on integrating it in Tails (soon?) or letting the project >> mature more? > > As Pond is still considered "experimental" with no security audit, it > will, from what I understood, not get

Re: [Tails-dev] AppArmor policy vs. hard links [Was: MFSA 2015-78 (aka. CVE-2015-4495) vs. Tails]

On 8/8/15, intrigeri wrote: > Hi, > > Jacob Appelbaum wrote (07 Aug 2015 12:33:10 GMT) : >> If you hard link a file say, /home/amnesia/.gnupg/secring.gpg into >> ~/Tor Browser/secring.gpg - you can read it with Tor Browser. AppArmor >> uses file paths to constrain thing

Re: [Tails-dev] MFSA 2015-78 (aka. CVE-2015-4495) vs. Tails

On 8/7/15, Georg Koppen wrote: > Jacob Appelbaum: >> On 8/7/15, jvoisin wrote: >>> Hello, >>> >>> I disagree with your analysis; >>> while the Apparmor profile (♥) will prevent tragic things like gpg key >>> stealing, please keep in mind tha

Re: [Tails-dev] MFSA 2015-78 (aka. CVE-2015-4495) vs. Tails

On 8/7/15, intrigeri wrote: > Jacob Appelbaum wrote (07 Aug 2015 10:37:25 GMT) : >> I've heard that the exploit in the wild doesn't work against esr31 - I >> haven't heard that it isn't impacted at all. > > Mozilla folks have explicitly written on t

Re: [Tails-dev] MFSA 2015-78 (aka. CVE-2015-4495) vs. Tails

On 8/7/15, jvoisin wrote: > Hello, > > I disagree with your analysis; > while the Apparmor profile (♥) will prevent tragic things like gpg key > stealing, please keep in mind that an attacker can access every Firefox > files, like cookies (stealing sessions), stored passwords, changing > preferenc

Re: [Tails-dev] MFSA 2015-78 (aka. CVE-2015-4495) vs. Tails

On 8/7/15, intrigeri wrote: > Hi, > > that is: > > https://www.mozilla.org/en-US/security/advisories/mfsa2015-78/ > https://security-tracker.debian.org/tracker/CVE-2015-4495 > > ... apparently only affect Firefox 38.x, so current Tails stable > (1.4.1) is not affected. Most likely Tails 1.5~rc

Re: [Tails-dev] reducing the amount of data on our mirrors

On 12/18/14, sajolida wrote: > Hey, > > The administrator of one of our mirrors ran out of disk space. That made > me realize that as of now, the size of those mirrors is ever growing as > we are keeping all past IUK: > > https://archive.torproject.org/amnesia.boum.org/tails/stable/iuk/ > > I migh

Re: [Tails-dev] Tails and forensics

On 12/11/14, Austin Hartzheim wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Jacob Appelbaum wrote: >> Hi, >> >> I was recently asked to help someone verify a Tails disk. I >> decided to help make a list of hashes and to collect various fi

Re: [Tails-dev] minimalist/anonymity-preserving DHCP clients [was: Re: Reducing attack surface of kernel and tightening firewall/sysctls]

On 12/9/14, Daniel Kahn Gillmor wrote: > On 12/04/2014 10:37 AM, Jacob Appelbaum wrote: >> On 12/4/14, Daniel Kahn Gillmor wrote: > >>> I'm not sure i'd characterize a simple DHCP client as "quite straight >>> forward", but certainly minimal

[Tails-dev] Tails and forensics

Hi, I was recently asked to help someone verify a Tails disk. I decided to help make a list of hashes and to collect various files such as iso files, signatures, signing keys and so on: https://github.com/ioerror/tails-verifier At the moment, the project is just a dataset and a small one. I'm

Re: [Tails-dev] [review'n'merge:1.2.1] feature/7740-remove-truecrypt

On 12/5/14, sajolida wrote: > Jacob Appelbaum: >> On 12/4/14, intrigeri wrote: >> >>> Except creating such volumes, every other thing has been possible, >>> documented and advertised to people every time they use TrueCrypt >>> since Tails 1.2

Re: [Tails-dev] Reducing attack surface of kernel and tightening firewall/sysctls

On 12/4/14, Oliver-Tobias Ripka wrote: > Thinking some more about this I think that there might not only be the > TCP PATH MTU issue, How should we test this, I wonder? > but also my list of protocols used by Tails was > incomplete. While it does not run by default I think I2P is supported > wit

Re: [Tails-dev] Reducing attack surface of kernel and tightening firewall/sysctls

On 12/4/14, Oliver-Tobias Ripka wrote: > According to anonym on Thu, Dec 04 2014: > >> FWIW I experienced no issues during my tests with *only* ESTABLISHED in >> both the INPUT and OUTPUT chains so neither NEW nor RELATED seems >> essential for the basic usage I tested. And of course the above >>

Re: [Tails-dev] [review'n'merge:1.2.1] feature/7740-remove-truecrypt

On 12/4/14, intrigeri wrote: > Hi, > > Jacob Appelbaum wrote (04 Dec 2014 15:04:35 GMT) : >> I work with a number of people who use TrueCrypt - I wonder how this >> will work for them? > >> They require TrueCrypt and this will probably force them to switch to >&

Re: [Tails-dev] 1.2.1 broken for install/upgrade?

On 12/4/14, BitingBird wrote: > intrigeri a écrit : >> Jacob Appelbaum wrote (04 Dec 2014 15:51:07 GMT) : >>> Is anyone else experiencing this issue? >> >> At least our automated test suite didn't see any such problem. >> FWIW, what we're testing

[Tails-dev] 1.2.1 broken for install/upgrade?

Hi, I was unable to upgrade a current Tails disk to 1.2.1. I find that this isn't so interesting but upon burning the ISO to a DVD, I found that the tails installer (liveusb-creator-launcher) after boot did not work to upgrade or install onto a fresh USB disk. I reported this as a bug with Whisper

Re: [Tails-dev] minimalist/anonymity-preserving DHCP clients [was: Re: Reducing attack surface of kernel and tightening firewall/sysctls]

On 12/4/14, Daniel Kahn Gillmor wrote: > On 12/04/2014 09:56 AM, Jacob Appelbaum wrote: > >> I'm currently working with a friend on a privilege separated dhcp >> client that does not need raw sockets. It is in the early stages but >> it is able to do the network

Re: [Tails-dev] [review'n'merge:1.2.1] feature/7740-remove-truecrypt

On 12/4/14, sajolida wrote: > intrigeri: >> anonym wrote (30 Nov 2014 22:38:25 GMT) : >>> However, in the TrueCrypt documentation we have an info bubble saying: >>> "We recommend that you use [[LUKS encrypted volumes]] instead of >>> TrueCrypt volumes." While the LUKS page in turn links to our per

Re: [Tails-dev] Reducing attack surface of kernel and tightening firewall/sysctls

On 12/4/14, Oliver-Tobias Ripka wrote: > Hi, > > I retried the test but deleted the lease files from the directory you > mentioned before reconnecting. I now see a complete DHCP DORA > (Discovery, Offer, Request, Ack) on the wire. So nothing gets blocked. I > would also expect that just doing a re

Re: [Tails-dev] Reducing attack surface of kernel and tightening firewall/sysctls

On 12/4/14, anonym wrote: > On 03/12/14 18:22, Jacob Appelbaum wrote: >> I propose that we change the rule to be: >> >> mod state state (NEW ESTABLISHED) ACCEPT; >> >> The reason is pretty simple - RELATED makes the kernel do a lot of >> extra

Re: [Tails-dev] Reducing attack surface of kernel and tightening firewall/sysctls

On 12/3/14, intrigeri wrote: > Hi Jake, > > Jacob Appelbaum wrote (03 Dec 2014 17:22:30 GMT) : >> Thoughts? > > Thanks a lot for this detailed report! :) > Sure - happy to help. :) > Were the proposed changes tested in Tails? > I've not tested it - I was ho

[Tails-dev] Reducing attack surface of kernel and tightening firewall/sysctls

Hi, After talking with a new friend about netfilter and the kernel, we discussed a funny thing that happens to lots of people who use iptables. As a result, I took a look at Tails and sure enough, that funny little issue is present. I think as a result, we should make a reasonable, minimal change

Re: [Tails-dev] Removing Polipo (and upgrading to torsocks 2.x): progress report

On 11/5/14, intrigeri wrote: > Hi, > > the feature/5379-remove-polipo branch builds upon the ones for #7416 > (proposed for 1.2.1), #6623 (proposed for 1.3) and #8194 (not > submitted formally yet), that configure the remaining Polipo users to > use the Tor SOCKS proxy instead. And it goes further

Re: [Tails-dev] AppArmor in Live systems, state of the union

On 10/20/14, intrigeri wrote: > Hi folks, > > [Cc'ing my fellow Tails developers, and also the Freepto ones who > might be interested.] > > I'm super happy to tell you that we've now released Tails 1.2, > finally with some minimal AppArmor support! :) > > Our implementation is described on > https

Re: [Tails-dev] [call for testing] AppArmor profiles

On 10/8/14, intrigeri wrote: > Jacob Appelbaum wrote (08 Oct 2014 12:19:57 GMT) : >> What are the parameters you'd like to be tested? That is - what would >> count as a bug? Do we have a security model of what should be readable >> by a given app? Or writable by a given

Re: [Tails-dev] [call for testing] AppArmor profiles

On 10/6/14, intrigeri wrote: > Hi, > > the latest experimental nightly built ISO confine some applications > with AppArmor: Tor, Vidalia, Evince, Pidgin and Totem. > > Please try using these applications and report back any regression you > might encounter. Thanks in advance! What are the paramet

Re: [Tails-dev] Bash bug

On 9/24/14, anonym wrote: > 25/09/14 01:02, Jurre van Bergen wrote: >> >> Dear Tails users, >> >> As you might have heard there is a Bash vulnerability, I have created a >> temporary countermeasure write-up below. > > Out of curiosity, have you (or any one else for that matter) come up > with a re

Re: [Tails-dev] TorBrowser Handling of PDF files

On 8/31/14, intrigeri wrote: > putinisoneofthelizardpeo...@safe-mail.net wrote (31 Aug 2014 10:06:06 GMT) > : >> Please change the method in which TorBrowser handles PDF files. With every >> TAILS boot >> I have to reconfigure this. Here is my suggested change: > >> # Edit: >> # Preferences: >> #

Re: [Tails-dev] How to seed urandom (or not)?

On 8/2/14, coderman wrote: > On Fri, Aug 1, 2014 at 10:24 AM, Jacob Appelbaum > wrote: >> ... >> Sure - if we have entropy, we can seed anything. :) > > *grin* > > > > >> How is that worse? The goal is entropy collectin. A public value is >> not

Re: [Tails-dev] How to seed urandom (or not)?

On 8/1/14, coderman wrote: > On Fri, Aug 1, 2014 at 2:44 AM, intrigeri wrote: >> ... >> [For full context, and to avoid rehashing previous discussion, please >> read https://labs.riseup.net/code/issues/7642.] > > sooner or later everyone hits this bag of sticky worms... :P > > for the old (deprec

Re: [Tails-dev] Risks of enabled/disabled TCP timestamps?

On 7/27/14, intrigeri wrote: > Hi, > > I was a bit sad that the TCP timestamps thing went nowhere, after the > energy we've put into discussing it, so I've built an ISO with the > corresponding branch merged in, and successfully run the automated > test suite on it. So, at least we now know it doe

Re: [Tails-dev] What to do about I2P in Tails?

On 7/27/14, Kill Your TV wrote: > On Fri, 25 Jul 2014 11:08:19 + (UTC) > intrigeri wrote: > >> Note: what follows is *not* about finding a solution to the last >> de-anonymization vulnerability found in I2P 0.9.13. I trust the I2P >> team will do a proper job at it. > > A new release is out t

Re: [Tails-dev] What to do about I2P in Tails?

On 7/27/14, intrigeri wrote: > Hi, > > [Re-adding Kill Your TV in the loop, again. kytv, you might want to go > read Jake's message in the list archive.] > > Jacob Appelbaum wrote (27 Jul 2014 02:13:43 GMT) : >> On 7/26/14, intrigeri wrote: >>> Jacob App

Re: [Tails-dev] What to do about I2P in Tails?

give it a try? I'd be happy to > provide guidance and advice. I'd be happy to test it, once I manage to get the ISO build working ( eg: #7661 ). > > Jacob Appelbaum wrote (27 Jul 2014 01:57:23 GMT) : >> I wonder though if that also means that the firewall would be locked &

Re: [Tails-dev] What to do about I2P in Tails?

On 7/26/14, intrigeri wrote: > Hi, > > [Re-adding Kill Your TV in the loop. kytv, you might want to go read > Jake's message in the list archive.] > > Jacob Appelbaum wrote (25 Jul 2014 11:56:05 GMT) : >> On 7/25/14, intrigeri wrote: >>> So, the main goals

Re: [Tails-dev] What to do about I2P in Tails?

On 7/26/14, sajol...@pimienta.org wrote: > intrigeri wrote: >> So, the main goals I have in mind are: >> >> 1. making it harder, for an attacker who compromises I2P running in >> Tails, to upgrade their attack to anything non-I2P; >> >> 2. making it harder, for someone attacking a Tails user

Re: [Tails-dev] What to do about I2P in Tails?

On 7/25/14, intrigeri wrote: > Hi, > > Note: what follows is *not* about finding a solution to the last > de-anonymization vulnerability found in I2P 0.9.13. I trust the I2P > team will do a proper job at it. > > > > I2P is software, software has bugs, and some bugs have security > implications. I

Re: [Tails-dev] firewall rules

Heya, On 7/24/14, intrigeri wrote: > Hi, > > Jacob Appelbaum wrote (24 Jul 2014 21:27:54 GMT) : >> That sounds like a great reason to find a way to make it easy to >> dynamically change the firewall for such an application - can ferm >> easily load different rules

Re: [Tails-dev] firewall rules

On 7/24/14, intrigeri wrote: > Hi, > > (happy to see someone look at these rules in details, and question > part of it!) > Thank you for the positive feedback! > Jacob Appelbaum wrote (24 Jul 2014 01:28:54 GMT) : >> When would we ever have a RELATED or ESTABLIS

[Tails-dev] firewall rules

Hi, I've been looking at ferm.conf and I have some questions. It appears that for ipv6, we have rules that state the following: # IPv6: domain ip6 { table filter { chain INPUT { policy DROP; # Established connections are accepted. mod state state (

[Tails-dev] vpwned

Hi, Some number of years ago, a paper was written about how to cause leakage outside of VPNs and it included Tails as an example target: https://www.usenix.org/system/files/conference/foci12/foci12-final8.pdf I've waited a while for folks to read it and I think at this point, we're at year two

Re: [Tails-dev] Removing or blacklist kernel modules

On 7/21/14, intrigeri wrote: > Hi, > > (Created https://labs.riseup.net/code/issues/7639 to track this all.) > Thanks! > Jacob Appelbaum wrote (21 Jul 2014 19:54:57 GMT) : >> On 7/21/14, intrigeri wrote: >>> However, removing modules altogether is no more work

Re: [Tails-dev] Removing or blacklist kernel modules

On 7/21/14, intrigeri wrote: > Hi, > > Jurre van Bergen wrote (11 Jul 2014 15:20:22 GMT) : >> I feel that it's important to reconsider what we would like to ship >> in Tails as the more kernel modules we load and/or ship we also >> increase the attack vector. > > Fine with me, as there seems to be

Re: [Tails-dev] user-agent analysis and suggestions: hooray!

On 7/21/14, intrigeri wrote: > Hi, > > Jacob Appelbaum wrote (24 Jun 2014 10:56:54 GMT) : >> I think agreeing on a specific user agent and having a central place >> to find it makes the job much easier to tackle. In any case, I think >> setting a few shell aliases

Re: [Tails-dev] user-agent analysis and suggestions: hooray!

Hi, On the subject of generic and easy to maintain fixes, we may also want to investigate using Privoxy: http://www.privoxy.org/user-manual/actions-file.html#HIDE-USER-AGENT Effectively, I think that means we'd want to have privoxy running on the system rather than polipo and that we'd want to

Re: [Tails-dev] user-agent analysis and suggestions: hooray!

On 6/24/14, Daniel Kahn Gillmor wrote: > On 06/24/2014 06:56 AM, Jacob Appelbaum wrote: > [snip interesting discussion of user-agents for human-driven HTTP clients] > >> As for the system itself - I looked at `apt-get update` and found the >> following user agent duri

[Tails-dev] user-agent analysis and suggestions: hooray!

Heya, On 6/23/14, intrigeri wrote: > Hi, > > Jacob Appelbaum wrote (22 Jun 2014 16:16:17 GMT) : >> On 6/22/14, intrigeri wrote: >>> On the other hand, the fingerprint of curl probably differs in many >>> other ways. So, for an attacker that looks at it mor

Re: [Tails-dev] Setting curl's user-agent to the same as Tor Browser?

On 6/22/14, intrigeri wrote: > Hi, > > on the one hand, for an attacker that only looks at the user-agent > header, telling curl to use the same value for it as the Tor Browser > would make it part of a larger anonymity set. > That is correct. It also has a secondary effect: curl has a crazy user

Re: [Tails-dev] grsec [Was: Upgrading the Linux kernel for 1.0?]

On 4/5/14, intrigeri wrote: > Hi, > > Jacob Appelbaum wrote (05 Apr 2014 08:26:27 GMT) : >>> 2. the Linux maintainers in Debian, and the stable release >>>manager, get an idea of how much critical paths are extended in >>>practice...

Re: [Tails-dev] Tails usability feedback?

Heya intrigeri, There are a few key issues - one is the difficulty of installing Tails, the next is the difficulting of upgrading it (pre-incremental updates; though that is broken for me on one machine), and the finally - the actual use of Tails is another story. I'm not sure how to best list ou

Re: [Tails-dev] grsec [Was: Upgrading the Linux kernel for 1.0?]

On 4/4/14, intrigeri wrote: > Hi, > > Jacob Appelbaum wrote (04 Apr 2014 12:52:59 GMT) : >> I'd be interested in trying to get a grsec patched kernel > > This is awesome news for Debian and Tails! I've had some discussions with Spender, the main grsec person a

Re: [Tails-dev] Upgrading the Linux kernel for 1.0?

I'd be interested in trying to get a grsec patched kernel into 1.0 or 1.1 - how do we suppose we could make this happen? I discussed this with another Debian developer and they felt that a kernel flavor is the way to go. How might we ship grsec + pax to end users? What would be useful here for me

Re: [Tails-dev] Risks of enabled/disabled TCP timestamps?

intrigeri: > Hi, > > it was brought to our attention (thanks Jacob!) that TCP timestamps > (net.ipv4.tcp_timestamps) are enabled in Tails, and this might be > a problem. > No problem. Glad to help, if it is actually helpful! > In a nutshell, we're said that the risks that go with the current >

Re: [Tails-dev] Last steps toward enabling incremental upgrades by default [Was: Please test incremental upgrades (from 0.22~rc1 to 0.22~rc2)]

intrigeri: > Sounds good, did I miss anything? > I would suggest including a small shell script and one utility to test the integrity of a tails release - something as simple as md5deep. Once we start to change the Tails disk, we really want to ensure that an attacker can't stick around past a r

Re: [Tails-dev] screen blanking and locking up with 0.20?

sajol...@pimienta.org: > On 14/08/13 04:14, Jacob Appelbaum wrote: >> Hi, >> >> I've noticed that since upgrading 0.20 that one of my Tails enabled >> laptops has some issues. Namely - after the system is idle for a while - >> say ~10 minutes - the screen blan

[Tails-dev] screen blanking and locking up with 0.20?

Hi, I've noticed that since upgrading 0.20 that one of my Tails enabled laptops has some issues. Namely - after the system is idle for a while - say ~10 minutes - the screen blanks and then the system appears to have locked up. I've heard this from a few other Tails users - though there isn't anyt

[Tails-dev] Tahoe-LAFS, Tor and Tails

Greetings from Berlin, Leif and I have been working on ways to deploy, use and sync data with Tahoe on Tails. Tails[0] is a live CD based on Debian GNU/Linux that is supported by the Tor Project. It is intended to lose state after every shutdown, unless a user configures it to keep certain bits of

[Tails-dev] download over http by default?

Hi, When upgrading a tails machine today, I noticed that the default download link is HTTP. We've done some statistics on the number of users that actually bother to download signatures - it basically borders on none for some software. Does Tails find that for every ISO, users download the signatu

Re: [Tails-dev] Tails contributors meeting: July 2

intrigeri: > Hi, > > the first Tails developers meeting that will happen in the open is > scheduled for July 2, on #tails-dev (OFTC) at 8pm UTC (10pm CEST). > Every Tails contributor is welcome to attend. Sorry for the > short notice. Great - I'm happy to join! Thanks for making it happen and let

Re: [Tails-dev] Tails report for April, 2013

Tails folks: > > Releases > > > Tails 0.17.2 was released on April 9th. > > https://tails.boum.org/news/version_0.17.2/index.en.html Hooray! Thanks for your great work on this project! > > > Metrics > === > > - 121 183 connections of Tails to the Tor network. This makes a boot

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

Maxim Kammerer: > On Thu, Apr 18, 2013 at 1:18 AM, Jacob Appelbaum 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 us

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

adrelanos: > Jacob Appelbaum: >> adrelanos: >>>> >>>> We already fail this test, no? >>> >>> Not necessarily. This is a difficult question. >>> >> >> Tor does not hide that you are using Tor > > Yes, but... While ma

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

adrelanos: > Jacob Appelbaum: >> Elly Fong-Jones: >>> On Tue, Apr 16, 2013 at 01:03:27PM +0200, intrigeri wrote: >>>> Hi Jacob and Elly, >>>> >>>> Thanks for your answers! See more questions bellow. >>>> >>>> Jacob A

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

adrelanos: >> >> We already fail this test, no? > > Not necessarily. This is a difficult question. > Tor does not hide that you are using Tor and using Tails or Whonix is an example of a system only emitting Tor traffic. It depends on your threat model but generally, we'd just making up "someone

Re: [Tails-dev] secure and simple network time (hack)

adrelanos: > Jacob Appelbaum: >> adrelanos: >>> Jacob Appelbaum: >>>> If I were to reinvent the wheel without having read any of tordate's >>>> source, I would: >>>> >>>> open the consensus or the cached-microdescs >>

Re: [Tails-dev] secure and simple network time (hack)

adrelanos: > Jacob Appelbaum: >> If I were to reinvent the wheel without having read any of tordate's >> source, I would: >> >> open the consensus or the cached-microdescs >>parse the absolute minimum time >> stat the respective file to see the l

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

intrigeri: > Hi, > > adrelanos wrote (17 Apr 2013 19:33:23 GMT) : >> Why not build the required features into Tor itself? > > (Let's assume this is no rhetorical question.) > > My best guess is that nobody had 1. enough interest in this topic; 2. > the right set of skills; 3. enough free time. I

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

intrigeri: > Hi, > > Jacob Appelbaum wrote (17 Apr 2013 08:58:32 GMT) : >> What version of htpdate are you shipping currently? > > This is documented there: > https://tails.boum.org/contribute/design/Time_syncing/#index2h2 > OK, so the perl version initially made me

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

intrigeri: > Jacob, are you interested in implementing something like our current > multiple pool -based approach [2], or something else with similar > security properties? What version of htpdate are you shipping currently? I've just been reading the source for htpdate-1.0.4 - is that the right v

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

Hi, intrigeri: > Hi Jacob and Elly, > > Thanks for your answers! See more questions bellow. > > Jacob Appelbaum wrote (11 Apr 2013 06:56:18 GMT) : >> Basically - tlsdate in Tails would be a minor set of users compared to >> the much larger user base of ChromeOS. >

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

Elly Fong-Jones: > On Tue, Apr 16, 2013 at 01:03:27PM +0200, intrigeri wrote: >> Hi Jacob and Elly, >> >> Thanks for your answers! See more questions bellow. >> >> Jacob Appelbaum wrote (11 Apr 2013 06:56:18 GMT) : >>> Basically - tlsdate in Tails would b

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

Maxim Kammerer: > On Fri, Jul 20, 2012 at 3:07 AM, Jacob Appelbaum 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.

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

Elly Jones: > On Fri, Apr 12, 2013 at 02:43:13PM +0300, Maxim Kammerer wrote: >> On Fri, Jul 20, 2012 at 3:07 AM, Jacob Appelbaum wrote: >>> Allow me to be very explicit: it is harder to parse an HTTP Date header >>> than properly than casting a 32bit integer an

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

intrigeri: > Hi, > > Jacob Appelbaum wrote (19 Jul 2012 23:48:48 GMT) : >> intrigeri: >>> So, Jake tells me that ChromeOS will use tlsdate by default, and that >>> this should solve the fingerprinting issue. Therefore, I assume this >>> implicitly answer

[Tails-dev] Reviewed laptops?

Hi, I was discussing laptop choices for use with tails today; I wasn't able to find an easy reference for laptops that people suggest for use with Tails. It would be nice to have a list of laptops, especially cheap netbooks, that work flawlessly with Tails - as a bonus, it would be nice to note w

Re: [Tails-dev] TorBirdy: first impressions

intrigeri: > Hi, > >> Jacob Appelbaum wrote (22 Jun 2012 01:00:01 GMT) : >>> What do we need to fix or do for you to ship TorBirdy? > > We need a way to configure TorBirdy so that it does *not* disable the > account creation wizard -- currently fails with "To

Re: [Tails-dev] Icedove modifications

intrigeri: > hi, > > since I had much more urgent stuff to do yesterday, I've rebased our > Icedove patchset on top of current sid's one, uploaded the resulting > packages to the feature-icedove APT suite, updated the feature/icedove > Git branch so that it builds and uses these packages. I don't

Re: [Tails-dev] performance test: randomsound vs haveged

adrelanos: > Hi, > > I've done a performance test to answer the following questions: > - Is randomsound faster than haveged or vice versa? > - Do they block each other or result in even more entropy available? > I've given up on randomsound for actual long term use - it makes sound entirely unus

Re: [Tails-dev] Support EntropyKey?

anonym: > 26/11/12 16:40, Jacob Appelbaum wrote: >> intrigeri: >>> Hi, >>> >>> we're asked to install ekeyd to support EntropyKey: >>> https://tails.boum.org/todo/Install_ekeyd_for___40__potentially__41___better_entropy/ >>> >>&

Re: [Tails-dev] Support EntropyKey?

Maxim Kammerer: > On Mon, Nov 26, 2012 at 5:40 PM, Jacob Appelbaum 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 ap

Re: [Tails-dev] Support EntropyKey?

intrigeri: > Hi, > > we're asked to install ekeyd to support EntropyKey: > https://tails.boum.org/todo/Install_ekeyd_for___40__potentially__41___better_entropy/ > > The total installed size of the needed packages is a few hundred > kilobytes. I think it's worth adding to improve cryptography -rel

Re: [Tails-dev] Tails: pcmcia / firewire / etc.

Ague Mill: > On Fri, Oct 12, 2012 at 06:15:07PM -0700, Steve Weis wrote: >> Hi. I booted Tails' latest release and was able to scrape memory contents >> via FireWire. All the necessary firewire modules are enabled by default and >> Inception worked out of the box. This would let someone root a mach

Re: [Tails-dev] Tails: pcmcia / firewire / etc.

Maxim Kammerer: > On Sat, Oct 13, 2012 at 1:30 AM, Jacob Appelbaum > 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/ > >> >

Re: [Tails-dev] Download manager

Alan: > Hi, >> From: intrigeri >> Date: Fri, 28 Sep 2012 17:47:50 +0200 >> >> Hi, >> >> a...@boum.org wrote (26 Sep 2012 17:44:20 GMT) : >>> https://tails.boum.org/todo/include_download_manager/ >>> - >>> [...] it might be useful to i

Re: [Tails-dev] Tails: pcmcia / firewire / etc.

Alan: > Hi, > >>> * de-activate PCMCIA and ExpressCard on systems that don't have any >>> PCMCIA or ExpressCard devices after running for 5 minutes. This is >>> going to byte some users, but probably only the first time. >> >> I am strongly inclined towards this one, for PCMCIA, ExpressCard >>

Re: [Tails-dev] Faking htpdate user agent worth it?

adrelanos: > Jacob Appelbaum: >> adrelanos: >>>>> Thus my suggestions: >>>>> - Keep only header. Safe users traffic, Tor's traffic and website traffic. >>>>> - Drop the user agent setting, it only gives a false sense of being in >>&g

Re: [Tails-dev] Faking htpdate user agent worth it?

adrelanos: >>> Thus my suggestions: >>> - Keep only header. Safe users traffic, Tor's traffic and website traffic. >>> - Drop the user agent setting, it only gives a false sense of being in >>> the same anonymity set as Tor Button. >> >> That is not the goal - the point is that you will say, drop t

Re: [Tails-dev] Faking htpdate user agent worth it?

adrelanos: > Jacob Appelbaum: >> intrigeri: >>> Hi, >>> >>> adrelanos wrote (30 Sep 2012 22:25:31 GMT) : >>>> I am wondering about this line in /etc/default/htpdate: >>>> HTTP_USER_AGENT="$(/usr/local/bin/getTorbuttonUserAgent)"

Re: [Tails-dev] Faking htpdate user agent worth it?

intrigeri: > Hi, > > adrelanos wrote (30 Sep 2012 22:25:31 GMT) : >> I am wondering about this line in /etc/default/htpdate: >> HTTP_USER_AGENT="$(/usr/local/bin/getTorbuttonUserAgent)" > > FTR, this is left from the times when htpdate did run wget in the > clear (without going through Tor). > >

Re: [Tails-dev] Faking htpdate user agent worth it?

adrelanos: > Jacob Appelbaum: >> I'd be interested in using the same headers for tlsdate - so whatever >> you guys end up using - lets try to make them look similar? > > curl is already a good choice. Supports socks proxy settings, ssl > certificate pinning, str

Re: [Tails-dev] Faking htpdate user agent worth it?

adrelanos: > Hello, > > I am wondering about this line in /etc/default/htpdate: > HTTP_USER_AGENT="$(/usr/local/bin/getTorbuttonUserAgent)" > > Since you are also using curl and only download the header, does faking > the Tor Button user agent provide any additional benefit? Couldn't the > server

Re: [Tails-dev] Erase memory: the GRUB way

Ague Mill: > On Sun, Aug 26, 2012 at 10:30:18AM +, Ague Mill wrote: >> For the patch and some details, please see: >> >> >> I have not tested it on bare metal, only qemu and bochs. >> >> The next step is to create a proper "sta

Re: [Tails-dev] Tails: pcmcia / firewire / etc.

intrigeri: > Hi, > > Jacob Appelbaum wrote (22 Aug 2012 21:01:22 GMT) : >> Pop up a dialog and ask "hey, you want to use firewire?" - at least >> if they had enabled a password, they will have to bypass a screen >> lock or authenticate to enable full

Re: [Tails-dev] vpwns:

Ague Mill: >> In our (I'm cc'ing Marsh here, please keep him in the cc list unless he >> objects) recent FOCI12 paper, we discuss some novel attacks on VPNs and >> we focus on anonymity related issues. Largely, I think that this paper >> is not news to Tails developers, I even sent in a per-release

[Tails-dev] vpwns:

Hi, In our (I'm cc'ing Marsh here, please keep him in the cc list unless he objects) recent FOCI12 paper, we discuss some novel attacks on VPNs and we focus on anonymity related issues. Largely, I think that this paper is not news to Tails developers, I even sent in a per-release copy months in ad

Re: [Tails-dev] ***SPAM*** Re: Tails: pcmcia / firewire / etc.

intrigeri: > Hi, > > Jacob Appelbaum wrote (22 Aug 2012 19:17:02 GMT) : >> I'm not sure, so I'd still disable it until you have a forensics >> toolkit or three that fails to work. > > Fair enough, so I updated our ticket to reflect that we should > act

[Tails-dev] ***SPAM*** Re: Tails: pcmcia / firewire / etc.

intrigeri: > Hi Jake, > > Jacob wrote (late 2011): >>> Disable all firewire kernel modules. This will help fight against >>> forensics programs that will attempt to suck out memory with the >>> internal firewire or a cardbus/pcmcia card. > > And ta...@boum.org replied (05 Jan 2012 23:54:40 GMT) :

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

Maxim Kammerer: > On Wed, Jul 18, 2012 at 7:31 AM, intrigeri 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 >

  1   2   >