- cypherpunks@lists.ogf.org

Market for secure systems, ICLOAK puts Nix/Tor/TBB/etc on USB raises $95k
by grarpamp 24 Jul '14

24 Jul '14

On Wed, Jul 23, 2014 at 6:09 PM, rysiek <rysiek(a)hackerspace.pl> wrote: > Dnia środa, 23 lipca 2014 17:24:22 grarpamp pisze: >> Snowden triggers flood of Crapware [was: Gruveo, more secure skype?] I'll fork this one off to the Tor folks... > Here, have a chuckle: > https://www.kickstarter.com/projects/icloak/icloak-tm-stik-easy-powerful-on… > > Hat-tip to all the TAILS/Tor people here. https://icloak.org/ At least it appears from the splashpage to be an open bundling of mostly open tools that are thought reasonably well of, ie: Nix, Tor, GnuPG. As opposed to being some new unheard of closed commercialware. Things like this could serve by dropping more 'crypto by default' on the net at the end user level (even if such users are their own newbie cannon fodder on a learning curve). And spreading Unix also helps shift marketshare and knowledge away from Windows long term. If my two minute read of this one is right, it would be hard to not give them some kudos. I don't know what amounts are typically fundraised and the donor counts, but $95k for something like this seems to indicate a demand for more secure/private systems in general. Maybe a million will sell and send some donations back.

2 1

Streisand: Silence censorship. Automate the effect.
by rysiek 24 Jul '14

24 Jul '14

So, this has been floating in my vincinity lately: https://github.com/jlund/streisand Wonder what you wonderful people think of it. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The Internet can be a little unfair. It's way too easy for ISPs, telecoms, politicians, and corporations to block access to the sites and information that you care about. But breaking through these restrictions is tough. Or is it? Introducing Streisand A single command sets up a brand new server running a wide variety of anti-censorship software that can completely mask and encrypt all of your Internet traffic. Streisand natively supports the creation of new servers at Amazon EC2, DigitalOcean, Linode, and Rackspace—with more providers coming soon! It also runs on any Debian 7 server regardless of provider, and hundreds of instances can be configured simultaneously using this method. The process is completely automated and only takes about ten minutes, which is pretty awesome when you consider that it would require the average system administrator several days of frustration to set up even a small subset of what Streisand offers in its out-of-the-box configuration. Once your Streisand server is running, you can give the custom connection instructions to friends, family members, and fellow activists. The connection instructions contain an embedded copy of the server's unique SSL certificate, so you only have to send them a single file. Each server is entirely self-contained and comes with absolutely everything that users need to get started, including cryptographically verified mirrors of all common clients. This renders any attempted censorship of default download locations completely ineffective. But wait, there's more... More Features Nginx powers a password-protected and encrypted Gateway that serves as the starting point for new users. The Gateway is accessible over SSL, or as a Tor hidden service. Beautiful, custom, step-by-step client configuration instructions are generated for each new server that Streisand creates. Users can quickly access these instructions through any web browser. The instructions are responsive and look fantastic on mobile phones: Streisand Screenshot The integrity of mirrored software is ensured using SHA-256 checksums, or by verifying GPG signatures if the project provides them. This protects users from downloading corrupted files. All ancillary files, such as OpenVPN configuration profiles, are also available via the Gateway. Current Tor users can take advantage of the additional services Streisand sets up in order to transfer large files or to handle other traffic (e.g. BitTorrent) that isn't appropriate for the Tor network. A unique password, SSL certificate, and SSL private key are generated for each Streisand Gateway. The Gateway instructions and certificate are transferred via SSH at the conclusion of Streisand's execution. Distinct services and multiple daemons provide an enormous amount of flexibility. If one connection method gets blocked there are numerous options available, most of which are resistant to Deep Packet Inspection. All of the connection methods (including L2TP/IPsec and direct OpenVPN connections) are effective against the type of blocking Turkey has been experimenting with. OpenSSH, OpenVPN (wrapped in stunnel), Shadowsocks, and Tor (with obfsproxy and the obfs3 or ScrambleSuit pluggable transports) are all currently effective against China's Great Firewall. Every task has been thoroughly documented and given a detailed description. Streisand is simultaneously the most complete HOWTO in existence for the setup of all of the software it installs, and also the antidote for ever having to do any of this by hand again. All software runs on ports that have been deliberately chosen to make simplistic port blocking unrealistic without causing massive collateral damage. OpenVPN, for example, does not run on its default port of 1194, but instead uses port 636, the standard port for LDAP/SSL connections that are beloved by companies worldwide. L2TP/IPsec is a notable exception to this rule because the ports cannot be changed without breaking client compatibility The IP addresses of connecting clients are never logged. There's nothing to find if a server gets seized or shut down. Services Provided L2TP/IPsec using strongSwan and xl2tpd A randomly chosen pre-shared key and password are generated. Windows, OS X, Android, and iOS users can all connect using the native VPN support that is built into each operating system without installing any additional software. Streisand does not install L2TP/IPsec on Amazon EC2 servers by default because the instances cannot bind directly to their public IP addresses which makes IPsec routing nearly impossible. OpenSSH An unprivileged forwarding user and SSH keypair are generated for sshuttle and SOCKS capabilities. Windows and Android SSH tunnels are also supported, and a copy of the keypair is exported in the .ppk format that PuTTY requires. Tinyproxy is installed and bound to localhost. It can be accessed over an SSH tunnel by programs that do not natively support SOCKS and that require an HTTP proxy, such as Twitter for Android. OpenVPN Self-contained "unified" .ovpn profiles are generated for easy client configuration using only a single file. Multiple clients can easily share the same certificates and keys, but five separate sets are generated by default. Client DNS resolution is handled via Dnsmasq to prevent DNS leaks. TLS Authentication is enabled which helps protect against active probing attacks. Traffic that does not have the proper HMAC is simply dropped. The Dante proxy server is set up as a workaround for a bug in Firefox for Android. Shadowsocks A QR code is generated that can be used to automatically configure the Android and iOS clients by simply taking a picture. You can tag '8.8.8.8' on that concrete wall, or you can glue the Shadowsocks instructions and some QR codes to it instead! Stunnel Listens for and wraps OpenVPN connections. This makes them look like standard SSL traffic and allows OpenVPN clients to successfully establish tunnels even in the presence of Deep Packet Inspection. Unified profiles for stunnel-wrapped OpenVPN connections are generated alongside the direct connection profiles. Detailed instructions are also generated. The stunnel certificate and key are exported in PKCS #12 format so they are compatible with other SSL tunneling applications. Notably, this enables OpenVPN for Android to tunnel its traffic through SSLDroid. OpenVPN in China on a mobile device? Yes! Tor A bridge relay is set up with a random nickname. Obfsproxy is installed and configured, including support for the obfs3 and ScrambleSuit pluggable transports. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- Pozdr rysiek

1 0

Snowden triggers flood of Crapware [was: Gruveo, more secure skype?]
by grarpamp 24 Jul '14

24 Jul '14

On Wed, Jul 23, 2014 at 2:29 PM, Cypher <cypher(a)cpunk.us> wrote: > On 2014-07-22 23:24, unixninja92 wrote: >> >> Recently found Gruveo[1]. Allows easy video and audio calls similar to >> cryptocat. Unfortunately not open source and makes no mention of being >> audited. Otherwise looks very interesting and promising. It tries to >> use P2P to make calls, and if it fails, then it will go through their >> servers. Uses WebRTC for end to end encrypted audio and video chat. >> They claim they don't keep any logs that could identify users. >> >> So the question is, is this an NSA honey pot or something that might >> actually be trustworthy? It seems at least a bit more >> secure/trustworthy than skype to me. > > > Why even consider closed alternatives when you have things like Jitsi[1] > available? It's open source, does secure voice, video, and text, and runs on > just about any platform (including Android). > > [1] www.jitsi.org > Eugen says... > RetroShare has quite good P2P audio. It's not properly audited though, > caveat emptor. Ditto. Though it will take some time not just for the open source community to pick which projects to audit under limited resources, but to even develop a real auditing framework within itself to do that under. It's a huge undertaking and responsibility in its own right. Further, what's with crap like gruveo.com, goldbug.sf.net [1], protonmail.ch, and so many more (especially the 'Look, we just solved Email encryption' crowd)? And of the partly open hw/sw stack vendor types like BlackPhone? What are we, some free debunkment service for shills, charlatans, closed source, browser/app/phone loaded crypto/exec environments provided by the service provider instead of reasonably disinterested third parties, keys disclosed, Web3.0, looks like a phone, junk? Sure, ok, it's good that we are, but the dearth of CrapWare and ProCrap analysts and marketers popping up out there lately is ridiculous. And I'm not laying down a universal CrapWare blanket, some of the stuff we see is pretty good, but simply fails to clearly, publicly, and obviously state to its users what risks their model does not cover. That's lack of care, obliviousness, lying, or profiteering... so it lands itself back in Crap territory. To quote OP... not open source.. not audited.. central servers.. webrtc.. 'no' logs.. and a shiny link for grins... and then claims it 'looks very interesting and promising'. WTF, really? I appreciate innocent questions, but the answer (or at least our response) should be obvious, from those parameters alone, to someone who's been around for a while. Though the makeup of their lists is perhaps not yet complete/ideal, you'd be better off picking anything from prism-break.org, yes say Jitsi, than this type of Crapware. We should make prism-locked.org just to list all the junk out there. It's good to have more crypto used in the world, but let's at least try to make and promote strong and open solutions. [1] I and others have been displeased with their, shall we say, 'community involvement'. As with the attempts at parallel compilation and auditing of Truecrypt, has anyone attempted that with their code? Tried to contact them? Seen any presentations? Know who they are? Open development? Etc? People say OpenPGP and crypto is hard for user adoption, no gui's for grandma, etc. So when potentially interesting gui tools appear, it's a shame many of them choose to draw these questions and thus seriously limit and tarnish their forward prospectus. At least Gruveo appears to have already answered those questions.

9 22

Fwd: a catalog of bugs, or "Why to disable assembly optimization"
by coderman 24 Jul '14

24 Jul '14

---------- Forwarded message ---------- From: Zooko Wilcox-OHearn <zooko(a)leastauthority.com> Date: Tue, Jul 22, 2014 at 12:23 PM Subject: a catalog of bugs, or "Why to disable assembly optimization" Folks: We had already agreed to disable assembly optimizations in pycryptopp, because there seem to have been a lot of bugs in the optimized assembly code in the past, and because the added speed really makes no difference to our uses, as far as I know. However, in order to explain and justify to other people (e.g. Debian packagers) why we are doing this, and why they should consider doing the same thing themselves, I just read through the entire history of issues in pycryptopp and classified whether they were runtime errors (and therefore potential security bugs) or build-time errors (therefore probably not), and whether they would have been avoided if we had been disabling assembly optimizations all along. Here are the results. They clearly show that we should disable the optimized assembly! About half of all the security-threatening bugs we've had would never have been an issue if we'd avoided assembly from the beginning. By the way, in my opinion the author of Crypto++, Wei Dai, is an *exceptionally* skilled, careful, and experienced coder, and I would assume that if Crypto++ has had this many security-threatening bugs in its optimized assembly code, then other crypto libraries that also use optimized assembly code also have at least as many. Here's the ticket to track this issue: https://tahoe-lafs.org/trac/pycryptopp/ticket/85 bugs that cause run-time failures ================================= (These bugs are potential security issues.) * would have been avoided by DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/24 - https://tahoe-lafs.org/trac/pycryptopp/ticket/31 - https://tahoe-lafs.org/trac/pycryptopp/ticket/45 (three *different* bugs in the assembly implementation) - https://tahoe-lafs.org/trac/pycryptopp/ticket/67 - https://tahoe-lafs.org/trac/pycryptopp/ticket/84 - https://tahoe-lafs.org/trac/pycryptopp/ticket/86 * unclear if it would have been avoided if we'd used DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/65 * would not have been avoided by DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/17 - https://tahoe-lafs.org/trac/pycryptopp/ticket/44 - https://tahoe-lafs.org/trac/pycryptopp/ticket/83 * would not have been avoided by DISABLE_ASM (but would have been avoided by using cffi instead of CPython API) - https://tahoe-lafs.org/trac/pycryptopp/ticket/19 - https://tahoe-lafs.org/trac/pycryptopp/ticket/70 - https://tahoe-lafs.org/trac/pycryptopp/ticket/80 * would have been avoided if we *didn't* use DISABLE_ASM! (A bug only in the non-ASM version!) - https://tahoe-lafs.org/trac/pycryptopp/ticket/66 bugs that cause deterministic build or compilation failures =========================================================== (These bugs are *typically* not potential security issues but they can be, and in any case they are engineering/deployment issues.) * would have been avoided by DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/37 - https://tahoe-lafs.org/trac/pycryptopp/ticket/96 * would not have been avoided by DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/22 - https://tahoe-lafs.org/trac/pycryptopp/ticket/23 - https://tahoe-lafs.org/trac/pycryptopp/ticket/32 - https://tahoe-lafs.org/trac/pycryptopp/ticket/39 - https://tahoe-lafs.org/trac/pycryptopp/ticket/62 - https://tahoe-lafs.org/trac/pycryptopp/ticket/77 - https://tahoe-lafs.org/trac/pycryptopp/ticket/78 -- Regards, Zooko Wilcox-O'Hearn Founder, CEO, and Customer Support Rep https://LeastAuthority.com Freedom matters.

2 1

Tails vulnerability specific to I2P, not Tor
by Eugen Leitl 24 Jul '14

24 Jul '14

http://blog.exodusintel.com/2014/07/23/silverbullets_and_fairytails/ SILVER BULLETS AND FAIRY TAILS Introduction This week we made mention on Twitter of a zero-day vulnerability we’ve unearthed that affects the popular Tails operating system. As the Tails website states: Tails is a live operating system, that you can start on almost any computer from a DVD, USB stick, or SD card. It aims at preserving your privacy and anonymity, and helps you to: use the Internet anonymously and circumvent censorship; all connections to the Internet are forced to go through the Tor network; leave no trace on the computer you are using unless you ask it explicitly; use state-of-the-art cryptographic tools to encrypt your files, emails and instant messaging.” This software was largely popularized due to the fact that it was used by whistleblower Edward Snowden. Since then, the OS has garnered much attention and use by a wide range of those seeking anonymity on the Internet. We publicized the fact that we’ve discovered these issues for a very simple reason: no user should put full trust into any particular security solution. By bringing to light the fact that we have found verifiable flaws in such a widely trusted piece of code, we hope to remind the Tails userbase that no software is infallible. Even when the issues we’ve found are fixed by the Tails team, the community should keep in mind that there are most certainly other flaws still present and likely known to others. Our customers use our information for both offensive and defensive purposes to better protect themselves and others. Providing a wide variety of exploit software we help penetration testers effectively test network security and incident response teams. One high profile example occurred last year when Facebook used a zero-day vulnerability to test their teams response to a zero-day attack. The information we provide is also leveraged in defensive purposes providing companies with well documented research for use in IDS and AV signatures for previously unknown threats. We at Exodus are able to do what many software projects cannot, perform security code audits and find exploitable vulnerabilities releasing them to the public. The Vulnerable Component The vulnerability we will be disclosing is specific to I2P. I2P currently boasts about 30,000 active peers. Since I2P has been bundled with Tails since version 0.7, Tails is by far the most widely adopted I2P usage. The I2P vulnerability works on default, fully patched installation of Tails. No settings or configurations need to be changed for the exploit to work. I2P is preconfigured so that all .i2p TLD sites are routed through the I2P network. At a high level I2P traffic is message based similar to IP packets. All communication is encrypted end to end with a total of four layers of encryption. I2P routers (end points) act as cryptographic identifiers, similar to a pair of public keys. I2P is a packet switched network, instead of circuit switched like Tor. This means transparent load balancing of packets across multiple peers. I2P is fully distributed with no centralized resources. There is no distinct separation of servers to nodes, this architecture helps eliminate single points of failure. Demonstration To lend credence to our claims we have created a video that demonstrates de-anonymizing a Tails user: TailsDeAnonymizationTailsDeAnonymization ► Timeline 0:00:00,000 –> 0:00:10,400: Demonstrating IP on listening server, Turning on listening server 0:00:19,000 –> 0:00:25,400: Tails user visiting website icanhazip.com which shows the anonymized IP address 0:00:36,000 –> 0:00:49,400: Showing that we’re indeed using the latest Tails build 1.1 0:00:50,000 –> 0:01:03,400: I2P address being resolved, proof of concept malicious payload being delivered 0:01:30,000 –> 0:01:40,400: Listening server retrieves the Tails user’s de-anonymized IP address (Austin RoadRunner ISP) Note on Disclosure Disclosure of vulnerabilities takes many forms, particularly their shape is adapted to the landscape that the platform is used upon. In the past at Exodus Intelligence, we’ve felt that significant vulnerabilities have been disregarded and have not had the requisite exposure. Through appropriate airing of the issue, we feel that users of such security platforms may come to understand the risks in base-level trust. Even further we hope to break the mold of unconditional trust in a platform. Users should question the tools they use, they should go even further to understand the underlying mechanisms that interlock to grant them security. It’s not enough to have faith upon security, rather to have an understanding of it. If the public thinks Exodus is one of a few entities finding bugs in software, they are grossly misinformed. As is the case with all vulnerabilities we report to vendors, we do not ask for any remuneration. All flaws that we give to vendors are given free of charge. All accusations of extortion perpetuated by those unfamiliar with our business model are completely unfounded. As of publication of this blog post the Tails team and the I2P team have both received all the relevant details and exploit code they require to remediate the vulnerabilities we’ve discovered. Recently a high profile talk on de-anonymization Tor users was pulled from Blackhat due to legal issues. Their talk outlined with a budget of $3000 with some powerful servers and multiple gigabit links they were able to de-anonymize hundreds of thousands of users in ‘a couple of months’. Exodus decided to pick up where this talk left off by letting the community know that there are many other vectors for de-anonymization. The vulnerability we have found is able to perform remote code execution with a specially crafted payload. This payload can be customized to unmask a user and show the public IP address in which the user connected from within ‘a couple of seconds’. Stay Tuned Part two of this blog post will present a technical discussion of the vulnerability. This will be posted once we have confirmed the vulnerabilities in I2P are patched and have been incorporated into Tails.

2 1

OT: List Archives
by grarpamp 24 Jul '14

24 Jul '14

Can mailman be configured to include the 'To:' and 'Cc:' addresses in the archive gz's? It would add some needed context when locally combining/splitting multiple lists for MUA use. And is there a way retrieve monthly attachment gz's without needing to fetch per attachment? Also, how is the 'since inception' archive project coming?

2 1

Gruveo, more secure skype alternative?
by unixninja92 24 Jul '14

24 Jul '14

Recently found Gruveo[1]. Allows easy video and audio calls similar to cryptocat. Unfortunately not open source and makes no mention of being audited. Otherwise looks very interesting and promising. It tries to use P2P to make calls, and if it fails, then it will go through their servers. Uses WebRTC for end to end encrypted audio and video chat. They claim they don't keep any logs that could identify users. So the question is, is this an NSA honey pot or something that might actually be trustworthy? It seems at least a bit more secure/trustworthy than skype to me. [1] https://www.gruveo.com/

9 8

Increased and Diverse Disclosure Initiatives Needed
by John Young 24 Jul '14

24 Jul '14

Cryptome has canceled the Kickstarter. Following the purpose of the kickstarter it urges support for increased and diverse disclosure initiatives. A few suggestions: 1. Many more and diverse disclosure initiatives are needed to broaden public participation, to diversify content and to increase unpaid access. 2. They should be novel and unexpected. 3. They should evolve and avoid being static, preferrably brand-free. 4. These may be online, offline or neither, inventive and variable. 5. They may be short- or long-lived or episodic and erratic. 6. Might be hit and run, for a single disclosure or unpredictable series. 7. Provided by individuals, groups or variable. 8. Funded by individuals, groups or variable. 9. Anonymous, nonymous, pseudononymous or variable. 10. Legal, extra-legal, quasi-legal, pushing against legal or variable. 11. Low-key, low-profile, low-recognition, the opposite or variable. 12. Reputable, disreputable or variable. 13. Risky, dangerous, outrageous, the opposite or variable. 14. Citizens' duty should be to disclose, resist secrecy, official secrecy most so.

1 0

Re: [Cryptography] hard to trust all those root CAs
by grarpamp 23 Jul '14

23 Jul '14

On Sat, Jul 19, 2014 at 5:03 PM, John Denker <jsd(a)av8n.com> wrote: > AFAICT, a lot of existing protocols were designed to resist > passive eavesdropping. In contrast, the idea of large-scale > MITM attacks was sometimes considered tin-foil-hat paranoia. > To this day, standard Ubuntu Firefox trusts 162 different > authorities (including the Hong Kong Post Office) to certify > /anything and everything/. > > In the /usr/share/ca-certificates/mozilla directory, only one > of 163 root certificates has any v3 Name Constraints at all. > Why Ubuntu and Firefox tolerate this is beyond me; I can > understand trusting Microsoft to sign Microsoft-related stuff, > but allowing them to sign /anything and everything/ ?!????!! The mozilla bundle includes about 150. It would be nice if the new cert observatoris publish a count of how many end certs they see each root cert covers... a topN list of sorts. Then you could save some time by including the N of your choice into your 'empty by default' list. I think the distribution would be severly skewed to maybe top 10 or 15 covers most any place.

2 2

Re: Gruveo, more secure skype alternative?
by John Preston 23 Jul '14

23 Jul '14

You can find the results of my inquiry below. ¬_¬ -------- Forwarded Message -------- > From: Art Matsak <art(a)gruveo.com> > To: John Preston <gizmoguy1(a)gmail.com> > Subject: Re: Security specifics > Date: Wed, 23 Jul 2014 18:34:28 +0200 > > Hi John, > > Thank you for your interest in Gruveo. Gruveo uses WebRTC, an open technology for browser realtime communication. You can find details on its security architecture here: > > http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10 > > Please note that WebRTC is work in progress and its specifications may change in the future. > > To answer your other questions, Gruveo is a proprietary product. > > Best regards, > > Art Matsak > Founder and CEO > Gruveo > https://www.gruveo.com > > > On 23 Jul 2014, at 18:19, John Preston <gizmoguy1(a)gmail.com> wrote: > > > From: John Preston <gizmoguy1(a)gmail.com> > > Subject: Security specifics > > > > Message Body: > > Hey all, > > > > Like the idea, but I'd like to know about the specifics of how Gruveo is designed. Specifically: > > * what is the threat model? > > * what are the network protocol specifications? Packet formats, ciphers and modes, and semantics all critically determine the security of the system. > > * who owns the IP, and how is it licensed? > > * what's the development model like? > > > > Thanks for your time, :) > > John > > > > -- > > This mail is sent via contact form on Gruveo https://www.gruveo.com > >

2 1