Re: [tor-talk] Strangeness when upgrading to Tor v. 0.2.1.30
Hi, James Brown wrote (27 Feb 2011 16:45:54 GMT) : > I upgrade the Tor from 0.2.1.29-1~~lenny+1 to 0.2.1.30-1~~lenny+1 using > the package 'tor_0.2.1.30-1~~lenny+1_amd64.deb' from the Tor repository. > It was successful, as I can see from /var/log/tor/log my Tor worked as > 0.2.1.30 after that, not as 0.2.1.29. > On this everning I have run commands `aptitude update && aptitude > safe-upgrade` and it upgraded my Tor version from 0.2.1.29 (how? it was > upgraded already!) to 0.2.1.30-1~~lenny+1 using the package > 'tor-geoipdb_0.2.1.30-1~~lenny+1_all.deb' (from the Tor repository too). > Is it normal? The answer is in the question :) Seems like the first step upgraded the package called "tor" (tor_0.2.1.30-1~~lenny+1_amd64.deb), while the second step upgraded the package called "tor-geoipdb" (tor-geoipdb_0.2.1.30-1~~lenny+1_all.deb). Bye. -- 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 and VOIP ( related to excito's b3)
Håken Hveem wrote (06 Apr 2011 12:00:57 GMT) : > To me, it looks like that the slower network rate of Tor will cause > problems for SIP and VOIP applications. Doable, see this thread in the list archive: http://archives.seul.org/or/talk/Dec-2010/msg00147.html Bye, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Then we'll come from the shadows. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Announce: Tails 0.7 is out
Hi, Tails, aka. The Amnesic Incognito Live System, version 0.7, is out. , | What is it? ` Tails is a Live system aimed at preserving your privacy and anonymity: - all outgoing connections to the Internet are forced to go through the Tor network; - no trace is left on local storage devices unless explicitly asked. More? -> https://tails.boum.org/ , | Get it, try it, share it! ` Try it! [1] Any comments are most welcome. Please note you'll need to install the CACert root certificate [2] into your web browser before connecting to our web site... unless you use Debian or one of its derivatives. [1] https://tails.boum.org/download/ [2] http://www.cacert.org/ , | What's new? ` Notable changes include: * Built on top of Debian Squeeze. * Tor 0.2.1.30 * Protecting against memory recovery: new, safer way to wipe memory on shutdown which is now also used when the boot media is physically removed. * Hardware support - printers: install more printer drivers, allow the default user to manage more kinds of printers - 3G: support mobile broadband devices such as 3G USB dongles - wireless: install Atheros and Broadcom firmwares - scanner and multi-function peripherals: better support * Iceweasel - install the HTTPS Everywhere extension - many Anonymity Set preservation enhancements, mostly inspired by the Tor Browser Bundle configuration - support FTP, thanks to FoxyProxy * Other software - user-friendly encryption support: install gnome-disk-utility (Palimpsest) and Seahorse plugins - add opt-in i2p support with Iceweasel integration through FoxyProxy - optionally install TrueCrypt at boot time to allow users of the (old and now unsupported) *Incognito* live system to access the data on previously created media; this is *not* meant to be used to create new TrueCrypt media - make better use of battery-powered hardware - replace xsane with simple-scan which is part of GNOME and way easier to use - install scribus-ng instead of scribus: more features, less bugs * Firewall - drop incoming packets by default - forbid queries to DNS resolvers on the LAN - set output policy to drop (defense-in-depth) * Miscellaneous - fromiso= bugfixes - configure keyboard layout accordingly to the chosen language for Italian and Portuguese - more robust HTP time synchronization wrt. network failures; display the logs when the clock synchronization fails - disable automatic media mounting and opening to protect against a class of attacks that was recently put under the spotlights - GnuPG: default to stronger digest algorithms Plus the usual bunch of minor bug reports and improvements. See the online Changelog [3] for technical details. [3] http://git.immerda.ch/?p=amnesia.git;a=blob_plain;f=debian/changelog;hb=refs/tags/0.7 , | Can I use it on a pre-Intel Mac computer? ` Tails images with *i386* in their name work on the Intel x86 architecture only. However, we've been working towards releasing a Tails image suitable for the pre-Intel Macs hardware (PowerPC architecture). Stay tuned, it will be prepared and made available soonish. , | A glimpse towards the future ` Were do we go from here? Have a look to our roadmap [4] to see where we are heading to. Would you want to help? As explained in our brand new "how to contribute" documentation [5], here are many ways **you** can contribute to Tails: no need to be a hardcore developer. [4] https://tails.boum.org/contribute/roadmap/ [5] https://tails.boum.org/contribute/ Bye, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Do not be trapped by the need to achieve anything. | This way, you achieve everything. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] To Toggle, or not to Toggle: The End of Torbutton
Hi, grarpamp wrote (12 Apr 2011 01:31:24 GMT) : > I'd rather see stuff sandboxed than tweaked or hacked... too much > maintenance. I'd bet torproject could distribute a unix (bsd or > linux) memory stick. One version to native boot, the other a > virtualbox of the same image. Stuff it full of comms apps, packet > filter it into tor. As a Tails [0] developer, I would be glad to read what our live system lacks to fulfill the usecase you are describing. [0] https://tails.boum.org/ Tails already mostly supports virtualization, although ease of use could be improved e.g. by shipping a Portable VirtualBox on the USB stick; see the dedicated page [1] in our TODO list. [1] https://tails.boum.org/todo/virtualization_support/ Bye, -- 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
Re: [tor-talk] To Toggle, or not to Toggle: The End of Torbutton
tween various FF versions and various extensions is also work I would not want to do... especially since it's already being done by the Debian maintainers for the extensions we ship. I'd hate having to replicate their work. Is it imaginable to see the new TBB make use of extensions that are installed system-wide? (probably opt-in as well) > We are collecting these issues as child tickets of this bug: > https://trac.torproject.org/projects/tor/ticket/2880 I'll summarize the discussion results there. In the meantime, I prefer using email if you don't mind. Bye, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | We're dreaming of something else. | Something more clandestine, something happier. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] built-in tor2web functionalities into TOR?
Hi Fabio, Fabio Pietrosanti (naif) wrote (18 Apr 2011 21:09:27 GMT) : > I am wondering whether for the Tor Project goals the functionality > of Tor2Web can be considered a milestone to be reached or if it's up > the to the community to grow a network of software running tor2web > systems. > I mean, it would be possible to envision the inclusion of tor2web > features into Tor, even if disabled by default? What do you exactly mean by "inclusion of tor2web features into Tor"? Including a forwarding web proxy into Tor proxies and/or bridges? If so, how do you intend to make every such proxy reachable by non-Tor-users? Bye, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Then we'll come from the shadows. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] sftp sites?
Hi, Udo van den Heuvel wrote (29 Apr 2011 15:42:09 GMT) : > Would torified untracable chrooted sftp things be of any use for > valid purposes? Sure. > Disk can be encrypted locally, tor network is encrypted, sftp encrypts > the rest. user can encrypt files as well. Last time I tried, combining Tor + sftp mounted by GNOME's "Connect to server" worked quite well. Inserting transparent encryption into the loop was a failure (very poor robustness, much too frequent disconnects), but I only tried gvfs-fuse + cryptkeeper (EncFS). I don't know if the root cause of the failure I faced was the slowness of Tor vs. lack of robustness of the tools, the depth of the stack, any used component or a combination thereof. In any case, I doubt Tor itself was the root cause of failure, so this is getting a bit off-topic IMHO. I'd be happy to hear (off-list?) of better results achieved by others. Bye, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Do not be trapped by the need to achieve anything. | This way, you achieve everything. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Vidalia 0.3.0-alpha is out
Hi, Tomas Touceda wrote (12 May 2011 03:13:15 GMT) : > Vidalia-0.3.0-alpha is out! Nice to hear. Any reason why it is tagged vidalia-0.3.0 in Git? Bye, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Then we'll come from the shadows. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] tor+virtualbox questions
Hi, Fernan Bolando wrote (25 May 2011 03:40:43 GMT) : > I have seen posts regarding running vmware's networking through Tor, > but have not seen anything specific to what I am doing. > I am running Tor inside a linx virtual machine based on virtualbox, > configured to use bridged network access. check.torproject.org > happily says i am running tor. So my questions are > 1. Does this mean as along as I run the browser from inside the > virtual machine I am safe? This setup gets you a bit more safety than not using VirtualBox at all because the host IP and hardware are not directly exposed to the guest. I am not sure about indirectly, so I am unsure of the practical gain, if it exists at all. > 3. We already have usb based torbrowser, I was hoping to use > virtualbox to build usbbased tor operating system package. Has this > been done before? This is so that they can just plug in the "TorVM > Usb" into a spare usb and run a virtual machine, with access to all > the unix tools running through tor. You may want to have a look to Tails features (and TODO list) with regards to virtualization: https://tails.boum.org/todo/virtualization_support/ The last section, about "Portable VirtualBox" et al., may be of particular interest to you. Help is welcome. In case you decide to build a fully Torified OS from scratch, please have a look to the Tails design document before you actually start: https://tails.boum.org/contribute/design/ ... it may convince you you actually don't want to undertake that mission, and you may eventually prefer to help us making Tails better :) Bye, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | So what? ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor TLS error
Hi, alex wrote (27 May 2011 15:35:55 GMT) : > Torifying it causes the TLS handshake to fail: > % torify openssl s_client -connect 83.223.73.105:465 > CONNECTED(0003) > 24520:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown > protocol:s23_clnt.c:607: > Any idea? Not really, but enabling starttls mode makes it work: $ /usr/bin/torify openssl s_client -starttls smtp -connect 83.223.73.105:465 [...] 250 STARTTLS Bye, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | We're dreaming of something else. | Something more clandestine, something happier. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] unbound, ttdnsd and DNSPort config
Hi, Anders Sundman wrote (06 Jun 2011 14:24:12 GMT) : > Used individually, the addr directives work fine and resolve using > their respective mechanism. Used together, it looks like ttdnsd > never gets a chance after tor has failed (e.g. when resolving a SRV > or MX record). > Any ideas? I've just had a look, by attempting to implement the same in Tails (i.e. query first the Tor resolver, and fallback to ttdnsd in case the former is not able to answer the query) as we planned to do for quite some time. I've seen the same results as you have, using the DNS frontend caching proxy Tails already ships (pdnsd) instead of unbound. A few dig commands learned me that the Tor resolver sends an empty reply (status: NOERROR, QUERY: 1, ANSWER: 0) rather than an error when it does not support the type of the query (e.g. MX). The obvious consequence of it is: the caching frontend DNS proxy (be it unbound, pdnsd or whatever) has thus no way to know it should fallback to ttdnsd in such a case, and it actually never does so, which confirms what you've observed in the first place. => In the current state of the Tor DNS resolver, we're forced to use ttdnsd by default, and only use the Tor resolver for .onion/.exit... unless I missed something. So I'm curious what the rationale for the "empty reply" behavior is. Any ideas? Bye, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Then we'll come from the shadows. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] unbound, ttdnsd and DNSPort config
Hi, Robert Ransom wrote (09 Jun 2011 08:02:00 GMT) : > This looks like a bug. Please open a Trac ticket for it. Done: https://trac.torproject.org/projects/tor/ticket/3369 Bye, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | So what? ___ 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, Gozu-san wrote (07 Aug 2011 19:53:36 GMT) : > As the router for a VirtualBox internal network, ra's Tor gateway VM > <http://ra.fnord.at/> does basically what you describe. Interesting. I was not able to find the source code / documentation to build one's own VM image, which is frustrating. Although not that strongly related, this discussion makes me think of an idea that's been sleeping for a while in Tails' wishlist: https://tails.boum.org/todo/Two-layered_virtualized_system/ Bye, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | If you must label the absolute, use it's proper name: Temporary. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Pirate Linux
Hi, AK wrote (05 Aug 2011 01:44:05 GMT) : > Soon we plan to create an ISO from this that will be based on > Ubuntu. It will have a Live Boot feature and Full Disk Encryption. > The Live Boot feature will allow someone to simply reboot their > system from the Pirate Linux disc and choose to boot a Live Privacy > Enhanced OS (such as Tails). Do you mean mutually exclusive Live Boot and Full Disk Encryption modes? More generally, I'd be happy to learn what makes your usecase / threat model / specification / implementation decisions different from Tails' ones [0], and to share as much work as we can. [0] https://tails.boum.org/contribute/design/ Bye, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | We're dreaming of something else. | Something more clandestine, something happier. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] presentation about tor and onion routing?
hi, startx wrote (24 Aug 2011 15:49:24 GMT) : > does anybody know a good presentation about using > tor and onion routing, targetting users ( not developers ) which can be > modified and used for talks? Last time I needed something like that my starting point was 2011-01-TU-Berlin-Techtalk.pdf (available as .odp too) in: https://svn.torproject.org/svn/projects/presentations/ (seems like this repo wasn't migrated to Git yet) bye, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Do not be trapped by the need to achieve anything. | This way, you achieve everything. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] attacks on Tor hidden services
Hi, Gozu-san wrote (23 Oct 2011 04:17:12 GMT) : > So, I open a few instances of TAILS 0.8.1 routed via VPN services to > various exit IP addresses. All of them can load my private test > sites, with typical delays of a minute or so. However, all of them > report "Proxy error: 504 ... General SOCKS server failure" for the > Freedom Hosting site, and they do so immediately, with no lag. These > are LiveCD instances, by the way, so there's no local Polipo cache. > Conversely, using an old Tor installation, freshly booted, the Freedom > Hosting site comes up, with typical delay of a minute or so. This might be a bug in Tails. If you're willing to help us investigate it on Tails side, let's move the discussion there: https://tails.boum.org/bug_reporting/ Bye, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | If you must label the absolute, use it's proper name: Temporary. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] tails on Microsoft Virtual PC
Hi, Matej Kovacic wrote (04 Dec 2011 16:55:00 GMT) : > I tried it in VirtualBox (under Linux), and it works really nice. Nice to hear. > However, I ahve one question - is it possible to copy/paste text > from host to virtual machine and back? This can be configured per-VM in VirtualBox. What's possible is: host-to-guest and/or guest-to-host. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Do not be trapped by the need to achieve anything. | This way, you achieve everything. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] tails on Microsoft Virtual PC
Hi, First, please take Tails -specific questions to the places where the Tails community lives; see at the bottom of https://tails.boum.org/support/ and https://tails.boum.org/contribute/ depending on the kind of input / question. Eugen Leitl wrote (04 Dec 2011 15:24:30 GMT) : > I've just tried tails in a Microsoft PC VM and it's quite nice. Great. That's something we want to support because some people, in some situations, simply don't have the choice and cannot run Tails on bare metal. But I'm not comfortable seeing this kind of stuff mentioned in places like tor-talk without any kind of warning, so let me add everyone interested in Tails + virtualization *must* read our warnings page: https://tails.boum.org/doc/advanced_topics/virtualization/ > Anyone knows how to switch the screen resolution, as the default > debian doesn't seem to know the virtual hardware? No idea. Please use the integrated "Report a bug" application, and hopefully we'll get enough details about that virtual hardware to answer, and possibly fix things on our side. > I know I could install it in theory, but the idea of booting afresh > from a live CD has a lot of tabula rasa appeal. I may have misunderstood you, but just in case it was not clear: Tails is a Live system. What we call "installation", in Tails world, is either burning a *Live* CD or preparing a *Live* USB stick. Both will behave the same "tabula rasa" way. On the contrary, when run in a VM, it totally depends on your *host* OS how much "tabula rasa" it will be in practice, and there's nothing Tails can do to protect you from that. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Every now and then I get a little bit restless | and I dream of something wild. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Running tails headless ... virtualbox ...
Hi, First, please take Tails -specific questions to the places where the Tails community lives -> https://tails.boum.org/ has pointers to there. If you tried finding that place(s) and failed, I'm curious where you looked, etc., so that we can fix it. John Case wrote (04 Dec 2011 07:28:46 GMT) : > So if I boot the tails ISO in virtualbox ... can I then ssh to the > tails system and use Tor from there ? Tails does not ship any SSH server. You can install the openssh-server package in it and open the port in the firewall if you wish. This being said, as soon as you tweak the system like so, you're reaching the "unsupported" area and you're more or less on your own. > Perhaps I need to dump the ISO filesystem, make some changes (like > enable sshd, etc.) and then re-make the ISO ? > Any pointers or comments ? I strongly advise against any solution of the "remaster" kind; this kind of fork is a pain to maintain on the long run. The way we manage Tails source and builds makes forking at the source level way much more desirable. This should get you started: https://tails.boum.org/contribute/build/ https://tails.boum.org/contribute/customize/ https://tails.boum.org/contribute/how/code/ Anyway: once we get enough persistence support [0], adding extra packages (that are re-installed at boot time) will be possible. Who knows, maybe you'll contribute back your changes in a way that is generic enough to be merged upstream and maintained by us? Hint, hint. [0] https://tails.boum.org/todo/persistence/ > Tails is really fantastic - the ability to go from zero-to-ToR in > a few mmoents inside of vmware or virtualbox, etc., is fantastic, > but not all systems have KVM... Thank you. FYI, in case it's what you mean by "KVM", you do not need hardware virtualization support to run Tails inside VirtualBox. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | If you must label the absolute, use it's proper name: Temporary. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] TBB, iptables, and seperation of concerns
Hi, Chris wrote (12 Dec 2011 08:35:01 GMT) : > 1. A user should not have to download a CD from a site every time an > update comes out. What kind of better solution are you thinking of? We've got an incremental upgrade system in the works: https://tails.boum.org/todo/usb_install_and_upgrade/#index5h2 Don't hesitate using the Tails communication channels to suggest improvements etc. > 2. Users should not need to know how to authenticate the download (each > update to TBB or Tails)- while nice users aren't competent enough to do in > practice and the difficult in doing it makes it unlikely even those who > know how may not do it. So we should avoid making the user do the > authentication at all. > That can be done if there is a distribution that is installed. > Authentication of updates is already built into apt. Lets use it. > Install once and forget. I may be missing your point, but Tails is not a random collection of packages that could be individually upgraded without any thought. Tails is a carefully crafted system that aims at guaranteeing certain properties. We do our best to ensure an ISO we ship meets a certain specification. There is simply no possible way for us to ensure the same for "that ISO plus any number of APT upgrades on top of it". Details: https://tails.boum.org/forum/Security_Updates:_apt-get_Sufficient__63__/#comment-ee6b87ae9397f6a9045f6c77fb52272d > 3. Does tails prevent non-Tor communications? I was reading something > which suggested it was an idea. If it is an idea chances are it isn't > implemented. It does. Details: https://tails.boum.org/about/ 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 | 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] TBB, iptables, and seperation of concerns
Hi, (This is the last email I'll send to this thread on tor-talk. Please follow-up where it belongs, that is on tails-dev.) Chris wrote (13 Dec 2011 04:21:53 GMT) : >> >>> 1. A user should not have to download a CD from a site every time an >>> update comes out. >> >> What kind of better solution are you thinking of? >> >> We've got an incremental upgrade system in the works: >>https://tails.boum.org/todo/usb_install_and_upgrade/#index5h2 >> >> Don't hesitate using the Tails communication channels to suggest >> improvements etc. > I think a solution with AUFS would make more sense. While there are > some benefits initially to doing it with squashfs the compression > gained is quickly overtaken by the amount of disk space this will > eat up. Using AUFS with a read-only mode would be the better way to > do it. There would be nothing left on the disk after a reboot > (except for any encryption partitions which were mounted read/write) > and users could still update the software through normal channels > (apt). Unless I misunderstood your words, Tails is already using AUFS the way you are suggesting. Users who feel they seriously know what they're doing, and want to take the risk, can already use APT to upgrade their currently running system in RAM. However, we don't generally recommend doing that for reasons I already highlighted and pointed you at. The incremental upgrades idea I pointed you at is something entirely different, though. It's about *persistently* upgrading a system when a Tails point-release is out, while minimizing the amount of data that must be downloaded. Please explain how AUFS could be used for solving that problem, and why it would be better (size-wise, or whatever) than the stacked SquashFS idea we've been thinking of. >> I may be missing your point, but Tails is not a random collection of >> packages that could be individually upgraded without any thought. >> Tails is a carefully crafted system that aims at guaranteeing certain >> properties. We do our best to ensure an ISO we ship meets a certain >> specification. There is simply no possible way for us to ensure the >> same for "that ISO plus any number of APT upgrades on top of it". > I may not fully understand the problem here as it is not well > explained. If I take an educated guess at where the problem lies > I think it is nothing that can't be overcome. The "tails context" is > a design issue and not something that can't be overcome. I believe > the issue is mainly that Tails runs from a CD and if installed is > using squashfs. Thus it can't be updated (except each time the > system is booted, and even then some updates require a reboot, at > which point those updates are lost). This is merely implementation details. We already have a plan to fix the "Tails is read-only" side of things (see the stacked SquashFS idea I pointed you at). The main problem is that Tails is a full Live system built upon a whole autonomous world (that is, Debian repositories) that is constantly changing; again: Tails is not a random collection of packages that could be individually upgraded without any thought. Tails is a carefully crafted system that aims at guaranteeing certain properties. We do our best to ensure an ISO we ship meets a certain specification. There is simply no possible way for us to ensure the same for "that ISO plus any number of APT upgrades on top of it". Please tell me what's unclear in this paragraph. The only possible way we could propose incremental upgrades through APT would be to manage our own APT repositories, so that we entirely control the flow of packages that could flow into a given Tails system. Personally, I don't think it would be worth the effort, and I still think it makes sense to go the "incremental upgrades using stacked SquashFS" way we've been pursuing. In any case, the APT way would make bug reporting, reproducing, debugging and fixing much more complicated: currently, one runs "Tails 0.9", not "Tails 0.9 plus this and that upgrades". Also, please be kind enough to quickly sum-up what is the exact problem you are suggesting us to solve, so that other Tails developers don't need to read the whole thread to (try to) understand what the problem could be, among discussions about implementation details. Cheers, -- 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
Re: [tor-talk] Did we decide about bad exits ? Where does bittorrent fall ?
Hi, Andrew Lewman wrote (15 Dec 2011 17:53:59 GMT) : > There are completely legitimate uses of bittorrent over Tor. > I've talked to people who want to get their ISO of Fedora or Ubuntu > from outside their country, so they bt over tor to do so. We've been refusing to include a BitTorrent client in Tails since the beginning due to some kind of common sense that was telling us it would harm the Tor network. Recently, we've been asked again -supposedly by a prominent member of the Tor community- to include Transmission; the request was sent with an offer to audit this piece of software for safeness in Tails usecase. This, added to reading this thread, makes me doubtful. What do you think? Shall we include a (carefully audited) BitTorrent client in Tails? Regards, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Then we'll come from the shadows. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [tor-announce] Tor 0.2.2.35 is released (security patches)
Hi, Roger Dingledine wrote (16 Dec 2011 18:19:10 GMT) : > Tor 0.2.2.35 fixes a critical heap-overflow security issue in Tor's > buffers code. Absolutely everybody should upgrade. > the attacker would need to either open a SOCKS connection to > Tor's SocksPort (usually restricted to localhost), or target a Tor > instance configured to make its connections through a SOCKS proxy My understanding of the flaw makes me think users of Tails 0.9 are not at risk: an attacker who is able to connect to the Tor's SocksPort in Tails is likely to be in a position to run arbitrary code already; and Tails does not configure Tor to use another SOCKS proxy. Please correct me if needed. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | We're dreaming of something else. | Something more clandestine, something happier. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] janusvm still safe?
Hi, Eugen Leitl wrote (22 Dec 2011 07:29:33 GMT) : > It warns the user, which is the right thing to do -- your host might > be compromised without you knowing. This is *not* only about the host being compromised or not. This is also about the host OS writing parts of the memory on the hard disk (e.g. "thanks" to swap) which violates the Tails "amnesic" property. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | So what? ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] browser with best privacy without using Tornetwork
Hi, slightly OT: among people interested in these matters, maybe one of a few would want to test and research evercookies? --> https://tails.boum.org/todo/Fight_evercookies/ Cheers, -- 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
Re: [tor-talk] Did we decide about bad exits ? Where does bittorrent fall ?
Hi, Jacob Appelbaum wrote (16 Dec 2011 08:48:05 GMT) : > I'm not clear that it will harm the network if Tails includes > a BitTorrent client. I think that the harm comes when someone runs > a few seeding boxes through Tor and doesn't bother to add any > capacity to the network at all. >> What do you think? Shall we include a (carefully audited) BitTorrent >> client in Tails? > I think that you should do so if only to ensure that Tails is > need/intention complete. I now tend to agree. Before we act on this I'd like to hear what other members of the Tor project members about it, though. There's no emergency anyway, since we would have to wait for the results of your BT client audits before we decide which one we ship. > Speaking of which - did you see my recent list of tails comments? > https://trac.torproject.org/projects/tor/ticket/4639 Sure we did. We're slowly discussing most of it and are preparing answers (== todo++, asking for clarification, or explanation of why we disagree) to every issue raised. However, we're currently prioritizing the final bits of Tails 0.10 over this. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | We're dreaming of something else. | Something more clandestine, something happier. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] difference ttdnsd and torrc DNSPort?
Hi, h...@safe-mail.net wrote (10 Jan 2012 04:24:00 GMT) : > 2. If ttdnsd is better then torrc DNSPort, why the hasn't the >DNSPort code been replaced by ttdnsd? One reason why we did not drop DNSPort in Tails, which using ttdnsd for requests types DNSPort is not able to answer: using *only* ttdnsd makes you rely on a very small number of upstream DNS servers; if you do so, whatever hostname they decide does not exist any more, does not exist anymore for you. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Do not be trapped by the need to achieve anything. | This way, you achieve everything. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] difference ttdnsd and torrc DNSPort?
intrigeri wrote (10 Jan 2012 06:50:37 GMT) : > One reason why we did not drop DNSPort in Tails, which using ttdnsd One should read "... , while using ttdnsd ...". Sorry for the confusing typo. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Then we'll come from the shadows. ___ 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
Re: [tor-talk] Tor Gateway and Tor Workstation by ra
Martin Hubbard wrote (21 Jan 2012 03:13:44 GMT) : > Users may break TAILS trying to watch YouTube. For the record, Tails 0.10 allows watching videos that YouTube and other video sites make available as HTML5. Cheers, -- 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
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] Odd connection probles in Tails 0.10
Hi, anonco...@hushmail.com wrote (23 Jan 2012 18:08:16 GMT) : > It seems all network connections, except trought the browser are now > failing, though tehy had previously worked. I don't think tor-talk is appropriate to report and discuss such Tails-specific problems. I'll be happy to reply when you ask through one of the many Tails communication channels. See you soon then :) Yes, the line is pretty blurry between what is specific to Tails and what is not. Sorry about that. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | If you must label the absolute, use it's proper name: Temporary. ___ 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 (09 Feb 2012 13:14:46 GMT) : > I've heard that a later version of torsocks does work correctly on > programs which use non-blocking sockets. torsocks 1.2-3 from Debian unstable should be installable as is on a Squeeze system. If someone confirms it fixes this problem, I'll upload a backport to the official Squeeze backports archive once it has migrated to testing, i.e. in one week from now. 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] 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] 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] 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. 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] 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] 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 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] [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 server?
Hi, Jerzy Łogiewa wrote (13 Aug 2012 22:04:17 GMT) : > is there anything close now? No, but it was partially thought through: https://tails.boum.org/todo/server_edition/ By the way, in the future, please direct discussion regarding Tails to the Tails communication channels. Cheers, -- intrigeri ___ 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 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
[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-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
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] 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] 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] 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] IsolateSOCKSUser vs IsolateSOCKSAuth bug in documentation or design?
adrelanos wrote (03 Nov 2012 13:37:04 GMT) : > Which one is correct? $ echo "SOCKSPort 1 IsolateSOCKSUser" > /tmp/intrigeri/torrc $ tor -f /tmp/intrigeri/torrc [...] [warn] Unrecognized SocksPort option '"IsolateSOCKSUser"' 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 is broken and unmaintained
Hi, Maxim Kammerer wrote (03 Nov 2012 12:16:23 GMT) : > inb4 incoming stream of Debian-centric patches: please be wary of > glibc differences: > https://bugs.gentoo.org/show_bug.cgi?id=395953 > Wrt. this specific bug, perhaps you will want to use Anthony Basile's > solution instead of the patch in Debian: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636943 Thanks, this remembered me I should test this patch. So, on current Debian Wheezy, Anthony Basile's patch (without our own one, that is apparently eglibc-specific) fixes *almost* all the false warning messages. So, given it apparently fixes the bug entirely on other platforms, applying it is probably the way to go. However, to entirely fix the bug for eglibc users too, our 0002-If-a-symbol-cannot-be-found-also-try-by-prefixing-it.patch (or something better) is needed as well, so I guess I'll go on carrying it in Debian if it is not merged upstream. No emergency in either case, Nick's careful plan looks totally sensible to me. 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 is broken and unmaintained
Hi, Jacob Appelbaum wrote (03 Nov 2012 11:17:05 GMT) : > Can you give me a list of things that matter most to you in order of > your priority? The bug list is mighty long... Sure, here's my top six. From highest priority to lowest. Most issues have patches attached. I'll refer to the Debian packaging repository a few times: git://git.debian.org/collab-maint/torsocks.git Patches live in debian/patches/ in there. Important bugs == symbols not found - This is about: https://code.google.com/p/torsocks/issues/detail?id=3 http://bugs.debian.org/636943 https://bugs.gentoo.org/show_bug.cgi?id=395953 As I wrote in this thread yesterday or so, Anthony Basile's patch fixes the bug for glibc users, and fixes most of the bug for eglibc users: https://bugs.gentoo.org/show_bug.cgi?id=395953#c7 However, for eglibc users, an additional patch is needed, as explained by Lunar on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636943#74 Robert Hogan reviewed it and replied "Seems fine to me. I'll apply it to trunk and let you know!" (did not happen): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636943#84 That patch may be found as 0002-If-a-symbol-cannot-be-found-also-try-by-prefixing-it.patch, in the Debian packaging repository. It would be good to see glibc users test it, on top of Anthony's one, and report any regression they see, though. segfault in libtorsocks.so -- An interesting one, reported as http://bugs.debian.org/684580. Enjoy! Trivial patches === (None of these is terribly important, but they are all trivial fixes I'd like to stop carrying as a Debian-specific delta.) Invocation without argument is broken - Patch submitted at https://code.google.com/p/torsocks/issues/detail?id=47 Typos in manpage Patch submitted at https://code.google.com/p/torsocks/issues/detail?id=48 display correct error message when the wrapped program cannot be found -- Patch available as 0001-Display-correct-error-message-when-the-wrapped-progr.patch in the Debian packaging repository. important usability issues == some way to whitelist local address:port E.g. to solve the "synchronize remote and local IMAP servers with offlineimap" usecase, and similar: https://code.google.com/p/torsocks/issues/detail?id=28 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] 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] 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
[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] 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
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] 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] Merging all languages (locales) into one Tor Browser package?
Hi, Sebastian G. 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] 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] 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] 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] 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
[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] 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
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] 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] 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] 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] 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] Interested in a Tor Browser update script for Debian, Ubuntu and derivatives?
adrelanos wrote (08 Dec 2012 13:02:54 GMT) : > What if we had a Debian package which contains a Tor > Browser updater? While working on the Tails incremental updates feature [1], I discovered (thanks to Robert Ransom) that, in some threat models one often considers when using Tor, upgrades are much harder to do safely than I initially thought. I strongly suggest reading the TUF project's documentation [2] to learn how much. [1] https://tails.boum.org/todo/incremental_upgrades/ [2] https://www.updateframework.com/ Cheers! ___ 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] 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, 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-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] 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] 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] [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] [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] secure and simple network time (hack)
Hi, adrelanos wrote (17 Apr 2013 19:33:23 GMT) : > Why not build the required features into Tor itself? (Let's assume this is no rhetorical question.) My best guess is that nobody had 1. enough interest in this topic; 2. the right set of skills; 3. enough free time. In my experience, this is a correct answer to most "why not?" questions about wishlist tickets in the free software world. Please don't refrain yourself from doing as much of the work as you can (write a proposal, discuss it, implement it) and from finding someone else to do the rest. I, for one, will be very grateful if this happens. [1] https://lists.torproject.org/pipermail/tor-talk/2011-January/008551.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] 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
