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

[Jacob Appelbaum]

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 but limit it to known good ICMP messages.
>
> Yes, this was proposed on the thread; in the email you're replying to
> I explained why I didn't pick this option, mainly because no (pseudo-)
> implementation thereof has been proposed nor discussed yet.

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 vulnerable to things we wrote in our paper (vpwned).
Allowing users by default to make non-tor connections, except for
specific pluggable transports or dhcp, will probably ensure that
variations on the disclosed issues stay relevant.

If a user wants to use a printer or touch the local subnet, why not
make them jump through a (`sudo unsafe-network-unlock`) hoop? Why
leave every other user vulnerable by default?

All the best,
Jacob
___
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] Fwd: Re: Reducing attack surface of kernel and tightening firewall/sysctls

[Jacob Appelbaum]

On 2/14/16, intrigeri <intrig...@boum.org> 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 vulnerable to things we wrote in our paper (vpwned).
>> Allowing users by default to make non-tor connections, except for
>> specific pluggable transports or dhcp, will probably ensure that
>> variations on the disclosed issues stay relevant.
>
>> If a user wants to use a printer or touch the local subnet, why not
>> make them jump through a (`sudo unsafe-network-unlock`) hoop? Why
>> leave every other user vulnerable by default?
>
> I think you're confusing this thread with another one,
> that is totally orthogonal as I see it.
>

I was specifically replying to this bit:

>> A conservative change to the tails config would be to keep an RELATED
>> rule but limit it to known good ICMP messages.

It seems odd to call that a conservative change, also.

All the best,
Jacob
___
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] AppArmor policy vs. hard links [Was: MFSA 2015-78 (aka. CVE-2015-4495) vs. Tails]

[Jacob Appelbaum]

On 8/8/15, intrigeri intrig...@boum.org 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 things. That second file path is allowed
 by the sandbox, even though the file is also outside of that path,
 AppArmor has no clue.

 Right, thanks for refreshing my memories :)

Sure thing.


 Reading the policy for Tor Browser on Tails 1.4.1 - I see the
 following relevant entries:
 [...]
 Note that none of those include the flag l - which is what is
 required to make a hard link. That was why I said until an attacker
 figures out how to make a hard link; if such a hardlink were made,
 they'd be able to read the contents of the linked file. That is all
 that I meant with my comment. AppArmor is useful but has some rough
 edges.

 OK. I've filed https://labs.riseup.net/code/issues/9949 about it, and
 after an initial evaluation of our current AppArmor policy, it seems
 everything is good... except the I2P confinement, but that one is
 still WIP (#7724), and the version we currently ship should merely be
 regarded as a technology preview, that's only marginally better
 than nothing.


Ok.

 It would be awesome if someone double-checked my findings. E.g.
 the regexp I've used might be buggy and miss some problematic rules.
 Jacob, perhaps?


I wouldn't call it an audit but I agree with your initial findings.

All the best,
Jacob
___
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] MFSA 2015-78 (aka. CVE-2015-4495) vs. Tails

[Jacob Appelbaum]

On 8/7/15, intrigeri intrig...@boum.org 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~rc1 is affected, but
 our AppArmor policy should mitigate the worst possible consequences,
 so I doubt it's worth adding to the RC announce's known
 issues section.

 If anyone has more insight or disagrees, let me know.


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. The bad news is that it
isn't fixed in esr31 - so while they have fixes in for ff38 - it isn't
because that was the only problematic version. :-(

( I think the apparmor profile may contain some of the worst aspects
but only until an attacker figures out how to make a hard link. That
is not a super high bar for code execution but will at least stop
random files from being included without a multi-bug payload. )

All the best,
Jacob
___
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] MFSA 2015-78 (aka. CVE-2015-4495) vs. Tails

[Jacob Appelbaum]

On 8/7/15, intrigeri intrig...@boum.org 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 their enterprise list that
 FF31 is not affected.

By the exploit, as I understood things? I could be mistaken and
probably am mistaken. I've heard that the vulnerable code is in FF31 -
I haven't looked myself yet.


 ( I think the apparmor profile may contain some of the worst aspects
 but only until an attacker figures out how to make a hard link.

 May you please elaborate on the hardlink aspect?  It rings a bell, but
 I don't remember the specifics.

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 things. That second file path is allowed
by the sandbox, even though the file is also outside of that path,
AppArmor has no clue.

You can test this by doing the following:

  mkdir ~/OUTOFSANDBOX/
  touch  ~/OUTOFSANDBOX/apparmor.txt
  echo out of sandbox   ~/OUTOFSANDBOX/apparmor.txt
  ln  ~/OUTOFSANDBOX/apparmor.txt ~/Tor\ Browser/apparmor.txt

If you then want to read that ( ~/Tor\ Browser/apparmor.txt ) file
with Tor Browser - it will work.

Reading the policy for Tor Browser on Tails 1.4.1 - I see the
following relevant entries:

  owner @{HOME}/Tor Browser/ rw,
  owner @{HOME}/Tor Browser/** rwk,
  owner @{HOME}/Persistent/Tor Browser/ rw,
  owner @{HOME}/Persistent/Tor Browser/** rwk,
  owner /live/persistence/TailsData_unlocked/Persistent/Tor Browser/ rw,
  owner /live/persistence/TailsData_unlocked/Persistent/Tor Browser/** rwk,
  owner @{HOME}/.mozilla/firefox/bookmarks/places.sqlite rwk,
  owner /live/persistence/TailsData_unlocked/bookmarks/places.sqlite rwk,
  owner @{HOME}/.tor-browser/profile.default/ r,
  owner @{HOME}/.tor-browser/profile.default/** rwk,

Note that none of those include the flag l - which is what is
required to make a hard link. That was why I said until an attacker
figures out how to make a hard link; if such a hardlink were made,
they'd be able to read the contents of the linked file. That is all
that I meant with my comment. AppArmor is useful but has some rough
edges.

All the best,
Jacob
___
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] MFSA 2015-78 (aka. CVE-2015-4495) vs. Tails

[Jacob Appelbaum]

On 8/7/15, jvoisin julien.voi...@dustri.org 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
 preferences (remember http://net.ipcalf.com/ ?), executing code inside
 the browser, …

I believe that the newest Tor Browser alpha will provide a fix. I hope
Mike will chime in here...


 This seems pretty serious to me, since people expect the web-browser to
 be reasonably trustworthy.

Agreed.

All the best,
Jacob
___
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] MFSA 2015-78 (aka. CVE-2015-4495) vs. Tails

[Jacob Appelbaum]

On 8/7/15, Georg Koppen g...@torproject.org wrote:
 Jacob Appelbaum:
 On 8/7/15, jvoisin julien.voi...@dustri.org 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
 preferences (remember http://net.ipcalf.com/ ?), executing code inside
 the browser, …

 I believe that the newest Tor Browser alpha will provide a fix. I hope
 Mike will chime in here...

 I don't know what kind of fix you have in mind. All we'll provide is an
 update to ESR 38.2.0. We are basically about to tag the things and start
 building. ETA for the alpha is probably Tuesday.

Ah ha - great. Thank you for chiming in!

The current Tails Tor Browser is 4.5.3 (based on Mozilla Firefox
31.8.0) - so the new alpha won't change anything and the current
browser shouldn't be impacted by it.

Did I understand that correctly?


 That said Mozilla's reasoning for not doing a chemspill for ESR 31 was

 we determined that the vulnerability isn't present in the current 31
 ESR.

Hey - that's great news - thanks for clearing that up!


 That's a quote from Liz Henry, the Firefox release manager.


Perfect - thank you!

All the best,
Jacob
___
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] Tails and forensics

[Jacob Appelbaum]

On 12/11/14, Austin Hartzheim aus...@austinhartzheim.me 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 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
 interested in creating a hash for every file ever released - is
 there an archive of old signature files and .iso files somewhere?

 I have kept some old ISO files specifically for cases like this, but I
 never got around to doing anything with them.

Great!


 I noticed that at some files I have are missing from your Git
 repository.  If you want, I will happily fork the repository and add
 the missing signatures/hashdeep output. Also, if you want to attain
 these files yourself, I can probably find a way to make them available
 assuming you cannot find them elsewhere.


I'd like to attain and verify the files myself. Could you put them
online somewhere for me to mirror them?

 Here is the list of versions I have the ISOs and signatures for:

 tails-i386-0.21
 tails-i386-0.22.1
 tails-i386-0.22.1~rc1
 tails-i386-0.22.1~rc1
 tails-i386-0.23
 tails-i386-1.0.1
 tails-i386.1.0-beta
 tails-i386-1.0
 tails-i386-1.1
 tails-i386-1.1.1
 tails-i386-1.2
 tails-i386-1.2.1

 Perhaps I can dig up a few more, but I'm not sure.


I'd be very happy to download and add all of those to the git repository.

All the best,
Jacob
___
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] minimalist/anonymity-preserving DHCP clients [was: Re: Reducing attack surface of kernel and tightening firewall/sysctls]

[Jacob Appelbaum]

On 12/9/14, Daniel Kahn Gillmor d...@fifthhorseman.net wrote:
 On 12/04/2014 10:37 AM, Jacob Appelbaum wrote:
 On 12/4/14, Daniel Kahn Gillmor d...@fifthhorseman.net wrote:

 I'm not sure i'd characterize a simple DHCP client as quite straight
 forward, but certainly minimalist one is more straightforward than one
 which handles all the possible extensions that have cluttered DHCP over
 the years.

 We've already written the start of very basic non raw socket DHCP
 client - it doesn't yet include the parser and later stages but it
 does fetch leases. It is completely straight forward with the basic
 socket API. It is absolutely not required to use a raw socket but it
 requires some trickery with the rp_filter in the kernel.

 I'm happy to hear about your progress!  can you point to the code
 someplace for people who are interested to review it?


The project isn't in a state where it makes any sense at all to share
it. It should not be used and we're just experimenting. Currently,
we've found a way to run without raw capabilities, which is a huge
security improvement. This is however a far far cry from a DHCP
client.

 The parsers for any dhcp client are of course rather annoying and the
 rest of the hooks are too. However - remember the DHCP client that
 talks to the *network* does not need to do anything other than the
 full DHCP lease process. Thus with the right design, a minimal or a
 full client are something in another process anyway.

 Getting the thing to a state where it's usable for normal people with
 normal computers encompasses the whole scope, so the project will have
 to deal with the stickier parts eventually.


Hrm. I think not - I think a DHCP client needs to do four basic things
- everything else can be handled by a small daemon that deals with
timers, user space and kernel configuration and so on. In an ideal
world, I'd like to have a very slim thing that touches the network and
then reuse a lot of other code for everything else.

 I'd be happy to talk with them. Please do introduce me to them in some
 way?

 done offlist.  hopefully we can produce something useful :)

Hope so too - thank you!


  * specify the lease renewal behavior algorithm

 It seems rather straight forward to use the time offered by the server
 - what else do you think is important to consider?

 the time offered by the server tells you when the lease expires.  it's
 up to the client to decide when to try to renew (t/2 seconds?  t - 20
 seconds?  something else? how does it deal with weird values for t like
 very small or very large values?).  It's also up to the client to decide
 how to deal with the renewal when ACKs are delayed or not forthcoming.


I think MAC address randomization and captive portals are two other
issues that are directly related too.

 Specifying all of the fiddly optional parameters of the renewal strategy
 would help implementations avoid being fingerprintable based on timing
 as well as content.

I certainly think that is a good goal. The first step will be to have
a minimalist dhcp client - once we have that, I think you're correct,
we should consider how to make that a uniform privacy enhancing DHCP
client.

All the best,
Jacob
___
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] Tails and forensics

[Jacob Appelbaum]

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
interested in creating a hash for every file ever released - is there
an archive of old signature files and .iso files somewhere?

How are IUK files verified? The JSON descriptors don't appear to
contain a signature, merely a hash:

  https://tails.boum.org/upgrade/v1/Tails/1.2/i386/stable/upgrades.yml

Regarding the file system layout - at the moment - we have a vfat file
system starting at 17.4kB - what's in that 17.4kB of data?

I also wonder about isohybrid - has anyone looked into making it deterministic?

In the future, I'll write a program that uses the dataset in a useful
manner. In an ideal world, we'd have a way to use a Tails disk to
verify any other Tails disk.

All the best,
Jacob
___
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] [review'n'merge:1.2.1] feature/7740-remove-truecrypt

[Jacob Appelbaum]

On 12/5/14, sajolida sajol...@pimienta.org wrote:
 Jacob Appelbaum:
 On 12/4/14, intrigeri intrig...@boum.org 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 (or earlier, I don't remember):
 https://tails.boum.org/doc/encryption_and_privacy/truecrypt/

 Most of your TrueCrypt users are not on the tails-dev list, I guess?

 I think it makes sense to remove TrueCrypt - it may also be that an
 announcement about how to use TrueCrypt and the replacement are also
 important for prominent blog entry or website update before the next
 major release.

 What intrigeri wanted to say is that since 1.2, when starting TrueCrypt,
 people were warned that it would be removed in 1.2.1 and pointed to that
 piece of documentation explaining how to open TC volume with cryptsetup.


OK. That makes sense - though I suspect that many will simply forget
or will not have understood.

 So people actively using TrueCrypt have been pointed to that doc and
 already know how to continue using their existing volumes in 1.2.1.

 I find this more elegant than hammering the blog about the end of a
 feature that that has been deprecated for years.


Many users that I know use Tails specifically for TrueCrypt - even if
it is considered deprecated, it is still one of the safest, easy and
contained ways to use TrueCrypt.

We'll see from support requests what happens, I think.

All the best,
Jacob
___
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] Reducing attack surface of kernel and tightening firewall/sysctls

[Jacob Appelbaum]

On 12/4/14, anonym ano...@riseup.net 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 lifting that is not needed by using the conntrack kernel code:

 While I think we should investigate whether RELATED can be dropped for
 the reasons you outline but adding NEW seems like a mistake.

Ok. That sounds good - I was thinking that NEW may be required for
OUTPUT (not INPUT) but I think I'm totally wrong. I'm glad to see
that! Thank you!

  In fact, I
 see no discussion why it should be there at all, so please clarify its
 purpose.

 From iptables(8):

 NEWmeaning that the packet has started a new connection, or
otherwise associated with a connection which has not seen
packets in both directions

 That sounds pretty bad. In my tests of your suggested rule, Tails' Tor
 enforcement [1] is broken:

 unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY
 curl https://check.torproject.org | grep Your IP address

 and so is the local services whitelist [2]:

 nc -l -p 1234 
 echo if you receive this, then you are pwned | nc 127.0.0.1 1234

 Or am I missing something obvious here?


I think you're exactly correct. NEW is not needed, I think.

 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
 exploits didn't work due to the absence of NEW.

Great - I'm glad to hear it!

All the best,
Jake
___
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] Reducing attack surface of kernel and tightening firewall/sysctls

[Jacob Appelbaum]

On 12/4/14, Oliver-Tobias Ripka o...@bockcay.de 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 renewal (request, ack) should be
 blocked as the Ack is a response to the request.

That sounds good all around.


 Doing some research I found that one possible explaination is that the
 dhclient uses raw sockets which get the packet even if netfiler rules
 are in place [1], [2].

Yes. dhclient uses raw sockets to get around the rp_filter in the
kernel, for one.


 This seems to be true: lsof -f | grep dhclient:

 dhclient  7946 root5u pack 34603 0t0 ALL type=SOCK_PACKET
 dhclient  7946 root6u IPv4 34605 0t0 UDP *:bootpc
 dhclient  7946 root   20u IPv4 34571 0t0 UDP *:45935
 dhclient  7946 root   21u IPv6 34577 0t0 UDP *:44461

 One would need to dig deeper into the dhclient code in order to check if
 this RAW socket is really necessary and if there are e.g. compile time
 options that would allow to just use UDP sockets (note also that
 dhclient does both it opens udp:68 and a raw socket) that would be
 filterable by the firewall.

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 lease without being root and without
having a raw socket. It is surprising that absolutely no one has done
this in the past. I think everyone just looked at the ISC DCHP code
and cargo culted from that point forward.


 In general it might be better for security to have a derooted DHCP
 client that does not need CAP_NET_RAW and also has less attack surface
 then dhclient (C code + shell scripts).

I completely agree. The DHCP client in Tails is a major attack vector.
I think that we could patch the ISC daemon, for example, to do some
tricks - if we didn't want an outright replacement. If anyone is
interested in this and would actually use some patches. I'm wary of
starting such a process if it will not be used. I'd rather focus on
writing a totally different dhcp client from scratch.  My experience
with writing tlsdate really influences me on this with regard to
Tails.

 Maybe use a small replacement
 client that does only support bare minimum needed to get an IP4/6 and
 not the whole spec (instead of trying to fix dhclient)? Anyways, some
 efforts for dhclient are made here [3].

I think a simple DHCP client is quite straight forward - integration
with Network-Manager is probably more difficult than a simple DHCP
network client.

All the best,
Jacob
___
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] [review'n'merge:1.2.1] feature/7740-remove-truecrypt

[Jacob Appelbaum]

On 12/4/14, sajolida sajol...@pimienta.org 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 persistence
 feature's docs, I think it would be convenient if we would link to it
 directly in that info bubble because probably that is what the user
 actually wants, since the integration into Tails makes it so easy to
 use.

 I'm not sure. I kinda like the current two-steps thing, to explain
 first the alternatives in terms of on-disk format / encryption, and
 then the integration. sajolida, others?

 Sorry for not answering this before. I have a tiny bit of backlog :)

 I pushed two commits to fix this. Honestly, I haven't thought about
 mentioning persistence on that page before. This is commit 0f41c36.

 I also lowered the level of this warning on the persistence page to
 tip (because it is not dangerous as such). This is commit 68ffa07.

 So please review and merge again feature/7740-remove-truecrypt into master.


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
another platform unless they can still mount, use and create those
kinds of volumes in the future.

I'm late to the party and generally support pushing for the end of
TrueCrypt in favor of dmcrypt/LUKS. Still - I worry majorly about this
change as it is already a hidden option...

All the best,
Jacob
___
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] 1.2.1 broken for install/upgrade?

[Jacob Appelbaum]

On 12/4/14, BitingBird bitingb...@riseup.net 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 is:
 https://git-tails.immerda.ch/tails/tree/features/usb_install.feature

 Cheers,

 Make sure your USB stick is not listed there:

 https://tails.boum.org/support/known_issues/index.en.html#index1h2


It has nothing to do with the USB stick as far as I can tell. I am
booting from a burned (gpg signature verified) ISO on a DVD reader.
When I attempt to launch the installer/upgrader - it starts but any
button click fails to open subsequent programs. This happens with or
without the USB stick inserted. The USB stick was running Tails 1.2
without issue.

 If it isn't, please follow :

 https://tails.boum.org/doc/first_steps/bug_reporting/index.en.html


I've filed a bug with WhisperBack.

All the best,
Jacob
___
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] [review'n'merge:1.2.1] feature/7740-remove-truecrypt

[Jacob Appelbaum]

On 12/4/14, intrigeri intrig...@boum.org 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
 another platform unless they can still mount, use and create those
 kinds of volumes in the future.

 Except creating such volumes, every other thing has been possible,
 documented and advertised to people every time they use TrueCrypt
 since Tails 1.2 (or earlier, I don't remember):
 https://tails.boum.org/doc/encryption_and_privacy/truecrypt/

Ok. That confirms what I had in my memory.


 I'm late to the party and generally support pushing for the end of
 TrueCrypt in favor of dmcrypt/LUKS. Still - I worry majorly about this
 change as it is already a hidden option...

 This has been discussed on this list for ages, so raising such
 concerns only after the last step of the plan has been released,
 oh well.


Most of your TrueCrypt users are not on the tails-dev list, I guess?

I think it makes sense to remove TrueCrypt - it may also be that an
announcement about how to use TrueCrypt and the replacement are also
important for prominent blog entry or website update before the next
major release.

All the best,
Jacob
___
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] Reducing attack surface of kernel and tightening firewall/sysctls

[Jacob Appelbaum]

On 12/4/14, Oliver-Tobias Ripka o...@bockcay.de 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
 exploits didn't work due to the absence of NEW.

 You're right it work with ESTABLISHED only. This is due to whitelisted
 rule for the debian-tor user that may send any kind of packet.

That is what I'd expect, yes. We should also tighten that user down as
well. What do you think for the first iteration?


 We might consider harden this rule to prevent leaks of other protocols
 by the debian-tor user; basically restrict it to only allow TCP SYN
 packets. The rest would be handled by the stateful rule.


Yes, I think ESTABLISHED makes sense and to have different users per
pluggable transport - for example.

All the best,
Jacob
___
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] Reducing attack surface of kernel and tightening firewall/sysctls

[Jacob Appelbaum]

On 12/4/14, Oliver-Tobias Ripka o...@bockcay.de 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
 within Tails and it seems to have also UDP firewall requirements [1]
 that need to be tested.

I think I2P needs different rules and of course to run as a different user, yes.

All the best,
Jacob
___
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] Reducing attack surface of kernel and tightening firewall/sysctls

[Jacob Appelbaum]

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 to our iptables rules. Looking at Ferm, the
firewall rules say something that is extremely common which is as
follows for INPUT and OUTPUT:

mod state state (RELATED ESTABLISHED) ACCEPT;

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 lifting that is not needed by using the conntrack kernel code:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/netfilter?id=refs/tags/v3.18-rc7

Take a look at the various nf_conntrack_*.c files to see the various
parsers that are exposed by using the RELATED connection tracking
state. We should never need the kernel to automatically modify the
firewall - as an example, we do not need it to setup an incoming FTP
session based on the kernel believing that we've tried to do an
outgoing FTP session. An old example of this kind of trick is
demonstrated here:

  http://www.securiteam.com/unixfocus/5DP0B2040S.html

An example of how RELATED opens up the firewall is written here:

  https://home.regit.org/netfilter-en/secure-use-of-helpers/

Now, I think that the older exploit above is not functional but I
admit, I haven't tested it or thought about how it may be extended for
the current kernel. That however doesn't convince me that we should
ever have that code exposed on a deployed Tails system. Unless RELATED
literally does nothing, I think it adds attack surface - how much is
an open research question. On the other hand, if RELATED does nothing,
we should remove it, it isn't needed as far as I see.

There are two basic issues that fell out of the discussion today: one
where an incoming connection is allowed, another where the parser has
a bug which is exploitable. Neither is required for our uses, right?
Both are actually harmful to our use cases, I think.

Some of the modules are written by very talented programmers and I'm
sure they're well written. Still, if you look at the code, you'll see
that they literally do IRC or Amanda parsing in the kernel. Here are
some examples:

Amanda:  
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/netfilter/nf_conntrack_amanda.c?id=refs/tags/v3.18-rc7

pptp: 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/netfilter/nf_conntrack_pptp.c?id=refs/tags/v3.18-rc7

If we look at on the latest Tails, we'll see
/proc/sys/net/netfilter/nf_conntrack_helper is set to 1. I propose
that we set it to 0. We do not want help tracking connections, we do
not want those extra protocol parsers in the kernel doing this kind of
heavy lifting.

Thus with two minor changes, I think we can easily tighten the system
and it should not impact anything except for an attacker. I think we
want to set the sysctl net.netfilter.nf_conntrack_helper to 0 and
remove RELATED from the Ferm configuration. I think we need to replace
it with NEW and nothing else.

We'll need to research exactly what other changes to Ferm need to made
for establishing a connection but I think it is simply (NEW
ESTABLISHED).

It seems that we should really look into tightening the network stack
down to the absolute minimum amount of code. I think right now, the
attack surface is larger than needed for our uses.

Thoughts?

All the best,
Jake
___
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] Reducing attack surface of kernel and tightening firewall/sysctls

[Jacob Appelbaum]

On 12/3/14, intrigeri intrig...@boum.org 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 hoping that someone might explain how
RELATED was inserted into the rules in the first place. Who reasoned
about it? Does anyone feel that I'm off base?

 If yes, then the next steps are:

   1. filing a ticket about that
   2. proposing a branch that implements the proposed changes
   3. building a branch that implements the proposed changes
   4. running the automated test suite against the resulting ISO

 Are you interested in doing any of these?


I'm happy to help once we know the direction. It isn't clear to me
that this is interesting or useful. In general, I'm happy to do all
four once we've had a bit of a discussion. I feel like I need a sanity
check for my previous email. I may be totally offbase or onto a topic
that makes some sense. I'm actually not completely sure.

All the best,
Jake
___
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] Removing Polipo (and upgrading to torsocks 2.x): progress report

[Jacob Appelbaum]

On 11/5/14, intrigeri intrig...@boum.org 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, by removing all
 traces of Polipo, thus achieving one of our goals for Tails 3.0.

 As indicated on #5379, it currently passes the revelant bits of our
 automated test suite, but Totem is broken = #8219.

 So, in short, in order to complete the Polipo removal, we need to
 upgrade to torsocks 2.x (#6880). Eight months ago, David Goulet has
 reported about early tests on that ticket, but I haven't seen things
 move since then. I suspect a run of our automatic test suite on an ISO
 that ships torsocks 2.x might be a good next step, and could help
 discover potential issues.

 Anyone wants to prepare a feature/6880-torsocks-2 branch that installs
 torsocks 2.0 from wheezy-backports, and migrates its configuration
 file accordingly?

 (Yeah, seems like I strongly needed to procrastinate and work on
 something not urgent, for a change -- thankfully it seems useful :)


I'm a fan of removing Polipo - I wonder - what will Tails users use
for an HTTP proxy? Privoxy? Shim (which isn't freely licensed, sadly)
or something else?

All the best,
Jacob
___
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] AppArmor in Live systems, state of the union

[Jacob Appelbaum]

On 10/20/14, intrigeri intrig...@boum.org 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://tails.boum.org/contribute/design/application_isolation/

Congratulations! I've been using Tails with AppArmor and I'm pretty
happy at how well it works.

There is one hitch for me and it is largely a development issue:

I've recently released tlsdate 0.0.11 - part of the release was aiming
to target Tails. Sadly, I found that the AppArmor profiles were
totally broken as expected because of the UnionFS issues. I'm happy to
spin another release and I'd like to update the upstream AppArmor
profiles in a way that will benefit Tails directly. What do you think
is the best way to write the upstream policies so that they work in
normal Debian and in (live distros like) Tails?

All the best,
Jacob
___
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] [call for testing] AppArmor profiles

[Jacob Appelbaum]

On 10/6/14, intrigeri intrig...@boum.org 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 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 app?

All the best,
Jacob
___
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] [call for testing] AppArmor profiles

[Jacob Appelbaum]

On 10/8/14, intrigeri intrig...@boum.org 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 app?

 We don't have any such thing specified yet. The idea was to get *some*
 minimal AppArmor support in and working first, so this call for
 testing is more about whether I broke anything, than about checking
 that the AppArmor profiles are actually efficient security-wise.


Understood.

 However, don't hesitate moving forward and trying to escape the
 confinement profiles to access things we clearly don't want to allow,
 e.g.:

  * none of these applications should be allowed to access files in
~/.{gnupg,ssh}/

That seems wise - It may make sense to simply say that Pidgin can only
open .purple, a network link and so on. The and so on part is
difficult - how do we deal with sharing files? Do we only allow files
from ~/Persistent/Documents/ or from somewhere else?

File path based access restrictions are... well, I don't feel great
about AppArmor for this kind of stuff. I think will still improve on
the status quo though. What happens when there is a hard link?

  * especially, file access via alternate paths specific to Debian Live
systems, e.g.
/live/persistence/TailsData_unlocked/{gnupg,openssh-client}
... should be tested


Ok. I'll give it a spin.

All the best,
Jacob
___
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] Bash bug

[Jacob Appelbaum]

On 9/24/14, anonym ano...@riseup.net 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 relevant exploit in Tails? I suppose I'm talking mostly about
 actively supported (client-oriented) use cases -- it's obvious that any
 one running a custom setup with a hidden service sshd with AcceptEnv,
 for instance, is affected.

 By the way, this will be fixed in the Tails 1.1.2 emergency release [1],
 scheduled to be released later today (Thursday, CEST).

 Cheers!

 [1] The reason for the 1.1.2 release is not the bash bug, but the
 Firefox bug:
 https://www.mozilla.org/security/announce/2014/mfsa2014-73.html

By my count we'd want to ship an update to Firefox (libnss), bash
(dhclient? what else?) and apt (the http parser buffer overflow). Any
other critical bugs that were disclosed in the last few hours? :)

All the best,
Jacob
___
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] TorBrowser Handling of PDF files

[Jacob Appelbaum]

On 8/31/14, intrigeri intrig...@boum.org 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:
 # Applications:
 # Portable Document Format (PDF): Always ask

 Why?

PDF readers are arbitrary code execution engines. It would be nice to
click to execute as we do with other complex media formats.

All the best,
Jacob
___
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] How to seed urandom (or not)?

[Jacob Appelbaum]

On 8/2/14, coderman coder...@gmail.com wrote:
 On Fri, Aug 1, 2014 at 10:24 AM, Jacob Appelbaum ja...@appelbaum.net
 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 entropic.

 but a public value in addition to other predictable values maybe
 provides an incremental increase in difficulty of attack. (i'll
 provide tech citations later this eve)

I'm not really convinced. An attacker who attacks the RNG is going to
find all of the plausable public seeds. This is what brl did with
exegesis to attack the Debian RNG bug:

  https://github.com/brl/exegesis

All public and predictable values are bad news. We need entropy not
predictability. :)



 It may make sense to add entropy to the disk at install time from the
 installing computer.

 this would fall into the persistence dependency category, but also
 very much useful!

I'm suggesting that installing on the USB disk would have a non-public
value. Unrelated to persistence, I might add.

 The date is strictly better than no entropy at all. A date is a very
 small amount of entropy but probably it is not sufficient.

 agreed.

In talking with Tanja Lange, she points me to this OpenSSL-fixed table:

 http://www.projectbullrun.org/dual-ec/performance.html

The clock is not a very good entropy source, as expected.


 That does that work? If we have no entropy, we have no entropy.

 i'm creating a matix of kernel versions and potential pre-init user
 space seeding avenues available.  this will explain it better.


Ok.

 odds low, but it could happen.


Odds low on creating the matrix? Or..?

 We need both - we cannot known when one will not function as hardware
 may change on a per boot basis.

 correct; this determination should be at inititialization: can rgnd
 run? if yes, don't launch haveged.

I think we want haveged as well.




 Could you explain the (unseeded) process for entropy collection in the
 kernel (3.14-1-amd64) in use on Tails? Assuming no haveged, rngd, etc.

 will do.


Looking forward to it.

All the best,
Jacob
___
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] How to seed urandom (or not)?

[Jacob Appelbaum]

On 8/1/14, coderman coder...@gmail.com wrote:
 On Fri, Aug 1, 2014 at 2:44 AM, intrigeri intrig...@boum.org 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 (deprecated) Tor VM experiment i read from host sources to
 pass seeds into guests.  ideally this would be combined with a strong
 entropy source like /dev/hw_random to rngd. adding haveged also a good
 idea.  (for VM guests the virtio_random driver best to pull from host
 reserves)
 ... but speaking to your specific scenario:

Sure - if we have entropy, we can seed anything. :)




 The long-term plan, for persistence users, is #7675 (Persist entropy
 pool seeds). However, it covers neither the short term, nor people
 using Tails without persistence.

 1. keep things as-is = urandom is seeded by date +%s.%N + a publicly
known value

 can be better, as discussed.


 2. drop the publicly known value = urandom is seeded by date +%s.%N
only

 this can only be worse. don't do #2.

How is that worse? The goal is entropy collectin. A public value is
not entropic.

It may make sense to add entropy to the disk at install time from the
installing computer.




 3. disable (at least the relevant part of) the urandom initscript =
urandom is only seeded by the kernel, somehow

 this would be less better, too.


The date is strictly better than no entropy at all. A date is a very
small amount of entropy but probably it is not sufficient.


 perhaps best compromise: #4

 read some bytes from /dev/urandom, in case kernel has seeded with some
 DRBG well seeded configuration.

That does that work? If we have no entropy, we have no entropy.


 specifically:
 1. read 8 bytes from /dev/urandom [in case well seeded entirely in
 kernel somehow - long thread goes here]
 2. urandom is [re]seeded by 8bytes + date +%s.%N + a publicly known value
 3. rngd started too, if appropriate noise source present for /dev/hwrandom.
 4. if no physical noise source present, run haveged at boot instead of
 rngd.
 5. prompt user to use persistence for saving entropy seeds, guards, etc.

 you can run rngd and haveged together, but this is tricky in weird
 ways. best to pick rngd if a true hardware random number generator is
 present, and fall back to haveged if not.

We need both - we cannot known when one will not function as hardware
may change on a per boot basis.




 I think it mainly depends on whether haveged (and rngd) will
 contribute to the pool used by urandom, which is still unclear to me
 (see note 12 on the ticket).

 they could, but they are also likely to contribute better later in
 system start up. seeding as above before and in addition to also
 running these daemons is still recommended.


 Does anyone know for sure the answer to this question (pointers to the
 relevant code might help)? Or shall I go ask Linux randomness experts,
 such as hpa and the rngd / haveged authors?

 i can go into as much technical detail on the linux kernel entropy
 behavior, user space interfaces, and common supporting infrastructures
 for various distributions as you'd like.

Could you explain the (unseeded) process for entropy collection in the
kernel (3.14-1-amd64) in use on Tails? Assuming no haveged, rngd, etc.

All the best,
Jacob
___
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] What to do about I2P in Tails?

[Jacob Appelbaum]

On 7/27/14, intrigeri intrig...@boum.org wrote:
 Hi,

 On 7/26/14, sajol...@pimienta.org sajol...@pimienta.org wrote:
 Regarding the when, if we decide to do a first temporary step by
 having an i2p boot option instead of an option in the Greeter, then we
 don't have to wait for the new Greeter... It feels a bit like going
 backward regarding our plans on the Greeter but we've been doing that
 for truecrypt forever and the doc is ready...

 Agreed, this looks like a good short-term plan, thanks!


I think I've said it previously but I also agree.

 That could be ready for Tails 1.1.1, no?

 Yes. I think all it takes is adapting the doc + writing a live-config
 hook that adds enable the needed credentials in sudoers, and makes the
 I2P launcher visible. Anyone willing to 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
 down by default?

 I'm still not convince this buys us much (escalating privs to a user
 that has no running service, in order to benefit from its special
 firewall exceptions, doesn't seem so easy), *but*: if someone does the
 additional work, and if the changes are not too risky and invasive for
 a point-release, then it does seem possible, yes :)


If we remove the i2p sudo rule, I'd probably agree that it doesn't buy
us too much. My concern is people jumping between users after the
system is fully booted.

All the best,
Jacob
___
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] What to do about I2P in Tails?

[Jacob Appelbaum]

On 7/27/14, intrigeri intrig...@boum.org 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 intrig...@boum.org wrote:
 Jacob Appelbaum wrote (25 Jul 2014 11:56:05 GMT) :
 A compromose of i2p is game over on Tails from an anonymity
 perspective.

 This is not so obvious to me: I2P activity could possibly be
 de-anonymized, without being trivially linkable to the torified
 activity.

 I think that seems incorrect. If a user visits a hostile web page
 served to a Tor exit... wouldn't they be able to tag that user? I
 think so.

 I'm sorry I don't get what you mean here. Could you please elaborate?

I mean - if someone serves you an i2p site in an iframe over an evil
exit, what happens? Is there any difference? Can you do something
nasty to them? Can you correleate other streams/circuits in any way?

I think the answer is no with total isolation in theory but in
practice, I wonder if if this is correct? Can an attacker hold a
socket open or do something tricky with i2p that would be hard to do
with a normal browser?


 E.g. we could forbid I2P to talk to anything it should not talk to
 (the Tor ports spring to mind, but obviously a whitelist approach
 would be better; and BTW, symetrically, the debian-tor user should
 only need to talk to the Internet, and to proxies on the LAN if
 configured to use one).

 I'm not sure that I understand the I2P protocol well enough to know
 how to define such a boundary. What should it talk to? What shouldn't
 it talk to?

 I think we could allow the i2psvc user to talk to any host on the
 Internet, but *not* to local services (apart of those that it really
 needs to talk to) nor to the LAN.


Ok. That sounds interesting!

 How shall we scope the audit? What do you have in mind?

 Everything that relies on privilege separation (see sudo
 configuration) could be worth looking it. In particular, I'm thinking
 of the incremental upgrades security design and implementation.


I'm happy to look at the sudo rules but I don't know very much about
the incremental upgrades. If you want to talk about it, I'm certainly
open to looking into it.

 The system is ready for i2p to run and
 as a result, it has a lot of permissive behavior that is not strictly
 required.

 I see the firewall rules that grant i2psvc full access to the network,
 the FoxyProxy configuration, and the fact the amnesia user can talk to
 I2P in many ways. Does a lot of permissive behavior include anything
 else I've missed?


 I'm not sure? The sudo rules ( /etc/sudoers.d/zzz_i2p )  seem
 rather... excessive but perhaps that is what you meant about the
 amnesia user can talk to I2P in many ways - I'm not sure?

 No, I was only mentioning the firewall rules that allow the amnesia
 user to talk to various local I2P services, and asking for what you
 were meaning by a lot of permissive behavior exactly.

Ah, OK. Understood.


 In passing, good news: if we go for users have to opt-in for I2P in
 the Greeter, or -- first step -- on the kernel command-line, then we
 can drop this sudo rule entirely, and have I2P start automatically in
 some other way, when opted-in for.


Sure. That sounds fine. Though when I2P does start - we'd isolate it
with Tor? If so, I think this is a fine design but perhaps not the
best thing for the I2P world. :(

 I would say that we should disable the i2p rules in the firewall
 unless a user positively affirms that they want to run i2p. As it
 stands now - there is a full user that is able to talk to the
 internet, regardless of the state of i2p.

 I'm not sure why escalating privileges to i2psvc would be any easier
 than escalating to debian-tor (especially given the latter is running
 stuff and talking to the network already anyway). Still, I agree this
 would be a good security-in-depth mid-term goal.

 What about the recent I2P bug? Seems much easier unless you've got
 some Tor 0day up your sleeve? :-)

 It seems we're not understanding each other on that one. Let me
 clarify what I meant:

 If I2P is running, then yes, escalating to i2psvc may be easier than
 escalating to debian-tor. But then, we do need these firewall rules,
 so disabling the i2psvc firewall rules unless a user positively
 affirms that they want to run i2p won't help in this case.

Hrm. If I2P is running because the user launched it (eg: at the
greeter), I agree. If I2P is running because of an attacker, I
wouldn't agree. Then the firewall *would* help stop such an attack. It
is reasonable defense in depth.


 If I2P is not running, then even bugs in I2P can't help escalating to
 the i2psvc user, while bugs in a few areas can help escalate to
 debian-tor. So, I'm not convinced that disabling the i2psvc firewall
 rules unless a user positively affirms that they want to run i2p
 would help much here either.


I disagree in practice - if someone can pop a shell

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

[Jacob Appelbaum]

On 7/27/14, Kill Your TV killyou...@i2pmail.org wrote:
 On Fri, 25 Jul 2014 11:08:19 + (UTC)
 intrigeri intrig...@boum.org 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 that resolves this recent XSS and a few other
 issues, but it has had very, very little testing. Perhaps there are
 other problems lurking which haven't been reported yet; people are
 certainly giving I2P more attention *now*.

Is it possible to disable the I2P console entirely until it has been audited?

 (Exodus reported *multiple*
 0days incl RCE affecting Tails. See also
 http://www.twitlonger.com/show/n_1s2jibg. Are these others in I2P? Tor?
 Something else? Will these other 0 days be disclosed or are they
 to be sold?)


I have a similar concern. I think that this suggests that we need to
get our act together and audit audit audit. We should also work to
mitigate these kinds of bugs - assuming that we've missed something as
we have probably missed something. :(

 WRT to the last I2P release: I do know that the filtering is a little
 too strict and broke retrieving torrent metainfo, so I think that there
 will be a point release relatively soon (Perhaps the I2P-users on Tails
 don't bother with this feature?).

Will the Debian packages be updated sometime soon?


 I still haven't had a chance to play 'catch-up' with the posts,
 Redmine, and/or IRC to give the level of detail that they deserve,
 but a few quick things:

 apparmor: This was in my plans prior to this bug but of course its
 priority has been raised.

Wouldn't any policy that blocks the latest RCE also block the way that
I2P actually functions?


 'router console access': How many on Tails on I2P just visit I2P
 internal sites? How many look at or change settings here? Should this be
 disabled by default?

Yes, please disable it, if that is possible. Or perhaps make a web
view or something similar with it?


 greeter or boot option: Seems like a reasonable compromise. I suppose
 could also allow the I2P-specific rules to be set if-and-only-if this
 option is specified.

I think it would be good to privilege separate administration of I2P
(eg: console) from usage of I2P (eg: touching the network).


 More will be forthcoming.

Sounds good. I look forward to hearing more and I'm happy to help.
What do you think about routing all I2P traffic over Tor? That seems
like something that may happen as a stop gap. Thoughts on that are
really needed.

All the best,
Jacob
___
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] Risks of enabled/disabled TCP timestamps?

[Jacob Appelbaum]

On 7/27/14, intrigeri intrig...@boum.org 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 doesn't break too much
 stuff in obvious ways. Good!

Ok. Great!


 But that's not enough to merge this branch:

 intrigeri wrote (07 Jan 2014 23:12:31 GMT) :
 I'll come back to you and Jacob for the design doc phrasing, as I'm
 still not convinced we can put statements as bold as tracking the
 clock down to the millisecond in there, without thinking a bit about
 how an attacker is affected by the network lag between the time a TCP
 timestamp was created, and the time when they get to see the packet.

 I mean, I'm weak at stats and all and you probably know better, but
 learning that some unknown time ago, the system clock was T with
 a millisecond precision does not really give me the current system
 clock with a millisecond precision, does it?

 This still needs some input.

 Now known as #6581.


Ok. I'll comment on #6581 shortly.

 This is still waiting for some input from those who are confident that
 disabling TCP timestamps buys us much, and feel able to phrase it in
 a way that's suitable for our design doc. Once we have that phrasing,
 I volunteer to integrate it into the design doc and propose a branch.

 Any taker?

Yes, I'm on it.

All the best,
Jacob
___
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] What to do about I2P in Tails?

[Jacob Appelbaum]

On 7/26/14, sajol...@pimienta.org 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's web
 browsing over Tor, to take advantage of bugs in the I2P router
 console;

  3. protecting the Tails users who don't intend to use I2P at all,
 from vulnerabilities in I2P, by making it harder, for an attacker,
 to start I2P in Tails, or to trick a user into doing it.

 Regarding #3, I think we should replace the sudo credentials that
 allow the `amnesia' user to start I2P, with an I2P option in Tails
 Greeter. I assume the new Greeter that's currently worked on would
 allow this.

  * If we keep I2P without adding any protection immediately, when do
we expect *which* protections to be ready? (reality check: we won't
have AppArmor before October; I guess the Greeter won't be ready
earlier either)

 Regarding the when, if we decide to do a first temporary step by
 having an i2p boot option instead of an option in the Greeter, then we
 don't have to wait for the new Greeter... It feels a bit like going
 backward regarding our plans on the Greeter but we've been doing that
 for truecrypt forever and the doc is ready... That could be ready for
 Tails 1.1.1, no?


A boot option seems like a fine way to fix things quickly without
actually harming the needs of actual i2p users. I wonder though if
that also means that the firewall would be locked down by default?

All the best,
Jacob
___
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] What to do about I2P in Tails?

[Jacob Appelbaum]

On 7/26/14, intrigeri intrig...@boum.org 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 intrig...@boum.org 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;

 A compromose of i2p is game over on Tails from an anonymity
 perspective.

 This is not so obvious to me: I2P activity could possibly be
 de-anonymized, without being trivially linkable to the torified
 activity.

I think that seems incorrect. If a user visits a hostile web page
served to a Tor exit... wouldn't they be able to tag that user? I
think so.

Also - note - I said a compromise - that is RCE on Tails and not just
a direct connection...


 E.g. we could forbid I2P to talk to anything it should not talk to
 (the Tor ports spring to mind, but obviously a whitelist approach
 would be better; and BTW, symetrically, the debian-tor user should
 only need to talk to the Internet, and to proxies on the LAN if
 configured to use one).


I'm not sure that I understand the I2P protocol well enough to know
how to define such a boundary. What should it talk to? What shouldn't
it talk to?

 This, combined with our stream isolation design, could raise the bar
 a bit on this front.


Perhaps so. I want to say that it can't be worse than the current
setup but I wonder if that is true.

  3. protecting the Tails users who don't intend to use I2P at all,
 from vulnerabilities in I2P, by making it harder, for an attacker,
 to start I2P in Tails, or to trick a user into doing it.

 I think that means we need to audit the default state of the system
 even if we're not running i2p.

 Agreed.


How shall we scope the audit? What do you have in mind?

 The system is ready for i2p to run and
 as a result, it has a lot of permissive behavior that is not strictly
 required.

 I see the firewall rules that grant i2psvc full access to the network,
 the FoxyProxy configuration, and the fact the amnesia user can talk to
 I2P in many ways. Does a lot of permissive behavior include anything
 else I've missed?


I'm not sure? The sudo rules ( /etc/sudoers.d/zzz_i2p )  seem
rather... excessive but perhaps that is what you meant about the
amnesia user can talk to I2P in many ways - I'm not sure?

 Regarding #1:

  a) On the filesystem and privilege escalation side, I think we should
 sandbox I2P better. We're working on integrating AppArmor in
 Debian and Tails, and I think I2P would be a good candidate for
 confinement. @I2P folks: do you already have anything in the works
 in this area? Anyone else?


 I would say that we should disable the i2p rules in the firewall
 unless a user positively affirms that they want to run i2p. As it
 stands now - there is a full user that is able to talk to the
 internet, regardless of the state of i2p.

 I'm not sure why escalating privileges to i2psvc would be any easier
 than escalating to debian-tor (especially given the latter is running
 stuff and talking to the network already anyway). Still, I agree this
 would be a good security-in-depth mid-term goal.

What about the recent I2P bug? Seems much easier unless you've got
some Tor 0day up your sleeve? :-)


 I think torifying i2p is a fine middle ground for accessing i2p
 services. [...] Still - it isn't enough. Code execution in i2p as
 detailed
 on the Exodus blog would not be stopped by Torification of i2p. The
 impact of such a bug would not be completely minimized either -
 arbitrary code on the system can still read out unique identifiers.

 Sure. This is why I raised the sandboxing topic :)


Does I2P still function when sandboxed in a way that would have
stopped that RCE bug?

  * If we keep I2P without adding any protection immediately, when do
we expect *which* protections to be ready? (reality check: we won't
have AppArmor before October; I guess the Greeter won't be ready
earlier either)

 I think this is probably not a wise idea. I really suggest a hotfix
 for all users as soon as possible.

 Our advisory (security/Security_hole_in_I2P_0.9.13) that all Tails
 users now see on every boot explains how to protect oneself, to
 various extends, depending how strongly they feel about it. Granted,
 it's a bit painful, but once balanced with how much energy is
 currently required to put a release out, I think I'd rather see us
 work on streamlining our release process, than kill ourselves with an
 additional emergency release.

Is it possible to ship an update with one package or something similar
without shipping a new ISO?


 Still, for 1.1.1, the question is left open, and I'm unsure what my
 take on it is. I think my level of comfort wrt. keeping I2P and
 waiting for proper solutions will strongly depend on what kind of
 energy I see arising to actually design

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

[Jacob Appelbaum]

On 7/25/14, intrigeri intrig...@boum.org 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. In the last few days, those of us who were lucky enough
 to read Exodus Intelligence's report have learned that there are quite
 a few such bugs in I2P. I can't say much publicly right now, and I'm
 no Java programmer, but given how these bugs look like, I would not be
 surprised if there were quite a few other similar security issues
 lurking somewhere in the I2P codebase. Shit happens, and oh well,
 we're shipping Pidgin and a Firefox-based browser, too.

Indeed.


 On the long-term, I'd like us to be able to go on shipping I2P in
 Tails, without fearing too much about it.

 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;


A compromose of i2p is game over on Tails from an anonymity
perspective. It has access to files on the disk, it has access to the
complete network and so on. What do you mean by 'upgrade' their
attack? Do you mean, for example, rooting the box? Keeping files
around? Running arbitrary code?


  2. making it harder, for someone attacking a Tails user's web
 browsing over Tor, to take advantage of bugs in the I2P router
 console;


That is an important goal, I fully agree.

  3. protecting the Tails users who don't intend to use I2P at all,
 from vulnerabilities in I2P, by making it harder, for an attacker,
 to start I2P in Tails, or to trick a user into doing it.


I think that means we need to audit the default state of the system
even if we're not running i2p. The system is ready for i2p to run and
as a result, it has a lot of permissive behavior that is not strictly
required.

 Regarding #1:

  a) On the filesystem and privilege escalation side, I think we should
 sandbox I2P better. We're working on integrating AppArmor in
 Debian and Tails, and I think I2P would be a good candidate for
 confinement. @I2P folks: do you already have anything in the works
 in this area? Anyone else?


I would say that we should disable the i2p rules in the firewall
unless a user positively affirms that they want to run i2p. As it
stands now - there is a full user that is able to talk to the
internet, regardless of the state of i2p. If it isn't running, we
should not have the following in ferm.conf:

# White-list access to I2P
# For more information, see
https://tails/boum.org/contribute/design/I2P and
https://geti2p.net/ports
daddr 127.0.0.1 proto tcp syn mod multiport
destination-ports (2827  4445 6668 7656 7657 7658 7659 7660 8998)
{
mod owner uid-owner amnesia ACCEPT;
}

# i2p is allowed to do anything it wants to.
mod owner uid-owner i2psvc ACCEPT;

We need some way to modify ferm.conf when a user does wish to use i2p.
It isn't started by default - so it seems clear that we don't need
these firewall rules by default unless we cannot change ferm.conf for
some reason.

  b) On the network side (mostly de-anonymization), the solution that
 springs to mind would be to torify I2P. I'm told it would not work
 well and be ugly, but it's completely unclear to me what it means
 in practice, and I'd like to hear well-documented experience
 reports. Note that Liberte Linux did torify I2P back when they
 shipped it, so it must somehow work, I guess. Anyone?


I think torifying i2p is a fine middle ground for accessing i2p
services. That would have stopped part of the impact of the i2p bug in
question. Still - it isn't enough. Code execution in i2p as detailed
on the Exodus blog would not be stopped by Torification of i2p. The
impact of such a bug would not be completely minimized either -
arbitrary code on the system can still read out unique identifiers. It
can probably jump across system boundaries quite easily at the moment
- especially with the LAN rules in place. :(

 And, if this doesn't work, any alternative solution, other than
 crossing fingers?

 Regarding #2, I think we should get rid of the Tor/I2P/LAN mix-up in
 the Tor Browser we ship. The LAN part still needs some more thought
 and discussion, but IMO the I2P part of the FoxyProxy configuration
 should simply go away. The solution I have in mind would be to create
 another browser dedicated to the I2P, running under a dedicated UID,
 and that can only talk to the I2P proxy and router console. Note that
 this would also help in addressing #1, possibly.

That seems like a fine thing for isolating i2p browser bugs but I'm
not clear that this will solve the actual bugs. It would only ensure
that those impacted are impacted by a special i2p enabled browser, so

Re: [Tails-dev] firewall rules

[Jacob Appelbaum]

On 7/24/14, intrigeri intrig...@boum.org 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 ESTABLISHED ipv6 connection when
 everything is dropped?

 I think the only reasons to have these rules are:

 1. it makes it *slightly* easier to develop and test stuff based on
OnionCat. Arguably, this hasn't happened recently, so it's a bit
weak reason.

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 on demand?

 2. historically (before we used ferm), at some point, we did accept
incoming and outgoing IPv6 on the loopback interface. When we
changed this (commit b4c48aa), we kept the RELATED/ESTABLISHED
rules; no idea why, I would guess that this fix went into
a point-release, and we wanted to keep the changes minimal.


Ok. I can make such a patch.

 I personally would be glad to apply a patch that changes this.

Sounds good.


 I'd like this patch (or branch) to have been used quite a bit on
 a Tails system first (and the exact scope of the tests documented),
 and then we can run the automated test suite on an ISO built from it
 before merging.


I've been using it for the last ~24hrs without issue.

 (In other words: the proposed change seems very unrisky to me, so
 *this* time, I don't feel the need to insist on having a branch that's
 been tested by building an ISO from it, and testing the result :)

 Furthermore, do we really want to REJECT with
 reject-with icmp6-port-unreachable? Why not simply drop it on the
 floor silently?

 It was copied straight from the IPv4 firewall configuration in 2010.
 It might help some badly torified and/or leaky applications give up
 IPv6 earlier = possibly some performance (and then, usability)
 improvements. Possibly minor, possibly important, can't know without
 extensive testing, I would say.


Ok. That sounds like a reason to just DROP the packet on the floor.

 TBH, I see little use in going through this process, and risking to
 introduce a surprising regression. What are the drawbacks with keeping
 the current REJECT rule, exactly?


Tails should be silent - these rules make Tails behave in a way that
deviates from silence. I guess it is a fingerprint on the network, no?

 Obviously, if a Tails user wants to use an IPv6 bridge or only has
 IPv6, it wouldn't work... Does it work at the moment for anyone?

 I'm not aware of anyone having worked on this yet. I'd be delighted to
 see some test results and early patches, to get the thing rolling :)


That sounds like we need not worry about ipv6 for a while with Tails.

All the best,
Jacob
___
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] firewall rules

[Jacob Appelbaum]

Heya,

On 7/24/14, intrigeri intrig...@boum.org 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 on demand?

 No idea.

Ok. This seems like a side point but still an important thing to
consider at some point - stuff like i2p, Tor and other firewall
exceptions might be good to disable by default.


 On 7/24/14, intrigeri intrig...@boum.org wrote:
 2. historically (before we used ferm), at some point, we did accept
incoming and outgoing IPv6 on the loopback interface. When we
changed this (commit b4c48aa), we kept the RELATED/ESTABLISHED
rules; no idea why, I would guess that this fix went into
a point-release, and we wanted to keep the changes minimal.


 Ok. I can make such a patch.

 Yay \o/

I have attached a basic patch to clean up the IPv6 firewall rules. It
is a very simple patch. Still, I would love someone to test it and
ensure that I didn't break everything. :)


 I'd like this patch (or branch) to have been used quite a bit on
 a Tails system first (and the exact scope of the tests documented),
 and then we can run the automated test suite on an ISO built from it
 before merging.


 I've been using it for the last ~24hrs without issue.

 It would be useful to know what you tested. You can share the sensible
 parts of this information privately with me, if needed. And hide some,
 of course :)

I used Tails as normal - browsing, ssh, xmpp-client, pond, etc.
Nothing ceased to function.

I did remove some other rules as well and thus making it even more
restricted. I did notice the following in my dmesg:

[77244.592308] Dropped outbound packet: IN= OUT=eth0 SRC=10.0.254.23
DST=10.0.254.1 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=57641 DF PROTO=UDP
SPT=68 DPT=67 LEN=308 UID=0 GID=0

Strangely, my DHCP client is still functioning. :)

This is why I'd like a second set of eyes...


 Tails should be silent - these rules make Tails behave in a way that
 deviates from silence. I guess it is a fingerprint on the network, no?

 This REJECT rule lives only in the OUTPUT chain, so I believe you're
 mistaken here. Did I miss anything?

You are correct - the REJECT rule is in the OUTPUT chain but I worry
that the other rules may bypass the firewall (eg: they're ACCEPT'ed)
and the TCP/IP stack will respond in some way. I would feel more
comfortable if iptables just dropped it on the floor before anything
else is involved in the affair.

All the best,
Jacob
From 6ee17706cdb2e4abbd4427416e36bf63731eaa20 Mon Sep 17 00:00:00 2001
From: Jacob Appelbaum ja...@appelbaum.net
Date: Thu, 24 Jul 2014 01:30:25 +
Subject: [PATCH] simplify ipv6 ferm rules

---
 config/chroot_local-includes/etc/ferm/ferm.conf |8 
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/config/chroot_local-includes/etc/ferm/ferm.conf b/config/chroot_local-includes/etc/ferm/ferm.conf
index 54ab253..754595d 100644
--- a/config/chroot_local-includes/etc/ferm/ferm.conf
+++ b/config/chroot_local-includes/etc/ferm/ferm.conf
@@ -154,9 +154,6 @@ domain ip6 {
 table filter {
 chain INPUT {
 policy DROP;
-
-# Established connections are accepted.
-mod state state (RELATED ESTABLISHED) ACCEPT;
 }
 
 chain FORWARD {
@@ -165,13 +162,8 @@ domain ip6 {
 
 chain OUTPUT {
 policy DROP;
-
-# Established connections are accepted.
-mod state state (RELATED ESTABLISHED) ACCEPT;
-
 # Everything else is logged and dropped.
 LOG log-prefix Dropped outbound packet:  log-level debug log-uid;
-REJECT reject-with icmp6-port-unreachable;
 }
 }
 }
-- 
1.7.2.5

___
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] firewall rules

[Jacob Appelbaum]

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 (RELATED ESTABLISHED) ACCEPT;
}

chain FORWARD {
policy DROP;
}

chain OUTPUT {
policy DROP;

# Established connections are accepted.
mod state state (RELATED ESTABLISHED) ACCEPT;

# Everything else is logged and dropped.
LOG log-prefix Dropped outbound packet:  log-level debug log-uid;
REJECT reject-with icmp6-port-unreachable;
}
}
}

When would we ever have a RELATED or ESTABLISHED ipv6 connection when
everything is dropped? Furthermore, do we really want to REJECT with
reject-with icmp6-port-unreachable? Why not simply drop it on the
floor silently?

I imagine that this policy would be helpful to simplify things and
ensure that they fail closed:

# IPv6:
domain ip6 {
table filter {
chain INPUT {
policy DROP;
}

chain FORWARD {
policy DROP;
}

chain OUTPUT {
policy DROP;
# Everything else is logged and dropped.
LOG log-prefix Dropped outbound packet:  log-level debug log-uid;
}
}
}

Or as a patch:

diff --git a/config/chroot_local-includes/etc/ferm/ferm.conf
b/config/chroot_local-includes/etc/ferm/ferm.conf
index 56bb20a..37939b8 100644
--- a/config/chroot_local-includes/etc/ferm/ferm.conf
+++ b/config/chroot_local-includes/etc/ferm/ferm.conf
@@ -145,9 +145,6 @@ domain ip6 {
 table filter {
 chain INPUT {
 policy DROP;
-
-# Established connections are accepted.
-mod state state (RELATED ESTABLISHED) ACCEPT;
 }

 chain FORWARD {
@@ -156,13 +153,8 @@ domain ip6 {

 chain OUTPUT {
 policy DROP;
-
-# Established connections are accepted.
-mod state state (RELATED ESTABLISHED) ACCEPT;
-
 # Everything else is logged and dropped.
 LOG log-prefix Dropped outbound packet:  log-level debug log-uid;
-REJECT reject-with icmp6-port-unreachable;
 }
 }
 }

Obviously, if a Tails user wants to use an IPv6 bridge or only has
IPv6, it wouldn't work... Does it work at the moment for anyone?

All the best,
Jacob
___
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] Removing or blacklist kernel modules

[Jacob Appelbaum]

On 7/21/14, intrigeri intrig...@boum.org 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 intrig...@boum.org wrote:
 However, removing modules altogether is no more work than blacklisting
 them: we can do it either via chroot_local-hooks (and then, regenerate
 the initrd's), or with the exclude file passed to mksquashfs (but in
 this case, if any of the blacklisted module is in the initrd's, then
 we're not really removing it; so likely a hook is better).


 Is that true? Isn't blacklisting them as simple as adding a few lines
 to /etc/modprobe.d/blacklist.conf?

 Right. Which is not much easier than maintaining a text file with
 a list of module names, and writing a ~10-lines build-time hook that
 runs find -delete on these names, and then runs update-initramfs.
 If we prefer to remove modules entirely, I can do that.

Sounds reasonable.


 In any case, I think the (one-time) cost of implementing this
 mechanism will be totally neglictible, compared to the energy needed
 to create and maintain the blacklist.

I think we should consider using the Ubuntu list of modules as a starting point.


 I think there are some modules we will never want (eg: appletalk) and
 some people may oneday force load (ax25) for their HAM radio
 emergencies.

 Good point. Then, we might want to keep some modules blacklisted, even
 when we move from blacklisting to removing. So, we need two lists.


Sure, we may need two lists in the long run.

 Is the right place to put things in /etc/modprobe.d/blacklist.conf
 as I think?

 I think we'll want to use a less generic name, such as
 tails-blacklist.conf.


The reason I suggested blacklist.conf is that it already exists. If
you want to create a different file, it certainly won't make sense to
send it directly to Debian; won't it remain a Tails delta?

 This would be my first addition to that file:

 I've just created https://tails.boum.org/blueprint/blacklist_modules/,
 and added your list to it. Please add a rationale for each module
 there (why it's useless and/or dangerous), as we won't just add
 modules to the blacklist because someone pretending to be Jake on
 a mailing-list said so :)


Ok.

 Also, for anyone interested in working on this blacklist, Ubuntu and
 Fedora have had some for years:

   *
 https://fedoraproject.org/wiki/Security_Features_Matrix#Blacklist_Rare_Protocols
   * https://wiki.ubuntu.com/Security/Features#blacklist-rare-net


Shall we take those two as the base sets to list?

 These are well tested, and would be a good basis. Likely we'll want to
 go further in Tails, but at least *this* should really be ported to
 Debian, and not carried as a Tails delta.

How would Debian want such a patch? It seems unlikely that
tails-blacklist.conf will be taken upstream by the name alone...

All the best,
Jacob
___
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] user-agent analysis and suggestions: hooray!

[Jacob Appelbaum]

On 7/21/14, intrigeri intrig...@boum.org 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 would not hurt and if they source a common
 file for a user agent, it should be straight forward to keep things in
 sync with perhaps no upstream modifications?

 For example:

 wget --user-agent=$useragent
 curl --user-agent $useragent
 GET -H User-Agent:$useragent

 This would definitely work. We ship a getTorBrowserUserAgent program,
 that's used by the curl processes started by htpdate. Its results
 could be cached at ISO build time, and then used by these aliases.

Seems fine, yes.


 One should look for other instances of using wget, curl, LWP and
 friends without going through the shell, too. Any taker?

Not it. :)


 For the discussion at hand, I sniffed my own sessions and saw the
 following data transmissions.

 Woohoo \o/ .. and sorry for the delay.

 wget:
 [...]
 Accept: */*
 Connection: keep-alive

 curl:
 [...]
 Accept: */*
 Proxy-Connection: Keep-Alive

 GET:
 [...]
 TE: deflate,gzip;q=0.3
 Connection: TE, close

 This is Tor Browser on Tails for the same file but on a different web
 server:
 [...]
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 Accept-Language: en-us,en;q=0.5
 Accept-Encoding: gzip, deflate
 Connection: keep-alive

 So, this shows that we have an identifying set of headers for each of
 these four clients, even if we ignore the user-agent information.

...


 ... but, in the following tests (with a forged user-agent), most of
 these discrepancies disappear, so I'm confused:

 Here are the same clients with a forged User Agent:

 wget --user-agent=User-Agent:Mozilla/5.0 (Windows NT 6.1; rv:24.0)
 Gecko/20100101 Firefox/24.0
 [...]
 Accept: */*
 Connection: keep-alive

 curl --user-agent User-Agent:Mozilla/5.0 (Windows NT 6.1; rv:24.0)
 Gecko/20100101 Firefox/24.0
 http://people.torproject.org/~ioerror/misc/tor-ips.txt; shows:
 [...]
 Accept: */*
 Connection: keep-alive

 I'm surprised: without faking the user-agent, we had
 Proxy-Connection instead of Connection. Is one of these results
 wrong, or is curl behaving erratically, or is there another
 rational explanation?


I don't remember? :-)

 GET -H User-Agent:Mozilla/5.0 (Windows NT 6.1; rv:24.0)
 Gecko/20100101 Firefox/24.0
 [...]
 Connection: keep-alive

 Same here, we had Connection: TE, close previously = same question.

 My conclusion is that setting the user agent for curl and wget to
 match Tor Browser isn't a horrible idea. It even seems like on a
 single GET request, it would be helpful for privacy and anonymity set
 reasons. It certainly reduces the version information leakage that is
 absolutely useful for fingerprinting and exploitation. For `GET` - we
 might also add -H=Accept: */* and then all three would be aligned.

 I'll wait for the surprising things highlighted above to be clarified,
 before commenting on this one.


I think the first set was wrong or weird and the second set was mostly
correct. It would be good if someone could re-run the tests on Tails
1.1 anyway. Any takers?

All the best,
Jacob
___
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] Removing or blacklist kernel modules

[Jacob Appelbaum]

On 7/21/14, intrigeri intrig...@boum.org 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 energy willing to be put into
 this :)

 I feel that actually _removing_ modules is a better way to achieve a
 slightly safer kernel as the code could not be reached anymore. Less
 attack vector!

 Blacklisting kernel modules allows you to compile them in, but not use
 them, however, *perhaps* code could still be reached which might be
 exploitable with some crazy exploit.

 My understanding is that to have a blacklisted module loaded, assuming
 one isn't root yet (otherwise, we've lost already), one needs to find
 a way to exploit a bug in modprobe so that it ignores at least part of
 its configured blacklist. And then, one has to have the module loaded
 (not so hard, in many cases) and exploit it. So, my take on it is that
 blacklisting should be Good Enough™, at least for a first iteration
 (see below).

I'm not clear that this is correct but I think we should find a way to
test this theory.


 However, removing modules altogether is no more work than blacklisting
 them: we can do it either via chroot_local-hooks (and then, regenerate
 the initrd's), or with the exclude file passed to mksquashfs (but in
 this case, if any of the blacklisted module is in the initrd's, then
 we're not really removing it; so likely a hook is better).


Is that true? Isn't blacklisting them as simple as adding a few lines
to /etc/modprobe.d/blacklist.conf?

 The only downside I can see to removing the modules (as opposed to
 blacklisting them) is that it entirely prevents users from
 force-loading a module they need. Which will probably matter in the
 initial stages of preparing, and fine-tuning, the list of modules we
 don't want: hardening is great, but regressions are bad.


I think there are some modules we will never want (eg: appletalk) and
some people may oneday force load (ax25) for their HAM radio
emergencies.

 So, I would suggest to blacklist (and document how to bypass the
 blacklist) as an initial step, and once we're happy with the
 blacklist, and haven't seen serious complains about it for a few
 releases, then we can remove modules for real. Makes sense?


That sounds reasonable.

 Now, regardless of the method used to disable these modules, the list
 will have to be maintained. Jurre, I guess you're volunteering,
 right? :)

Is the right place to put things in /etc/modprobe.d/blacklist.conf as I think?

This would be my first addition to that file:

+blacklist ipx
+blacklist appletalk
+blacklist ax25
+blacklist psnap
+blacklist rose
+blacklist p8023
+blacklist llc
+blacklist p8022

All the best,
Jacob
___
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] user-agent analysis and suggestions: hooray!

[Jacob Appelbaum]

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 have it have the
following configuration value:

  hide-user-agent{Mozilla/5.0 (Windows NT 6.1; rv:24.0)
Gecko/20100101 Firefox/24.0}

If we consider https://trac.torproject.org/projects/tor/wiki/doc/PrivoxyConfig
we may want a configuration file like so:

 forward-socks4a / 127.0.0.1:9050 .
 confdir /etc/privoxy
 logdir /var/log/privoxy
 logfile logfile
 debug   4096 # Startup banner and warnings
 debug   8192 # Errors - *we highly recommended enabling this*
 listen-address  127.0.0.1:8118
 toggle  1
 enable-remote-toggle 0
 enable-edit-actions 0
 enable-remote-http-toggle 0
 buffer-limit 4096
 hide-user-agent{Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101
Firefox/24.0}

We may want additional listeners and of course, if we don't configure
the user agents, we'll leak a lot of User Agent data that privoxy
won't replace inside of SSL/TLS connections.

All the best,
Jacob
___
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] user-agent analysis and suggestions: hooray!

[Jacob Appelbaum]

Heya,

On 6/23/14, intrigeri intrig...@boum.org wrote:
 Hi,

 Jacob Appelbaum wrote (22 Jun 2014 16:16:17 GMT) :
 On 6/22/14, intrigeri intrig...@boum.org wrote:
 On the other hand, the fingerprint of curl probably differs in many
 other ways. So, for an attacker that looks at it more closely, a curl
 HTTP client pretending to be Firefox is part of a very small
 anonymity set.

 We should fix the issues we discover and as we learn more, we should
 evaluate each change.

 I agree that it would be good if some ideal we did this, but I'm
 very unsure that Tails can take responsibility for starting what could
 very well be a never-ending quest. Anyway, it's hard to know how hard
 this mission would be, before we know the answer to:


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 would not hurt and if they source a common
file for a user agent, it should be straight forward to keep things in
sync with perhaps no upstream modifications?

For example:

wget --user-agent=$useragent
curl --user-agent $useragent
GET -H User-Agent:$useragent

 That said - for a single GET request, we should study the various
 clients on Tails and determine if this hypothesis (easy to
 fingerprint) is correct.

 That would be good to know, indeed. Any taker?


For the discussion at hand, I sniffed my own sessions and saw the
following data transmissions.

wget:

GET /~ioerror/misc/tor-ips.txt HTTP/1.1
Host: people.torproject.org
User-Agent: Wget/1.12 (linux-gnu)
Accept: */*
Connection: keep-alive

HTTP/1.1 302 Found
Date: Tue, 24 Jun 2014 10:30:13 GMT
Server: Apache
Location: https://people.torproject.org/~ioerror/misc/tor-ips.txt
Vary: Accept-Encoding
Content-Length: 310
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
htmlhead
title302 Found/title
/headbody
h1Found/h1
pThe document has moved a
href=https://people.torproject.org/~ioerror/misc/tor-ips.txt;here/a./p
hr
addressApache Server at people.torproject.org Port 80/address
/body/html

curl:

GET http://people.torproject.org/~ioerror/misc/tor-ips.txt HTTP/1.1
User-Agent: curl/7.21.0 (i486-pc-linux-gnu) libcurl/7.21.0
OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6
Host: people.torproject.org
Accept: */*
Proxy-Connection: Keep-Alive

HTTP/1.1 302 Found
Content-Length: 310
Date: Tue, 24 Jun 2014 10:24:46 GMT
Server: Apache
Location: https://people.torproject.org/~ioerror/misc/tor-ips.txt
Vary: Accept-Encoding
Content-Type: text/html; charset=iso-8859-1
Connection: keep-alive

!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
htmlhead
title302 Found/title
/headbody
h1Found/h1
pThe document has moved a
href=https://people.torproject.org/~ioerror/misc/tor-ips.txt;here/a./p
hr
addressApache Server at people.torproject.org Port 80/address
/body/html

GET:

GET http://people.torproject.org/~ioerror/misc/tor-ips.txt HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: people.torproject.org
User-Agent: lwp-request/5.834 libwww-perl/5.836

HTTP/1.1 302 Found
Content-Length: 310
Date: Tue, 24 Jun 2014 10:28:34 GMT
Server: Apache
Location: https://people.torproject.org/~ioerror/misc/tor-ips.txt
Vary: Accept-Encoding
Content-Type: text/html; charset=iso-8859-1
Connection: close

!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
htmlhead
title302 Found/title
/headbody
h1Found/h1
pThe document has moved a
href=https://people.torproject.org/~ioerror/misc/tor-ips.txt;here/a./p
hr
addressApache Server at people.torproject.org Port 80/address
/body/html

This is Tor Browser on Tails for the same file but on a different web server:

GET /~ioerror/misc/tor-ips.txt HTTP/1.1
Host: perdulce.torproject.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

..HTTP/1.1 404 Not Found
Date: Tue, 24 Jun 2014 10:37:29 GMT
Server: Apache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 243
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

Here are the same clients with a forged User Agent:

wget --user-agent=User-Agent:Mozilla/5.0 (Windows NT 6.1; rv:24.0)
Gecko/20100101 Firefox/24.0
http://people.torproject.org/~ioerror/misc/tor-ips.txt; shows:

GET /~ioerror/misc/tor-ips.txt HTTP/1.1
Host: people.torproject.org
User-Agent: User-Agent:Mozilla/5.0 (Windows NT 6.1; rv:24.0)
Gecko/20100101 Firefox/24.0
Accept: */*
Connection: keep-alive

curl --user-agent User-Agent:Mozilla/5.0 (Windows NT 6.1; rv:24.0)
Gecko/20100101 Firefox/24.0
http://people.torproject.org/~ioerror/misc/tor-ips.txt; shows:

GET /~ioerror/misc/tor-ips.txt HTTP/1.1
Host: people.torproject.org
User-Agent: User-Agent:Mozilla/5.0 (Windows NT 6.1; rv:24.0)
Gecko/20100101 Firefox

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

[Jacob Appelbaum]

On 6/24/14, Daniel Kahn Gillmor d...@fifthhorseman.net 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 during a fetch:

 GET /debian-backports/dists/squeeze-backports/Release.gpg HTTP/1.1
 Host: backports.debian.org
 Cache-Control: max-age=0
 User-Agent: Debian APT-HTTP/1.3 (0.8.10.3)
 Connection: keep-alive

 That seems like it is worth masking as well, especially since it runs
 as root!

 While i doubt that changing the User-Agent here will concretely hurt
 anything, an adversary who can observe the HTTP request for
 squeeze-backports/Release.gpg (and the associated Release, Packages, etc
 -- a very distinct traffic pattern) will able to guess with very high
 certainty what version of APT is making the connections in the first place.


I wonder if that is true? I guess it might be true with enough
observations. Wouldn't it be a possible release in a set amongst all
the fetched releases? That is - I might run a newer version of
`apt-get` and access older repositories, no? Seems like a wide variety
of versions are possibly accessing that those mirrors.

Leaking the version settles any speculation, of course.

All the best,
Jacob
___
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] Setting curl's user-agent to the same as Tor Browser?

[Jacob Appelbaum]

On 6/22/14, intrigeri intrig...@boum.org 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
agent that leaks specific version numbers and we can reduce leaking
these details. This will make exploitation of curl harder.

 On the other hand, the fingerprint of curl probably differs in many
 other ways. So, for an attacker that looks at it more closely, a curl
 HTTP client pretending to be Firefox is part of a very small
 anonymity set.

We should fix the issues we discover and as we learn more, we should
evaluate each change. I support changing the user agent of curl to be
one that is shared with Tor Browser.

That said - for a single GET request, we should study the various
clients on Tails and determine if this hypothesis (easy to
fingerprint) is correct.


 Against which one of these attackers do we want to optimize Tails for?


We should aim for unification of user agents across all clients - not
just curl but all user agents of all software in Tails. It is easy to
tackle this with Firefox and with Curl. It should also be done with
wget, GET, POST, HEAD, /usr/lib/apt/methods/http (apt-get update), and
other tools on the system. Each one will have its own set of problems,
of course.

What is a good way to set the user agent on a system wide basis?
Perhaps a string in /etc/useragent that each program can source? That
would make maintenance easier. Such a file would set one place to
update the User Agent string.

( I think I reported a bug similar to this one with a user that I was
training. )

All the best,
Jacob
___
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] Tails usability feedback?

[Jacob Appelbaum]

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 out my thoughts on the topic. On the one
hand, I think it should be clear, I use Tails everyday for nearly
everything. On the other hand, there are little details where I've
adapted and so, my working routine is strange, perhaps not even the
target audience.

As an example, I use extra software in a Persistent drive - stuff like
Pond and xmpp-client. That is why I'm working on packaging it. I also
use a laptop which requires some extra stuff at each boot to keep X
functioning properly. All of that requires a specific environment and
that requires a setup. That kind of configuration is not hard but
requires some basic hoop jumping.

My biggest complaint is that the unsafe-browser is slow to launch and
sometimes Tor won't start or stop properly on captive portals. Also,
various other security related concerns (dhclient, lack of grsec, etc)
that cause me to do other hacky things.

Overall, I feel like the quirks are mostly old Gnome quirks that have
to do with a few things being very automated, but not all of them and
when they go wrong, everything is messed up (like Vidalia crashing at
some point).

All the best,
Jake

On 4/6/14, intrigeri intrig...@boum.org wrote:
 Hi Jake,

 I've heard you say at LibrePlanet that you found that Tails had
 usability issues. I certainly don't disagree, and we have already
 identified a few such issues. But perhaps you know about others,
 so I'd be glad to get more specific feedback from you about it.

 Describing them in an email to the tails-dev mailing-list would be
 a great way to share this report with us. I'll create tickets as
 needed later.

 Thanks in advance!

 Cheers,
 --
   intrigeri
   | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
   | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc

___
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] grsec [Was: Upgrading the Linux kernel for 1.0?]

[Jacob Appelbaum]

On 4/5/14, intrigeri intrig...@boum.org 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... and get confidence in the grsec team;

 That is upstream isn't it? That is - the kernel team in Debian has
 been working with upstream to ensure the two kernel trees are in sync,
 right?

 No, I was rather speaking of the team that maintains the grsec-patched
 kernel (be it a flavour, something built from linux-source, or
 whatever) in Debian. It'll be clearer to you once you've read the bug,
 hopefully :)


Ok. I understand - well, I'll have to ask Spender if he is up for it.

 3. users who want, or need, a hardened kernel -- of course! :)

 I discussed this with another Debian developer and they felt that
 a kernel flavor is the way to go.

 After quickly skimming over #605090 again, I doubt this will be
 acceptable without a strong team, that has proven they are able to be
 fast enough not to delay non-grsec kernel updates (too much).


 I think we should ask Spender to join such a team. Also, I guess I'd
 ask you too. :)

 I'm afraid I am not knowledgeable in maintaining (potentially
 conflicting) changes to the kernel source, but I'll gladly be
 a tester.


There would be a single patch to the kernel - that is the massive
grsec patch. Spender has done all of the other hard work. And for
years, I might add. We'll certainly need testing too.

 How might we ship grsec + pax to end users? What would be useful here
 for me to do? I'm happy to rebuild the kernel with the specific
 patches but I'm sure that is far from enough... :)

 I'm afraid I don't get what you mean here.


 I was thinking that we should come up with a todo list - for example -
 to ship an experimental grsec kernel in the next version of tails (to
 be selected by beta testers).

 eg:

   0. create a .dsc that builds a kernel with stock grsec
   1. build it
   2. integrate it into tails by doing x, y, z

 I'd rather see progress on the Debian side of things first, but
 providing an experimental Tails ISO with this kernel would definitely
 be a great way to get feedback on whatever product the team that takes
 care of it in Debian creates :)

Sure, that can be a TODO list for Debian. I tend to think that
whatever package I make should be fitting for Debian but I'd also like
to test it in the place where I care about it working. I want it to
work for Debian at large but I want it to first work for Tails. If it
is good enough for Tails, it will be good enough for Debian. The
inverse is not always true...

All the best,
Jake
___
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] grsec [Was: Upgrading the Linux kernel for 1.0?]

[Jacob Appelbaum]

On 4/4/14, intrigeri intrig...@boum.org 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 and he
is also keen to make this happen.


 into 1.0 or 1.1

 1.0 will be a point-release, so introducing a large kernel patchset is
 clearly not an option. 1.1 might work, but not sure Debian will be
 fast enough, even if you are. Anyway, you know what? We'll merge it
 once it's ready :)


Awesome to hear!

 - how do we suppose we could make this happen?

 You'll have to find a working code and rough consensus solution for
 https://bugs.debian.org/605090. The maintainability concerns if this
 new kernel was to be released in Debian stable are quite challenging.


I'll look at that bug and give it a think.

 Perhaps a let's do that only in sid to start with approach would
 help:

 1. this new kernel's maintainers get used to the job, and prove
they can sustain the workload and act in a timely manner
whenever other parts of Debian are blocking on them

Good news - Spender wants to make Debian grsec a reality. He is the
upstream patch creator and author of grsec. There is no better person
to involve and he has been making patches against the linux kernel for
years without fail.

 2. the Linux maintainers in Debian, and the stable release
manager, get an idea of how much critical paths are extended in
practice... and get confidence in the grsec team;

That is upstream isn't it? That is - the kernel team in Debian has
been working with upstream to ensure the two kernel trees are in sync,
right?

 3. users who want, or need, a hardened kernel -- of course! :)

 I discussed this with another Debian developer and they felt that
 a kernel flavor is the way to go.

 After quickly skimming over #605090 again, I doubt this will be
 acceptable without a strong team, that has proven they are able to be
 fast enough not to delay non-grsec kernel updates (too much).


I think we should ask Spender to join such a team. Also, I guess I'd
ask you too. :)

 How might we ship grsec + pax to end users? What would be useful here
 for me to do? I'm happy to rebuild the kernel with the specific
 patches but I'm sure that is far from enough... :)

 I'm afraid I don't get what you mean here.


I was thinking that we should come up with a todo list - for example -
to ship an experimental grsec kernel in the next version of tails (to
be selected by beta testers).

eg:

  0. create a .dsc that builds a kernel with stock grsec
  1. build it
  2. integrate it into tails by doing x, y, z

All the best,
Jacob
___
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] Upgrading the Linux kernel for 1.0?

[Jacob Appelbaum]

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 to do? I'm happy to rebuild the kernel with the specific
patches but I'm sure that is far from enough... :)

All the best,
Jacob

On 4/4/14, Alan a...@boum.org wrote:
 Hi,

 anonym wrote (02 Apr 2014 14:50:51 GMT) :
  Looking at the Debian changelog for the Linux kernel it seems only
  these changes have CVE:s:

 Thanks for the research.

 I've had a look (details below) and my conclusion is that... I'm
 unsure if it's worth taking the risk of introducing regressions in
 1.0. Other opinions?

  * nfqueue: Orphan frags in nfqnl_zcopy() and handle errors
(CVE-2014-2568)

 Info leak triggered from the LAN.

 Do you know what kind of info can leak? sensitive information from
 kernel memory could include cryptographic keys?

  * net: fix for a race condition in the inet frag code
  (CVE-2014-0100)

 use-after-free = DoS and possibly [...] unspecified other impact
 Over ICMP, so generally exploitable only on the LAN.
 Requires high CPU load on the attacked system.
 This one seems worth fixing.

 [...]

  * skbuff: skb_segment: orphan frags before copying (CVE-2014-0131)

 Info leak triggered from the LAN.


 I'd say it's worth taking the risk of regressions, at least if the two
 info leak might include cryptographic information leak.

 Cheers
 ___
 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 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] Risks of enabled/disabled TCP timestamps?

[Jacob Appelbaum]

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
 setting are:
 
   1. The system uptime can be inferred from this information.
 

That is correct.

   2. The system clock can be tracked down to the millisecond.

That is also correct.

 
 As far as I understand it, in the context of Tails, this can be done
 by an attacker who monitors the network somewhere between the attacked
 Tails system and the Tor entry nodes being used. Right?

Yes. And due to a Tor issue (TLS itself), the absolute clock on the
system is also leaked in the handshake. Nick has been working on fixing
this - both in the IETF working group on TLS, in patches for OpenSSL and
in other places, I think. When Nick finishes killing the gmt time leak
in TLS, we'll still have one left in Tails: the TCP timestamp itself... :(

 
 I must admit that I did not look closely enough, so in what follows,
 I'm assuming that this information is not forwarded by the three Tor
 hops to the other side of the connection. Please correct me if
 I'm wrong.
 
 Given such an attacker anyway knows the public IP used by the attacked
 system, I don't really get why Jacob calls this a Major privacy info
 leak. May you please clarify what exact threat you have in mind?
 

I think the inverse issue is important to consider: look for clocks that
match an expected value to _find_ the public IP used by a user.

 Off the top of my head, I can think of:
 
   a. Finding out how long a given Tails system has been running: if an
  attacker in this position got to watch the network (close enough
  to the attacked system) when it was bootstrapping Tor, then they
  can learn this too. I'm not overly concerned by this threat.
 

There are currently two ways to do this that come to mind - one is by
watching Tails traffic (first bootstrap, etc), the other is by looking
at every TCP connection setup. This also ensures that non-Tails clients
or different Tails clients behind a NAT will be distinguishable. It
would be nice if a network of Tails machines behind a NAT looked like a
single Tails machine other than the bootstrapping phase.

   b. Distinguishing several Tails systems running behind NAT and using
  the same IP address: I would call this a minor issue, and the
  same reasoning as in (a) applies.
 

If there are four Tails clients behind a NAT, an attacker can probably
distinguish them by TCP timestamp alone.

 A very quick web search seems to indicate that disabling TCP
 timestamps brings its own share of issues: first, disabling TCP
 timestamps also disables the TCP protection against wrapped sequence
 numbers mechanism; second, TCP timestamps seem to be a pretty useful
 performance feature of TCP.

Do we need those features? I would prefer to not leak anything about the
system at all. Currently, to recap: we leak the full clock and then
millisecond offsets. This allows for unique tracking across the internet
as well as unique host counting behind a NAT or similar networks that
proxy traffic in various ways.

 That's why I am reluctant to disable this feature without knowing what
 exact problem we would solve. I'm all ears :)

We'll make it harder to count Tails users behind a NAT, we'll make it so
that Tails users who sleep their machines won't be tracked across
networks, we'll make Nick's removal of gmt time from TLS complete for
the Tails picture, and we'll remove a general side channel.

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[Jacob Appelbaum]

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 reboot.

I could write such a utility but I'd like some feedback - for example -
should we run this after install and put the current state into the
persistence? Should we keep a list of hashes of all possible updates, so
that we can check a user's data set against a known good list?

The easy bit is basically to write something to check the MBR, the
partitions and then walk the file systems. It won't detect firmware
changes to the disk drive (usb, sata, whatever) but it should be able to
very easily detect any binaries that are changed. Obviously we'd need
two tails disks to really be able to do this kind of basic forensics.

Thoughts?

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[Jacob Appelbaum]

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 anything consistent - a variety of laptops are in use. The systems
didn't have any other changes - I've verified that my BIOS firmware
hasn't changed, nor has any of the other programmable firmware in my
machine where I am able to dump the flashable memory/eeprom/chips.

Has anyone else noticed these changes since 0.19? Is there an easy way
to try to log these errors to a Persistent part of the system?

All the best,
Jake
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[Jacob Appelbaum]

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
information in a so-called Persistent container. This is usually a LUKS
encrypted partition on the same bootable medium that contains Tails.

To start - we worked through bootstrapping Tahoe on a Tails system - the
Tahoe package in Debian and thus available in Tails as of the Tails 0.19
release is 1.9.2-1. This is a bit older than we'd like, so we
bootstrapped from source with only a few Debian packages from the
packaging system.

Here is the git repo for the script that we used to bootstrap Tahoe-LAFS
on Tails 0.19:

  https://github.com/leif/tahoe-tails-utils

The following ticket covers the overall issues of actually trying to
bootstrap Tahoe safely on any network at all:

  https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2055

The issues outlined in the above ticket should cover Tor users, though
likely it equally applies to a VPN user, an i2p user and really, anyone
barebacking with the internet.

Once this bootstrapping process was completed, we connected the Tails
machine to a Tahoe-LAFS grid that is Tor aware. The introducer runs as a
Tor hidden service. Each of the Storage Nodes also presents their
respective addresses as Tor hidden services through the previously
mentioned introducer.

We found that the open browser command uses the system browser included
with Tails. We weren't thrilled about the main browser being used for
local system daemon or system service related activities. I dislike that
it talks to the loopback interface, while other content it loads may go
over the Tor network or even try to do other things with stored data in
the browser or on the file system.

This ticket is an example of why total browser isolation is a good idea:

  https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1942

We prefer that at least this browser data should be isolated from any
other web browsing I might perform with this machine. We wrote a quick
little hack to use a different profile - we added a wrapper called
`tahoe-browser` written in bash and stuffed it into
/usr/local/bin/tahoe-browser. We then set BROWSER in the environment to
point to it:

  export BROWSER=/usr/local/bin/tahoe-browser

This allows me to use `tahoe webopen grid-news/Latest/index.html` in a
completely separate browser profile. Hooray. What is grid-news? A useful
news service on our local Tor grid - any url would have the same issues
as noted.

Is this useful? Should we generalize this and add it to Tahoe? It would
be easy enough to extend src/allmydata/scripts/tahoe_webopen.py to do
this job with the addition of another small class. No such tahoe-browser
program would be required - though it surely wouldn't hurt to keep them
completely separated.

An interesting trick would be to put that browser profile itself inside
of a user's Tahoe grid. It would provide some on-the-go anti-forensics
and keep all Tahoe related url data, bookmarks and so on inside of the
grid itself. Leif isn't so hot on this idea because of Tahoe's Magic
Folders idea isn't implemented. Abstractly, I like the idea but I'm not
sure if it is practical.

As it stands, we've now managed to bootstrap Tahoe on Tails - so it is
basically possible to do all grid related activity over Tor. We don't
have to worry about exit nodes as we're using Tor Hidden Services for
all of the services. Though generally, I'm not really worried about Tor
Exit nodes in the context of Tahoe-LAFS.

In an ideal world, we'd use the Tails persistence feature to store a
user's Tahoe's introducer furl and a few other important bits. This
could then in turn be used to store all of the other Tails persistance
data - things like web browser history, .{ssh,gnupg,pidgin,etc}, and/or
even added Debian packages. To do this, we need to add persistence
support for Tahoe related configuration in Tails and we need to ensure
that Tahoe ships as part of Tails.

Here are a few bugs related to this in the Tails bug tracker:

  https://labs.riseup.net/code/issues/5514
  https://labs.riseup.net/code/issues/5804

Adding '/home/amnesia/.tahoe' to the Tails persistence seems to be
possible from an existing Tails system. We've filed a bug to add this
discuss adding Tahoe as a default option in the persistence
configuration dialog:

  https://labs.riseup.net/code/issues/6227

There are a few interesting improvements that came up for discussion
during this process.

One such idea relates to changing the way that the Storage Nodes publish
data to introducers.

Wouldn't it be nice if we could reduce the authority of the introducer
even more? With a little bit of effort, we could ensure that an attacker
who learns about the introducer is only able to learn the number of
Storage Servers but not any other information.

For an all 

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

[Jacob Appelbaum]

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 letting
people know!

 
 Topics currently on the agenda are:
 
   * Broken window week?
 https://tails.boum.org/contribute/roadmap/#index1h1
 
   * Monthly low-hanging fruits / review'n'merge meeting?
 It was great to have one in April and May.
 We skipped it in June. How about having one in July?
 
   * ioerror's debrief on users i have trained
 
 Feel free to propose and prepare other discussion topics. Please raise
 them in this thread so that others can ask details and prepare the
 discussion too.

I'd like to propose a few topics:

  tlsdate inclusion
  revisiting a default transparent proxy
  allowing users to choose a less secure Tails during boot
eg: enable bluetooth automatically, run cups, etc.
  TorBirdy and Thunderbird inclusion
  Tor Browser Bundle
  kernel hardening
  writing and shipping an installer for Win/OSX/linux
  improving tails upgrades
  running gnome-screensaver when a password is enabled
  EFI booting
  32bit and 64bit builds
  downloads pre-tailored for specific install mediums
  adding golang, xmpp-client and pond to tails
  support for adding vm transparent level proxy
eg: running tails inside of a vm
  ...with a stripped down tails as the host
  not launching the web browser on startup
eg: lowering the attach surface with about://tor
  a way to perform forensics on an untrusted tails disk
eg: from another (trusted) tails disk or a Debian system

Any of those seem interesting to me - also some feedback from different
kinds of users - is available.

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

[Tails-dev] download over http by default?

[Jacob Appelbaum]

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 signature? Ten to one? Perhaps one out of ever thousand
downloads?

I really strongly encourage that the default download link should be
secure - if there was a tool to download updates and it automatically
checked the signatures, I'd think it was perhaps OK to use HTTP.
Probably not but well, I could at least believe that someone might
complete both steps. Without such a tool, I think this is merely a
recipe for disaster.

We carry a secure mirror here:

  https://archive.torproject.org/amnesia.boum.org/tails/stable/

If you guys can't handle HTTPS traffic, I really encourage you to link
to our HTTPS site as the default. If nothing else, I believe that some
browsers also pin our certs. That at least changes the game to something
a bit harder.

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[Jacob Appelbaum]

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
   every 21 seconds on average (this is an approximation from the
   requests made to the security announcements feed when Tails is
   connected to Tor).
 

Fantastic job.

 - 71 reports were received through WhisperBack.

Is there a common complaint or are most of these automated?

 
 - 1515 comments were posted on the forum, with 76 signed by Tails. This
   means there has been much more activity on the forum, and that we are
   having a hard time coping with it, but also that anonymous
   contributors are providing more and more good answers without our
   help.

Quite nice. Is English the primary language?

 
 
 Code
 
 
 - We had a highly successful low-hanging fruits week: at least 16
   tickets were touched, and at least five persons attended one session
   or more.
 
   https://mailman.boum.org/pipermail/tails-dev/2013-April/002834.html
 
 - The persistence feature to remember installed packages (has matured a
   lot) and should be ready for Tails 0.18.
 
   https://tails.boum.org/todo/remember_installed_packages/

Will it be possible to ensure that this isn't abused for persistent
rootkits? Also, I wonder if there is a way to verify the packages as
being both up to date and actually valid packages from a valid repo?

 
 http://git.immerda.ch/?p=amnesia.git;a=shortlog;h=refs/heads/feature%2Fremember%5Finstalled%5Fpackages
 
 - Support for Obfs3 bridges (has been added).
 

This is fantastic!

 
 http://git.immerda.ch/?p=amnesia.git;a=shortlog;h=refs/heads/feature%2Fobfs3
 
 - Torbutton 1.5.x can now be included in Tails. We also reorganized and
   cleaned our iceweasel prefs to look a bit more like the ones from TBB.
 
 
 http://git.immerda.ch/?p=amnesia.git;a=shortlog;h=refs/heads/feature%2Ftorbutton%2D1%2E5%2Ex
 
 - GNOME accessibility themes were installed to provide high contrast and
   large print themes.
 

Thanks for this too - I know a nearly blind Tails user who really
appreciates having these kinds of accessibility improvements.

 
 http://git.immerda.ch/?p=amnesia.git;a=shortlog;h=refs/heads/feature%2Fgnome%2Daccessibility%2Dthemes
 
 - The About GNOME menu entry has been customized to provide
   information about the running version of Tails.
 
 
 http://git.immerda.ch/?p=amnesia.git;a=shortlog;h=refs/heads/feature%2Fabout%5Ftails
 
 - A branch is ready to disable wireless devices other than Wi-Fi,
   Bluetooth, WWAN, and WiMAX by default.
 
 
 http://git.immerda.ch/?p=amnesia.git;a=shortlog;h=refs/heads/feature%2Fset%2Dwireless%2Ddevices%2Dstate
 

I generally want Bluetooth, WWAN and WiMax disabled, while I often want
Wi-Fi, I don't want it on without having joined the network previously.
This is especially true when the MAC address is not completely
randomized at every if-up or every boot.


 - Some initial work was done to not start the browser automatically
   anymore.
 
 
 http://git.immerda.ch/?p=amnesia.git;a=shortlog;h=refs/heads/feature%2Fdont%5Fautostart%5Ficeweasel
 
 - The audio preview when having the mouse pointer on an audio file in
   Nautilus has been disabled.
 


Sounds good. ;-)

 
 http://git.immerda.ch/?p=amnesia.git;a=shortlog;h=refs/heads/feature%2Fdisable%5Faudio%5Fpreview
 
 - The support for non-obfsproxy proxy has been fixed.
 
   https://tails.boum.org/todo/non-obfsproxy_proxy/
   http://git.immerda.ch/?p=amnesia.git;a=shortlog;h=refs/heads
 /bugfix%2Fnon%2Dobfsproxy%5Fproxy
 
 - IPv6 is not disabled anymore. It turns out that the IPv6 leaks we
   wanted to fix actually don't exist.
 
 
 http://git.immerda.ch/?p=amnesia.git;a=shortlog;h=refs/heads/feature%2Fenable%2DIPv6
 

Unless I'm mistaken, without a random MAC address, IPv6 has some pretty
bad privacy concerns, no?

 - GNOME screenshot has been installed.
 
 
 http://git.immerda.ch/?p=amnesia.git;a=shortlog;h=refs/heads/feature%2Fgnome%2Dscreenshot
 
 
 Documentation and website
 =
 
 - Getting started... is now the homepage for the Tails documentation
   accessible from the desktop.
 
 - The content of the /bugs section of the website was moved to /todo.
 
 - A bug concerning MD5 Reborned Hasher Hasher has been documented.
 
 
 https://tails.boum.org/doc/get/verify_the_iso_image_using_other_operating_systems/index.en.html
 
 - The instructions for manual installation on Mac have been brought back
   online and the instructions for Linux and Windows have been improved.
 
 
 https://tails.boum.org/doc/first_steps/manual_usb_installation/mac/index.en.html
 
 - The introduction of the bug reporting instructions have been improved.
 
   https://tails.boum.org/doc/first_steps/bug_reporting/index.en.html
 
 
 Translation
 ===
 
 - A solution was proposed to distribute translation workflows 

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

[Jacob Appelbaum]

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 making this point up, I saw pluggable transports as a
 tool which can be thrown into the mix and make this a non-issue.

I don't think so - I also this this is non-trivial. Some pluggable
transports may seek to obfuscate traffic or to morph it. However, they
do not claim to hide that you are using Tor *in all cases* but rather in
very specific cases. An example threat model includes a DPI device with
limited time to make a classification choice - so the hiding is very
specific to functionality and generally does not take into account
endless data retention with retroactive policing.

 
 (In theory obfsproxy and alike tools can hide the fact that someone is
 using Tor, which will be required against trying-hard-censurers so or
 so. This assumes, that pluggable transports will win the arms race
 against censors.)

Perhaps for a time but again - rarely is anyone thinking about say, the
one, five or ten year logging of full packets.

 
 and using Tails or Whonix is an
 example of a system only emitting Tor traffic.
 
 The plan is...
 
 Whonix:
 When using VMs (as most people do), there is still a host operating
 system people start first - so there is not only Tor traffic. Tor usage
 can be hidden by using pluggable transports.

I would be very careful with that claim. It might be hidden and it might
just be that no one is looking.

 
 Tails:
 When this becomes an issue, there are two workarounds:
 - running Tails in a VM (naturally requires starting a non-Tails os
 beforehand) using pluggable transports to hide Tor usage
 - booting a second computer with a non-Tails operating system behind the
 same router, wait a bit, run Tails using pluggable transports to hide
 Tor usage
 
 And one possible fix: boot the amnesic system, simulate this is Debian
 (or other mainstream distro) by running it untorified in chroot or in a
 VM; fire up Tor using pluggable transports to hide Tor usage.
 
 The point I wanted to make is, I can very well imagine, not to fail this
 test, i.e. pretending to be a mainstream distribution, having non-Tor
 traffic and obfuscating Tor traffic using pluggable transports. Perhaps
 it can be prevented, that tlsdate introduces new operating system
 fingerprinting possibilities for ISPs.
 

That's my point - I don't believe that tlsdate introduces anything more
than what any OpenSSL TLS connection would introduce. The main
difference is the host and *that* is currently a set of *extremely*
popular hosts, way way more popular than Tor nodes or some random bridge
or something. Yes, we could use obfsproxy in the mix but that is punting
and a side step.

 It depends on your threat
 model but generally, we'd just making up someone could as a network
 distinguisher.
 
 Yes.
 
 I assert that someone could watch - see no traffic except
 encrypted traffic, decide it is Tor and then decide you're running Tails
 or Whonix.
 
 I tried to picture solutions to that above.
 

That doesn't solve the fingerprinting issues - attackers can classify
the number of users with different machines behind a NAT and often do so.

All the best,
Jacob

___
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)

[Jacob Appelbaum]

Maxim Kammerer:
 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.
 

There are a lot of issues with ntp - my favorite is that a basic (eg:
shipping with OS X) ntp client will hit the default Apple NTP servers.
These servers may be queried by external third parties and the
information returned is enough to attack any client who is using the
server. The information returned includes the client ip, the udp source
port, the udp destination and of course, the attacker knows the server
ip. This means that an attacker may now send packets as the server -
thus the attacker can even attack ntp clients behind a nat or a stateful
firewall. UDP is part of the problem, the lack of the client/server
authentication is another part of the problem, the fact that the ntp
clients aren't written with security in mind is yet another problem.

This says nothing of an attacker who controls the network path - such an
attacker has an even larger number of attacks and ntp falls over for
nearly all of them. The entire idea of a False Ticker relies on the
notion that you have some path to some honest ntp server, so you can
have some phase locked loops and determine which of the set is wrong or
bad. Good luck without authentication, integrity, confidentiality in
syncing that clock...

So again, I understand you don't like my hack and I'd just like to be
clear - we can't use the current ntp tools to safely, securely or
anonymously set our clock in nearly any use case. I'm working on
alternative ways to do it and I'm using IETF compliant protocols on the
network to ensure that it is actually more than a silly hack that only
works for a while.

All the best,
Jacob
___
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)

[Jacob Appelbaum]

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.
 
 Sure.
 
 I doubt we can blend in this anonymity set, though: unless Tails
 wants to forever copy the set of hosts ChromeOS queries (which I don't
 think we would want to rely upon on the long run), then Tails' use of
 tlsdate will probably be fingerprintable at least by the ISP if the
 connections are made in the clear, so we probably would want to run
 tlsdate over Tor anyway.

I mean, I guess? It looks like a vanilla OpenSSL client connection to a
TLS service - it can be *any* TLS service - so you could pick domain
names at random and connect to their mx records, their pop/imap or
www/https ports, etc.

The list of hosts is the least interesting way to fingerprint it, I
guess is my thought - so we could try to make sure that tlsdate always
has the same cipher-suites for tlsdate on Tails and ChromeOS. Then the
main difference would be the host name - I suspect though that both will
vary and in any case, such variance isn't a bad thing per se.

I guess I sorta feel like this is being over thought.

 
 So, I'm now considering this (tlsdate over Tor) to replace our use of
 htpdate, and not to replace our initial time guess based on the Tor
 consensus [1].

I'm happy to hear that. Proxy support works today - so we could easily
ship a tlsdated.conf in git master for tails. Send me one and I'll merge
it; perhaps even as the default?

 
 [1] https://tails.boum.org/contribute/design/Time_syncing/#index3h1
 

I think tordate should be integrated into tlsdate's timewarp feature -
that is - we may already slam the clock forward to the compile time for
tlsdate. We could also tell it where there might be a consensus and slam
it a second time as long as it is newer than the compile date.

I could either write a simple user tool that is basically the most
simple tordate like function inside of tlsdate, or I could spawn a
process that calls tordate with some arguments, or I could write a new
tordate like program (eg: tlsdate-tor-consensus-date-parser).

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 last possible atime/mtime/ctime
  pick the later time of the two
  jump the clock forward again

I suspect that we'd also want to make sure that the consensus on disk
did verify and check out - I wouldn't want to trust it blindly until I
carefully checked out how those files are created.

I realize that Tails doesn't start with a consensus and I consider this
to be a bug. If I use persistence for example, I would like a consensus
cached so that I might have the protection of Guard nodes as well as a
forward moving clock, as an example.

 I'd like to settle on a list of hosts that it uses by default which may
 include a Google host or not. I haven't yet decided.
 
 OK.
 
 Jacob, are you interested in implementing something like our current
 multiple pool -based approach [2], or something else with similar
 security properties?

We support multiple hosts in the configuration file. I'd be happy to
take a default config that sets against any set of hosts you'd like, I
bet. Would that satisfy your desire for a pool? I'm also happy to start
working on the TLSDATEPOOL idea that I've written up in the git repo.

I think though that it makes more sense to pick the top set of hosts
from the alexa top 1000, pick a host randomly and try a tls connection.
This gives us some entropy as the list changes, it also gives us the
ability to blend in with the overall large amount of traffic to those
sites and the list is largely neutrally collected without revealing much
about us.

 If Tails wants to move to tlsdate some day,

I don't mean to sound frustrated but really, what is the core set of
features that you would want added that would allow you to replace
htpdate? Do you want me to add an HTTP date parser helper or what? :)

 I guess a prerequisite would be not to lose the nice security
 properties this approach currently gives us.

I see that you'd like both multiple hosts by default and a way to pick
from a set, effectively to create a consensus. I generally think this is
a fine idea but really, I question the security properties if you're
worried about fingerprinting. If you're using it over Tor, I feel like
the fingerprinting is not worth serious consideration. If you're not, I
feel like a set of three host pools is extremely revealing. So in that
sense, if you want to settle for that - yeah, a consensus is a possible
enhancement I'd consider.

I'd like it even more if we pick a few different keys/root chains, burn
those into tlsdate, and add other stuff like DANE, convergence, CT, a
look aside via Tor and so on are added

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

[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 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.

 Sure.

 I doubt we can blend in this anonymity set, though: unless Tails
 wants to forever copy the set of hosts ChromeOS queries (which I don't
 think we would want to rely upon on the long run), then Tails' use of
 tlsdate will probably be fingerprintable at least by the ISP if the
 connections are made in the clear, so we probably would want to run
 tlsdate over Tor anyway.
 
 Even if not, there are other easyish ways to distinguish a Chrome OS device,
 such as the autoupdate behavior.
 

I assume over time one would be able to distinguish it - though we
mostly care about getting a correct clock and then if someone tries to
guess our OS, we might be fine with them then filtering us or trying to
attack us. However, if we haven't set our clock correctly, we might have
some issues with actual attacks like replaying a consensus, etc.

 So, I'm now considering this (tlsdate over Tor) to replace our use of
 htpdate, and not to replace our initial time guess based on the Tor
 consensus [1].

 [1] https://tails.boum.org/contribute/design/Time_syncing/#index3h1

 I'd like to settle on a list of hosts that it uses by default which may
 include a Google host or not. I haven't yet decided.

 OK.

 Jacob, are you interested in implementing something like our current
 multiple pool -based approach [2], or something else with similar
 security properties? If Tails wants to move to tlsdate some day,
 I guess a prerequisite would be not to lose the nice security
 properties this approach currently gives us.

 [2] https://tails.boum.org/contribute/design/Time_syncing/#index4h2

 Elly Fong-Jones wrote (08 Apr 2013 03:06:02 GMT) :
 The (slightly outdated now) time-sources design doc is here:
 https://docs.google.com/a/chromium.org/document/d/1ylaCHabUIHoKRJQWhBxqQ5Vck270fX7XCWBdiJofHbU/edit

 Elly, is this design doc correct that tlsdate queries
 clients3.google.com only in ChromeOS?
 
 Correct.
 

Do you happen to have a pcap of tlsdate on a recent ChromeOS device
doing a handshake? I wouldn't mind considering it a design goal that all
Tails tlsdate builds should have matching cipher suites. With some other
hackery we can probably make it identical for the data in a given
tlsdate flow.

 (Given you implemented the multi-host feature, I'd be surprised that
 you don't use it, but I could not find what /etc/tlsdate/tlsdated.conf
 ChromeOS is using, so I don't know.)
 
 We are supposed to be using it, but are not yet. Open bug :)
 

If we made that set of hosts the default set of hosts - would anyone
mind? :)

All the best,
Jacob
___
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)

[Jacob Appelbaum]

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 version? I
didn't find an htpdate package in Debian, where is the version Tails
uses? Is it the perl version? Or perhaps htpdate-1.0.5?

My initial thoughts from reading 1.0.4 very quickly are:

  It is written for HTTP services only
I thought surely that it used TLS, am I auditing the wrong version?
It is trivial to fingerprint
  It isn't written with defense in depth as a solid programming paradigm
  It looks like it might leak DNS (which in Tails probably won't matter)
  It has a static and easy to fingerprint user-agent:
'User-Agent: htpdate/VERSION'
  If called with long urls/host names:
the HTTP HEAD request will be truncated
  It has a hand rolled HTTP parser
  It assumes no day light savings time
Is this absolutely certain?
  It doesn't appear to be optimized for speed
it creates and initializes data structures while parsing HTTP
  It has an interesting way of doing rtt calculation:
rtt * 1e-6
  It may use adjtime which is kinder and gentler
it also uses settimeofday()
htpdate_adjtimex() is a reasonably interesting idea
  It does basically everything setting euid/guid as 0
it doesn't really privsep
  It runs as root by default
why not ensure that an unprived user/group is required?
the code allows for dropping to user:group root:root
  The priv dropping code is not safe:
  641 »·if ( sw_uid ) seteuid( sw_uid );
  642 »·if ( sw_gid ) setegid( sw_gid );
  The programmer is funny:
  750 »·if ( goodtimes )

I didn't see anything obviously exploitable but I did see that if some
things fail to happen... all bets are off about things like not being
root and there are no checks to catch such failures.

All the best,
Jacob
___
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)

[Jacob Appelbaum]

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 a lot less concerned - that C
code isn't the safest. Though in the perl version, I think most of the C
problems are missing - I'd wager a few general issues might remain. I'd
like to see the user switching code - do have it handy?

All the best,
Jacob

___
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)

[Jacob Appelbaum]

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. In my experience, this
 is a correct answer to most why not? questions about wishlist
 tickets in the free software world.

I have a proposal that is half written on the topic. Once I write the
proposal, I will probably build it into Tor if no one else beats me to
it. It will however require a bit of work as we don't want to keep such
time setting capabilities forever, etc.

 
 Please don't refrain yourself from doing as much of the work as you
 can (write a proposal, discuss it, implement it) and from finding
 someone else to do the rest. I, for one, will be very grateful if
 this happens.
 

Sure. Of course.

However - the goal here is to for tlsdate to work everywhere - it will
work anywhere where openssl works and that is even more places than Tor,
sadly. I also want it to be used by groups that are not Tor - even if
tor could set the time in this way, I'd want a way to check that
confirms it. Trust but verify, right?

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[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
parse the absolute minimum time
   stat the respective file to see the last possible atime/mtime/ctime
   pick the later time of the two
   jump the clock forward again
 
 What in case the directory authority is not reachable (censored area)?
 

Well, if we have a file on the disk, we don't even have to touch the
network to jump the clock, right?

 Is the parasitic approach future proof anyway? Won't that cost the
 remote server admins cpu load and traffic?

Probably and probably not?

 
 What if the remote server admins install some intelligent filter,
 which blocks Tor? (for other unrelated spam/ddos issues)

Which server admins? People offering TLS?

 
 Why trust and get the time of some remote server admins who are not
 really willing to run a network time server? They most likely get their
 own time over unauthenticated NTP. Getting time from TLS is more a hack
 than a replacement for non-existing tcp, authenticated and distributed  NTP.
 

Yeah, I'm aware. Really, well aware. People keep telling me over and
over again - it's not demotivating though as zero of those people
suggest replacements, write the code and then show that it is actually
as secure or more secure.

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.

 Instead I can imagine a better approach. The Tor network and Tor client
 itself are a good base for an alternative, safe, non-SSL-CA-dependant,
 Tor-safe, authenticated time server network.

Sure - We have discussed extending the Tor protocol specifically and
also with a small set of changes we can already extract the remote
server time. We can even do this anonymously and quite easily. That
won't solve it for everyone else using who isn't using Tor... which is
basically the entire planet! :)

 
 Parse Tor consensus approach... Well, what if that format changes in
 future? Why not build the required features into Tor itself?

I'll update tlsdate and fix it? The stat of the file will give us a time
reference in any case - that won't change unless posix changes and if
that happens, I am fine with porting tlsdate to this future system. :)

 
 My suggestions are here:
 https://trac.torproject.org/projects/tor/ticket/6894
 https://trac.torproject.org/projects/tor/ticket/8170
 
 If Chrome OS where to connect to Tor because of the new time sync
 feature of Tor, that makes connections to Tor less suspicious and adds
 more Tor clients.

That isn't happening - they can't figure out a UX way to offer a full
Tor client. They did ship Tor in their base OS for a while but basically
the UI/UX issues made them remove the binary from the system - elly, my
co-author on tlsdate was the one who ported it over and maintained it.

 
 Just sharing my thoughts. Not complaining. Whatever you decide, thanks
 for your work! :)

I've commented on https://trac.torproject.org/projects/tor/ticket/6894
and I'll try to implement it after I write a proposal.

All the best,
Jacob

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[Jacob Appelbaum]

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
parse the absolute minimum time
   stat the respective file to see the last possible atime/mtime/ctime
   pick the later time of the two
   jump the clock forward again

 What in case the directory authority is not reachable (censored area)?


 Well, if we have a file on the disk, we don't even have to touch the
 network to jump the clock, right?
 
 I must admit I am the over thinking type. Three cases. One appears
 unsolved to me.
 
 1) there is a file on disk - no consensus parser required
 2) there is no file on disk; Tor directory authority available - parse
 consensus
 3) there is no file on disk; Tor directory authority is not reachable - ?
 
 How likely is it that there is no file on disk and that Tor directory
 authority is not reachable? I have no idea, just thought, if it isn't a
 likely use case, you wouldn't think about a consensus parser.
 

I'd add another case:

4) There is a file on disk with a consensus
  we see the mtime is newer than the current clock
we jump the clock forward
  we parse the consensus, we decide that we should jump the clock again

This may end differently:

 we download a new consensus, we decide to jump the clock again

or:

 we have fetched a new consensus via some other means

 Is the parasitic approach future proof anyway? Won't that cost the
 remote server admins cpu load and traffic?

 Probably and probably not?
 
 I don't know.
 

 What if the remote server admins install some intelligent filter,
 which blocks Tor? (for other unrelated spam/ddos issues)

 Which server admins? People offering TLS?
 
 The admins of the servers which tlsdate contacts, i.e. top 100 alexa or
 whatever hosts you may pick.)
 

What will they do? Break the TLS spec and stop offering time? Set their
clocks wrong? Stop serving TLS clients?


 Why trust and get the time of some remote server admins who are not
 really willing to run a network time server? They most likely get their
 own time over unauthenticated NTP. Getting time from TLS is more a hack
 than a replacement for non-existing tcp, authenticated and distributed  NTP.


 Yeah, I'm aware. Really, well aware. People keep telling me over and
 over again
 
 I apologize, very sorry for my wording and didn't want to join that, in
 fact very happy about ANY kind of improvements in the network time sync
 area.
 

No need to apologize - perhaps just consider that we're trying to make
those improvements. We'd love the help, rather than an argument where we
make no improvements and people just tell us we're stupid for trying new
things that are imperfect. Especially when everything is imperfect.

I mean, the best complaint I've heard is that we suck for only doing
32bit time. I take that as a challenge and I look forward to solving
that issue because it does really lack in that department.

All the best,
Jacob

___
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)

[Jacob Appelbaum]

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

 Sure.

 I doubt we can blend in this anonymity set, though: unless Tails
 wants to forever copy the set of hosts ChromeOS queries (which I don't
 think we would want to rely upon on the long run), then Tails' use of
 tlsdate will probably be fingerprintable at least by the ISP if the
 connections are made in the clear, so we probably would want to run
 tlsdate over Tor anyway.

 Even if not, there are other easyish ways to distinguish a Chrome OS
 device,
 such as the autoupdate behavior.
 
 Good point. Running tlsdate in the clear will therefore be
 fingerprintable and subsequently the whole client could get blocked in
 censored areas.
 

How so?

 What could be the solution? I don't know. Can there be ever any network
 time sync solution which works in the clear?
 

Yeah, a parasitic one? For example, I'd be happy to add a network
sniffer ( tlsdate-passive ) or a proxy for HTTPS connections
(tlsdate-clock-extraction-proxy) that just looks for tls sessions,
extracts the server time and generates no traffic at all.

 If many distributions jump on the tlsdate train by shipping tlsddate by
 default, that may help?

I feel like we're over thinking it - even in the most harsh networks, we
rarely see full https blocking endlessly. The fact is that we could
probably even set our clocks against a tls mitm device ( I do so against
captive portals somteimes ) and it would still work well enough. In the
cases when https is really blocked entirely, I believe that we can
instruct tlsdate to try to look up other services (eg: randomly pick an
alexa top domain, do an mx query or connect to pop.example.com or
imap.example.com to start a tls connection).

Again, another feature request - it is a property of tls, so we can use
things other than webservers.

For what it is worth, in Egypt, ntp was busted when the network went
down unless you had a local ntp server; the same was true for most services.

 
From ntp* manpage:
 ntpd adjusts the clock in small steps so that the timescale is
 effectively continuous and without discontinuities
 
 I haven't had any issues without that feature and therefore don't miss
 it. My speculation is, that mainstream distributions may care more.
 

adjtime is a reasonable feature enhancement. It is in the queue. I've
been working on porting tlsdate to a few other platforms over that
feature though. I'd like to have a hardened parasitic network time
client before I worry about how it doesn't optimally update the clock.

 I assume over time one would be able to distinguish it - though we
 mostly care about getting a correct clock and then if someone tries to
 guess our OS, we might be fine with them then filtering us or trying to
 attack us. However, if we haven't set our clock correctly, we might have
 some issues with actual attacks like replaying a consensus, etc.
 
 This is a difficult topic, I hate being a nitpicker, don't have all the
 answers, but must say...
 
 Distinguishing the operating system should be prevented if somehow
 possible: otherwise achievements made by pluggable transports wouldn't
 last long.

We already fail this test, no? Hell, who is even testing for that except
potential censors?

All the best,
Jacob
___
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)

[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 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 could as a network
distinguisher. I assert that someone could watch - see no traffic except
encrypted traffic, decide it is Tor and then decide you're running Tails
or Whonix.

Also, the way these systems do TLS handshakes will reveal your current
clock as well as other details - such as if you're using Whonix or Tails
(if one caches the consensus, and the other doesn't).

 Tails:
 (For your ISP or local network administrator)
 https://tails.boum.org/doc/about/fingerprint/index.en.html
 
 Whonix (since interested in this topic as well):
 https://sourceforge.net/p/whonix/wiki/Fingerprint/#for-your-isp-or-local-network-administrator
 
 My point is, even if the answer is at the moment we fail that test,
 it's hopefully possible to fix as well. And, we should try to prevent
 adding new factors, which could worsen the current status, if that
 appears (already) attractive and doable.

Well, TLS is the default transport and so, I think TLS is the best way
to get time information. We're not really going to stick out any more
than the rest of the TLS traffic - in fact, we might even stick out less
because we have a valid cert and it isn't Tor, it's a shared network
time program. I admit, it can probably be fingerprinted but I think that
fingerprinting it won't look much different from the rest of the TLS
traffic - it will look lets say, less sketchy?

 
 Of course, the already existing (or new) operating system fingerprinting
 by ISP issues could still get fixed when they get real world issues. For
 example, Tails could mimic a mainstream operating system, by running one
 untorified in a VM or chroot; and letting pluggable transports doing the
 obfuscation for Tor traffic.
 

I'd be curious what snoopy says about any of the systems?

  http://www.sensepost.com/blog/7557.html

 Hell, who is even testing for that except
 potential censors?
 
 Potential censors, yes. Other, I don't have an answer.

Well, if we want to red team it, we should set up some parameters and go
for it?

All the best,
Jacob
___
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)

[Jacob Appelbaum]

Maxim Kammerer:
 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.
 

tlsdated isn't tlsdate - it launches various helper programs. How is it
crashing?

All the best,
Jacob
___
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)

[Jacob Appelbaum]

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 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.
 
 Did you get a stack trace?
 

Not that I've seen - Maxim is often extremely harsh - don't take it
personally.

 Also, yes, tlsdated is not very well-written. I wrote it in a great hurry and
 now don't really have time to undo the worst of the hacks :(. Patches 
 gratefully
 accepted.

I haven't really touched it as I consider you to generally be the owner
of that part of the code. What specifically do you think we should re-write?

All the best,
Jacob
___
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)

[Jacob Appelbaum]

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 the (half-rhetorical, I admit) question I asked in
 March, and I assume there is indeed some fingerprinting issue. So, in
 the following I'll assume it's relatively easy, for a close network
 adversary (say, my ISP) to detect that I'm using tlsdate.

 
 It isn't shipping yet, so we'll see what happens.
 
 I'm told ChromeOS ships it nowadays, so I'm excited at the idea to
 learn more about it, so that we can move forward a bit about the
 fingerprinting issue.

It does indeed - their network time document is here:

 
https://docs.google.com/a/chromium.org/document/d/1ylaCHabUIHoKRJQWhBxqQ5Vck270fX7XCWBdiJofHbU/edit

 
 I was not able to find any authoritative information about how they
 run it. Their time sources [1] design doc is quite clearly outdated.
 Where can I find up-to-date information on this topic? I assume one of
 the dozens of Chromius Git repositories [2], but which one?
 
 [1] http://www.chromium.org/developers/design-documents/time-sources
 [2] http://git.chromium.org/gitweb/
 

Basically - tlsdate in Tails would be a minor set of users compared to
the much larger user base of ChromeOS.

I've also just updated the INSTALL file to document the different places
that git-master of tlsdate works:

  Debian Gnu/Linux 6.0.7
  Ubuntu 11.04, 12.04, 12.10
  CentOS 6.2, 6.3
  Fedora 17, 18
  RedHat Enterprise Server 6.4
  OpenSUSE 11.2, 12.3
  FreeBSD 10-CURRENT
  Mac OS X 10.8.2, 10.8.3
  ChromeOS 26.0.x.x, 27.0.x.x (tlsdate is part of the ChromeOS TCB!)

I'd like to settle on a list of hosts that it uses by default which may
include a Google host or not. I haven't yet decided.

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Icedove modifications

[Jacob Appelbaum]

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 really
 intend to go on, but well, I hope this eases things.
 
 Note that the patchset was imported into the tails gbp-pq topic, to
 allow the Debian package to build and generally be consistent with how
 the icedove maintainers deal with their patches on top of upstream.
 Don't hesitate asking me if some Git or packaging workflow is unclear :)
 
 The ticket was updated quite a bit along the way:
 https://tails.boum.org/todo/Return_of_Icedove__63__/
 

Have you looked into the patches we've submitted upstream for TorBirdy?

All the best,
Jacob

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] TorBirdy: first impressions

[Jacob Appelbaum]

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 TorBirdy has disabled
 Thunderbird's auto-configuration wizard to protect your anonymity.
 Is it possible to a preference setting to do so?

We'd gladly accept a patch to handle this case - one problem is that the
auto-configuration wizard is simply dangerous. It may use insecure
protocols, even if it doesn't directly cause leaking, it is isn't safe
to use on the internet, I think.

 
 Rationale: our patchset secure account creation patchset should take
 care of most, if not all, of the issues highlighted in Tagnaq's paper.
 

Did you merge our patches to ensure the date/time stamp issues are taken
care of, amongst other issues?

 In case someone wants to review / test / have a look,
 here's the code:
 
   repo:git://labs.riseup.net/tails_icedove.git
   branch:  tails/master-10.x
   patches: debian/patches/tails/*
 

Could you describe how it solves the issues we faced? I don't have
access to this git repo at the moment. If for example such patches
allowed for the use of Tor safely and prevented insecure protocols from
being used, I'm in favor of enabling the wizard. However, I find it
concerning to enable the wizard if the result is an accidental leak or
the use of an insecure protocol...

All the best,
Jake
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[Jacob Appelbaum]

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 unusable in non-obvious ways.

I settled on rng-tools, ekeyd, haveged and ~60 seconds of randomsound; I
kill randomsound after a minute so I may use audio again.

All the best,
Jacob

 All tests have been done in Virtual Box.
 
 Every 1.0s: cat /proc/sys/kernel/random/entropy_avail
 watch -n 1 cat /proc/sys/kernel/random/entropy_avail
 
 no package installed  ~130 and ~180
 rng-tools in VM without rng hardware  no effect
 ekeyd in VM without entropykeyno effect
 randomsound only  ~130 and ~3800
 haveged only  ~1100 and ~4000
 randomsound and haveged   ~1100 and ~4000
 
 (~ is defined as, for exmaple ~1100 could be up to 1199.)
 
 Off topic:
 
 http://en.gentoo-wiki.com/wiki/Generating_better_random_numbers#Dieharder
 is an excellent source for information about entropy in general.
 
 I am conducting some entropy quality tests and will share the results soon.
 
 Cheers,
 adrelanos
 ___
 tails-dev mailing list
 tails-dev@boum.org
 https://mailman.boum.org/listinfo/tails-dev
 

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Support EntropyKey?

[Jacob Appelbaum]

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 -related
 hardware support. What do you think?
 
 Cheers,
 

I think it is a good idea. I regularly install it with Tails anyway.

It might also make sense to include rng-tools, randomsound, and haveged
for around of 1,098 kB on disk. Tails should really do everything
possible to collect entropy as often as possible; if the rng runs dry,
all the crypto fails badly... It might even be worth seeding the rng
from an unlocked persistence partition - it should be possible to drain
/dev/random of ~200 bits of entropy at any given point in time to ensure
that the rng never goes unseeded...

On a slightly related note...

I've been thinking quite a lot lately about low entropy systems that
create persistent encrypted storage. It seems like low entropy systems
that fail horribly for asymmetric keys are also likely to fail horribly
for symmetric keys.

On a modern system install a user may set up an encrypted disk. On a
recently installed laptop, I found that it had essentially zero sources
of entropy beyond the keyboard, the clock and the hostname. Of the
three, I think one could make an educated guess about the time the disk
was formatted and the hostname. The network driver wasn't working, so I
had no network traffic at all. I used the text installer, so until I
arrived at the disk encryption, my keyboard entry was essentially
setting the hostname and hitting return a half dozen times.

Basically, I think the installer calls cryptsetup like this:

  cryptsetup --verbose --verify-passphrase luksFormat /dev/sda1

Internally, I think that cryptsetup calls _action_luksFormat_useMK() or
_action_luksFormat_generateMK(), which in turn calls crypt_format() or
crypt_luksFormat(). Eventually, LUKS_generate_masterkey() or
LUKS_alloc_masterkey() will be called. Internally this just opens
/dev/urandom. As we know from Nadia's latest work[0], disaster strikes
often with /dev/urandom and especially with embedded systems or
similarly entropy starved modern laptops with no moving parts...

This may or may not be an actual bug. It seems like it is debatable if
using /dev/urandom is a bug but using it with zero entropy is clearly a
bad idea... Debian apparently considered it to be a no problem in 2010,
so they use /dev/urandom (a change *from* /dev/random) according to the
cryptsetup debian/changelog file:

  * change default for random key from /dev/random to /dev/urandom in
README.Debian, extend explanation. (closes: #579932)

... o_0 ...

I guess it would be interesting to collect actual LUKS masterkey disk
keys and look at the distribution of bits. My guess is that if the LUKS
password is collected *after* LUKS_generate_masterkey(), the entropy of
the system is basically close to zero. I think this happens only when
get_key() isn't called before crypt_format(). Though depending on how
the entropy pool is seeded, I guess the entropy of the key may still be
less than the actual bytes of the passphrase.

It may be that cryptsetup is called with /dev/random as a key file,
though I think that would mean that get_key() wouldn't be called. So it
might have less entropy than expected as there simply isn't really
anything that is actually well, entropic, for the attacker with the
computer/disk in hand. The answer is probably in the partman-crypto
package. It seems to create a key file by calling `cat $randfifo 
$keyfile` - strangely, create_random_keyfile() appears to call
call_entropy_plugin only after it starts reading from the randfifo.

Does anyone know offhand how cryptsetup is called from debian-installer?

All the best,
Jake

[0] https://factorable.net/paper.html
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Support EntropyKey?

[Jacob Appelbaum]

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/

 The total installed size of the needed packages is a few hundred
 kilobytes. I think it's worth adding to improve cryptography -related
 hardware support. What do you think?
 
 Given what I've read about HAVEGE (or rather, mostly the lack of good
 criticism) it seems like we already have solved the problem of
 generating good random numbers at will in Tails by installing haveged.
 I'm not against the inclusion of ekeyd, however.

Seems reasonable. I don't know that I'd call it solved because it is
extremely hard to know if the random numbers are, well, actually
entropic. :-/

 
 Cheers,


 I think it is a good idea. I regularly install it with Tails anyway.

 It might also make sense to include rng-tools, randomsound, and haveged
 for around of 1,098 kB on disk.
 
 Tails do install haveged by default.
 

I missed that haveged is installed. Glad to hear it.

 Tails should really do everything
 possible to collect entropy as often as possible; if the rng runs dry,
 all the crypto fails badly... It might even be worth seeding the rng
 from an unlocked persistence partition - it should be possible to drain
 /dev/random of ~200 bits of entropy at any given point in time to ensure
 that the rng never goes unseeded...
 
 Running (in Tails):
 
 cat /dev/random | pv  /dev/null
 
 reports a pretty stable rate of 2MB/s on my system, which should be
 sufficient for all *realistic* use cases. Given that the rate is good I
 don't see any reason for mixing in additional entropy sources, like you
 propose, except if haveged doesn't have good enough entropy quality on
 its own.
 

I admit, I find a high performance RNG to be... less than compelling.

 Here's two pretty interesting blog posts about haveged and its entropy
 quality:
 
 http://jakob.engbloms.se/archives/1370
 http://jakob.engbloms.se/archives/1374
 

I generally agree with the author - our tests about the entropic nature
of a bitstream are pretty weak. It seems to me that (at debian-install
time) the system will likely have very little variation. At boottime on
a given piece of hardware, I imagine this is also true for repeated runs
if one could reset the hardware to the original state. The goal for me
isn't perfect predictability but rather, predictability within a certain
set of bounds. I think that is related to the point of the Proartis[0]
project.

 Most points raised in them seem highly academic, though, so my
 conclusion is that haveged is good enough on its own.
 

I think that almost no single entropy source is good alone. The kernel
should take a few and mix them together, hopefully the kernel's mixing
works well enough. I remember hearing that the entropy pooling system
was going to get an overhaul after Nadia's paper, I wonder if that happened?

I think it would be interesting to know how the rdrand CPU flag is
utilized in Tails? If a machine has it, will the kernel automatically
use this entropy source? It would also be interesting to see if
randomsound would at least make the attack surface of the microphone
worthwhile...

All the best,
Jake

[0] http://www.proartis-project.eu/
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[Jacob Appelbaum]

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 machine
 through, say, a daisy chained thunderbolt monitor.

 I'd either remove support from the kernel, blacklist the modules in
 modprobe, or disable support with a boot param.
 
 We can't just do that. Tails is also meant to be a safe environment to
 produce sensitive documents. Being able to retrieve a video from a DV
 camera, edit it and send it online is a use case Tails should support.
 

I'd hardly call this safe. I mean, sure - those video people are safely
able to download videos over firewire - but for every person that does
that, how many people will be vulnerable to DMA attacks without even
having a clue about firewire?

 From the recent discussions regarding ExpressCards and the likes, it
 looks like we are moving to a common pattern of you have 5 minutes to
 plug things on those ports that can be dangerous, otherwise, they will
 be disabled. This should work for FireWire too, even if it feels more
 cumbersome to me than for an expansion card.
 

As this is a modular kernel - is there a reason not to simply add a
enable firewire widget? That way everyone is secure by default and
when someone wishes to enable it, someone will be able to be notified of
the danger they have just enabled?

All the best,
Jacob

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[Jacob Appelbaum]

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
 FireWire and even Bluetooth.
 
 Seems this could be a consensus. Without disagremment before Oct 19 I
 consider this as agreed.
 

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/

All the best,
Jacob

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[Jacob Appelbaum]

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)

 FTR, this is left from the times when htpdate did run wget in the
 clear (without going through Tor).

 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 quite easily distinguish from real Tor Button
 users and tails_htp curl users?

 It may be worse than what you are suggesting.

 If iceweasel + Torbutton rarely, if ever, sends HTTP HEAD requests,
 then we should probably not pretend to be Torbutton. Does it?

 The more software that pretends to be TorButton - the better, I think.
 
 As a political statement?

No. As a feature for feature match - it is true that there are other
protocol distinguishers and ... so what?

 
From technical view it's impossible [1] to imitate Tor Button with curl.
 The user agent is just one bit, there are loads of other bits to find
 out if someone is actually running Tor Browser and curl.
 

I don't care about curl at all.

 Just download for testing cnn.com with curl and look how much traffic
 has been transfered and how quick it goes, even if fetching the whole
 page, not just the header. Then watch the same thing in Tor Browser. It
 fetches loads of pictures and also connects to doubleclick and other
 third party sites.

Indeed.

 
 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 that and no
one else will do so - so you will entirely stick out.

 
 [1] Not exactly impossible. The curl devs would have to change too much,
 extremely unlikely.

I don't use curl with tlsdate.

All the best,
Jacob

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[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
 the same anonymity set as Tor Button.

 That is not the goal - the point is that you will say, drop that and no
 one else will do so - so you will entirely stick out.
 
 Well, don't drop it individually or right away. Drop it in a new release.
 

And I am saying - TBB won't drop their user agent. So you won't look
like them - you will look like you.


 [1] Not exactly impossible. The curl devs would have to change too much,
 extremely unlikely.

 I don't use curl with tlsdate.
 
 Replace curl with a placeholder for any command line downloader.
 

I think you are confused. If I send a GET request with all the headers
sent by say, Tor Browser, that *single* GET request should look
identical. That is my goal.

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[Jacob Appelbaum]

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 quite easily distinguish from real Tor Button users and tails_htp
 curl users?
 
 Even if you were not telling curl to only download the header. If you
 were still downloading the whole site. Would that actually add any
 additional benefit?
 
 Haven't found this in the design. Please explain.
 

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?

All the best,
Jacob

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[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)
 
 FTR, this is left from the times when htpdate did run wget in the
 clear (without going through Tor).
 
 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 quite easily distinguish from real Tor Button
 users and tails_htp curl users?
 
 It may be worse than what you are suggesting.
 
 If iceweasel + Torbutton rarely, if ever, sends HTTP HEAD requests,
 then we should probably not pretend to be Torbutton. Does it?

The more software that pretends to be TorButton - the better, I think.

All the best,
Jacob

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[Jacob Appelbaum]

Ague Mill:
 On Sun, Aug 26, 2012 at 10:30:18AM +, Ague Mill wrote:
 For the patch and some details, please see:
 https://tails.boum.org/bugs/sdmem_does_not_clear_all_memory/grub/

 I have not tested it on bare metal, only qemu and bochs.

 The next step is to create a proper standalone GRUB image that can be
 booted using kexec(). For reasons I don't yet understand, I have not
 been able to do so.
 
 I have been able to create a standalone image. It even include our
 boot splash screen and a progress bar.
 
 I have not yet been able to find a way to load and execute such image
 with kexec. After several hours of struggling, I have asked help on
 grub-devel.
 
 This looks really really promising though.

Thanks for all this effort. When we released the Cold Boot paper, a few
of us thought that hardware memory controllers with built-in crypto for
the stuff in DIMMs would be the norm in no time. Boy were we wrong!

I guess soon it will be XBox360 and Tails users who are safe. ;-)

All the best,
Jacob

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[Jacob Appelbaum]

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 memory forensics.
 
 I'm not sure I understand clearly what you are suggesting.
 When do you think such a dialog should appear?
 

If a firewire card was inserted into the pcmcia slot and pcmcia/cardbus
is active, I suggest it. If such things were entirely disabled, I'd have
a setup wizard that stores preferences in the persistent storage area.

All the best,
Jacob

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[Jacob Appelbaum]

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) :
 Recent Linux kernels shipped by Debian use filtered physical DMA;
 unfiltered physical DMA seems to be disabled
 (CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set). Do you know which class
 of attacks is still practicaly doable on such a system?
 
 We are still very interested in your answer to this question :)
 Thanks a lot in advance!
 

I'm not sure, so I'd still disable it until you have a forensics toolkit
or three that fails to work.

 (Reference: https://tails.boum.org/todo/disable_firewire__63__/)

Also, what about pcmcia/pccard/express card?

All the best,
Jake

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[Jacob Appelbaum]

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
 actually test this. What forensics toolkits would you suggest us to
 use for these tests?
 

In an ideal world? Get a cop to use FinFisher's kit on your stuff - lots
of people are working hard on ruining the secrecy of their entire
product line, I hear.

I'd also suggest using any of the freely available Firewire toolkits.

 However, Tails is also about Working on sensitive documents [0],
 and I'm told people working on video often need FireWire.
 So, the answer to what to do in the meantime? is not that obvious
 to me.

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 memory forensics.

 
   [0] https://tails.boum.org/contribute/design/#index3h3
 
 Also, what about pcmcia/pccard/express card?
 
 Sorry, we still have not discussed what usability vs. security balance
 we want in this area. For the record, these are tracked there:
   https://tails.boum.org/todo/disable_expresscard__63__/
   https://tails.boum.org/todo/disable_pcmcia__63__/
 

I'd still go for disabling those two unless there is actually a
compelling reason to enable them. If there is such a reason, I'd ask
that users assert it and that the assertion binds to a single device,
rather than all devices blindly. These bus attacks are simply too
powerful and too obscure for users to knowingly defend themselves.

All the best,
Jake
___
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)

[Jacob Appelbaum]

Hey hey,

intrigeri:
 Hi,
 
 intrigeri wrote (25 Mar 2012 23:02:55 GMT) :
 Jacob Appelbaum wrote (20 Feb 2012 20:30:08 GMT) :
 For a while I've been interested in secure network time that would
 be useful for Tor users. Tor users generally need accuracy to the
 hour in the local system clock.
 
 Thank you for tackling this problem.
 
 ... and thank you for going on with it!
 
 As a result, I've also written another tool, tlsdate[1], that
 I regularly use for setting my own clock.
 
 What network fingerprint does tlsdate currently display if I run it
 in the clear, without forwarding its traffic through Tor?
 
 Jake asked me to have another look at tlsdate, which was uploaded to
 Debian, so here it goes :)
 
 (It's pretty clear I lack much of the background and intended usecase,
 so please correct whatever is wrong in what follows!)
 
 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 the (half-rhetorical, I admit) question I asked in
 March, and I assume there is indeed some fingerprinting issue. So, in
 the following I'll assume it's relatively easy, for a close network
 adversary (say, my ISP) to detect that I'm using tlsdate.
 

It isn't shipping yet, so we'll see what happens.

From what I remember from our past attempts to discuss this on IRC,
 I assume the intended usecase for Tails is to run tlsdate in the clear
 (that is, without going through Tor) so that the clock is set before
 Tor is started.

There are a few use cases - the first is to use it with the -t option -
this at least will skip the clock forward to a recent build time. So if
previously, the clock was in 1970, you're at least now in the same
decade as the tails release. Probably the same year and likely, with a
few releases a year, the same month. That has no network access at all.

The next use case is to use it over Tor - I haven't added direct proxy
support yet but I'll do so when it becomes a blocking issue. As it
stands now, you can easily just `usewithtor tlsdate` and it will work
fine. This gives you the ability to securely set your clock over Tor.

Another use case is to fire it up against any SSL/TLS enabled server,
including the Tor relay you were going to use anyway, and attempt to use
it as a time source. If you use a Tor relay, tlsdate currently lacks a
way to verify the key for that relay - so it's a leap of faith, rather
than a leap of cryptographic something or other. But at the very least,
you no longer need to involve any third party that you weren't already
going to connect to - it isn't more secure, it's just a cute hack.

The most common way for me to use tlsdate is to connect to a popular TLS
server and if I trust the CA, which can be pinned to a *single* CA that
isn't part of the traditional cartel, I can easily trust it. Generally,
I find that this works fine.

 
 If so, from the PoV of a close network adversary, if Tails starts to
 use tlsdate in the clear, as a Tails user, then I'm part of the set of
 people who run tlsdate and start Tor soon after, and in the current
 state of things, this set would almost exactly match the set of
 Tails users.
 

That might be true - that's a good reason to add Tor tls fingerprint
verification to tlsdate - however, I'd take this fingerprinting risk
over a older consensus or Tor simply not working at all.

 The fact that ChromeOS uses tlsdate forces this kind of adversaries to
 detect tlsdate followed by Tor, instead of merely detecting tlsdate
 alone, in order to detect Tails users. (Looks like we have to convince
 Google to run Tor by default on ChromeOS? :)
 

Tor has been ported to ChromeOS as far as I know - I have talked with
them about adding a guest mode that uses Tor.

 Therefore, I'm not convinced tlsdate in the clear would be any better,
 on the fingerprinting side of things, than the htpdate in the clear
 system we eventually managed to escape in Tails 0.9 and later.
 Which means it looks quite worse, fingerprinting-wise, than what we
 currently ship.
 

The key difference with htpdate is that one has a cryptographic
signature. I'll take a subset of possible MITM attackers over fully
trusting something that anyone could MITM.

Furthermore, I think that you're making a trade-off between
fingerprinting on the network, which Tor does not even try to address by
default, and the ability for someone to try to use Tor with an incorrect
clock, something that explicitly doesn't work in the Tor design.

In an ideal world, Tor will learn the clock anonymously and not care
about the system time. We're not there yet; patches are always welcome!

 Thoughts?
 
 (Seriously, please prove me wrong, my life would be easier as
 a result :)
 

I generally think that shipping tlsdate makes sense, especially if Tor
is already running as you can then keep clocks securely in sync. It may
not make sense for first boot, other than to at least move it forward
with `tlsdate -t

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

[Jacob Appelbaum]

Maxim Kammerer:
 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.
 

Huh, you think that setting your clock where *everyone* can *always*
MITM your time is somehow better? Fascinating!

 Motivation behind tlsdate is incorrect:
 1. Extracting the HTTP Date: header is not a “nightmare” — it is easy,
 standards-compliant, and safe.

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.

 If anything, TLS is much harder to get
 right (see issue #16 on GitHub, for instance — tlsdate is currently
 susceptible to a MITM attack).

It's a work in progress, of course. I use it with a pinned CA, so in
such a case, users are not vulnerable to a MITM attack unless one can
get certs from that specific CA.

With that said, I have a branch to add CN/SAN checking but it makes
little sense when one use case is pre-DNSSEC bootstrapping. Rarely do
certificates contain the IP address of the host, so what we care about
is an assertion of trust by a given authority. That use case would
suggest a pinned CA anyway, so perhaps it would make sense to just add a
few new options to tackle that use case.

I'm not totally sure but I think getting a CA signature for a specific
CA is harder than any CA. I agree that using it where it trusts *any* CA
allows *any* CA to assert things. That doesn't really change with CN/SAN
checking. Practically, it makes it harder for an attacker but
theoretically, we're still relying on the CA playing nice. Pinning
removes that gamble, which seems better all around.

 2. The latency due to receiving HTTP headers is negligible when
 compared to the latency of a TLS handshake.

Do you have some data about that? The TLS ServerHello is generally the
first thing sent to the client. I'd expect the timing to be very similar

 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.

Nothing? That seems a little... technically incorrect. Users gain a
cryptographic signature - which is the goal here - to use time to trust
signatures, we might want to start with signatures that don't require
time. That raises the bar against an attacker and with a pinned CA, it
means that the attacker has to own CA or find another vulnerability in
TLS itself.

Furthermore, in the TODO, I suggest that we should offer an option to
confirm the date by comparing it with HTTP over SSL/TLS - then we can at
least say that our HTTP date has some kind of integrity protection. The
goal isn't to have millisecond accurate clocks, it's to validate
cryptographic signatures that have hour or year long windows.

 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.

Yes, another known issue - so does Tor - what's your point? It's turtles
all the way down, right?

I'll gladly add an option to break the standard, if a user wishes to use it.

 
 Additionally, tlsdate lacks important features:
 6. It cannot run as a daemon with clock skewing and hosts rotation.

That isn't the goal of tlsdate but it is something that could be easily
added. Support for a list of hosts would be a fine addition, I'm not
sure that a daemon mode makes a lot of sense. With the accuracy levels
we're discussing, an hourly cronjob would be fine as well.

 7. There is no explicit proxy support.
 

It appears to work fine with `usewithtor` but I'd gladly take a
SOCKS4a/SOCKS5 patch.

 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).

Are you one of the authors of htpdate or something? :-)

I'll gladly mirror the functionality of htpdate but the primary goal is
to solve a few problems that htpdate does not aim to solve. I think
these two tools are complementary but with very different goals -
htpdate is like rdate without any kind of security properties and
tlsdate is like rdate with the possibility of some security properties.

Lots of work to be done, of course.

 
 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.
 

I've emailed with them, so no, it's not just a github pull request.

However, I assure you, the 

Re: [Tails-dev] Switch to Privoxy?

[Jacob Appelbaum]

On 03/25/2012 08:40 AM, intrigeri wrote:
 Hi,
 
 intrigeri wrote (20 Jan 2012 15:39:54 GMT) :
 Jacob Appelbaum wrote (26 Dec 2011 15:25:23 GMT) :
 Who does support Privoxy for anonymity reasons?
 We're using it for all Tor stuff now when we need an HTTP proxy.
 
 Could you please share a Privoxy configuration you trust to be safe
 using with Tor?
 
 Ping? Did I miss a reply? I've got no such configuration I can easily
 share would be a valid reply, but at least we would know we should
 not wait for it :)
 

Sure - here you go:

# Generally, this file goes in /etc/privoxy/config
#
# Tor listens as a SOCKS4a proxy here:
forward-socks4a / 127.0.0.1:9090 .
confdir /etc/privoxy
logdir /var/log/privoxy
# actionsfile standard  # Internal purpose, recommended
#actionsfile default.action   # Main actions file
#actionsfile user.action  # User customizations
#filterfile default.filter

# Don't log interesting things, only startup messages, warnings and errors
# logfile logfile
#jarfile jarfile
#debug   0# show each GET/POST/CONNECT request
debug   4096 # Startup banner and warnings
debug   8192 # Errors - *we highly recommended enabling this*

# user-manual /usr/share/doc/privoxy/user-manual
listen-address  127.0.0.1:8118
toggle  1
enable-remote-toggle 0
enable-edit-actions 0
enable-remote-http-toggle 0
buffer-limit 4096
#EOF

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] A bunch of old but possibly interesting Polipo ideas and patches

[Jacob Appelbaum]

On 03/25/2012 08:49 AM, intrigeri wrote:
 Hi,
 
 intrigeri wrote (06 Jan 2012 15:53:31 GMT) :
 Hi Juliusz,
 
 I'm writing you on behalf of the Tails[0] development team.
 We've been shipping Polipo for years in Tails.
 
 We were alerted by Jacob Appelbaum about a few bugs in Polipo that
 could have security consequences.
 
 This warning came with a bunch of ideas and patches; not all are
 complete but they may be of some interest to you; in case these
 patches were never submitted to you, please find them attached to
 this email.
 
 We would be very interested to read your thoughts about the security
 issues suggested by Jacob.
 
 Ping?
 
 Any ETA to comment on the the potential security issues Jacob
 Appelbaum alerted us about?
 

Those issues are pretty old, I wouldn't be surprised if it was all dead
code by now.

 Given I'm neither familiar with the code nor with the issues Jacob
 reported, I'm not comfortable going the CVE / Debian bugs tagged
 security way myself, but I strongly feel someone who cares about
 Polipo should do something about it.
 
 Besides, our users have reported to us they could not download files
 bigger than chunkHighMark; is it expected? Fixed in Git? We've found
 a related bug report about it there:
 https://trac.torproject.org/projects/tor/ticket/1149
 
 This is much less urgent, and should probably not block your
 commenting upon the potential security issues.
 

I think this is actually equally as urgent. You can't use polipo to
download tails, right?

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Switch to Privoxy?

[Jacob Appelbaum]

On 03/25/2012 01:57 PM, Maxim Kammerer wrote:
 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.
 

The first part of the FAQ is the most important:

Why a HTTP proxy at all?

 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.
 

It's a wiki. Feel free to update it?

I looked at your config (
https://github.com/mkdesu/liberte/blob/master/src/etc/privoxy/config )
and it looks like the following:

confdir /etc/privoxy
logdir  /var/log/privoxy

actionsfile match-all.action# Actions that are applied to
all sites and maybe overruled later on.

# Ad-blocking is done in browsers nowadays, and removing
# page blocking and content manipulation from Privoxy makes
# it more robust (e.g., for cables communication).

# actionsfile default.action  # Main actions file
# actionsfile user.action # User customizations

# filterfile  default.filter  # Main filters file
filterfile  user.filter # User filters file

logfile privoxy.log

listen-address  127.0.0.1:8118
toggle  1
enforce-blocks  0

buffer-limit4096

forward-socks5  /   127.0.0.1:9050  .
forward-socks5  check.torproject.org127.0.0.1:9050  .
forward-socks5  torcheck.xenobite.eu127.0.0.1:9050  .
forward-socks5  .onion  127.0.0.1:9050  .
forward-socks5  .exit   127.0.0.1:9050  .

forward .i2p127.0.0.1:
forward .i2p:443127.0.0.1:4445
forward */  127.0.0.1:
forward *:443/  127.0.0.1:4445

forward 127.0.0.1/  .
forward localhost/  .
forward liberte/.
# forward192.168.*.*/ .

forwarded-connect-retries   2
accept-intercepted-requests 0

keep-alive-timeout  5
socket-timeout  300
# EOF

It seems like your config tampers with the requests pretty heavily and
the support of .exit should probably be disabled. I also think it is
dangerous to support both i2p and Tor with the same privoxy config. It
seems like it should be possible to construct a single webpage that
attempts to link i2p and Tor usage via HTTP and thus fingerprints the
user as using Liberté... No?

If I was going to make your config more generic, I'd probably remove the
filters to reduce the attack surface and to simply make it an HTTP shim:

#Begin
confdir /etc/privoxy
logdir  /var/log/privoxy
logfile privoxy.log

listen-address  127.0.0.1:8118
toggle  1
enforce-blocks  0

buffer-limit4096

forward-socks4a /   127.0.0.1:9050 .
forward-socks5  /   127.0.0.1:9050  .
forward-socks5  .onion  127.0.0.1:9050  .

forwarded-connect-retries   2
accept-intercepted-requests 0

keep-alive-timeout  5
socket-timeout  300
#EOF

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Switch to Privoxy?

[Jacob Appelbaum]

 is what's been used by most Tor users for years
 ==
 
 TBB did ship Polipo, the Tor Debian / Ubuntu packages recommend Polipo
 as the preferred alternative on top of Privoxy. Anonymity set++, etc.,
 we all know the deal.
 

We're not shipping either of them anymore, I just checked with helix.
Privoxy is what we'd suggest if anything.

 
 Polipo is not very well maintained upstream
 ===
 
 This is not to be easily ignored. IIRC the upstream author abandoned
 it for a while; it was more or less forked / maintained by the Tor
 project in the meantime; the upstream author came back, but the
 improvements made by Tor were not all merged yet.
 

Right.

 OTOH, apart of the file size download limit, it's not as if we had had
 to report many bugs against it.
 

There were a bunch.

 
 Polipo does caching
 ===
 
 We don't care, since we're not talking about web browsing anymore here.
 

We should care - leaving a copy of data around might complicate things.

 
 Jacob wants us to remove Polipo
 ===
 
 Jacob, you talked of lots of reliability/security issues and told us
 that Privoxy is a better http proxy for most things. Would you
 please elaborate, after reading this very email, _what_ exact issues
 you're thinking of, and _what_ makes Privoxy that much better?
 
 

% git branch
* bugs
  master
  type-fixup

I've attached the commits from bugs and type-fixup. They're old and I
think Chris at least has seen all of the commits in these branches.

All the best,
Jacob

 Wanna add more pros and cons?
 
 Cheers,

commit 7db83d6a303ff372a367afa68895fe1a19abb08f
Author: Jacob Appelbaum ja...@appelbaum.net
Date:   Fri Mar 19 19:34:36 2010 -0700

DNS issues

diff --git a/dns.c b/dns.c
index 1a5b39b..11957c4 100644
--- a/dns.c
+++ b/dns.c
@@ -1394,6 +1394,8 @@ stringToLabels(char *buf, int offset, int n, char *string)
  memcpy((_d), (_dd), sizeof(unsigned)); } while(0);
 #endif
 
+
+/* This should be rewritten to use descriptive names for n, *d, m, etc... */
 static int
 labelsToString(char *buf, int offset, int n, char *d, int m, int *j_return)
 {
@@ -1413,6 +1415,7 @@ labelsToString(char *buf, int offset, int n, char *d, int 
m, int *j_return)
 if(i = n) return -1;
 o = (ll  ~(3  6))  8 | *(unsigned char*)buf[i];
 i++;
+/* XXX Is this possibly full of endless recursion? */
 labelsToString(buf, o, n, d[j], m - j, k);
 j += k;
 break;
@@ -1544,6 +1547,7 @@ dnsDecodeReply(char *buf, int offset, int n, int 
*id_return,
 error = EDNS_FORMAT;
 goto fail;
 }
+/* This is missing check to see if i is still in buffer... */
 DO_NTOHS(type, buf[i]); i += 2;
 DO_NTOHS(class, buf[i]); i += 2;
 
@@ -1587,6 +1591,14 @@ do { \
 
 for(j = 0; j  ancount; j++) {
 PARSE_ANSWER(an, fail);
+ /* XXX used length from network, instead of length from name- ...
+  * also...
+  * For any request polipo makes for say yahoo.com, anything starting
+  * with y will match if the network returns a lie for the length...
+  *
+  * This is pretty sub-optimal...
+  *
+  */
 if(strcasecmp_n(name-string, b, m) == 0) {
 if(class != 1) {
 do_log(D_DNS, DNS: %s: unknown class %d.\n, 

commit 039e87e5bba790920101e6c39acab1246a1e49fc
Author: Jacob Appelbaum ja...@appelbaum.net
Date:   Fri Mar 19 19:06:58 2010 -0700

atomCat issues

diff --git a/atom.c b/atom.c
index ed18d92..68a5249 100644
--- a/atom.c
+++ b/atom.c
@@ -91,6 +91,10 @@ atomCat(AtomPtr atom, const char *string)
 char *s = buf;
 AtomPtr newAtom;
 int n = strlen(string);
+/* XXX atom-length may be insanely large and overflow with n to be less
+ * than 128; n may also be a giant string - this is not safe. It's likely
+ * the case that we should ensure that atom-length is some MAX_SIZE that we
+ * never grow above... */
 if(atom-length + n  128) {
 s = malloc(atom-length + n + 1);
 if(s == NULL)

commit 668d8e27a78adbf73194c5795562e1e565fc04c6
Author: Jacob Appelbaum ja...@appelbaum.net
Date:   Fri Mar 19 18:58:14 2010 -0700

Initial TODO notes

diff --git a/TODO b/TODO
new file mode 100644
index 000..e07f5ed
--- /dev/null
+++ b/TODO
@@ -0,0 +1,35 @@
+We should enable as much exploit mitigation support as possible
+
+
+The following relates to SOCKS4/SOCKS5 interfacing with Tor.
+
+Why does Polipo have DNS support at all?
+Removal of all DNS code or force to be 127.0.01?
+Removal!
+Add --disable-dns flag?
+Perhaps overload all functions to log, rather than resolve?
+This will help us find stray calls that _would_ leak information
+
+Caching attacks
+We need to have a new identity function for Polipo
+We already have this in Vidalia and Tor

Re: [Tails-dev] [tor-talk] Did we decide about bad exits ? Where does bittorrent fall ?

[Jacob Appelbaum]

On 12/15/2011 12:10 PM, intrigeri wrote:
 Hi,
 
 Andrew Lewman wrote (15 Dec 2011 17:53:59 GMT) :
 There are completely legitimate uses of bittorrent over Tor.
 I've talked to people who want to get their ISO of Fedora or Ubuntu
 from outside their country, so they bt over tor to do so.
 
 We've been refusing to include a BitTorrent client in Tails since the
 beginning due to some kind of common sense that was telling us it
 would harm the Tor network.
 

I'm not clear that it will harm the network if Tails includes a
BitTorrent client. I think that the harm comes when someone runs a few
seeding boxes through Tor and doesn't bother to add any capacity to the
network at all.

 Recently, we've been asked again -supposedly by a prominent member of
 the Tor community- to include Transmission; the request was sent with
 an offer to audit this piece of software for safeness in Tails usecase.
 

It seems like Transmission is a fine torrent client. On second thought,
I'd want to see what possible clients are written in Python or another
safer language. One challenge is that any security bug, and certainly
memory corruption bugs in C programs, may become an anonymity bug rather
quickly. So an audit is really two tasks - the first is to see if it's
proxy aware/obedient and the second is that the code base is generally
sanely written.

 This, added to reading this thread, makes me doubtful.
 
 What do you think? Shall we include a (carefully audited) BitTorrent
 client in Tails?

I think that you should do so if only to ensure that Tails is
need/intention complete. It's going to be a great day when someone can
easily and simply anonymize their entire computing experience without
needing to learn if they shot themselves in the foot, etc.

Speaking of which - did you see my recent list of tails comments?
https://trac.torproject.org/projects/tor/ticket/4639

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev