Re: [Tails-dev] Proposal for Anti-Keystroke Fingerprinting Tool
@flapflap Yeah it looks this is the direction many are leaning. I'll try and discuss this with kernel/Wayland/Xorg devs ad see what happens. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Proposal for Anti-Keystroke Fingerprinting Tool
== Attack Description == Keystroke fingerprinting works by measuring how long keys are pressed and the time between presses. Its very high accuracy poses a serious threat to anonymous users.[1] This tracking technology has been deployed by major advertisers (Google, Facebook), banks and massive online courses. Its also happening at a massive scale because just using a JS application (or SSH in interactive mode) in presence of a network adversary that records all traffic allows them to construct biometric models for virtually everyone (think Google suggestions) even if the website does not record these biometric stats itself.[2] They have this data from everyone's clearnet browsing and by comparing this to data exiting the Tor network they will unmask users. == Current Measures and Threat Model == While the Tor Browser team is aware of the problem and working on a solution, current measures [6] are not enough. [4][5] Security distros are designed to protect the user even if an end user application is compromised and provide desfense in depth. The goal is to protect users even in the event of an attacker taking over an application running ina VM/Container. This is valid for systems running in VMs or on bare metal. == Existing Work on Countermeasures == As a countermeasure security researcher Paul Moore created a prototype Chrome plugin known as KeyboardPrivacy. It works by caching keystrokes and introducing a random delay before passing them on to a webpage.[3] Unfortunately there is no source code available for the add-on and the planned Firefox version has not surfaced so far. There are hints that the author wants to create a closed hardware soltuion that implements this which does not help our cause. == Proposal for a System-wide Solution == A very much needed project would be to write a program that mimics the functionality of the this add-on but on the display server / OS level. Ideally the solution would be compatible with Wayland for the upcoming transition in the near future. [1] http://arstechnica.com/security/2015/07/how-the-way-you-type-can-shatter-anonymity-even-on-tor/ [2] http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=7358795 [3] https://archive.is/vCvWb [4] https://www.lightbluetouchpaper.org/2015/07/30/double-bill-password-hashing-competition-keyboardprivacy/#comment-1288166 [5] https://trac.torproject.org/projects/tor/ticket/16110 [6] https://trac.torproject.org/projects/tor/ticket/1517 *** This feature request has been mirrored on each project's bugtrackers respectively: https://github.com/subgraph/subgraph-os-issues/issues/103 https://labs.riseup.net/code/issues/11257 https://github.com/QubesOS/qubes-issues/issues/1850 ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [Whonix-devel] Persistent Tor start in Tails vs location aware Tor entry guards (LATEG)
On 2016-02-06 23:14, intrigeri wrote:
Hi,
[can you please decide what mailing-list this discussion should happen
on, and then we can stop cross-posting over 4 mailing-list?]
[snip]
I'm not sure I understand the problem you mean to raise, though.
Can you please elaborate what problem you see if users do exactly this
("click through whatever hoops required to make the WiFi connect
again", which I agree is very likely)?
Thanks!
Cheers,
The problems in LATEG/AdvGoalTracking go deep enough that TPO is
investigating how to solve them in Tor's codebase:
https://lists.torproject.org/pipermail/tor-dev/2016-February/010364.html
A wider effort to think about usability of the user facing part of this
(is any at all) is good too.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Secure way to set time using Hidden Service descriptors
Hi Intrigeri, a lot has happened in this space since I last posted. The Hidden Service descriptor proposal didn't make sense so we query Hidden services directly and extract timestamps from their HTTP headers. At the moment in Whonix, we use reputable Onion Sites exclusively for time syncing purposes. The reason we stayed away from clearnet + HTTPS is because its almost certain NSA and friends have burrowed their way into CAs trusted by browsers. These guys bribe their way into companies and deploy field gents to sabotage and steal keys. Its a given that they go after CAs. With clearnet SSL being useless, they can manipulate system time, or worse, exploit the system if there’s a bug in sdwdate/htpdate. You can see the list of sites we are now using over here: https://github.com/Whonix/sdwdate/blob/master/etc/sdwdate.d/30_sdwdate_default We integrated anondate (our version of tordate) in our timesync process but only as an extra plugin for time sanity checking. The plugin is not operational yet AFAIK. On 06/10/2015 04:48 PM, intrigeri wrote: Hi, [please don't Cc me, I read the list] It seems that this has slipped through the cracks... sorry! ban...@openmailbox.org wrote (12 Sep 2014 01:04:41 GMT) : The current secure timesyncing solution has some serious implications for security because they rely on an untrusted model using clearnet servers. Even though SSL is used, the broken CA model negates its protection and the adversary could easily MITM requests and send fake replies or potentially exploit the time synchronizer process running on the system. I assume you're talking of the htpdate part of our current time synchronization solution, since it's the only part where your note about the CA cartel makes sense as far as I understand it. Note that those connections go through a Tor SocksPort that thas the IsolateDestAddr and IsolateDestPort options enabled. So, to perform such an attack via MitM against htpdate's connections, an adversary will need to do that in several places at the same time; quoting the corresponding bits of our design doc: It also uses several different pools of time sources, and if there are too many that fail for any given pool, e.g. because of failed certificate checking or being unreachable, the pool is considered to be potentially compromised and htpdate aborts. I easily admit I didn't think very hard about it, but given this, I fail to see how an attacker can easily MITM those requests in a way that effectively affects a running Tails much. Am I missing something, or did you overlook this aspect? Use of Hidden Service descriptors to obtain more accurate time: [...] Thanks a lot for thinking through this potential other solution. How does it play with the next-generation (ahem) time sync'ing design we have in mind? It's described there: https://tails.boum.org/blueprint/robust_time_syncing/ Note that in this new design, htpdate is only used to detect replayed Tor consensus. Cheers, ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Secure way to set time using Hidden Service descriptors
The current secure timesyncing solution has some serious implications for security because they rely on an untrusted model using clearnet servers. Even though SSL is used, the broken CA model negates its protection and the adversary could easily MITM requests and send fake replies or potentially exploit the time synchronizer process running on the system. To overcome this, here is a suggestion for a reassessment of the tordate approach, to overcome the problems mentioned above and the shortcomings. Use of Hidden Service descriptors to obtain more accurate time: There are some problems with using Directory Authority consensus data, the only one IMO is the fuzzy window of three hours which makes it harder to set a realistic time. My proposal is to have a time synchronizer daemon query the DHT for specific Hidden Service descriptors from the HSDir Authorities without actually connecting to them and calculate a more finegrained time to set. Here is why i think its a good idea: * Descriptors contain a timestamp field which shows the time they are generated. Time reported is number of microseconds since 1970. * Descriptors are signed by the HS and cannot be spoofed by the HSDirAuth. * Descriptors are refreshed hourly. [1] * A malicious HS that want to fool our time check has to go out of its way and forge the timestamp in its descriptor. If they are doing this by just running with a wrong clock, they will make themselves inaccessible. * According to rend-spec, the damage is much limited (only and 18 hour window) before HSDir Authorities reject these forgeries. [2] * There does exist stable, available and friendly HS besides the TPO one that was taken down. The only addresses that will be used are those of trusted organizations that will not carry out the forging attacks described above. These will be Whistleblowing and Freedom friendly sites. Some suggestions: Wikileaks, RiseUp (each service they provide has a unique HS address assigned), TheNewyorker's SecureDrop service and probably more. * The way to go about this is to fetch descriptors without connecting. * The timestamps will be averaged to get a more accurate reading. A high time resolution is possible, we can pinpoint within that one hour range the probable time because each server was started at a different time than the other so it uploads its descriptor at asynchronously. With 1400 HSAuth Dirs on the network, I don't think there will be much of a load problem. Problems and solutions: Couldn't the consensus data be replayed? Not possible if forcing Tor to depend only on verified consensus data. Tor doesn't depend on CAs and SSL is safe from cryptanalysis meaning no MITM attack is possible when communication with DirAuths But what if a bridge feeds the client a stale consensus? We have come up with a technique to check against this very kind of attack. In short, it involves fetching consensus data through the Tor bridge connection and cross referencing it with what the bridge gave us. If its off, the user will be warned and the stale data will be replaced by the fresh set. Then after Tor connects the time is further adjusted using HS descriptors. Won't this give off a fingeprintable network pattern when Tor restarts after a failed connection because the fresh consensus hadn't been fetched? There is no reason to believe that these actions are different from any Tor that is used in common setups. If someone suspends their machine and Tor is running, there will be TCP connections are frozen in the middle. And by the time they continue after a resume, the other side will receive unexpected packets and reject them. (It thought the other side timed out, now suddenly a closed connection wants to continue as if nothing happened.) Freezing a TAILS session should result in the same situation as freezing TBB on any other supported host. [1] http://donncha.is/2013/05/trawling-tor-hidden-services/ [2] https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=rend-spec.txt ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Why OnionCat + Mumble - why not just Mumble?
On 2014-08-16 14:00, ban...@openmailbox.org wrote: On 2014-08-16 00:38, ban...@openmailbox.org wrote: On 2014-08-15 15:22, ban...@openmailbox.org wrote: On 2014-08-14 23:26, ban...@openmailbox.org wrote: Hi. I found out why onioncat wasn't working and configured it accordingly with help from Bernhard. It was a peculiarity that had to do with our specific two machine design. Now VOIP works. Linphone is what we'll be using. Thought I'd tell you so you guys can add that too. Details: https://www.whonix.org/forum/index.php/topic,407.msg3360.html#msg3360 Unfortunately the Linphone version in Debian stable does not have zrtp support. But wouldn't Hidden Services and onioncat be providing the authentication layer? Note that Linphone does have a text messaging mode but its completely plaintext. Again it shouldn't matter if what I'm saying about Hidden Services is correct. More interesting information on the functionality of VOIP clients. you might like to factor them into your blueprint https://www.whonix.org/forum/index.php/topic,407.msg3396.html#msg3396 You are right. Please make a backport and I will work on instructions for authentication. Here is what Bernhard says about authentication: https://www.whonix.org/w/index.php?title=OnionCatstable=0shownotice=1fromsection=Security#Security A backport is necessary to take advantage of it. A backport of linphone is nice too, but not strictly necessary as the first. Even if untested your linphone backport is very likely to work so please include it too. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Why OnionCat + Mumble - why not just Mumble?
On 2014-08-16 00:38, ban...@openmailbox.org wrote: On 2014-08-15 15:22, ban...@openmailbox.org wrote: On 2014-08-14 23:26, ban...@openmailbox.org wrote: Hi. I found out why onioncat wasn't working and configured it accordingly with help from Bernhard. It was a peculiarity that had to do with our specific two machine design. Now VOIP works. Linphone is what we'll be using. Thought I'd tell you so you guys can add that too. Details: https://www.whonix.org/forum/index.php/topic,407.msg3360.html#msg3360 Unfortunately the Linphone version in Debian stable does not have zrtp support. But wouldn't Hidden Services and onioncat be providing the authentication layer? Note that Linphone does have a text messaging mode but its completely plaintext. Again it shouldn't matter if what I'm saying about Hidden Services is correct. More interesting information on the functionality of VOIP clients. you might like to factor them into your blueprint https://www.whonix.org/forum/index.php/topic,407.msg3396.html#msg3396 You are right. Please make a backport and I will work on instructions for authentication. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Why OnionCat + Mumble - why not just Mumble?
On 2014-08-14 23:26, ban...@openmailbox.org wrote: Hi. I found out why onioncat wasn't working and configured it accordingly with help from Bernhard. It was a peculiarity that had to do with our specific two machine design. Now VOIP works. Linphone is what we'll be using. Thought I'd tell you so you guys can add that too. Details: https://www.whonix.org/forum/index.php/topic,407.msg3360.html#msg3360 Unfortunately the Linphone version in Debian stable does not have zrtp support. But wouldn't Hidden Services and onioncat be providing the authentication layer? Note that Linphone does have a text messaging mode but its completely plaintext. Again it shouldn't matter if what I'm saying about Hidden Services is correct. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Why OnionCat + Mumble - why not just Mumble?
On 2014-08-15 15:22, ban...@openmailbox.org wrote: On 2014-08-14 23:26, ban...@openmailbox.org wrote: Hi. I found out why onioncat wasn't working and configured it accordingly with help from Bernhard. It was a peculiarity that had to do with our specific two machine design. Now VOIP works. Linphone is what we'll be using. Thought I'd tell you so you guys can add that too. Details: https://www.whonix.org/forum/index.php/topic,407.msg3360.html#msg3360 Unfortunately the Linphone version in Debian stable does not have zrtp support. But wouldn't Hidden Services and onioncat be providing the authentication layer? Note that Linphone does have a text messaging mode but its completely plaintext. Again it shouldn't matter if what I'm saying about Hidden Services is correct. More interesting information on the functionality of VOIP clients. you might like to factor them into your blueprint https://www.whonix.org/forum/index.php/topic,407.msg3396.html#msg3396 ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Why OnionCat + Mumble - why not just Mumble?
Hi. I found out why onioncat wasn't working and configured it accordingly with help from Bernhard. It was a peculiarity that had to do with our specific two machine design. Now VOIP works. Linphone is what we'll be using. Thought I'd tell you so you guys can add that too. Details: https://www.whonix.org/forum/index.php/topic,407.msg3360.html#msg3360 ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Why OnionCat + Mumble - why not just Mumble?
I'm currently working on getting UDP based chat clients like Linphone working over Onioncat using Whonix. At the moment I simulated a two part chat each running their hidden service and instance of Onioncat but they are not seeing eachother when configured to use IPv6 to do direct IP chat. Since you will be using UDP settings anyway, then IMHO concentrating on serverless options are probably the better way forward as it lessens the burden on users. I tried Jitsi and its IPv6 support seems broken as it doesn't recognize such addresses for contacts. Its also more resource heavy than Linphone. 1. Can you please tell me if there is any additional configuration that you did to your firewall to make Onioncat work? 2. From looking at this: https://www.cypherpunk.at/onioncat_trac/wiki/Security I got the impression that anyone running Onioncat can connect to anyone else that has it too. I don't know if the version currently available in Debian stable has the authentication features in r555. What firewall precautions are needed to cope with this situation if necessary? ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Why OnionCat + Mumble - why not just Mumble?
On 2014-08-09 18:10, intrigeri wrote: Hi, ban...@openmailbox.org wrote (09 Aug 2014 16:41:54 GMT) : I'm currently working on getting UDP based chat clients like Linphone working over Onioncat using Whonix. Great news! I'm very glad to see someone working on this, which I've been wanting to do for years, but clearly failed to. Woohoo :) Since you will be using UDP settings anyway, then IMHO concentrating on serverless options are probably the better way forward as it lessens the burden on users. Full ACK. I'm personally wary of encouraging users to put trust into yet another server, hence my interest in OnionCat: I've been maintaining it in Debian for years, in the hope it can be useful for such uses; glad to see someone trying it out! 1. Can you please tell me if there is any additional configuration that you did to your firewall to make Onioncat work? We've made it work 2-3 years ago in Tails, but I'm afraid I don't remember any of the details. Are you actually seeing reject logs from the firewall, that indicate it's the culprit? 2. From looking at this: https://www.cypherpunk.at/onioncat_trac/wiki/Security I got the impression that anyone running Onioncat can connect to anyone else that has it too. I don't know if the version currently available in Debian stable has the authentication features in r555. As one can see in the source package, Wheezy's 0.2.2+svn553-3 doesn't apply any patch on top of the upstream source. If needed, I can rebuild and upload Jessie's 0.2.2+svn559-1 to wheezy-backports. What firewall precautions are needed to cope with this situation if necessary? No idea. I would instead look into handling the authorization and authentication in the VoIP client instead. Cheers, My status report so far: The conflict is not caused by the firewall form the logs I checked. However onioncat keeps complaining about not finding a peer to forward to. Any idea what this is about or what I need to do? From what I understand using Onioncat is as simple as running it with ocat MyHiddenServiceID and then connecting to the IPv6 address of the other endpoint with the software in question. In this case its the local Linphone client calling the user@[IPv6] address. Correct? N.B. As an aside, The Linphone version in Wheezy does not support ZRTP. Suppose I get this working, will that be a problem? ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
