handsomeransoms's comments

Whether or not this is acceptable depends on your threat model. If you believe your adversary might compromise or coerce the service operator, then you cannot trust in-browser encryption even if it is served over https - the code sent to you could be modified to be malicious, and you have no way to prevent or even detect that this is happening. See the Tor Freedom Hosting [0] incident for an example of how LEA already do this.

So, the inability to guarantee integrity of a web application remains a problem. TLS helps, but falls short if your adversary can MITM TLS or compromise/coerce the service operator. Web applications unfortunately make this a very convenient attack vector, since their code gets reloaded from the server so frequently and remote code execution (RCE) is trivial to achieve on the web platform (XSS, browsers are full of exploitable bugs).

[0] http://www.wired.com/2013/09/freedom-hosting-fbi/

This is very similar to the functionality provided by tlsdate (https://github.com/ioerror/tlsdate). They appear to have eschewed tlsdate's default approach of using the timestamp from the handshake in favor of using the `Date:` field, which tlsdate also supports. It would be interesting to see whether the randomization of TLS timestamps in modern implementations of TLS might mean that tlsdate's default mode is no longer useful. Either way, it's really cool to see this sort of functionality being included in ntpd by default!

Are you generating the User ID with the additional characters and expecting the user to remember/keep track of it? I do think that is very user-friendly, even with the cookie trick you describe.

It seems like you are trying to force your user to remember a salt. Why not just use a proper salt and a strong password hashing function?

Also note that this protection is only useful in the case where an attacker can get a database dump but cannot perform an active attack on the server.

On the other hand, I have seen some sites (gandi.net comes to mind) do something similar to this. Wonder if they have a similar security reasoning?

Part of the problem of running an exit node is that it's unclear how "safe" it actually is, and as a result there is a lot of rumor and paranoia. Every country has different laws that affect the legal status of an exit node operator.

For example, an Austrian man was arrested in 2011 for running an exit node and charged with being an accomplice to crimes that were carried out over Tor using his exit node. He was ultimately found not guilty, but a law was passed as a result that effectively makes it illegal to run a Tor exit in Austria. [0]

Meanwhile, in the US no one has ever been arrested simply for running a Tor exit node (at least to my knowledge). Anecdotal information suggests that the most difficult thing is finding someone to host the node (many cloud VPS providers, for example, will not) if you don't host it yourself. A Reddit commentator and operator of Tor exits suggests that running Tor exits is protected under U.S. law, although I'm not sure if this has been tested in court [1].

I think Mozilla should take the (relatively small, due to their presence in the U.S.) risk of running Tor exit nodes. They could even turn it into a project of its own, to explore the common problems and develop some best practices for running Tor exits. I could imagine this being a fruitful collaboration with the EFF, for example!

[0] https://www.techdirt.com/articles/20140701/18013327753/tor-n... [1] http://www.reddit.com/r/IAmA/comments/20243q/iaman_operator_...

Clicked "Look: Try our latest demo version" and got a certificate error in Chrome :(

minilock (https://minilock.io/) intends to fill that exact niche. Have you tried it?

FYI Google Chrome warns that imagebin.com "might contain malware".

I think the title of this post is misleading. For context, see the summary of the amendment on p. 324, under "ACTION ITEM—Rule 41 (venue for approval of warrant for certain remote electronic searches)".

The goal of this amendment (appears to me, a non-laywer) to be to allow judges to issue warrants for crimes that occur in their jurisdiction, for materials that may not be in their jurisdiction, when the location of the materials has been obfuscated with an anonymizing technology. I don't think this is an "automatic warrant" - they still have to establish probable cause, etc.

A more interesting sentence from p. 325 discusses the mechanism by which the search may be carried out: "The proposal speaks to two increasingly common situations affected by the territorial restriction, each involving remote access searches, in which the government seeks to obtain access to electronic information or an electronic storage device by sending surveillance software over the Internet."

Another (incorrect, but hilariously so) interpretation of the output of traceroute: http://youtu.be/SXmv8quf_xM

Been using this for a minute, it's quite nice! Kudos to Nadim & team for a friendly and mostly intuitive UI, with some creative new ideas in the context of email/messaging.

A few initial questions:

1. Is any part of the communication forward secure? I can't imagine how the multiparty chat would be.

2. Using the avatar to verify cryptographic identity seems weak, mostly because I don't expect users will check it (it's only in the Contacts view, and it's unclear that it has that use). It resembles the placeholder avatars used on Github among other sites, which seems to suggest that it is not meaningful. So - can the Peerio server silently MITM my communications?

3. I'm not quite sure how the search works (still reading the code), but it seems like it must be searching the plaintext stored in the client's memory. How well will that scale?

> With email, you're right that POP/IMAP on a dedicated box is preferable from a security standpoint.

This depends on your threat model, and I'd argue that this statement is untrue for the vast majority of people, even people who have the technical know-how required to run their own email server. Running an email server, keeping it up to date with the latest security patches, managing SSL certificates, blocking spam, blocking malware, and blocking phishing attempts are all things that Google is better at than you. Part of the reason for this is their access to incredible volumes of data, which lets them analyze trends and emerging threats across an relatively large subset of the email-using population.

The average user's threat model is much more along the lines of phishing, malware, or spam-related fraud. Google is incredibly good at protecting people from these threats (as is obvious when I compare the volume of spam, which often contains malware or phishing links, that I receive on my Gmail account against my other, non-Gmail accounts).

Of course, if your threat model is that you require protection from law enforcement or government surveillance, then Google may be a poor choice as they are legally obligated to turn over information about you that is requested by such entities. If that is your adversary, however, than you should have a lot more work to do to protect yourself than just quitting Gmail and setting up your own mail server.

Freedom of the Press Foundation https://freedom.press -- DevOps Engineer

Full-time, Bay Area local preferred but remote possible for exceptional candidates.

We develop SecureDrop, an open source whistleblower submission system. SecureDrop is currently used in over 15 major newsrooms, including those of the Washington Post, the Guardian, the New Yorker, and ProPublica. [0]

One of our big challenges moving forward is scaling. For legal and security reasons, we require every organization to deploy their own SecureDrop instance on dedicated hardware. We do not offer SecureDrop "as a service". As a result, traditional scaling techniques do not apply. However, we believe that by automating the testing, development, deployment, and troubleshooting of SecureDrop systems, we can continue to support a growing base of SecureDrop installs without becoming overwhelmed. That's where you come in :)

For more information on the job, see our full job description, which includes instructions for applying: https://freedom.press/jobs/job-opening-devops-engineer-secur...

[0] https://freedom.press/securedrop/directory

I think it's theoretically possible to use Service Workers to do this, giving you a TOFU trust guarantee, although I think there are some issues due to the spec-mandated auto-updating of Service Workers every 24 hours.

> And Firefox's certificate API is not much better, only passive access without ability to block connections if you detect an unwanted cert.

Nope. Firefox's Addon API lets you do pretty much whatever you want. It might be kind of hard and annoying, but you can certainly block connections that are signed by an untrusted CA. How do you think Convergence [0] worked?

[0] http://convergence.io/

How many people are careful to type "https" every time they visit a website? How many people pay close attention to the lock icon/color of the URL bar? This advice seems to ignore the existence of sslstrip [0] and related attacks, and the numerous countermeasures that have been designed to deal with this problem (e.g. HSTS).

[0] http://www.thoughtcrime.org/software/sslstrip/

This is the problem that pinning is intended to solve.

That's a common problem when using OTR with the same account in a multi-device environment. It is fixed by the introduction of instance tags in libotr 4.x [0]. You should check the versions of libotr used by all your clients - if they are all libotr 4.0+, you shouldn't have these problems.

[0] https://otr.cypherpunks.ca/UPGRADING-libotr-4.1.0.txt

A simple workaround is to use a different account for each device (e.g. [email protected], [email protected]).

TextSecure's developers recognize that a good multi-device experience is essential to provide a comparable experience to other messaging apps. Their approach is different from OTR's, and is described here [0].

[0] https://moderncrypto.org/mail-archive/messaging/2014/001022....

This reminds me of the recent (~2 months ago) addition of a new, very fast Tor relay (faster than any other relay at the time) that only relayed Bitcoin traffice [0].

Wonder if that has anything to do with this research, or if someone else has independently arrived at the same result?

[0] http://www.reddit.com/r/Bitcoin/comments/2bwds2/what_does_th...

You don't have to pick one or the other. According to the FAQ [0] (linked from the blog post):

"In general, you’ll still be able to use a verification code the way you normally do on any device that doesn’t support Security Key."

[0] https://support.google.com/accounts/answer/6103523

See https://bugzilla.mozilla.org/show_bug.cgi?id=1008706