Re: [liberationtech] Encrypted Pastebins: Attack Vectors against ezcrypt.it and 0bin.net
Hi Lucas, I tried to set up a secure WebRTC server about one month ago using Kamailio with the Mediaproxy-ng to bridge text, audio, and video with appropriate ciphers which provided random public keys per session. The main security problem I found was with WebRTC's reliance on PKI to secure the media stream and SIP signaling. The second problem is WebRTC clients do not authenticate users (all authentication responsibility was delegated to my server) I think the fix for both of these problems would be to add ZRTP support to Chrome and/or Firefox and secure the media stream without PKI. A https://github.com/wernerd/ZRTPCPP and can intercept audio from the WebRTC client (chrome or firefox) and the SIP Server. On 01/21/2014 08:01 PM, Lucas Dixon wrote: On Sun, Jan 19, 2014 at 7:23 AM, carlo von lynX l...@time.to.get.psyced.org mailto:l...@time.to.get.psyced.org wrote: The highest level of this feature would be if this Mock JS could have full WebRTC functionality ;) Dunno, WebRTC is so prone to MITM. I'd rather have something secure. What kind of MITM attack are you thinking of? WebRTC doesn't specify a key authentication protocol, so not sure WebRTC is anything specific enough to say it not secure. WebRTC is compatible with ZRTP key-authentication which builds in a video-based auth scheme and should stop MITM attacks (last time I checked). You could also use some other form of key-auth with WebRTC, e.g. swap key-hashes in person. -- Lucas Dixon | Google Ideas -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Encrypted Pastebins: Attack Vectors against ezcrypt.it and 0bin.net
On Tue, Jan 14, 2014 at 6:44 PM, Uncle Zzzen unclezz...@gmail.com wrote: 3. Passive global adversary attack: As long as the JS is what the owner claims it is (assuming it's code that has been peer reviewed enough according to your standards), it doesn't matter whether they confiscate the hard drive or just listen. i hate the term passive global adversary. the adversary active across the global theater is able and active. also, you're wrong three ways: 1) if entropy is compromised (see history of RNG tampering) this assumption is actionable-ly false. don't get me started on the OpenSSL/* RDRAND fiasco... 2) JS is what the owner claims it is is suspect in BULLRUN situation where private keys pilfered. (not to mention all the other subversive techniques applied) 3) the attack surface of the browser. nuff said! (or said again, just listen is only harmless if no prior active intervention has occurred) -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Encrypted Pastebins: Attack Vectors against ezcrypt.it and 0bin.net
On Tue, Jan 14, 2014 at 6:53 PM, Tony Arcieri basc...@gmail.com wrote: ... http://cryptosphere.org I also detail the present unsuitability of the browser for cryptographic applications in this blog post: http://tonyarcieri.com/whats-wrong-with-webcrypto i see what you did there. browser based crypto... pointed to localhost! touché! ;) agree with your premises: - failure to provide cryptographic lower bounds - failure to do crypto outside insecure browser - failure in trusting https however i would go further in that cryptosphere demands defense in depth; put your trusted localhost in an environment isolated from the browser entirely; Qubes style. best regards, -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Encrypted Pastebins: Attack Vectors against ezcrypt.it and 0bin.net
On Wed, Jan 15, 2014 at 4:34 AM, Eduardo Robles Elvira edu...@gmail.comwrote: This is what I call the server-in-the-middle attack. My proposal would be to do something like SSL for end-to-end crypto. To have secure isolated reusable web-components so that you don't need to trust the web site, but the web browser. I proposed this some time ago: http://edulix.wordpress.com/2012/01/08/the-server-in-the-middle-problem-and-solution/ Nice, sounds like what I have in mind for the Cryptosphere ;) -- Tony Arcieri -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Encrypted Pastebins: Attack Vectors against ezcrypt.it and 0bin.net
IMHO there's a #readme missings at the end of the Learn more url. Makes it kinda hardcore ;) On 15 January 2014 09:53, Tony Arcieri basc...@gmail.com wrote: On Tue, Jan 14, 2014 at 6:44 PM, Uncle Zzzen unclezz...@gmail.com wrote: Maybe one day JS will introduce signed code :) If this interests you, I'm working on the problem: http://cryptosphere.org I also detail the present unsuitability of the browser for cryptographic applications in this blog post: http://tonyarcieri.com/whats-wrong-with-webcrypto -- Tony Arcieri -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Encrypted Pastebins: Attack Vectors against ezcrypt.it and 0bin.net
On Tue, Jan 14, 2014 at 9:44 PM, Uncle Zzzen unclezz...@gmail.com wrote: Maybe one day JS will introduce signed code :) Coming at that from a different angle... tl;dr [1] It's possible to sign JS, it's just a pain. See for example: http://tjl73.altervista.org/HTML_sign_tutorial/tutorial_en.html If the SPA[2] concept is reduced to atomic documents[3] then signing a web app and it's code becomes feasible[4] with some planning and trade-offs[5][6]. FWIW, I'll start signing Atomic OS reference implementations[7] in my next release. Cheers [1] view-source:http://tjl73.altervista.org/HTML_sign_tutorial/example.html [2] Single Page Application [3] The Atomic Client Document at http://code.google.com/p/atomos/ [4] If there's only one signature to verify, it should be easier to convince people to do so [5] For transparency to work, minification should be avoided and probably most 3rd party libraries as well [6] Embedded binaries (ie images) need to be kept to a minimum due to size concerns [7] http://psema4.github.io/Atomic-OS/ -- Scott Elcomb @psema4 http://psema4.com/pubkey.txt http://www.pirateparty.ca/ -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
[liberationtech] Encrypted Pastebins: Attack Vectors against ezcrypt.it and 0bin.net
Synopsis: Hi, you may have seen the popularity rising of https://ezcrypt.it and its imitator https://0bin.net. These are services that let you encrypt a message using Javascript in your own browser, then pass on the encrypted contents for the service to store while you pass the decryption key your browser generated directly to the recipient using the #anchor part of the URL. You MUST not send it to the server. Once the recipient clicks on the URL her browser will keep the anchor on the client side, get the content and the necessary Javascript from the server and the Javascript will then access the anchor in order to decrypt the message in the browser. In other words, this is a pretty nifty way to use existing web technology to implement opportunistic end-to-end encryption. I can tell three attack vectors that an adversary can use - two active and a passive one - to gain access to the encrypted contents of the message. 1. Active local adversary attack: This is the more obvious one: An adversary gains access to the server and changes the Javascript or HTML code in such a way, that an unencrypted copy of the message is submitted to the server. The attacker can choose to do this only for specific targets in order to avoid getting caught. See http://secushare.org/end2end for more on these kind of attacks. 2. Local man in the middle attack: Similarly to attack 1, if the attacker cannot gain access to the server she can still intercept communications using false HTTPS certification and provide modified HTML or Javascript from there. You can protect your recipients against this kind of attack by having them install Certificate Patrol (see http://patrol.psyced.org). 3. Passive global adversary attack: Although we haven't seen any evidence yet, it is reasonable to assume that many computing facilities offering server hosting, housing and especially virtual machine hosting (VPS) have been compromised using Patriot legislation to offer a 24/7 surveillance access to authorities. See http://secushare.org/2011-FSW-Scalability-Paranoia for more information on this kind of attack. The authority can therefore access all encrypted messages being stored on the server passively as they move around server memory or virtual hard disk. In other words, once this infrastructure is in place with the computing center, there is no way for the server administrator to observe such kind of surveillance. Combined with the ability of a global adversary to evaluate the URLs as they are passed on through the Internet by means of e-mail or Facebook chat, the authority can extract the private key attached to the URL and apply it to the encrypted data obtained from the server in order to decrypt the message without showing up in the access logs of the server. Conclusion / Recommendation: There are safer ways to communicate privately: Pond, I2P, freenet, TorChat, RetroShare (see http://secushare.org/comparison). OTR and PGP not as much, but still better (see http://secushare.org/PGP for details). If you have the possibility to install such a software, do so. If you don't, try to at least pass the URL over a safe channel such as OTR. If that still isn't an option, then find a server that is very unlikely to be tapped by the authorities according to attack vector (3) and install the service from the available source codes. Remember to also protect yourself against attack vector (2) with certificate pinning practices. Sorry for spoiling this apparently easy solution, but the Internet is currently more broken than that. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Encrypted Pastebins: Attack Vectors against ezcrypt.it and 0bin.net
On Mon, Jan 13, 2014 at 4:57 AM, carlo von lynX l...@time.to.get.psyced.org wrote: Sorry for spoiling this apparently easy solution, but the Internet is currently more broken than that. I don't think you're spoiling it. I use 0bin only for things I'd otherwise use a non-encrypted tool for... I'm sure some users make errors by assuming too much security there, but considering that the alternatives aren't 1/100th as accessible I'd have a hard time arguing that the tools aren't a net gain. They could perhaps be improved if they suggested a more secure alternative. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
