August 2013 - cypherpunks - lists.cpunks.org

Re: [liberationtech] Anonymity Smackdown: NSA vs. Tor
by Eugen Leitl 07 Aug '13

07 Aug '13

----- Forwarded message from Roger Dingledine <arma(a)mit.edu> ----- Date: Wed, 7 Aug 2013 03:05:35 -0400 From: Roger Dingledine <arma(a)mit.edu> To: liberationtech <liberationtech(a)mailman.stanford.edu> Subject: Re: [liberationtech] Anonymity Smackdown: NSA vs. Tor User-Agent: Mutt/1.5.20 (2009-06-14) Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> On Tue, Aug 06, 2013 at 10:43:39PM -0500, Kyle Maxwell wrote: > The key, obviously, is the primary assertion that the NSA runs "lots" > of Tor nodes. I've seen this assertion before, and while it's > certainly a reasonable assumption, I don't know if anybody outside the > NSA actually has hard evidence for that. I remember having this discussion with Bruce Schneier long ago, when he was about to add the phrase "of *course* NSA runs Tor relays" to a blog post. Consider two scenarios. In scenario one, NSA doesn't run any Tor relays, but they have done deals with AT&T and other networks to be able to passively monitor those networks -- including the (honest, well-intentioned) Tor relays that run on those networks. They're able to monitor some fraction of the Tor network capacity -- whether that's 1% or 10% or 30% is a fine question, and depends on both Internet topology and also what deals they've done. In scenario two, they do that plus also run some relays. They have to deal with all the red tape of deploying and operating real-world things on the Internet, and the risk that they'll do it wrong, somebody will notice, etc. And the benefit is maybe a few percent increase in what they can watch. Why would they choose scenario two? Scenario one seems like it would be working out pretty well for them. And if it's not, their resources would be better spent fixing that, since it leads to better surveillance of everything else they care about too. See https://lists.torproject.org/pipermail/tor-talk/2013-July/028851.html for a related discussion. Oh, and this argument should also lead you to ask "ok, but what about <smaller country that hasn't yet been reported to have a huge Internet surveillance program>? Shouldn't they run relays?" Maybe they should. Maybe we should hope they all do, which could make the network more diverse assuming they don't share well with each other. > Assuming that assertion holds, the architectural criticisms start to > matter more: 3 hops, 1024 bit RSA keys, etc. Somebody should tell Robert about the recent (Tor 0.2.4.x) shift to much stronger circuit handshakes and link encryption: https://gitweb.torproject.org/tor.git/blob/refs/tags/tor-0.2.4.15-rc:/Chang… https://gitweb.torproject.org/tor.git/blob/refs/tags/tor-0.2.4.15-rc:/Chang… And for the "Multiple apps share the same underlying Tor egress" concern, he should learn about the stream isolation features added in Tor 0.2.3.x: https://gitweb.torproject.org/tor.git/blob/refs/tags/tor-0.2.4.15-rc:/Chang… All of this said, I don't want anybody to conclude that Tor is perfect. Many of the attacks from my 25c3 "security and anonymity vulnerabilities in Tor" talk remain hard research questions: https://media.torproject.org/video/ --Roger -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Former NSA Boss Calls Snowden's Supporters Internet Shut-ins; Equates Transparency Activists With Al-Qaeda
by Tony Arcieri 07 Aug '13

07 Aug '13

Suddenly the al-qaeda.net domain is seeming more appropriate. Apparently we're terrorists because we like Snowden! https://www.techdirt.com/articles/20130806/12154724080/former-nsa-director-… -- Tony Arcieri

1 0

[tor-dev] Damian's Status Report - July 2013
by Eugen Leitl 06 Aug '13

06 Aug '13

----- Forwarded message from Damian Johnson <atagar(a)torproject.org> ----- Date: Sat, 3 Aug 2013 16:16:31 -0700 From: Damian Johnson <atagar(a)torproject.org> To: tor-dev(a)lists.torproject.org, tor-reports(a)lists.torproject.org Subject: [tor-dev] Damian's Status Report - July 2013 Reply-To: tor-dev(a)lists.torproject.org Hi all. This month was mostly spent on non-tor work including a server migration, bad service outage at work, and a full week of cleaning my apartment. Still, plenty of spiffy news in stem land... ====================================================================== Remote Descriptor Fetching ====================================================================== Major feature for this month was the addition of a module to remotely fetch tor descriptors... https://stem.torproject.org/api/descriptor/remote.html https://lists.torproject.org/pipermail/tor-dev/2013-July/005156.html This works much like tor itself does, downloading descriptor content from directory authorities and mirrors. With it we can now easily script against the present state of the tor network without piggybacking on a live tor instance. Curious what you can use it for? See our present monitors for some ideas... https://lists.torproject.org/pipermail/tor-dev/2013-July/005209.html https://gitweb.torproject.org/atagar/tor-utils.git/tree This also included a little work with Nick on the spec and tor side... * Dropped the unimplemented microdescriptor query from the spec. (#9271) * Noting the max queryable fingerprints/hashes in spec. (#9282) * We're getting a high failure rate on the downloads we make. A little more investigation is needed on my part to help narrow this down. (#9379) ====================================================================== Other news includes... * Revised the appearance of stem's frontpage. The blue buttons were pretty jarring, so switched to something that matches the rest of the page... http://www.atagar.com/transfer/stem_frontpage/before.png http://www.atagar.com/transfer/stem_frontpage/after.png * Added Slackware to our download page. Many thanks to Markus for adding us to SlackBuilds! http://slackbuilds.org/repository/14.0/python/stem/ * Worked with Sreenatha to port Tor Weather to stem. Unfortunately Weather does not presently have an active maintainer so I'm not sure how we will proceed on this front. (#8264) https://lists.torproject.org/pipermail/tor-dev/2013-July/005111.html * The Munich dev meeting has attracted quite a few potential volunteers. After discussing prospective projects with seros I tidied up our volunteer page. Changes included... * Added Christian's Globe project https://lists.torproject.org/pipermail/tor-commits/2013-August/060124.html * Dropped Thandy https://lists.torproject.org/pipermail/tor-commits/2013-July/059830.html * Merged TorStatus into the entry for Atlas https://lists.torproject.org/pipermail/tor-commits/2013-July/060003.html * General page corrections https://lists.torproject.org/pipermail/tor-commits/2013-August/060125.html * Our automated Jenkins test runs ran into another regression in tor that caused it to segfault. (#9298) * STREAM events mishandled IPv6 addresses. (caught and patched by soult, #9181) * Thread with Pierre about TorPylle which turned into a discussion with Nick regarding future language direction for the tor codebase. I'm looking forward to seeing where it goes! https://lists.torproject.org/pipermail/tor-dev/2013-July/005161.html * We just finished with midterms for Google Summer of Code. Chang unfortunately did not pass, but the other projects are going well. * Sorted out travel arrangements for the GSoC mentor summit. Nick and I will be going, and Moritz is presently on the waitlist. * Code reviewed ra's rttprober. He provided some great feedback for which I still owe him a reply. https://lists.torproject.org/pipermail/tor-dev/2013-July/005183.html Cheers! -Damian _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: Cypherpunks
by John Young 06 Aug '13

06 Aug '13

Opposition, disgust, revulsion, ridicule toward al-qaeda is perfectly cypherpunkian. Never, ever unanimous nor what's acceptable without merciless, obnoxious, off-topic digression argument. "Fuck that to death." - A Sage "Cypherpunks" -- the name, the adventure, the rise and fall, and multiple rebirths and splits and plagiarisms -- has been subjected to as much irrational ridicule and exploitation as hyper-plagiarized "al-qaeda." "Cryptography" list is a bastard of a bastard of a bastard of cypherpunks, each iteration trying to act snooty about villanous cryptography and failing repeatedly to hide its cypherpunkian malice. There are thousands of vile and sappy posts in the cpunk archives as with the "fucked to death and still going" internet. Crud begets crud. Delete the crud and there's nothing left of the shit-hole except the gargantuan cesspools on Wayback and Wikipedia and Tor "hidden services" and blacknet and undernet and intel.net and virulent cheating, lying and fucking users and each other. Extra good shit:, big data crud is growing exponentially, a golden bowl of explosive fertilizer likely leading to global cyberwar over who runs the cess. Never ask for permission, never give it. Cross-sub everybody and spy them secretly.

5 5

[tor-talk] Tortilla
by Eugen Leitl 06 Aug '13

06 Aug '13

----- Forwarded message from Jason Geffner <jason(a)crowdstrike.com> ----- Date: Tue, 6 Aug 2013 14:12:33 -0500 From: Jason Geffner <jason(a)crowdstrike.com> To: tor-talk(a)lists.torproject.org Cc: cameron(a)crowdstrike.com Subject: [tor-talk] Tortilla Organization: CrowdStrike, Inc. X-Mailer: Microsoft Outlook 15.0 Reply-To: tor-talk(a)lists.torproject.org I'd like to announce the availability of Tortilla, a free open-source tool that allows users to securely, anonymously, and transparently route all TCP/IP and DNS traffic through Tor. Though the Tor client natively supports transparent proxying on Linux-based systems, Tortilla allows Tor users to use Windows for transparent proxying. Unlike other similar solutions, Tortilla does not rely on API hooks (and as such does not allow malware to circumvent the Tor tunnel) and does not require extra hardware, a VPN, or an extra Tor gateway virtual machine. The whitepaper for Tortilla which describes the design goals, architecture, and usage instructions is available at https://media.blackhat.com/us-13/US-13-Geffner-Tor...-All-The-Things-WP.pdf The source code is available at https://github.com/CrowdStrike/Tortilla A pre-built distribution (compatible with 32-bit and 64-bit versions of Windows XP through Windows 8) is available at http://www.crowdstrike.com/community-tools Tortilla is still in beta, but I'd be pleased to answer any questions you may have about it. Please note that Tortilla is produced independently from the Tor(r) anonymity software and carries no guarantee from The Tor Project about quality, suitability or anything else. Sincerely, Jason Geffner Sr. Security Researcher, CrowdStrike -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [tor-relays] VPS Hardware Specification & Advice
by Eugen Leitl 06 Aug '13

06 Aug '13

----- Forwarded message from Tor Pids <torpids(a)yahoo.com> ----- Date: Tue, 06 Aug 2013 20:40:11 +0200 From: Tor Pids <torpids(a)yahoo.com> To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] VPS Hardware Specification & Advice Reply-To: tor-relays(a)lists.torproject.org Hi, i just saw this post on the web archive and felt I can contribute something here so I finally registered. Maybe this reply will not be correctly recognized to the thread, sorry. The VPS specs you posted should be more than enough - but the price is too expensive! I currently run about 20 Tor relays on cheap VPS all around the world: http://globe.rndm.de/#/search/query=torpids Basically I just care for the bandwidth/included traffic when choosing a VPS. 256MB RAM is enough, disk space doesn't matter at all. Tor doesn't scale that well with CPU cores so 1 core is ok. For only 1 or 2 of my VPS the CPU is the bottleneck (at about 20-30MBit/s), but most are fast enough. Most cheap VPS are based on the OpenVZ virtualization which limits you to their old kernel and sometimes they limit the number of tcp connections (see "cat /proc/user_beancounters"). KVM or Xen virtualisation is better because you have more control on the VM. Most VPS providers add up the incoming and outgoing bandwidth, meaning that you might be able to just send about 500GB with your 1TB plan. For example with a VPS from www.jiffybox.de for 15€ per month it is possible to push more than 1TB PER DAY(!) (and not per month as with the 18€ plan you mentioned). OVH just released a server for £2,99 per month with unlimited 100MBit/s as well: https://www.ovh.co.uk/dedicated_servers/kimsufi.xml Other typical offers are like 10TB for 10$ or 20MBit/s unlimited for 3€. Good places to find cheap VPS deals: http://www.lowendbox.com/ and http://lowendtalk.com/categories/offers http://www.wjunction.com/46-vps http://www.webhostingtalk.com/forumdisplay.php?f=104 Best, Torpids _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Twitter details on 2FA
by Kyle Maxwell 06 Aug '13

06 Aug '13

I kinda dig the level of detail in Twitter's blog post today on their new 2FA system. Not really qualified to analyze said details, but certainly they're not going for the obscurity approach. https://blog.twitter.com/2013/login-verification-on-twitter-for-iphone-and-… -- @kylemaxwell

1 0

Re: [liberationtech] CJDNS hype
by Eugen Leitl 06 Aug '13

06 Aug '13

----- Forwarded message from Caleb James DeLisle <calebdelisle(a)lavabit.com> ----- Date: Mon, 05 Aug 2013 14:55:22 -0400 From: Caleb James DeLisle <calebdelisle(a)lavabit.com> To: Michael Rogers <michael(a)briarproject.org> Cc: liberationtech <liberationtech(a)lists.stanford.edu> Subject: Re: [liberationtech] CJDNS hype User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, On 08/05/2013 01:26 PM, Michael Rogers wrote: > Hi Caleb, > > On 03/08/13 01:33, Caleb James DeLisle wrote: >> We could spend a long time discussing locally effective attacks on social networks and not be any closer to agreement. > >> Instead I think it's worth asking who your attacker is... I find that when people don't stop to ask who the attacker is, what he wants and what resources he can apply on the attack, they end up with a default assumption that the attacker is everywhere and has infinite resources..... > >> If you can give me a clear picture of the person who would use this attack, what they want from the attack and what resources they can bring to bear on the problem, I might be able to speak more to the issue. > > Excellent point! The adversary I have in mind looks something like this: > > * Can create adversarial nodes * Can persuade a limited proportion of users to make direct connections to adversarial nodes Infecting existing nodes is cheaper than knocking on doors asking people to connect to your evil nodes because your reputation doesn't suffer when the trick is discovered. > * Can co-ordinate the behaviour of all adversarial nodes * Can create low-latency, high-bandwidth connections between adversarial nodes It doesn't cover whether adversarial nodes are geographically dispersed or not. If they are then the the attack is significantly more expensive. > * Can't monitor or tamper with direct connections between non-adversarial nodes * Can't break standard crypto primitives * Aims to degrade the performance of cjdns for some or all users This is good from a capabilities standpoint but it doesn't cover motive which is hugely important to threat modeling. If someone has significant resources and their motive is "to cause mayhem", securing infrastructure against them is not really possible which is why traditional antiterrorism efforts seem incoherent. Causing localized network disruption is trivial in any ethernet, you simply answer ARP or DHCP packets. This is done by some malware but the motive is to carry out a MiTM attack and trick the victim into installing the malware binary which is disguised as an update. With cjdns you would not have the ability to MiTM so the same style attack would just cause a localized network outage. Another motive for localized DoS is to force users to an unencrypted channel. If every time the police use encrypted radio you jam it, they may be tricked into using unencrypted channels. The main defense against this is not to have an insecure backup. Also note that localized network outages can be caused by wire cutters and/or wifi jammers so a protocol attack may never be the most effective approach. > >>> What heuristics do you have in mind? > > >> Given a set of known evil nodes, find the longest common route prefix(es) which contain all of the evil nodes. The last node along each common prefix is probably an edge. > > How would you find a set of known evil nodes? cat-and-mouse games which is why I don't like this approach. You could send forwarded packets to nodes to whom you know a direct path and then send them a direct packet asking if they got the forwarded packet. You have to try it a few times to be sure the endpoint is not fooling you and there are still more ways to detect and work around it. It's not something I'm interested in ever implementing so it's not really worth further discussion. > >>> People have put years of research effort into designing automatic Sybil defenses. The solutions they've come up with (SybilGuard, SybilLimit, Gatekeeper, SybilInfer) are complex and heavyweight, and they depend on assumptions about the structure of the social network - in other words they're not off-the-shelf solutions that you could just drop into cjdns later if the need arises. > > >> They operate under different constraints. > > Could you elaborate on the differences? The systems I mentioned are designed for use in P2P networks where the edges are based on real-world social relationships and there's no central authority. Isn't that similar to the cjdns setting? I suppose it is because the same information can be derived, albeit with some complexity. In cjdns the path through the social network which is represented by any given node is expressed in the label so you get it for free. > >> Everybody knows paths to those who are the numerically closest to themselves no matter the physical distance. Since addresses are spread randomly throughout the network, it means that anyone given node is directly reachable from a few nodes in each physical locality of the network. > > Let's consider what happens as the network grows. On average, each node is pointed to by t routing table entries, where t is the size of a node's routing table. As the network grows, the t entries pointing to a given node will be spread more thinly across the network, unless we increase t in direct proportion to the number of nodes. Increasing t like that won't scale indefinitely, but for the sake of argument let's assume it will scale well enough for whatever size cjdns grows to. > > So wherever we start from, there's some nearby node that knows a switching path to the destination. However, the length of that switching path will increase (on average) as the network grows. Even if we had a magic oracle that told us the shortest path to any destination, that path would still be longer on average in a large network than a small network. > > Therefore if some proportion of the nodes are adversarial, the probability of hitting an adversarial node on the way from a randomly chosen source to a randomly chosen destination will increase as the network grows. It's all true but it's worth noting that in order to maintain the same proportion of evil nodes in a growing network, the evil net must grow as well which brings us back to motive. If somebody is willing and able to invest a significant amount of money into setting up evil nodes then he must want something. It seems more realistic that the evil nodes would be compromised good nodes, an attack which which scales better. > >>> If the attacker creates a Sybil region of social space that's larger than the non-Sybil region, and you try to ensure that your routing table contains a diverse sampling of the whole social space, then your routing table will tend to contain more Sybils than non-Sybils. > > >> The number of nodes and the way they're organized doesn't help. They're all behind a common label prefix (the path to the sybil edge) and that label prefix would cause them to be seen as a cluster. > > Unfortunately it's not that simple. You're assuming that from the point of view of a given node, all the Sybils are behind a single edge (an attack edge, in SybilGuard terminology). But a given Sybil may be reachable via multiple attack edges. That's why SybilGuard and its descendents are so complex: before sampling the network to look for clusters, they have to ensure that there's only a single way for samples to reach each node. With cjdns there are multiple ways to reach a node but only one best way so that's mostly a solved problem. A non-adversarial way to look at this proposal is it attempts to avoid over-reliance on a single network link. Each edge would just appear as a link with a disproportionate number of nodes relying on it. You should check out the network, I think you'd find some interesting discussions in the dark irc network (irc.hypeirc.net) #hyperboria and #cjdns you might also find some people interested in helping with briar ;) Thanks, Caleb > > Cheers, Michael > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJR//UaAAoJECYAmptlsgnWHtMP/07m2NN2A+vk9isBn9eOzkyN GcjgJFL0VbcRQXU/sSQnzowcfoGT2bDy2IkscrjrIZYULbzJMGTurkfQK8+t/ZDH MVCouz6T/p8XVhPjQ8s/sq/JEIS3roV4sE/Qrt+P7vZp7Dv6vL69gAmf+OSTmgLY K8R1NY9BQD1wv16pwSUfyaccsoftxE3GytKCxMkW4jqa8ENUIDWEJ5qrsbesSTdy Tl0zaypC2Z1teud8G1plxV7sQvTQjjeV7+RXG39icTdkteyZQr8wcqo/69FUI6yb MXc2fBYLjnQjr6yJFSZPvhCnD8AR5TLwZC6Oi2x3TbYsBNXqjGxr73y/gRsX/SEv mHXWCzIa3MIWStVQZTDuM4edLi6ab2ZViMueospfs/sfptMiJkDpPjom8HvHgNZh 9tjScCPZKiOqYU44DYNkCeNKKbuABukkEGh5S0KafSg0YiV4qrogLsfata2+AXjy joa3YydwcCkjZ2wa5A3LIZV8qwLFVdQ9Y+6dIMOe1xqBF7Cd/5KOtFMpglXU0pdF tIFxnILYc3B5w71wADDGnC69+iOde3Wv8NVgqmSplu94nq1UKQO4MzQB2hiiMgE9 XG+xBNpqJH0MpTgoH0zSwcdaw5z2E94MQ+stSDi2Ll19pmoTQHIDKcSdnT6Q/UPP XUOK2ZWn3eP24w9F4Ao9 =Pohw -----END PGP SIGNATURE----- -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[guardian-dev] BREACH: SSL is pwnd
by Eugen Leitl 06 Aug '13

06 Aug '13

----- Forwarded message from Josh Steiner <josh(a)vitriolix.com> ----- Date: Tue, 6 Aug 2013 11:06:10 -0700 From: Josh Steiner <josh(a)vitriolix.com> To: Guardian Dev <guardian-dev(a)lists.mayfirst.org> Subject: [guardian-dev] BREACH: SSL is pwnd in summary, you need to turn off gzip to mitigate this for now: http://breachattack.com/ https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/ At last week's Black Hat conference, researchers announced the BREACH attack<http://breachattack.com/>, a new attack on web apps that can recover data even when secured with SSL connections. The BREACH paper<http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seco…> (PDF) contains full details (and is a good and fairly easy read). Given what we know so far, we believe that *BREACH may be used to compromise Django's CSRF protection*. Thus, we're issuing this advisory so that our users can defend themselves. BREACH takes advantage of vulnerabilities when serving compressed data over SSL/TLS. Thus, to protect yourself from BREACH, you should disable compression of web responses. Depending on how your application is deployed, this could take a couple forms: 1. Disabling Django's GZip middleware<https://docs.djangoproject.com/en/dev/ref/middleware/#module-django.middlew…> . 2. Disabling GZip compression in your web server's config. For example, if you're using Apache you'd want to disable mod_deflate<http://httpd.apache.org/docs/2.2/mod/mod_deflate.html>; in nginx you'd disable the gzip module<http://wiki.nginx.org/HttpGzipModule> . Additionally, you should make sure you disable TLS compression by adjusting your server's SSL ciphers<http://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/> . We plan to take steps to address BREACH in Django itself, but in the meantime we recommend that all users of Django understand this vulnerability and take action if appropriate. Posted by *Jacob Kaplan-Moss* on August 6, 2013 _______________________________________________ Guardian-dev mailing list Post: Guardian-dev(a)lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/eugen%40leitl.org You are subscribed as: eugen(a)leitl.org ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[zfs-discuss] Harddisk hacking - gain root in some bisare way
by Eugen Leitl 06 Aug '13

06 Aug '13

Potentially useful attack vector. ----- Forwarded message from Turbo Fredriksson <turbo(a)bayour.com> ----- Date: Mon, 5 Aug 2013 18:09:00 +0200 From: Turbo Fredriksson <turbo(a)bayour.com> To: zfs-discuss zfs-discuss <zfs-discuss(a)zfsonlinux.org> Subject: [zfs-discuss] Harddisk hacking - gain root in some bisare way X-Mailer: Apple Mail (2.1283) Reply-To: zfs-discuss(a)zfsonlinux.org Just came across this, thought I'd share... http://spritesmods.com/?art=hddhack -- Turbo Fredriksson turbo(a)bayour.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

2 1