Re: [tor-talk] Announce: amnesia Live system (initial release)
Hi, 10 years ago, I announced here the first public release of "amnesia", that later merged with Incognito to give birth to the operating system that's now called Tails: https://lists.torproject.org/pipermail/tor-talk/2009-August/002667.html To quote my team-mate anonym: 拾拾拾 It was a great journey and I'd like to thank everyone who participated in this collective effort or supported it :) Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] if browser remembers URLs visited before shutdown even during Never Remember History
bo0od: > There is a full comparison of Tails and Whonix (persistent virtual OS) > can be found here: > https://www.whonix.org/wiki/Comparison_with_Others#Introduction FTR the Tails part of that page is quite outdated. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] AORTA - others tried it?
Rob van der Hoeven: > Except for programs that clone an already running instance the > interception and redirection of AORTA *should* be guaranteed. > On my Debian system, programs like Firefox and Chromium do not work > with TorSocks. For AORTA I haven't been able to find a program that > does not work under AORTA. If I wanted to find another type of applications that AORTA does not manage to torify, I would look for programs whose main executable merely triggers startup of the main program via D-Bus activation (e.g. those started with gapplication). Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] onioncircuits
tor user:
>> There's Onion Circuits that we ship in Tails and Debian:
>> https://git-tails.immerda.ch/onioncircuits/
>> https://tracker.debian.org/pkg/onioncircuits
> Oh great thanks for the pointers.
> I tried it shortly and realized another vidalia
> feature I used: bandwidth graphs
Onion Circuits was developed primarily with Tails in mind,
and since Tails routes all Internet traffic through Tor,
the network bandwidth graph provided by GNOME System Monitor
was deemed sufficient.
Now, I guess we would not reject a a good UX/GUI design + branch that
adds bandwidth graphs.
> How does one configure/specify non-defaults for onioncircuits?
> - the target IP address
> - ControlPort
> - unix socket file
> - ControlPort password?
I'm afraid the best doc we have for this is the source code:
connect_args = dict()
if 'TOR_CONTROL_SOCKET' in os.environ:
connect_args['control_socket'] =
os.environ.get('TOR_CONTROL_SOCKET')
if 'TOR_CONTROL_ADDRESS' in os.environ or \
'TOR_CONTROL_PORT' in os.environ:
connect_args['control_port'] = (
os.environ.get('TOR_CONTROL_ADDRESS', '127.0.0.1'),
int(os.environ.get('TOR_CONTROL_PORT', 9051))
)
self.controller = stem.connection.connect(**connect_args)
Cheers,
--
intrigeri
--
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Looking for a tool to replace vidalia?
Hi, tor user: > Do you know of any tool that: > - displays tor circuits and the streams attached to it? > It is not required to display them on a map, but it should display the 3 > nicknames with > country information and the streams attached to it by their destination and > port (hostname). There's Onion Circuits that we ship in Tails and Debian: https://git-tails.immerda.ch/onioncircuits/ https://tracker.debian.org/pkg/onioncircuits > - allows me to kill specific circuits That's not supported by Onion Circuits. Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] unable to start tbb after a tor update on debian.
Hi shirish! shirish शिरीष: > I am using debian buster. I used to start tor from an alias > /home/shirish/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/start-tor-browser Given the path where your Tor Browser is installed, it looks like you're using torbrowser-launcher. If you're using the torbrowser-launcher Debian package, then please report a bug against it. And if you're using the upstream torbrowser-launcher, then its bug tracker lives there: https://github.com/micahflee/torbrowser-launcher/ Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tails prevents MAC changes as design feature
krishna e bera: > On 04/07/17 02:13 AM, intrigeri wrote: >> Answered on tails-...@boum.org. > That shows as a mailto: link. Perhaps meant to point to […] Sorry I was too lazy to express what I meant clearly enough. I wasn't overly enthusiastic at the idea of spending time myself dealing with others' ill-advised cross-posting practices. Whatever, what I meant was: https://mailman.boum.org/pipermail/tails-dev/2017-July/thread.html Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tails prevents MAC changes as design feature
Answered on tails-...@boum.org. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] release of heads 0.2 live 100% libre torified distro based on devuan
Hi, Lara: > those handicapped enough to be unable to write software This can be interpreted in a number of ways, including some that I personally find problematic. But maybe you want to rephrase so I understand better what you meant? Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [Secure Desktops] [Tails-dev] Persistent Tor start in Tails vs location aware Tor entry guards (LATEG)
Hi,
Patrick Schleizer wrote (09 Feb 2016 23:42:22 GMT) :
> intrigeri:
>> [can you please decide what mailing-list this discussion should happen
>> on, and then we can stop cross-posting over 4 mailing-list?]
This still holds.
>> I'm not sure I understand the problem you mean to raise, though.
>> Can you please elaborate what problem you see if users do exactly this
>> ("click through whatever hoops required to make the WiFi connect
>> again", which I agree is very likely)?
> day 1
> 1) Tails user regularly goes to physical place A that provide [free] WiFi.
> 2) The name of the wifi is FreeWifi832458252823523 with MAC address "A".
> The user uses the regular way to set up a WiFi connection. Network
> Manager etc.
> 3) Now, Tails would remember FreeWifi832458252823523 and assign entry
> guard A.
> day 2
> 3) Tails user goes to the same physical place A that provide [free] WiFi.
> 2) The name of the wifi has changed to FreeWifi358235892435 with mac
> address "B". The user uses the regular way to set up a WiFi connection.
> Network Manager etc.
> 3) Now, Tails would remember FreeWifi358235892435 and assign entry guard A.
I don't understand why we would pick Entry Guard A in the last step on
day 2, can you please explain?
> This is the behavior I expect from most users. And this is what I meant
> by 'users will click through whatever hoops required to make the WiFi
> connect again'.
Fully agreed!
> The entry guard selection would now be influenced by by the provider of
> the [free] WiFi. And I think such an adversary capability is something
> as we agree that is to be avoided.
Right, it's something we want to limit. anonym and I have been working
a bit more on it, and have reverted the addition of the ESSID in the
data we hash, found another attack, thought a bit about potential
defenses, and discussed it a bit more. See the "First iteration"
section on our blueprint for details:
https://tails.boum.org/blueprint/persistent_Tor_state/
In the current state of things we're undecided whether our current
design is good enough to be worth shipping, or not. We'll probably ask
someone (probably Isis) for help evaluating it and/or designing
something better.
Cheers,
--
intrigeri
--
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [Tails-dev] Persistent Tor start in Tails vs location aware Tor entry guards (LATEG)
sajolida wrote (07 Feb 2016 13:01:57 GMT) : > If we think that the relationship between location and entry guard is a > meaningful information, for the mobile user for example, maybe the name > of the entry guard could at least be fed back somehow before the > connection takes place, in Tor Launcher or whatever connection process > will might come up with in Tails. Not sure I understood what you mean with "fed back" here. IMO merely exposing this info to the user in more places brings little value, if any. If we find a good way to give the user some meaningful control over it, it's different of course. Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [Tails-dev] Persistent Tor start in Tails vs location aware Tor entry guards (LATEG)
Hi,
[can you please decide what mailing-list this discussion should happen
on, and then we can stop cross-posting over 4 mailing-list?]
Patrick Schleizer wrote (02 Jan 2016 22:36:13 GMT) :
> But I think location aware Tor entry guards (LATEG) are wrong headed.
> The topic of LATEG is so difficult to explain to the user, that as you
> plan, you cannot add it the the UI. Perhaps buried under an advanced
> setting, but that's not worth so much. So it cannot be manual by
> default. Only automatic.
I agree.
> Which brings me to the issue.
> There is a reason, why Tor picks a Tor entry guard and sticks to it. By
> changing it more often than Tor would do, you are subverting the reason
> for using Tor entry guards in the first place. In a sense, you are to a
> small degree thereby becoming a Tor developer, and modifying Tor's relay
> choosing algorithm.
I think I see what you mean, and indeed it's the kind of things about
which my self-confidence is pretty low, and I'd personally rather
avoid fiddling with things I don't understand.
But the thing is: by using random guards every time Tails starts, we
are _already_ making the very same kind of decisions. Only, we are
making it very badly, and this has been going on for too many years
already.
Let's face it: as distro integrators, in the current state of things,
we have to make a decision to compensate for the fact that Tor's guard
selection wasn't designed with our threat model in mind.
Keeping things as-is would be a decision. Using fully persistent entry
guards (not location aware), like Tor Browser users get currently,
would be another decision. We cannot escape it, so we're trying to
make this decision in a way that's much better for the vast majority
of Tails users.
> I wonder, if the whole LATEG thing would not be much better implemented
> in Tor itself. If so, then any (further) research of the entry guard
> topic would still apply to Tails, and not to Tor only.
With my (lazy by design) distro integrator's hat, I can only agree:
the more work is done by little-t-tor, the less I have to deal with
myself, and the more is shared cross-distro. Yay.
However, taking a step back, I'm not sure it makes a whole lot of
sense: to be location-aware, tor would have to gain knowledge about
new concepts, and interface with OS services, that it can currently
happily ignore so far; add to this that tor is multi-platform;
I expect it's not an easy problem to deal with at this specific place,
but again: if someone solves it, I certainly won't complain :)
> The documentation advice for advanced users caring about AdvGoalTracking
> could be to use obfuscated [private] bridges and to alternate
> them per travel location.
Right, I think it's important that people who what more control can
get it this way, and IIRC our current best proposal does not prevent
anyone from doing this.
> Or perhaps you might be able to explain in tor-launcher /
> anon-connection-wizard [1] [2] [3] the LATEG / AdvGoalTracking issue.
If the configuration GUI has good facilities to document a broad and
complex problem, yay, bringing the doc closer to the software is
probably a winning strategy.
>> [...] By adding the SSID, we prevent attackers from being able to
>> spoof only the MAC address of the router to reuse a given Tor state;
>> they also have to spoof the SSID which is visible to the user and might
>> be detected as malicious. [...]
> I find it unlikely, that users might judge an often changing SSID
> malicious. FreeWifi832458252823523 vs FreeWifi358235892435. How many
> users are going to remember that? I would guess, they would just click
> through whatever hoops required to make the WiFi connect again.
I have no time/energy to think seriouly about it now, and I've been
postponing my reply for a month due to this, so I'll try to be
pragmatic: I'm adding this as a FIXME on our blueprint, and will come
back to it later.
I'm not sure I understand the problem you mean to raise, though.
Can you please elaborate what problem you see if users do exactly this
("click through whatever hoops required to make the WiFi connect
again", which I agree is very likely)?
Thanks!
Cheers,
--
intrigeri
--
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Best devices to boot Tails off of?
Qaz wrote (15 Aug 2015 05:20:45 GMT) : Are there flash drives that really work well with Tails? Please send such support requests to the appropriate channels: https://tails.boum.org/support/ Thanks in advance! Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How can I make sure that the Tails I'm running is legitimate?
Hi, qazxsw...@openmailbox.org wrote (14 Aug 2015 11:46:00 GMT) : So I'm running a Tails on a DVD-R version 1.5 and I'm very curious as to if I'm running a legitimate copy of Tails. Could you guys help me? Thanks for your interest in Tails. Please address such questions to the Tails support channels: https://tails.boum.org/support/ Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Hacking Team looking at Tails
Hi, [redirecting this discussion to tails-...@boum.org, which is more suitable for this discussion = please drop tor-talk@ from the list of recipients when replying -- thanks!] I wrote (12 Jul 2015 13:06:15 GMT) : https://wikileaks.org/hackingteam/emails/emailid/25607#efmBTaBTh Below research points remain outstanding ... VECTORS · Offline: [...] by translate.google.com but obviously not precise but concerning nonetheless. I got a translation made by a native speaker who's skilled in this area, quoting it below with my notes+todo inline. $native_speaker wrote: [EN] Below the feature that will be deployed for RCS10. The release is expected for [... not sure what does it means ...] (October) VECTORS: Offline: o Infection of bootable usb keys from UEFI (Antonio)$ The infected usb key will drop (release) a scout itself. This seams to mean that a corrupted UEFI firmware would modify a Tails device plugged in the machine to infect it. To me it looks like it's part of Tails can't protect against compromised hardware, modulo nitpicking wrt. whether firmware is software (which is correct strictly speaking), or a mere part of the computer hardware (which is also correct, from the PoV of a Tails system, as it's pre-existing to Tails starting). We have WIP to clarify our documentation in this respect. o Infecting USB device which appears to be a bootable disk (Antonio + Giovanni)§ It will drop (release) the scout, then it will run a wipe. Seems to be the same, but from a running and already infected non-Tails OS, when a Tails USB stick is plugged in it. That's more concerning. We should check if we're communicating clearly enough that: * the OS used to install or upgrade a Tails device can corrupt it * plugging one's Tails device in an untrusted OS is dangerous o Infection of Tails USB (Antonio)$ The infection will occur at runtime This seems to mean an running Tails infecting its boot device. Totally unclear if they had any remote idea of how to implement that, back then. Not much we can do about it that is not on our hardening milestone already, I guess. o New NTFS driver for UEFI infection (Antonio) o Persistent infection also on OSX and signed UEFI (Antonio) Network Injection: o New set of external antennas for the TNI (Andrea) o Creation o a mini-TNI (Andrea)$ transportable by a drone, without any melting constraints o Creation of a micro-TNI (Andrea)$ HW of a mobile $ It will have a subset of the functionality Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] vpn+tor in tails
Hi, Petru Daniel Diaconu wrote (25 May 2015 09:56:56 GMT) : Can you make so that you install cyberghost in tails [...] Please use the Tails support channels for Tails questions: https://tails.boum.org/support/ Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Client obfs4 Trouble
Hi, Keepin On wrote (13 May 2015 09:36:12 GMT) : I'm using Tails 1.4. Please use the Tails support channels for such requests: https://tails.boum.org/support/ I try to edit the torrc file to add obfs4 bridges and [...] https://tails.boum.org/doc/first_steps/startup_options/bridge_mode/ Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Why obfs4 bridges aren't work in Tails?
Hi, FYI, when we tested Tails 1.3.2, we could successfully use obfs4 bridges. Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor and HTTP/2?
Lara wrote (18 Feb 2015 17:42:46 GMT) : What is the stand of the Tor Project related to HTTP/2? Tor can transport basically anything that lives on top of TCP. Assuming HTTP/2 is TCP, then there's basically nothing to do on the Tor side, it should just work :) And I guess HTTP/2 won't be widespread enough to be very useful for pluggable transports before a while. No idea if the protocol has specific issues that will delay its support in Tor Browser until later than whenever Firefox ESR supports HTTP/2. Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Which PTs shall we prioritize for inclusion in Tails?
Thanks for the input! -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Removal of Vidalia content from our website
Kevin wrote (09 Feb 2015 15:59:53 GMT) : Why is it no longer supported? Because there are better options for the use cases the Tor Project is actively supporting, and nobody has volunteered to maintain Vidalia upstream in the last few years. Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Which PTs shall we prioritize for inclusion in Tails?
Hi, Tails currently supports regular bridges, obfs2 and obfs3. Work is in progress to support scramblesuit. I see that Tor Browser 4.5 ships flashproxy, meek and obfs4. Assuming an ideal world in which they involve an equal amount of work, among scramblesuit, meek, flashproxy and obfs4, which ones should we prioritize our efforts on? (An option is of course all, just take whatever the Tor Browser ships, but it's not obvious that it's the best solution for us, hence my question.) Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Where's longclaw
lu...@riseup.net wrote (16 Jan 2015 19:18:06 GMT) : Riseup Networks has been getting DDoS'd sporadically these couple of days, this probably explains the outage of their dir auth. s/days/weeks/ Actually, that DDoS has started at the beginning of 31C3 :/ Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Including Adblock to TBB to save bandwith
Hi, Justaguy wrote (15 Dec 2014 13:44:05 GMT) : What if torbrowser would include adblock, this would reduce the amount of bandwith used, and thus increase the overal speeds @ tor See 5. No filters in https://www.torproject.org/projects/torbrowser/design/#philosophy Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How to disable Tor Browser's Internal Updater?
Hi, Rusty Bird wrote (09 Dec 2014 12:24:55 GMT) : since updates downloaded by Tor Browser's Internal Updater [1] [2] are unverified [3] we at Whonix project [4] are wondering [5] how to disable it. Especially since updates are downloaded over Tor in case of Whonix. Ideally, is there some way to disable it without recompiling / forking TBB? I'm under the impression that the TB updater is the regular Firefox updater, configured to use torproject.org as a data source. So have a look at the app.update.* preferences, app.update.enabled in particular. Indeed, in Tails we do: pref(app.update.enabled, false); Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Luks and Tails: (why can I not access encrypted folder?)
Hi, please don't cross-post. This will be replied on tails-support@. Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Merging all languages (locales) into one Tor Browser package?
Hi, Sebastian G. bastik.tor wrote (07 Sep 2014 12:29:15 GMT) : Upsides: + will make it easier for Tails to switch to using the Tor Browser binaries. Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Weekly News — September 3rd, 2014
Hi, I wrote (03 Sep 2014 23:06:18 GMT) : If I'm on the Tails list because I'm disseminating Tails why aren't I being told to replace the old with the new version before this? Please direct support questions about Tails to our user support channels: https://tails.boum.org/support/ Thanks! Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] how many verify their tbb ?
Hi, mick wrote (29 Jul 2014 19:02:39 GMT) : But it begs the question - what proportion of the the monthly total downloads from all the mirrors that represents. Any idea? No idea: we've never asked the people operating our mirrors to collect such stats. If anyone wants to think of it, draft an email we could send them, think how we would receive and store the data, and retrieve useful info from it: I certainly wouldn't mind :) Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] how many verify their tbb ?
Hi, mick wrote (29 Jul 2014 14:54:10 GMT) : I have just checked on my tails mirror and I get the slightly depressing results below: [...] which I make 0.68% Our download page has been pointing to our own website for downloading the detached signature file for a few months, which explains the traffic you see (or rather, fail to see). Look at our monthly reports for more useful signature downloads figures :) Cheers! -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] GnuPG and Tor
Michael Carbone wrote (15 Jul 2014 19:11:15 GMT) : https://gaffer.ptitcanardnoir.org/intrigeri/code/parcimonie/ Currently down = better install from Debian (if using this distribution, or a derivative) or get the source from https://packages.debian.org/source/sid/parcimonie Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] GnuPG and Tor
Red Sonja wrote (16 Jul 2014 11:58:41 GMT) : Do you have anything less demanding? *I* haven't. See the shell version, linked by Michael earlier on this thread. I haven't looked at it in details, no idea if it satisfies the same design goals etc. Cheers, -- intrigeri -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Fake keys for Tails developers' email address
Hi, u. (Cc'd) has notified me of two fake keys with Tails developers' email addresses: EB24 9600 79A3 E2B9 3BFE 48B5 05F8 BB78 B38F 4311 C3BA A4BF E369 B2B8 6018 B515 0E08 AC78 06C0 69C8 These are *not* genuine. Don't trust them. Our real keys are documented on https://tails.boum.org/doc/about/openpgp_keys/. Interestingly, the 2nd one has been created two days before the fake key Erinn discovered [1] two months ago, and has the same lifetime (4 years). I guess one might find more such keys by looking at keys created in the same period. [1] https://lists.torproject.org/pipermail/tor-talk/2014-March/032308.html Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc pgpXAQDCuj6Nb.pgp Description: PGP signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Orbot v14 alpha: obfsclient, Tor 0.2.5.3-alpha
Hi, Nathan Freitas wrote (02 May 2014 19:44:35 GMT) : We are also experimenting with a switch to Polipo (https://github.com/jech/polipo.git) from Privoxy. Jacob was strongly advocating that we do the exact opposite change in Tails, so I'm curious why. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Pirate Linux 2.0 alpha
Hi, AK wrote (01 Apr 2014 01:53:06 GMT) : Let me just clarify some points. Is the goal to be more secure than a standard Linux distro such as Ubuntu or Debian? Yes. OK. What I'd be delighted to read now is what more secure means. I'll wait for your next write-up :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Pirate Linux 2.0 alpha
Hi, AK wrote (30 Mar 2014 20:14:06 GMT) : More details are here: https://piratelinux.org/?p=567. Interesting, thanks! Where can I read about the threat model this system is meant to address? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [tor-dev] Linux kernel transproxy packet leak (w/ repro case + workaround)
grarpamp wrote (28 Mar 2014 21:02:35 GMT) : [...] what happens with entire vm IP transproxy (perhaps like Tails)? Tails only uses a transproxy for the automapped .onion addresses: https://tails.boum.org/contribute/design/Tor_enforcement/ Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Thunderbird leak
Mike Cardwell wrote (26 Jan 2014 18:34:59 GMT) : Also you might want to post this on the tails list. I am not on the Tails list. Perhaps somebody who is already there might bring it up? FYI, Tails does not ship Thunderbird. Also, anyone can post on the Tails lists (no need to subscribe first). Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] USB Sticks for TAILS
Hi, (Adding Tails folks into the loop; the thing is not called TAILS more than Tor is called TOR, by the way :) I thought I would just drop some notes so that anyone interested is aware of issues that shall be taken into account (#1 below) and solved on the long term (#2 below) when considering mass-duplication of Tails USB sticks. 1. There is currently no way to verify the integrity and authenticity of a pre-installed Tails, and I don't think it will get any better in the future: in my understanding of the chicken'n'egg theory, there is no easier way to bootstrap a trust path to a pre-installed Tails thumb drive, than to bootstrap a trust path to a downloaded ISO image. If we wrote software that allows one to verify a Tails thumb drive from another, running and trusted Tails system, then the usecase we're adressing could as well be solved by just cloning the trusted one to the other thumb drive, right? I still see how it could be useful to write such a piece of software, but I'm unsure the energy needed is worth it, once the most obvious potential usecase has been debunked. 2. It will be hard to scale mass-duplication of pre-installed Tails USB sticks once we have thrown some new spicy security improvements into Tails-users land. The easiest way we've found to give the persistent volume some plausible deniability properties is to create it by default at installation time (https://labs.riseup.net/code/issues/5929). The need behind this technical solution is often expressed to us, and we want to satisfy it. For this to add any security, every created persistent volume must have different key material. In this context: * Selling handmade Tails works fine, and could be scripted with a carefully crafted liveusb-creator command-line run in a loop. * The only ways I can think of to have this scale beyond 100% handmade installation feel kludgy, and it may not be trivial to ensure the result still offers plausible deniability (I'm thinking of using a USB duplicator, and then post-process the cloned thumb drives to replace the encrypted key, in the used LUKS slot, with other random data). Still, as far as 30C3 is concerned, it's totally fine to bring a hundred pre-installed Tails 0.22 sticks, and I'm very happy you are planning to do so — please just make sure they're installed in a supported, compatible with the persistence feature, way :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] USB Sticks for TAILS
Andreas Krey wrote (15 Nov 2013 15:41:26 GMT) :
I didn't read anything about actually putting Talis onto the sticks,
just about providing the sticks (whose unique feature is the working
r/o switch.) Subject: 'for', not 'with'.
Right, I {over,mis}-interpreted Moritz' email, sorry.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
--
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Fwd: [rt.torproject.org #15873] Re: Another way that people can be watched
Chuck wrote (10 Nov 2013 19:18:31 GMT) : I recommend sending this email to the tor-talk mailing list, you will get a lot more useful answers than here. https://lists.torproject.org/pipermail/tor-talk/ Sorry to redirect you once again, but tails-support is probably more appropriate given the topic: https://tails.boum.org/support/ Cheers! -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] More and more websites block Tor, which will eventually become useless!
hi...@safe-mail.net wrote (10 Nov 2013 18:37:10 GMT) : Today I discovered that wiki.debian.org blocks Tor exit nodes. It blocks *some* exit nodes, not all. E.g. it works for me right now. Data point: I had the exit nodes removed from the blacklist (via private follow-ups to http://bugs.debian.org/725445) a few weeks ago, and FTR there were only a few ones. The admins made it clear they will incrementally re-add addresses on abuse. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [RELEASE] Torsocks 2.0.0-rc2
David Goulet wrote (05 Nov 2013 21:08:33 GMT) : In terms of new naming, I would personally *love* that but we have to be careful with package that depends on torsocks and one comes into mind, parcimonie. So, if we decide that a new name is a good idea, packaging needs to consider the transition and possible breakage. At least for parcimonie (which I'm upstream for), I'm pretty sure we'll manage to talk to each other and provide a good transition path :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] EncFS in Tails
Red Sonja wrote (05 Nov 2013 18:22:29 GMT) : I have just discovered that EncFS works well under Windows. So that would be a secure way to share files between Windows and Linux. But can I do it with Tails also? Please take Tails-specific questions to the Tails support channels: https://tails.boum.org/support/ Thanks in advance! Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Fwd: SecureDrop, new whistleblower submission system
Micah Lee wrote (31 Oct 2013 22:24:13 GMT) : With SecureDrop, the viewing station requires Tails with persistent storage, and you can only use persistent storage if you boot off of a USB stick. FTR: you can boot from DVD and use persistence on a USB stick. It's not documented nor formally supported, but I'm told it works fine. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [Tails-dev] TAILS (Tor Linux distribution) contains extra root CAs ?
Hi, Anonymous Remailer (austria) wrote (17 Oct 2013 17:58:39 GMT) : I have a question: @OP: first, it seems you have cross-posted this to at least tor-talk, tails-dev and Full-Disclosure, without making it clear with an explicit Cc:. This will painfully lead to various unlinked discussions and will be a mess for us to address this question. So, please don't do that next time, thanks in advance :) I'm setting I-R-T and References headers to at least avoid breaking the thread on tor-talk and tails-dev. Tor Browser Bundle - Firefox ESR 17.0.9 (LATEST TOR) Compared to: Iceweasel 17.0.9 (LATEST TAILS Linux distribution) To be found in Tails (not found in TBB), some additional certificates: Thanks for carefully auditing this aspect of Tails. DigiCert Inc - DigiCert High Assurance EV CA-1 DigiCert Inc - DigiCert High Assurance CA3 GeoTrust Inc. - Google Internet Authority G2 StartCom Ltd. - StartCom Class 2 Primary Intermediate Server CA The Go Daddy Group, Inc - Go Daddy Secure Certification Authority The USERTRUST Network - Gandi Standard SSL CA All these are listed as Software Security Device certificaties. The others are Builtin Object Token and baked in the browser. Tails ships NSS 2:3.14.3-1~bpo60+1 from Debian squeeze-backports. If you are interested in investigating this any further, next step is to compare with the version of NSS that is shipped by (or linked into, or something) the TBB. Question is: did TAILS added some extra CA's ? No, we don't add any CA to Tails. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] New Onions
grarpamp wrote (04 Oct 2013 08:25:51 GMT) : Lots of identical banners... Tails/Whonix are you shipping some defaults? Tails doesn't ship any web server by default. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor users are not anonymous
Lunar wrote (06 Sep 2013 13:16:24 GMT) : See tc-play for an alternative implementation, though: https://github.com/bwalex/tc-play FWIW cryptsetup 1.6 supports the TrueCrypt on-disk format, too. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Is Tor still valid?
Hi, mirimir wrote (06 Aug 2013 05:46:37 GMT) : If this exploit had included a Linux component, Tails would not have protected you. I've not studied the attack code but this appears to be mostly correct. Our shortest-term plan to address this is to contain [1] the web browser; this is part of the 2.0 milestone on our roadmap [2]. On the longer term, we are interested in evaluating how VM-based approaches can be put to good use within our design goals. If you're interested, help [3] is much welcome! [1] https://labs.riseup.net/code/issues/5525 [2] https://labs.riseup.net/code/projects/tails/roadmap [3] https://tails.boum.org/contribute/ Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] What about new Vidalia GUI features ?
Hi, VakVarjucska wrote (05 Aug 2013 22:52:18 GMT) : What do you think about new vidalia GUI features like: You need to be aware that Vidalia currently lacks a maintainer. A new one was on his way to take care of this piece of software, but I've not been able to reach him for a few weeks. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Is Tor still valid?
Hi, Gregory Maxwell wrote (06 Aug 2013 06:47:03 GMT) : This is basically the threat model that whonix's isolation is intended to address, it would be good to see tails improve wrt this. Sure. The Live environment and our wish to support not-so-powerful hardware may get in the way, but I'm curious to see someone check what is our actual workable margin. (Annoyingly, we depend to some degree on whether Intel go on using the VT-x feature, or lack thereof, to segment their stuff.) Did I mention we need help? :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] What's different in torbrowser?
Hi, Martin Kepplinger wrote (01 Aug 2013 09:35:18 GMT) : Is there a list of what of the patches you maintain on top of firefox https://gitweb.torproject.org/torbrowser.git/tree/HEAD:/src/current-patches/firefox are user-configurable in about:config for example (like probably not leaking dns over socks proxy)? I'm not sure what you mean, but the TBB configuration may be the way to look at: https://gitweb.torproject.org/torbrowser.git/tree/HEAD:/build-scripts How to make a systemwide firefox installation as similar to torbrowser as possible as a user? What we're doing in Tails might be the closest thing to what you describe, but I would not recommend anyone doing the same at home. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] TorBirdy patches for Mozilla Thunderbird
Hi adrelanos, adrelanos wrote (31 Jul 2013 00:14:58 GMT) : adrelanos: Debian's answer is get patches merged upstream […] [...] Neil Williams: Then create a new upstream which can take the patches and package the code *ONCE*. Thanks for digging this up, it helps understand exactly where was the misunderstanding. I appreciate it. But, wow! This was the opinion of one individual Debian contributor (who might not know the context well), expressed on one specialized Debian mailing-list (among hundreds). May I suggest you are more careful in the future, when drawing and spreading conclusions about the Debian project's position? Thanks in advance :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] TorBirdy patches for Mozilla Thunderbird
Hi, adrelanos wrote (28 Jul 2013 17:54:31 GMT) : TBB can't become a Debian package. Debian's answer is get patches merged upstream [...]. It seems that you are misinformed, and therefore incorrectly pointing foreign causes for things don't happen the way we want, while they don't happen... simply because nobody makes them happen. Sure, upstream first would likely be Debian's answer if the Torbrowser patches were designed in a way that they only affect the browser behaviour if some opt-in setting is enabled, and if someone asked for these patches to be applied to Iceweasel. AFAIK these patches are not designed this way, which easily explains why nobody ever asked the Iceweasel maintainers to apply them. So, in the current state of things, this policy of Debian's is simply not applicable, and irrelevant as far as the Torbrowser is concerned. As was explained already on this list (last time by Lunar a few months ago IIRC), the only reasonable way to get Torbrowser in Debian is to make it possible to install it in parallel with Iceweasel. The major blocker right now is the lack of someone to actually do the needed work, not this or that policy: policy matters were sorted out, and agreed upon with the relevant Debian teams already. Finding someone with the right set of skills and enough free time to actually do this work would be a great way to help. Interested? The situation may be different on the Thunderbird / Icedove side, though :) Hoping it helped clarifying what the real blockers are, cheers! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] TorBirdy patches for Mozilla Thunderbird
Hi, adrelanos wrote (29 Jul 2013 10:51:10 GMT) : intrigeri: which easily explains why nobody ever asked the Iceweasel maintainers to apply them. I understand, that the Iceweasel maintainers are not interested to add them. It's not about being *interested* (which is purely about feelings). It's about taking responsibility to maintain patches outside of the area / usecases / codebase where they were meant to be used (that is, effectively committing to do more work). Finding someone with the right set of skills and enough free time to actually do this work would be a great way to help. Interested? I'd be interested, but that task appears too difficult and obscure to me. For the record, I was not suggesting you would do this work yourself: my Interested? was about the *finding someone* part :) So, in the current state of things, this policy of Debian's is simply not applicable, and irrelevant as far as the Torbrowser is concerned. I have a quite different viewpoint here. There are people willing to contribute, but no one able to do it as policy dictates. Policy is blindly enforced while saying for security reasons. I'm curious what policy you're talking about. (I've taken the liberty to ignore the part about people blindly doing things, assuming you were neither referring to something that happened for real, nor meaning to be offensive to actual people.) Flexibility is the bottleneck here. If flexibility is the bottleneck, and manpower is not, I'm more than happy! Then, please enlighten me: how could Debian, as an organization, be more flexible on the Torbrowser topic, in a way that doesn't imply additional work for current Debian contributors? Since we're moving out of the tor-talk topic into learning how Debian works, perhaps this should be taken off-list at some point... Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] TorWall - experimental transparent Tor proxy for Windows
Hi, Fabio Pietrosanti (naif) wrote (05 Jul 2013 06:06:32 GMT) : It would be interesting to try to build a TinyXP live-iso machine, with TorWall integrated to create a sort of Tails based on Windows . Data point: Tails hasn't shipped with a transparent proxy since 0.10, released in January, 2012. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tails statistics / browser homepage [Was: CloudFlare]
Hi, NoName wrote (22 Apr 2013 06:00:48 GMT) : Only there is no conspiracy. Only plain stupidity. Regardless of the actual wording of the emitted judgment, I suggest you check your facts, and make sure you know what you're talking of, before judging other people's action. Just a friendly advice. Take Tails for example: once upon a time they used to default to check.torproject.org. Only that somebody decided it would be cool to have some statistics. Now it defaults to the tails homepage. For the record, this is an entirely incorrect description of the decision process we had. Facts: * the homepage was changed in Tails 0.16, released on January 11 this year * the Tails report for August, 2012 has boot statistics = We were publishing boot statistics _months before_ the browser home page was changed... no magic involved: the data from which these stats are computed simply does *not* depend on the web browser homepage. I think I've guessed what may have confused you in the first place: the Tails report you're pointing to reads this number is an approximation from the requests made to the security announcements feed. I'm sorry that security announcement feed is vague enough for you to mix it with the connection the web browser makes to the Tails news page. The language we use in our reports is aimed at end-users, and may not be as technically precise as what you'd like. As I'm sure you are interested in drawing conclusions from more precise technical information, I suggest you read the 3.4 Notification of security issues and new Tails release section of our design document, that points to the actual code: https://tails.boum.org/contribute/design/ Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [Tails-dev] secure and simple network time (hack)
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 Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [Tails-dev] secure and simple network time (hack)
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. 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? (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.) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] secure and simple network time (hack)
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. 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/ Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] What is up with: tails-i386-0.17.1?
Hi, whistler wrote (25 Mar 2013 18:55:25 GMT) : But when I go to https://archive.torproject.org/amnesia.boum.org/tails/stable/ to find it, that directory is not there. When I go directly to the directory for 17.1, it is there, and has a signature file and iso file. The signature file is a real signature file but the iso file consists of html saying that there is no iso file. I can reproduce none of these problems, sorry. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [Tails-dev] Tails Mac support
Hi, Maxim Kammerer wrote (22 Feb 2013 20:45:24 GMT) : Don't you already regret basing Tails off a binary distro like Debian? Personally, I have to say I absolutely do not regret this. not only are you completely dependent on an upstream distro's features implementation cycle I've no idea what misconceptions about Tails and Debian make you think this, but this is incorrect in practice. First, I fail to see what compiling binaries yourself buys you, in terms of your level of dependency on upstream distro's features implementation cycle. But anyway, let's debunk this myth before it propagates any further. Most of the time, what prevents us from diverging from our various upstreams (Debian, Tor, Torbrowser to name a few) are design decisions and personal taste, and have nothing to do with basing our stuff on a binary distro: * It was decided early in Tails development to treat long-term maintenance as a very important criterion -- and generally, the smaller the delta we have to carry ourselves, the easier the maintenance. * We quite like to share tools, have them used by more people rather than just Tails users, maintain them with other people and not on our own. We quite dislike inventing wheels that only fit on the Tails car. All this is no news, should be quite easy to get when reading a bit about Tails development, and has been documented for a while on our Relationship with upstreams page: https://tails.boum.org/contribute/relationship_with_upstream/ So, yes, e.g. having UEFI support added to Debian Live makes sense to me, as opposed to implementing in a Tails-only way and maintaining it forever. Sure, it sometimes means we get the feature a bit later (which is not that clear in this specific case). you are missing the opportunity to learn new things while implementing those features yourself. If you intend to go on writing such bold public statements about Tails, then I'd rather give you first-hand information that you can base your affirmations on. Here we go, then. My experience absolutely does not match your assumption. I'm personally quite happy with how I've been learning new things when implementing features for Tails, be it when writing Tails-specific software, or when implementing the feature upstream, or when working to make Debian an awesome platform to build the next Tails generation upon. I mean, Liberté was the first Linux distro to ship with a UEFI Secure Boot-based trusted boot chain Congrats. do you think you will ever be able to say something of the sort about Tails? Historians could probably build long lists of such things that could be said about Tails, but life's too short for me to do this work :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] torsocks 1.3 is tagged and released
Hi, Nick Mathewson wrote (22 Feb 2013 17:47:34 GMT) : [...] so I've uploaded a tarball to [...] Thanks! Since I was given conflicting information from Nick and Jake on this topic, I've used the data source that had the most information in it (i.e. the tarball) as a basis for torsocks 1.3-1 that I've eventually uploaded to Debian experimental. I'll be happy if Jacob and Nick find an agreement and give a single authoritative answer on the tag / tarball topic for 1.4 :) As an extra wrinkle, this is my first time running make dist on torsocks, so it's possible that make dist has bugs that don't appear when using the tags. I've compared the content of the tarball and the content of the tagged Git tree, and the result seems good enough. I'm not sure if it's on purpose that the tarball doesn't ship FAQ, README.TORDNS, nor doc/tsocks.conf.*, though. The previous release didn't either. Please open tickets if so; caveat haxxor. :/ Sure. FWIW, it would be a bit easier to try and avoid reporting duplicates if there was a dedicated Trac tickets report, listed on the available reports page [1], for the torsocks component. I managed to get myself such a report by modifying the URL of another existing report, but I doubt everyone would do that. [1] https://trac.torproject.org/projects/tor/report Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tails Mac support [Was: Training Journalists in Istanbul]
Hi, Runa A. Sandvik wrote (04 Feb 2013 15:12:51 GMT) : - Tails has very limited support [8] for Apple hardware. 23 out of 30 attendees were Mac users. I tried booting Tails on my MacBook Air, but OS X was unable to find the USB stick. OK. As discussed on IRC, we're aware of this serious issue. A great part of the problem may be solved relatively easily by shipping a hybrid ISO again [1]. A first useful set of reports would be to try our obsolete Mac installation instructions [2] with a Tails ISO that was hybrided first, either with `isohybrid` (from the syslinux package, on GNU/Linux) or with `isohybrid.pl` (Perl version, can be taken from the syslinux source, should hopefully work on OSX), and reporting back if it works, how exactly it fails, and the exact hardware model / version. Also, trying with refind instead of refit would be nice too. Runa and other Mac users, could you please try this? The remaining part of the problem will be solved by adding UEFI support [3] to Tails. We're currently making plans with Debian Live upstream so that this support is added there, and benefits all Debian Live systems. [1] https://tails.boum.org/todo/hybrid_ISO/ [2] http://git.immerda.ch/?p=amnesia.git;a=blob;f=wiki/src/doc/first_steps/manual_usb_installation/mac.mdwn;hb=165da525a2b0e3b84afba1cd4da532ba8e85da73 [3] https://tails.boum.org/todo/UEFI/ Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] torsocks 1.3 is tagged and released
Hi, Jacob Appelbaum wrote (12 Feb 2013 19:25:59 GMT) : intrigeri: A Git tag integrates perfectly with packaging workflow... iff it's the canonical form of distribution of the complete upstream release. [...] I'll discuss it with nickm and see what he thinks. A tar.gz isn't too much of a problem but I'm not sure of where I'd put it. FTR, I'm waiting for an authoritative upstream answer on this before I upload 1.3 to the Debian archive. I'm more and more tempted to take the Git tag as the canonical form of distribution of the complete upstream release, which it seems to be in practice, given there's no tarball that I can find 10 days after the release was announced (and again, the Git tag suits me well). Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] torsocks 1.3 is tagged and released
Hi Jacob, Jacob Appelbaum wrote (12 Feb 2013 00:54:46 GMT) : After quite a long development cycle, we've tagged torsocks 1.3 today: https://gitweb.torproject.org/torsocks.git/shortlog/refs/tags/1.3 Awesome! Do you plan to release it in form of a tarball, or is the Git tag the canonical way to get the released code? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] torsocks 1.3 is tagged and released
Hi, Jacob Appelbaum wrote (12 Feb 2013 16:40:01 GMT) : Would you like a tar.gz and a tar.gz.asc? A Git tag integrates perfectly with packaging workflow... iff it's the canonical form of distribution of the complete upstream release. If a tarball with slightly different content (e.g. that includes autotools generated stuff) is going to be published, and is considered to be the canonical released source code, then I'll deal with it and take the tarball, but I'm certainly not asking for it :) Cheers! ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] how tails sync the clock afer network connection ?
Hi, charlie.mail wrote (01 Dec 2012 06:07:49 GMT) : I have seen tails sync the clock with UTC just after a network connection and start browser. How does it do so. It is the ntpupdate ? Please direct questions about Tails to the Tails communication channels. Anyhow: https://tails.boum.org/contribute/design/Time_syncing/ ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] tor breaks after applying firewall
hi, charlie.m...@riseup.net wrote (29 Nov 2012 13:39:31 GMT) : If I then apply my firewall ping failed and no access to internet. I think this is off-topic, and I suggest you find a better suited place for basic iptables/netfilter support. iptables -N lan As far as I can see, this chain is never called. iptables -t filter -A OUTPUT ! -o lan -j DROP I don't parse this line, and I doubt iptables does. Other than that, at first glance, I fail to see how Tor would be allowed to connect to the Internet. I suggest starting over from a known-working similar firewall, such as Tails' or Liberté's one. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] torsocks is broken and unmaintained
Hi, Matthew Finkel wrote (03 Nov 2012 03:10:53 GMT) : On 11/02/2012 07:36 PM, Jacob Appelbaum wrote: If Robert wants someone to maintain it, I'd be happy to do so. I saw this thread earlier but didn't have a chance to reply. I was thinking about volunteering to patch it up and maintain it if no one else wanted to take it on, also, but if you want to take the lead on it then I'm more than happy to help you where ever possible...assuming this is the direction that's decided upon. With my maintainer of torsocks in Debian hat on, I must say I am very pleased to see two people volunteering to maintain it upstream. Thank you, Jacob and Matthew! I'd love someone to take care of the bunch of bugs that have been waiting for a while in torsocks bug tracker, and I'd love to decrease the amount of patches I'm carrying in the Debian package! I guess next step is to talk to Robert, and perhaps put a 1.2.1 bugfix release out, that would include some long-standing proposed fixes, and prove the world that upstream is alive and kicking again. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Multiple servers with SAME hidden service
and...@torproject.is wrote (20 Oct 2012 16:01:01 GMT) : The last to publish a descriptor wins. I do this now for some of my own hidden services. The relevant keys are copied to multiple machines. If one goes offline, the others become used. This is more like failover than load balancing, but it works today. We've been doing the same for a month or two for the SMTP relay used by WhisperBack in Tails, and are happy with it. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Review request: TorVM implementation in Qubes OS
Hi,
adrelanos wrote (16 Oct 2012 18:28:19 GMT) :
Abel Luck:
I need to do more research into what it would take to protect the
localtime. For example, what are the consequences (technically and
UX-wise) of changing the local timezone to, presumably, UTC?
UTC is fine. Afaik Tails, Liberte Linux and Whonix are using UTC.
Since the initial question was about UX too, I feel like I should add
that many Tails users don't think UTC is fine. Quite unsurprisingly,
they are confused when they are shown a clock that is off by a few
hours, compared to their own idea of what time it is in their current
location.
It looks like *displaying* UTC for everybody is a UX failure.
What would be best, IMHO, is to have UTC as the system timezone,
but display local time in the {GNOME,whatever} clock applet.
I've not researched if/how this is possible in GNOME yet.
Help is welcome.
Cheers!
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [Tails-dev] Please review Tails stream isolation plans
Hi, Nick Mathewson wrote (30 Aug 2012 15:10:52 GMT) : * Pidgin Not too scary, I think. You'd typically wind up with one destination per chat, or one per chat protocol? Typically, per chat account. * Liferea RSS feed reader This one is a little scary. Do I understand correctly that an RSS reader will make a separate connection for every RSS feed that you subscribe to? If so that might make some pretty serious load. Yes, it will. I've personally been using per-destination separate streams for 70 feeds in my own reader for a while. Shame on me for loading the Tor network, maybe, but at least I can confirm it works well. Anyhow, I don't expect many Tails users to make such an intensive use of the feed reader: RSS in itself is unlikely to grow in popularity, and like it or not, modern uses involve a web-based RSS reader rather than a desktop one... Then you have a few command-line ones such as wget. Also, some software that is not SOCKS aware, such as APT, goes through Polipo (to be replaced with Privoxy, some day). Oh wow. Instead of shunting these applications' traffic through Polipo or privoxy, have you considered relinking against torsocks to *make* applications understand SOCKS, We have not considered adding SOCKS support to APT and wget, and given our limited resources, I doubt we'll do it. We could probably run them using torsocks, though. or using some kind of iptables trickery? I'm not sure how doable it is to use iptables to convert HTTP proxying to SOCKS, but I'd be happy to learn :) When we stopped using those proxies, we weren't really thrilled with their security or their performance. It makes me uncomfortable to see and here goes an HTTP proxy in any Tor design these days. Sure. Instead of investing time to move to Privoxy, we might as well want to simply drop Polipo. I've updated our ticket on this topic accordingly: https://tails.boum.org/todo/replace_polipo_with_privoxy__63__/ Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [Tails-dev] Please review Tails stream isolation plans
Hi, Thank you for having had a look. adrelanos wrote (28 Aug 2012 23:53:01 GMT) : Consider Pidgin with several accounts configured for different identities. If you connect with all of the accounts at the same time, they'll all get the same circuit, so the identities can be correlated. While Tails does not formally support using multiple contextual identities at the same time, Pidgin generally opens very few network connections, so the performance impact of using IsolateDestAddr should be small. Given how cheap it is, it looks like it is worth having Pidgin use a (not necessarily dedicated) SocksPort that has IsolateDestAddr and IsolateDestPort enabled. True. Difficult to document. I don't think we want to document that at all: documenting it would look like we support using multiple contextual identities at the same time, while we don't. I initially proposed the feature for Tails Well, I think Jacob did (in 2011). and now I am considering your improvements for aos. Nice! I'm glad this may be useful for aos :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [Tails-dev] Please review Tails stream isolation plans
Hi, Nick Mathewson wrote (29 Aug 2012 13:22:36 GMT) : I'd need an actual list of applications to think about IsolateDestAddr. Which ones did you have in mind? Thank you for having a look. The main network applications shipped in Tails, that would get IsolateDestAddr according to our plan, are: * Claws Mails (replaced with icedove / Thunderbird, some day) * Pidgin * Liferea RSS feed reader * Gobby Then you have a few command-line ones such as wget. Also, some software that is not SOCKS aware, such as APT, goes through Polipo (to be replaced with Privoxy, some day). Basically, that's it. Note, however, that Tails users may choose to install whatever they want from the Debian archive, or hand-compile whatever they feel like, but I doubt the ones who will do so, and unfortunately pick applications that don't play well with IsolateDestAddr, will be that many to make a measurable difference. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Please review Tails stream isolation plans
Hi, we are told that Tor 0.2.3.x is good enough for Tails, so a bunch of Tails developers have eventually spent some time thinking what could be the initial step towards basic usage of Tor stream isolation within Tails. The resulting plans are waiting to be reviewed there: https://tails.boum.org/todo/separate_Tor_streams/ While I'm at it, we wanted to ask whether it is reasonable for Tails to ship with IsolateDestAddr enabled by default (but for the web browser) as described in our plans, or if it is doomed to put too high a load on the Tor network. (Not that there are tht many Tails users, and I guess these options were not added in order not to be used, but still.) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tails question: Desktop in laptop mode during shutdown, mysterious sense data?
Hi, goosee...@safe-mail.net wrote (25 Aug 2012 15:39:56 GMT) : I'm posting here because this was not solved/addressed on the Tails forums. The Tails forum homepage reads The forum is open for discussions that *do not* belong to bugs [...]. You may be more lucky by following our bug reporting guidelines, that will lead you report your problem in a way that enables us to help: https://tails.boum.org/doc/first_steps/bug_reporting/ Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [tails] Crypto enforcement proposal
Hi, HardKor wrote (23 Aug 2012 09:05:00 GMT) : I took a look on the persistant partition of tails : [...] Thank you for caring about this. What do you think about that ? Not all Tails developers read tor-talk, so please direct such discussion threads to the communication channels documented there: https://tails.boum.org/contribute/how/input/ Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [Tails-dev] tails_htp: exit node can fingerprint Tails users until exit node is changed
Hi, adrelanos wrote (23 Jul 2012 01:36:26 GMT) : Because Tails doesn't use stream isolation and uses tails_htp over Tor, the exit node can see Hello, this is a Tails user!. (Who else uses tails_htp over Tor.) The problem persists until the exit node is changed. To be on the safe side, I'll assume the underlying unproven assumption (that tails_htp's fingerprint is that easily recognizable by an exit node) is true, which is probably the case in the current state of things. Proposed solution: use stream isolation, run tails_htp/wget over a different SocksPort. Great idea, thanks! I've added it to this ticket: https://tails.boum.org/todo/separate_Tor_streams/ ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tails' htpdate [Was: secure and simple network time (hack)]
Hi, adrelanos wrote (21 Jul 2012 04:30:31 GMT) : If I understand correctly, you pick three random servers. One from each pool. And then build the mediate of the three. This is correct. What's the point of asking the foe pool? (Servers which generally do not care about privacy.) This means we implicitly decided it was more important to ask parties that are unlikely to cooperate to send fake time information to Tails users, than it would be to entirely avoid asking servers who generally don't care about privacy. In general, for such matters, I'd rather rely on diversity, rather than on a set of trusted peers. Why doesn't tails_htp ask more than three servers for the time and build the mediate? Like 6, 9 or 12. IIRC: speed, and simplicity (good enough is good enough). If that's not good enough, I'm happy to take a patch :) ... but we need to make up our mind wrt. tlsdate first, I think. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] TBB lags behind as Firefox ESR 10.0.6 is released
Hi, Roger Dingledine wrote (21 Jul 2012 15:54:22 GMT) : the Tails people set up a forum, and I hear they hate it so much that at this point they wish they had nothing rather than the one they have. Well, not exactly, else we would just shut it down immediately :) But yeah, our current forum clearly did not scale well to its current usage rate, and we do want to replace it with something better: https://tails.boum.org/todo/improve_the_forum/ Cheers! ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor on Raspberry Pi
Hi, || ΣΖΟ || wrote (21 Jul 2012 18:28:14 GMT) : PiTails? On the Tails side, we have decided to wait a bit for the dust to settle, and for our upstreams (Linux, Debian, Debian Live) to support embedded and ARM platforms better, before we even try supporting this kind of hardware. Our efforts (or lack thereof, right now) in that field can be followed there: https://tails.boum.org/todo/handheld_Tails/ ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] secure and simple network time (hack)
Hi, adrelanos wrote (18 Jul 2012 18:37:18 GMT) : To make our life even worse... Sorry... But not using NTP and only emmiting Tor traffic is also pretty clearly Tails. Because that puts you in the group of users Uses Tor, nothing else, but does not use NTP? How many people act like this?. So you should at least emmit a fake NTP query (when others that usuaally do) and drop it. This is indeed true for a non-shared public IP, and is mitigated to some degree when sharing an IP (e.g. behind home router NAT, concurrently with others non-Tails systems). Looks like we'll need to think a bit more what kind of fingerprinting resistance a system like Tails can reasonably pretend to at this scale. (I'm re-adding the Cc to tails-dev, that was lost at some point. Please don't drop it again.) Cheers! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] secure and simple network time (hack)
Hi, Jacob Appelbaum wrote (19 Jul 2012 23:48:48 GMT) : 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. I think this is wrong in the context of Tails. There are a few pieces of software called htpdate, and the one Tails uses only connects to HTTPS servers, and delegates to wget the X.509 certificates validation: https://tails.boum.org/contribute/design/Time_syncing/#index3h2 In addition, the pal/foe/neutral pool system Tails uses gives *some* protection against untrustworthy sources of time information, which limits what one can do with only a few illegitimate X.509 certificates they got from a trusted CA: https://tails.boum.org/contribute/design/Time_syncing/#index4h2 Thanks a lot for your detailed answer! I'll think about the rest later. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] secure and simple network time (hack)
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. 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. 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. 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? :) 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. Thoughts? (Seriously, please prove me wrong, my life would be easier as a result :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] TorBirdy 0.0.10 released - testing and feedback requested!
Ethan Lee Vita wrote (12 Jul 2012 20:23:38 GMT) : I agree, but what about the email client for Tails? Will Thunderbird/TorBirdy be available in Tails in the future? Or a way to torify that client? Please see https://tails.boum.org/todo/Return_of_Icedove__63__/ In case you want to follow-up on the Tails-specific part of the discussion, please consider doing so on the Tails development discussion channels, if only because not all Tails developers read tor-talk. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Pirate Linux 1.5
hi, AK wrote (31 May 2012 15:36:27 GMT) : Was it your answer to my question about upgrading Tails? [...] If someone is using Tails booted from Pirate Linux, they can download the ISO from the Tails website, and use the USB installer there, it should work as long as they have enough RAM to store the ISO. I'm not sure I understand correctly what you mean, but the way I understand it won't work at all in the current state of our tools. (I'd be glad to see our tools improved to support this usecase, though :) My point here is that I absolutely do not want to see a new class of users, locked in a non-upgradable, obsolete and buggy installation, coming up on our support channels, because someone gave them something called Tails, that did not really work like the real thing. So please: * Either make sure you give the Pirate Linux users a working and documented way to upgrade the Tails you are distributing to new versions we put out. Relying on should work feels inadequate to me. Best would be to make it so the standard, documented way somehow works for Pirate Linux users too, I guess, so that you don't have to fork the Tails documentation, the Tails upgrade notification system, and possibly more. It may boil down to contributing the changes you need to Tails, instead of having to slowly fork it. * Or, make it crystal clear to Pirate Linux users the version of Tails shipped with it is meant to easily allow people to try Tails, and that it may be obsolete, may contain security issues fixed in Tails since then, and may be broken in various random ways. This clearly is the cheapest way to do it. In that case, perhaps synchronizing somehow with our release dates could be worth it, to avoid putting a new Pirate Linux out two weeks before the scheduled release of a Tails major version? ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Pirate Linux 1.5
Hi, Andrew K wrote (31 May 2012 19:07:54 GMT) : - Convenient access from the boot menu to the Tails Amnesic Incognito Live System (This method of using Tails is not officially supported by the Tails developers, and some features such as the USB installer may not work). It always feels good to see Tails spread around, but given the non-standard way this one is installed, I feel compelled to ask: Is any security feature of Tails known to be broken? How are users supposed to upgrade the Tails provided by Pirate Linux? ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Pirate Linux 1.5
Hi, AK wrote (31 May 2012 14:00:17 GMT) : From what I tested, no security feature is broken. Great. It's meant to easily allow people to try Tails, an if they like it and they want the official version, they can go to the Tails website and download the latest ISO. Was it your answer to my question about upgrading Tails? ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Creating distributed social networks with WebId behind Tor
miniBill wrote (15 May 2012 19:25:46 GMT) : 4) this requires every user to have an always on machine Julien Voisin is going to work on Tails server during GSoC this year; the task page was not updated -yet- with all the deeper thought that was put in the project since then, but you'll get the idea: https://tails.boum.org/todo/server_edition/ ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Designing a secure Tor box for safe web browsing?
Hi, Maxim Kammerer wrote (04 Apr 2012 22:39:09 GMT) : The user is expected to keep private information on the system (remember that Liberté had persistence from the beginning, but this is often true even without persistence). If the system is exploited, finding out the computer's MAC / IP addresses will most likely be the least of the user's problems. Back to the threat model, then :) One of the main Tails use-case we've heard of is to work on stuff that is public, or will become public soon: in this case, what they want to hide is not really the actual content, but instead its linkage to particular physical locations or hardware. In this case, finding out the computer's MAC / IP addresses is not the least of their problems. I hope this clarifies things a bit. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Designing a secure Tor box for safe web browsing?
Hi,
Preamble: I'm still not convinced the benefits of the Live amnesic
host OS + Tor routing VM + desktop VM approach are worth the energy
we would need to move Tails to this model, but I do find it
interesting to go on a bit with the thought experiment, and to explore
the limits of this idea.
Maxim Kammerer wrote (26 Mar 2012 16:12:41 GMT) :
On Mon, Mar 26, 2012 at 00:52, intrigeri intrig...@boum.org wrote:
I'm curious about what resources proved to be limiting during your
experiments, and what too demanding means in your usecases.
Well, Intel VT / AMD-V virtualization extensions are rarely
available on laptops, and without these extensions (accessible,
e.g., via KVM), running a virtualized instance is extremely slow
In my experience, a 7 year old laptop with no VT extensions runs quite
comfortably a full Debian desktop inside a VirtualBox virtual machine.
Obviously, you don't get the entire power of your bare metal CPU, but
you don't lose that much either, and I would certainly don't feel the
end result to be anything like extremely slow. On the other hand, my
experience with QEMU clearly matches the extremely slow results.
Maybe your conclusions on VM speed are simply too tightly bound
to QEMU?
There are also RAM requirements — how much do you allocate?
This needs to be decided in advance, regardless of how much memory
the user needs for performing the task in the VM.
In the scenario this thread is about, I don't think it's that hard to
find a way of splitting the memory that allows the user to perform
their task, without being all too wasteful:
* the host system's memory needs are not likely to vary much,
are they?
* the Tor routing VM memory needs are not likely to vary much,
either
* the Desktop VM gets what's left
Obviously, this gets much harder for applications VM.
I would be happy to learn why you consider this is pointless.
For tasks like abstracting network interfaces and other hardware,
the user can run everything in a VM by themselves — why force it
on everyone?
These abstractions are probably the only reason why I think this
approach would somehow make sense for Tails needs (even if I don't
know if we will go this way in the end).
This is hardly a technical question. It's obvious to me how the way
you ask it, and the way I am answering, say much about how Tails and
Liberté Linux differ in their approach of non-technical matters, in
the ways we think our relationship to users. Let's catch this
opportunity to explain my take on this a bit, and hopefully understand
each other better. Note that I don't care about convincing anyone
here :)
So, why would it make sense to pre-configure, for everyone, the
technical tools that get these abstractions up and running?
Because Tails is about building a common pre-configured system that
tries to address certain common needs, for anyone who happens to share
these needs.
(We certainly value user {self-,}education very much, as I think the
recent efforts put into reorganizing and writing Tails documentation
clearly displays: learning some amount of technical stuff is a must
to make ones own security decisions properly. But I absolutely don't
think that learning how to choose, install and configure
virtualization software, and how to setup a Tails or Liberté VM in
there belongs to the kind of knowledge that empowers people to make
their own security decisions properly. I'd rather see Tails users
learn things more useful than this.)
Because, while people can run Tails in a VM by themselves already,
doing this certainly does not give them the same benefits as an
integrated, pre-configured Live amnesic host OS + Tor routing VM +
desktop VM Tails would:
* In the first case, they have to trust _their host system_ to not
steal information, and to not leak anything to disk, willingly
or not.
* In the second case, they don't need to setup and configure that
host system, because we do.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] obfsproxy
pro...@secure-mail.biz wrote (29 Mar 2012 21:34:28 GMT) : I haven't seen any ticket for creating a .deb package. Perhaps obfsproxy should also be added to the torproject.org repository? obfsproxy is in Debian experimental: http://packages.qa.debian.org/o/obfsproxy.html Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] secure and simple network time (hack)
Hi, 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. 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? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Designing a secure Tor box for safe web browsing?
Hi, Maxim Kammerer wrote (22 Mar 2012 14:07:25 GMT) : I implemented that approach once for the purpose of running unsafe browser (https://github.com/mkdesu/liberte/commit/0f0646e), executing an already-running image inside a nested QEMU. It's a nice exercise, but too demanding on resources, I'm curious about what resources proved to be limiting during your experiments, and what too demanding means in your usecases. Knowing these figures would make this report useful, to a degree, to draw conclusions for other usecases. and ultimately pointless (personal opinion). I would be happy to learn why you consider this is pointless. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How can the video play in TBB without plagins?
Sebastian G. bastik.tor wrote (26 Mar 2012 16:37:54 GMT) : The windows version of TBB ships with NoScript which is set to allow scripts globally, but Forbid AUDIO/VIDEO and Apply these restrictions to whitelisted sites too are both enabled. This means one has to click the object (this time a video) and answer the dialog of NoScript. I think this may be what this ticket is about: https://trac.torproject.org/projects/tor/ticket/5266 Regards, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] irc clients and Tor
Robert Ransom wrote (20 Feb 2012 08:23:05 GMT) : torsocks 1.2-3 just hit wheezy/testing, and it works on irssi (at least as shipped in wheezy). torsocks 1.2-3~bpo60+1 is now available in squeeze-backports. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Operating system updates / software installation behind Tor Transparent Proxy
Hi, Moritz Bartl wrote (02 Mar 2012 00:27:58 GMT) : The second reason to avoid Bittorrent over Tor is that there is no audited torrent client. There is none because of the first reason. In case someone wants to do this audit, they should get in touch with Jacob Appelbaum who offered Tails developers to audit Transmission, or possibly a client written in a safer language - better avoid duplicating the effort. Cheers, -- intrigeri ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Gateway and Tor Workstation by ra
pro...@tormail.net wrote (21 Jan 2012 13:32:36 GMT) : Perhaps someone could create a LiveCD with Linux, VirtualBox and the VMs. Maybe that's a feature request for tails. First operating system could be a hypervisor, as guest the Tor Gateway which remains invisible and the Tor Workstation what top you see right now. See similar ideas on our wishlist / todo list: https://tails.boum.org/todo/Two-layered_virtualized_system/ https://tails.boum.org/todo/autorun_in_Windows/ Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | The impossible just takes a bit longer. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor survey
Hi, The reason you are receiving this message is that, to improve our study, we require some extra information about the Relay(s) you are running that, unfortunately, is not publicly available. I'm curious how such extra information will improve their study, if/why knowing such private information is useful to make this attack more efficient (or working). Regards, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Who wants a world in which the guarantee that we shall not | die of starvation would entail the risk of dying of boredom ? ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
