Re: [liberationtech] dark mail alliance
On Saturday, November 09, 2013 08:50:32 AM Fabio Pietrosanti wrote: Il 11/8/13 3:26 PM, phree...@yandex.ru ha scritto: The tor2webmode is a tiny and straightforward patch. See: https://gitweb.torproject.org/rransom/tor.git/shortlog/refs/heads/feature2 553-v3 This patch would require to get some more work, because with the latests version of Tor, it hangs once every X time. As a workaround on Tor2web servers we've put a crontab that restart Tor once every 59 minutes. This need further investigation to tackle the issue with Tor2web mode. Latest = 2.3.* or 2.4.* ? btw, thanks for this cool service. It really makes a difference! p.s. Tor2web software need a lot of love! We're looking for grants and projects to work with to keep on with the software development at full speed! -- 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] dark mail alliance
On Friday, November 08, 2013 12:50:19 PM adrelanos wrote: phree...@yandex.ru: [...Tor...] Both client and service can opt to drop their half of the circuit, which turns it into a more or less direct tcp connection, with nat traversal capabilities. Is dropping half of the circuit really already implemented for client and for server? There is Tor2webMode for connecting non-anonymously to hidden services. But which option hidden services could use to drop half of their circuit? I meant that the technical ability to do so is present and proven by the tor2webmode. If there are any takers, doing so for the hidden service part would be just as easy. In fact, the hardest part was finding all the checks in the code which tried to ensure you aren't shooting yourself in the foot by using insecure circuits. The tor2webmode is a tiny and straightforward patch. See: https://gitweb.torproject.org/rransom/tor.git/shortlog/refs/heads/feature2553-v3 -- 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] dark mail alliance
On Monday, November 04, 2013 01:17:49 PM Jonathan Wilkes wrote: On 11/04/2013 05:28 AM, phree...@yandex.ru wrote: On Sunday, November 03, 2013 04:06:11 PM Bill Woodcock wrote: On Nov 3, 2013, at 3:30, phree...@yandex.ru phree...@yandex.ru wrote: I don't see how pasting over a QR code in a way that's not easily detectable is somehow harder than pasting over a domain/email, or printing a real-looking fake ad and pasting it over the real one. A QR code is already isolated in an opaque white square. It's single color, and moreover, that color is black. And it's smaller than a billboard. By contrast, a textual URL or email address will be in a specific typeface, probably matched to the rest of the billboard. It's also likely size-matched to other text. Most importantly, it's likely printed right over a patterned and colored background. While you're correct that you can address, to some degree, all of those issues by wheatpasting over the entire billboard, provided you're at least as competent a visual designer as the person who executed the original ad, which is easier to print and transport? A full-color billboard, or a black-on-white sheet of tabloid-sized paper? To put this all in more practical terms, since these issues were not apparent to you, you're a less-skilled visual designer than anyone who would be paid to produce an advertisement. Therefore, you would not be capable of covertly coopting their advertisement. Yet you'd still be perfectly capable of successfully pasting over their QR code without anyone being the wiser. I can't talk about others, but I'd be quite suspicious if I saw a second layer of paper exactly where the qr code is located. If such attacks gained momentum, I guess people would be more careful. Now you are climbing up on a billboard and inspecting the QR code personally as a way to prove human readable addresses are a solution looking for a problem? Can you name a specific attack which actually happened, and which involved altering an ad url in any way or posting a fake physical ad? Are we talking about something that actually exists? It's not like an ad by microsoft can't point to a legitimately-looking domain name which isn't microsoft.com eg getthefacts.com You already mentioned the idea of domain names that aren't as widely-known as others. Widely-known is a feature-- that feature doesn't exist with QR codes so you clearly understand the issue. I'm not saying that issue cannot be solved, nor that the current domain name system is immune to exploits. But if you don't understand the benefits of human readable addresses you're likely to end up with a less secure system to replace it. I understand also that: * these benefits exist for maybe top 100 domains * it's usual for well-known entities to use campaign-specific domain names * even if you know the entity name to be $NAME, the domain can still be $NAME.com, $NAME.org, $NAME-project.org, get$NAME.com etc The security of physical ads is pretty much about the cost/benefit, and that's why we don't see such attacks in the first place. (Especially when the smartphones people must use to read the QR code in the first place are almost all locked down and not under the user's own control.) There are gateways like tor2web.org and onion.to, and these can be encoded into the QR code for compatibility purposes since there's 1:1 mapping beween darknet and gateway urls. For all practical purposes, the DNS replacement is already available in the form of tor hidden services, tested and known to be quite reliable. The status-quo is: 1) you pay money to get a DNS record which: a) can be revoked at will by a number of entities b) requires you to identify yourself, unless you're willing to play spy games(and noone know for how much longer the loopholes will exist, see (a)) c) requires you to be able to pay, which may exclude children who can't get the bank account/card, residents of sanctioned countries. 2) you get a ssl cert, with MITM-by-advanced-adversary as an inherent security feature. This also may come with random and potentially ridiculous hops to jump thru, the list is subject to change 3) wait for hours/days for payments to complete and records to propagate. Tor hidden service: 1) add 2 lines to torrc, or use vidalia to do the same 2) grab the service address from tor's dir 3) the service goes online in 5-10 minutes, with encryption and authentication always on. HTTP gateway is available for legacy platforms. Bookmarking and address book features are widely available thus making the appearance of the url itself not that important. Both client and service can opt to drop their half of the circuit, which turns it into a more or less direct tcp connection, with nat traversal capabilities. Yes there are caveats, yes tor devs are spending their effort on making tor hide users, rather than optimizing
Re: [liberationtech] dark mail alliance
On Sunday, November 03, 2013 04:06:11 PM Bill Woodcock wrote: On Nov 3, 2013, at 3:30, phree...@yandex.ru phree...@yandex.ru wrote: I don't see how pasting over a QR code in a way that's not easily detectable is somehow harder than pasting over a domain/email, or printing a real-looking fake ad and pasting it over the real one. A QR code is already isolated in an opaque white square. It's single color, and moreover, that color is black. And it's smaller than a billboard. By contrast, a textual URL or email address will be in a specific typeface, probably matched to the rest of the billboard. It's also likely size-matched to other text. Most importantly, it's likely printed right over a patterned and colored background. While you're correct that you can address, to some degree, all of those issues by wheatpasting over the entire billboard, provided you're at least as competent a visual designer as the person who executed the original ad, which is easier to print and transport? A full-color billboard, or a black-on-white sheet of tabloid-sized paper? To put this all in more practical terms, since these issues were not apparent to you, you're a less-skilled visual designer than anyone who would be paid to produce an advertisement. Therefore, you would not be capable of covertly coopting their advertisement. Yet you'd still be perfectly capable of successfully pasting over their QR code without anyone being the wiser. I can't talk about others, but I'd be quite suspicious if I saw a second layer of paper exactly where the qr code is located. If such attacks gained momentum, I guess people would be more careful. Most of ads tend to be quite simplistic and lacking any of unintentional anti- tampering features you mention, yet it doesn't look like hijacking attacks happen on a massive scale. Besides this, I highly doubt that being friendly to ads is somehow the most important feature, or at least nearly as important than having a permanent ID that can't be hijacked because the service terms changed or some bureaucrat signed a paper. I'm saying this as someone who makes it a point to ignore spam and untargetted ads, so maybe I miss something useful... -- 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] dark mail alliance
On Saturday, November 02, 2013 12:10:02 PM staticsafe wrote: On 11/2/2013 02:31, phree...@yandex.ru wrote: And you still have problems with phishing thanks to being able to register a similar domain. Of course, despite its shortcomings, namecoin is better than the existing global namespaces which are outright run by hostile entities. Hostile? What hostility? Which entity? I should have said effectively run by hostile entities. I'm sure DNS guys don't run their services with an intention to conquer the world, but they aren't effectively in control of the thing, the government is. Try using a court order confiscate a tor hidden service or force a hand over to another party like it routinely happens with DNS. Yes, there are issues with the current tor hidden service implementation, but centralized dns is a joke compared to it. Global namespaces seem to be a solution looking for a problem though. In the world full of QR codes and text messaging, sharing your unique ID is not a problem, bookmarking/address book handles assigning a memorable name or even several descriptive names. How many people use google search bar as their address bar to locate the sites they already know about? Which of the window manufacturers/installers should get windows.com domain? What is the use case for a global namespace? I for sure won't shed a tear if it disappears. -- 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] Deterministic Builds Part One: Cyberwar and Global Compromise
[1] http://nixos.org/nixos/ A very interesting project! Does the following: Packages are never overwritten after they have been built; instead, if you change the build description of a package (its ‘Nix expression’), it’s rebuilt and installed in a different path in /nix/store so it doesn’t interfere with the old version. mean that upgrading a library due to e.g. security fixes requires recompiling all packages that depend on it? There's no way to know to what extent a change in the package source code and/or its build script is going to affect the dependencies. Thus, the strong guarantees provided by Nix* currently require a rebuild. In case of a simple security fix, the rebuild is a formal check that the change is indeed trivial. This doesn't cause too much troubles in real life though but if builds are generally deterministic, caching could be used to make trivial rebuilds very fast. This is #2 motivation for me to pursue deterministic builds. I believe it is possible to make verification/trivial rebuilds fast enough to not put us at a disadvantage compared the distros which rely on maintainers to decide what to rebuild and when, while still providing formal guarantees. -- Liberationtech is a public list whose 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] Announcing Scramble.io
One difficult problem in public-key encryption is key exchange: how to get a recipient's public key and know it's really theirs. My plan is to make make your email the hash of your public key. For example, my address is *nqkgpx6bqscsl...@scramble.io* (I borrowed this idea from Tor Hidden Services.) This is what we need everyone to adopt. Your ID = your public key hash and not an account on some server you don't control. Glad to see more people adopt this idea. Any chance of interoperability with other projects with similar aims and ideas like Cables? [1] [1] http://dee.su/cables -- Liberationtech is a public list whose 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] Deterministic Builds Part One: Cyberwar and Global Compromise
I think a lot of people would benefit from reading Mike Perry's latest blog post. He addresses how The Tor Project is working towards the problems referenced by Zooko in his latest open letter to Silent Circle: Current popular software development practices simply cannot survive targeted attacks of the scale and scope that we are seeing today. NixOS distro[1] takes build reproducibility seriously and build determinism is being worked on. I have patched the most important toolchains to not systematically introduce non-determinism[2]. Some of the patches are in the master branch already, some are in the staging branch and will be merged in a month or two. These patches are sufficient to make a large subset of package builds deterministic. After the merge, I'll do another round this time fixing non-determinism due to quirks of build systems of specific packages. Luckily, there aren't that many packages like Firefox and luckily Firefox has been already tackled by someone else :) I'm committed to making at least installation media, typical desktop and server installs fully deterministic. [1] http://nixos.org/nixos/ [2] http://lists.science.uu.nl/pipermail/nix-dev/2013-June/011357.html -- Liberationtech is a public list whose 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.
