Re: [liberationtech] DecryptoCat
On 07/11/2013 02:08 PM, Maxim Kammerer wrote: On Thu, Jul 11, 2013 at 9:04 PM, Jonathan Wilkes jancs...@yahoo.com wrote: I think the upshot of that is to steer whatever funds Cryptocat has toward the form of peer review that did work, which is the bug hunt (as well as look into other forms of peer review that would be more effective). The problem with bug hunting is that, in virtually all cases, the reward for an exploitable bug is orders of magnitude lower than what can be fetched on the open market. How do people selling exploits on the open market generally get paid? Is it a lump sum? Per month that it's not divulged? Something else? -Jonathan -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On Tue, Jul 9, 2013 at 4:45 PM, Jacob Appelbaum ja...@appelbaum.net wrote: I think he very clearly stated it: Interviewer: What happens after the NSA targets a user? Snowden: They're just owned. An analyst will get a daily (or scheduled based on exfiltration summary) report on what changed on the system, PCAPS 9 of leftover data that wasn't understood by the automated dissectors, and so forth. It's up to the analyst to do whatever they want at that point -- the target's machine doesn't belong to them anymore, it belongs to the US government. Indeed, after rereading this excerpt I see that he meant exploitation. Perhaps I was too influenced by the first automatic translation from German. Are there any known examples of such NSA-grade exploits being used to own targets? I.e., besides one-of-a-kind events like Stuxnet/Flame. E.g., Chinese attacks are being mentioned all the time, but even those seem to rely on spearfishing attacks. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On 2013-07-11, at 12:38 PM, Maxim Kammerer m...@dee.su wrote: On Tue, Jul 9, 2013 at 4:57 PM, Jacob Appelbaum ja...@appelbaum.net wrote: While I think Maxim is viewed as exceedingly harsh in how he writes, I think that your response is really the wrong way to deal with him. We should consider that his cultural background is different and that as far as I understand it, he isn't a native english speaker. Between the two things, perhaps we might just ask him to be nicer? I am often harsh because I dislike circlejerks. Activists are too often completely unable to employ critical thinking when the result of that thinking would go contrary to their ideology — even more so when said activists lack scientific/technical education. E.g., recall that case last year where legal activists on this list finally succeeded in (or at least supported, not sure) enhancing export controls of software [1]. I was as annoyed as you, but I wasn't surprised. This is what these people do: claim they support some idea (e.g., freedom to write software), but easily do something to the contrary when the result is not aligned with their ideology. There is no critical thinking involved — nothing in their life accustomed these people to the need to think critically. Anyway, back to the topic. I don't care much about Cryptocat, simply because I don't care much about web programming. I don't think I participated in a discussion about Cryptocat previously. I did converse with Nadim when he was going to do something stupid in the project once, but got tired quickly when he found it hard to grasp simple CS concepts. So he fixed the problem, and I stopped caring, fine. But in this thread, I pointed out something very simple: Cryptocat paid for professional peer review (audit, whatever you call it), and it didn't work. Then, people start to lecture me for some reason, as if I have any reason to listen to that chatter. Did Cryptocat contact Veracode for a response? I mean, they spent CIA money on that, no? Or was that money spent just to be able to write a rosy blog post? E.g., I thought about hiring their audit services as well before — is that a bad idea? Is the value in such an audit only in being able to convince people who don't understand anything about programming? So, say, clueless people got happy due to an audit, and Cryptocat people were forced to fix a bug due to someone finding and widely publishing it — I can understand that. So, where are the answers to these questions? Why am I reading useless apologies and expressions of support instead? Wow. NK [1] https://mailman.stanford.edu/pipermail/liberationtech/2012-September/004854.html -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On 07/11/2013 12:38 PM, Maxim Kammerer wrote: On Tue, Jul 9, 2013 at 4:57 PM, Jacob Appelbaumja...@appelbaum.net wrote: While I think Maxim is viewed as exceedingly harsh in how he writes, I think that your response is really the wrong way to deal with him. We should consider that his cultural background is different and that as far as I understand it, he isn't a native english speaker. Between the two things, perhaps we might just ask him to be nicer? I am often harsh because I dislike circlejerks. Activists are too often completely unable to employ critical thinking when the result of that thinking would go contrary to their ideology — even more so when said activists lack scientific/technical education. E.g., recall that case last year where legal activists on this list finally succeeded in (or at least supported, not sure) enhancing export controls of software [1]. I was as annoyed as you, but I wasn't surprised. This is what these people do: claim they support some idea (e.g., freedom to write software), but easily do something to the contrary when the result is not aligned with their ideology. There is no critical thinking involved — nothing in their life accustomed these people to the need to think critically. Anyway, back to the topic. I don't care much about Cryptocat, simply because I don't care much about web programming. I don't think I participated in a discussion about Cryptocat previously. I did converse with Nadim when he was going to do something stupid in the project once, but got tired quickly when he found it hard to grasp simple CS concepts. So he fixed the problem, and I stopped caring, fine. But in this thread, I pointed out something very simple: Cryptocat paid for professional peer review (audit, whatever you call it), and it didn't work. I think the upshot of that is to steer whatever funds Cryptocat has toward the form of peer review that did work, which is the bug hunt (as well as look into other forms of peer review that would be more effective). Paying someone to tell you what problems they _did_ find makes it possible for the peer to self-validate their peerness without referring to credentials, and possible to test the claims of the peer that go beyond the immediate evidence. E.g., the bug finder says the programmer is incompetent because in the few places he cared to look there were bugs; there's more money in the bug hunt coffers; thus, a bug hunter who likes money would continue to find bugs in other places until he drains the coffers. It isn't perfect, and of course the community still has to work hard to keep developers from claiming that no bugs found with an outstanding prize means it's secure or well-designed. But as one piece of the puzzle on a small project it is a) transparent, b) the incentives of the peer line up with one of the professed aims of the developer, and c) the peer has no incentive to exploit a developer's hidden desire to confirm that the software in its current state works as claimed. (Which I'm sure all developers have even if they don't want to admit it.) -Jonathan -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On 2013-07-11, at 2:08 PM, Maxim Kammerer m...@dee.su wrote: On Thu, Jul 11, 2013 at 9:04 PM, Jonathan Wilkes jancs...@yahoo.com wrote: I think the upshot of that is to steer whatever funds Cryptocat has toward the form of peer review that did work, which is the bug hunt (as well as look into other forms of peer review that would be more effective). The problem with bug hunting is that, in virtually all cases, the reward for an exploitable bug is orders of magnitude lower than what can be fetched on the open market. So it is not a replacement for a thorough review by experts. There was a recent article on this: http://threatpost.com/researchers-find-bug-bounty-programs-pay-economic-rewards/101243 NK -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On 2013-07-09, at 12:34 AM, Jonathan Wilkes jancs...@yahoo.com wrote: On 07/08/2013 07:07 AM, Nadim Kobeissi wrote: On 2013-07-08, at 3:34 AM, Tom Ritter t...@ritter.vg wrote: On 7 July 2013 17:20, Maxim Kammerer m...@dee.su wrote: This thread started off with discussion of peer review, so I have shown that even expensive, well-qualified peer review (and I am sure that Veracode people are qualified) didn't help in this case. As one of the people on this list who does paid security audits, I both want to, and feel obligated to, weigh in on the topic. I don't work for Veracode, I have done audits for projects in the LibTech space, I have not done one for Cryptocat. I would like to, and given enough free time might get around to it, Just a quick note out of your awesome email: If you don't have enough free time, let me help you make some. I am able to fund further auditing. Round up a team and get in touch! Are you still offering bounty for finding security bugs? Because that seems to be the system under which a critical bug was revealed, and subsequently fixed. Absolutely: https://crypto.cat/bughunt/ NK -Jonathan I sincerely appreciate the perspective in the rest of your email. NK but like _everyone_ in this space, doing something publicly and putting your name on it means holding yourself to a certain standard, and that standard requires time - a lot of time (on the order of 60-100 hours). A good security audit will give you two things. Firstly it will give you bugs. These bugs are usually constrained to issues that are security vulnerabilities (but not always depending on the issue/the auditor/the time available). We find these bugs through meticulous testing and reading source code (see the 60-100 hours), through checklists to make sure we don't omit anything (see https://github.com/iSECPartners/LibTech-Auditing-Cheatsheet for a Creative Commons version of mine), and through experience and hunches. Usually an audit is time boxed so we don't literally read every line - the 60-100 hours would balloon up considerably if it were the case. We read a lot of code, we see and find a lot of bugs. The best auditors are always reading about new bug classes and exploitation vectors so we can recognise these bugs when they are in new projects. The Cryptocat bug, using a random string (or decimal digits) instead of bytes - I've seen before, as most people in my company have. (Usually it's in the form of using a hexadecimal string instead of converting the hexadecimal into bytes.) I know Cryptocat has been audited by humans in this fashion before, I've read their report, and it found good bugs. Of course, no auditor is perfect - we never find every single bug that's in an application and we can never say something is 'safe'. Which is why we give you the second thing: We give recommendations for making your codebase better. In older, more mature codebases this usually takes the form of recommendations like Everywhere you do file handling is wrong, and you need to centralize it, fix it in the centralized version, and make sure everyone uses that going forward. Those are the straightforward ones. Sometimes they're more defensive, like You really like to use the php system() function for doing stuff like removing files from the filesystem and chmodding. You do really meticulous character escaping, so we couldn't get command execution - but nonetheless, you should really use the unlink() and chmod() functions, so you can be sure a bug never makes it's way in. Now those are pretty obvious examples. In a project where the developers are making every effort they can to lock things down, where they're making every effort to do things 'right' - if we still can't provide examples, we're not doing a very good job. There are a lot of defense in depth measures that can be applied to web applications. Request preprocessors can look for global IDs, and assert that the current session can access that object (in *addition* to the page-level checks on object access). Database query logging can assert that all queries that go into particular tables use a certain column in the WHERE clause. I can go on and on. A good source of these is an ex-coworker's talk Effective approaches to web application security http://www.slideshare.net/zanelackey/effective-approaches-to-web-application-security (honestly, Etsy is driving the industry forward with their techniques for proactive web app security.) Defense in depth lends itself very easily to 'classically' exploitable conditions around things like Cross Site Scripting, Direct Object Reference, Command Injection, Code Execution. Weak RNG and fundamental protocol flaws are much harder to talk about in terms of defense in depth. So, not avoid the hard problem, let's take this particular bug. What I would say is MOAR ABSTRACTION. Now, I'm not actually a fan of
Re: [liberationtech] DecryptoCat
On 08 July, 2013 - Nadim Kobeissi wrote: On 2013-07-08, at 2:48 PM, Reed Black r...@unsafeword.org wrote: On Mon, Jul 8, 2013 at 11:00 AM, David Goulet dgou...@ev0ke.net wrote: Furthermore, looking at those lines of code, there is simply NO comments at all, nothing to help peer review, to explain why this or that is done that way and nothing linked to any design document. This is in my opinion VERY important that developers design their system/subsystem beforehand *especially* a crypto design in a public document. And, if it has to change, the design should be peer reviewed before even making one line of code. So, the technical critical issue, CryptoCat responded well, quickly but the point here is that there is a problem in terms of how development is done and how *little* the maintainability of the code is. I think there is a bigger problem in the commit messages. Looking at the history, many are tweak guehh update FIX THE BUG and some of those are tied to large many-purpose Swiss Army Knife commits. Without descriptive commit messages and single-purpose commits, community review is highly unlikely. It takes an order of magnitude more effort for a reviewer to suss out the intent of a code change. The reviewer is also much less likely to ask about suspicious side effects if he's starting with infinite possibility of intent on first encountering the code. Few volunteers will make a routine effort. Remember when someone tried slipping this into the Linux kernel? + if ((options == (__WCLONE|__WALL)) (current-uid = 0)) + retval = -EINVAL; Ask if something that subtle have been spotted so quickly if it were one of many Swiss Army Knife guehh commits. I'm sure guehh and so on are either exceptions or relate to very irrelevant commits. If they're not, then we definitely have a commit documentation problem! NK Looking at the commit history, you do. Specifically, when fixing bugs, you do note the trac number, but you do not include a link to the bug in question, and neither do you mention what the actual cause of the bug was. Instead you write Fix #whatever, sometimes with a hopefully, or maybe. A brief description of what the bug/feature entailed, and how it was fixed helps immensely if anything goes wrong later, and it also makes other peoples understanding of the codebase significantly more likely. Also, there are numerous instances where you do one thing, and also various cosmetics or clean-up operations, for example d158c4cd from late May. Try to separate commits into fully independent change sets, where code functionality commits are clearly marked as such, and code cosmetics likewise. Generally, software development is messy. Try not to make that show in the commit history. Best /P I think any project that relies on community review for security needs to first stop and ask what would make community review likely. At the least, that's some venue for review discussion where the developers are reading, single-function commits, and descriptive commit messages. Does anyone know if there's something like a best practices page to point to for maintaining a healthy reviewer community? -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Petter Ericson (pett...@acc.umu.se) -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/07/13 20:35, Maxim Kammerer wrote: Writing secure software is relatively easy, and does not rely much on abstraction layers or whatever OOP ideology is popular at the moment. You just document each function' input/output, test it somehow, and check input/output requirements when calling any other function. The simpler, the better, it's not difficult. This is contradicted by a mountain of evidence. The great majority of developers clearly don't find it easy to write secure software. If they did, we wouldn't see a constant stream of security patches for new and old software alike. Google and Mozilla wouldn't have to run competitions to find holes in their own browsers. There wouldn't be a multi-million-dollar 0day black market. It wouldn't be possible for the NSA (according to Snowden) to simply own the computer of any person of interest. Writing secure software is much, much harder than simply writing comments, writing tests and coding defensively. You might as well say that good government consists of wearing a suit, talking about laws, and remembering not to have wars or recessions. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR28w5AAoJEBEET9GfxSfMLT8H/RUK16xsgpomruwd+qZx3hl6 endDibCLoMFL4zWiTtupOMLjxhyvziZFeLKzLb7HGjch9f8tXKG6SRb1PuedIEAd znZ8Myeg7somPbrdVnNQOHZycwIpYOpWRyo3ZLXl0enbv8H+RjfzVKB1NWmyvYLM p5PnRJJOtKcuvkXon00uomVe3yHJrbF0ra8D03btv2+AuOU7pHqk6a+OyYJQMlOy xFc4IAWVth8Z2MgfbQl0HGEvpdJbkwKWMJf1U8KfZHAr4IyrozGIAupBRRCGL88t P3xZyDUO36n14uG7x6aSUD2pTe534wmWyWTU8+ABqLiMduqK/p0L9tBdRZqWMG8= =5mEN -END PGP SIGNATURE- -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On Tue, Jul 9, 2013 at 11:39 AM, Michael Rogers mich...@briarproject.org wrote: Google and Mozilla wouldn't have to run competitions to find holes in their own browsers. There wouldn't be a multi-million-dollar 0day black market. You are talking about huge projects with complex design, where the architecture itself is a source of security issues. Not to mention that WebKit and Mozilla weren't engineered for security to begin with. It wouldn't be possible for the NSA (according to Snowden) to simply own the computer of any person of interest. Offtopic, but I didn't see any indication in that last paragraph of Jacob's interview that Snowden talks about exploiting computers. In general, Snowden for some reason is usually terribly vague for someone who apparently exhibits excellent command of English language (from my non-native speaker's POV). Writing secure software is much, much harder than simply writing comments, writing tests and coding defensively. This is a thread about Cryptocat. Cryptocat is a web frontend for a couple of protocols. Yes, it is that easy. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
If it's so easy, go ahead and produce a more secure alternative that people will use. Talking about how exceedingly easy it is in Internet forums doesn't contribute much. On Tue, Jul 9, 2013 at 5:55 AM, Maxim Kammerer m...@dee.su wrote: On Tue, Jul 9, 2013 at 11:39 AM, Michael Rogers mich...@briarproject.org wrote: Google and Mozilla wouldn't have to run competitions to find holes in their own browsers. There wouldn't be a multi-million-dollar 0day black market. You are talking about huge projects with complex design, where the architecture itself is a source of security issues. Not to mention that WebKit and Mozilla weren't engineered for security to begin with. It wouldn't be possible for the NSA (according to Snowden) to simply own the computer of any person of interest. Offtopic, but I didn't see any indication in that last paragraph of Jacob's interview that Snowden talks about exploiting computers. In general, Snowden for some reason is usually terribly vague for someone who apparently exhibits excellent command of English language (from my non-native speaker's POV). Writing secure software is much, much harder than simply writing comments, writing tests and coding defensively. This is a thread about Cryptocat. Cryptocat is a web frontend for a couple of protocols. Yes, it is that easy. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
Patrick Mylund Nielsen: If it's so easy, go ahead and produce a more secure alternative that people will use. Talking about how exceedingly easy it is in Internet forums doesn't contribute much. I'm not sure if you're away but Maxim did exactly this many years ago. He wrote a system called cables: http://dee.su/cables What I hear from you is a common idea: it is the idea is that people who don't build those systems don't have a right to voice negative or critical views. When we degrade others for their criticisms by suggesting that they only get to speak if they've met some arbitrary bar for entry is dis-empowering. I know that we all do this but perhaps it isn't the best way to move forward? While I think Maxim is viewed as exceedingly harsh in how he writes, I think that your response is really the wrong way to deal with him. We should consider that his cultural background is different and that as far as I understand it, he isn't a native english speaker. Between the two things, perhaps we might just ask him to be nicer? Allow me to try a different tactic: Hey - Maxim - people appreciate what you have to say but when you say it in a way that they perceive harshly, they can't hear your pretty reasonable advice. I think you might care about this - albeit moderately - still, I think you'd reach a lot of people if they understood it in a different frame. Probably people don't understand that you're a one man powerhouse of anonymity and security projects (cables, Liberté Linux, etc), they probably stop thinking when they feel insulted or that you've insulted someone else. :( All the best, Jacob -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
Patrick Mylund Nielsen: On Tue, Jul 9, 2013 at 9:22 AM, Eugen Leitl eu...@leitl.org wrote: On Tue, Jul 09, 2013 at 09:12:21AM -0400, Patrick Mylund Nielsen wrote: If it's so easy, go ahead and produce a more secure alternative that people You mean something like http://dee.su/ ? And http://dee.su/cables ? No, I mean an alternative to Cryptocat (i.e. an OTR client with multiparty communication) that is more secure, and as easy to use. While Cryptocat has OTR - the multi-party communication is not the OTR protocol. Cables is as easy to use as email. Generally it is used with an email client. If you boot liberte - there is little to no configuration beyond establishing communication and verifying that you've done so correctly. Once that is done, you do not need to do it again - a key defense against active attackers. As I understand things this critical step (verification and persistence, or merely verification in a usable manner) cannot be done in CryptoCat at the moment. Active attackers will win against everyone without verification. The last bug ensured that *passive* attackers won against everyone on the main server and they would also win against everyone not using forward secret TLS modes. As I understand, we do not have numbers on how many users are using the less secure TLS modes. Please read this page: https://www.ssllabs.com/ssltest/analyze.html?d=crypto.cat On three computers near me, I see it using non-forward secret modes today - SSL_RSA_WITH_RC4_128_SHA - this isn't good news. This also means that if CryptoCat's security may be reduced to SSL, it is now possible to reduce that to plaintext by forcing disclosure of the current website's key. This may happen legally or it may happen through exploitation. I'm not sure why CryptoCat doesn't just exclusively offer everything with forward secret modes, and encourage everyone else to upgrade their browser when they use a less secure mode? I suggested this to Nadim on another mailing list, I'm not sure if he is working on this already? Perhaps so? I hope so... In any case, more secure than CryptoCat is not a high bar during the time of this bug. Any CA could have subverted the very little security provided the web browser trust model. Also the security provided by non-forward secret TLS connections is a really serious problem. If you mean as easy to use as a plugin in a browser and that it can be as secure as just chatting over HTTPS protected servers without any other security, I think that the requirement is not proportional. Usability is absolutely critical - but we're not looking to build usable software without any security - if we were, we'd all be using Facetime, Skype, GChat and so on, without any complaints. All the best, Jacob -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On Tue, Jul 9, 2013 at 9:57 AM, Jacob Appelbaum ja...@appelbaum.net wrote: Patrick Mylund Nielsen: If it's so easy, go ahead and produce a more secure alternative that people will use. Talking about how exceedingly easy it is in Internet forums doesn't contribute much. I'm not sure if you're away but Maxim did exactly this many years ago. He wrote a system called cables: http://dee.su/cables What I hear from you is a common idea: it is the idea is that people who don't build those systems don't have a right to voice negative or critical views. When we degrade others for their criticisms by suggesting that they only get to speak if they've met some arbitrary bar for entry is dis-empowering. I know that we all do this but perhaps it isn't the best way to move forward? While I think Maxim is viewed as exceedingly harsh in how he writes, I think that your response is really the wrong way to deal with him. We should consider that his cultural background is different and that as far as I understand it, he isn't a native english speaker. Between the two things, perhaps we might just ask him to be nicer? Allow me to try a different tactic: Hey - Maxim - people appreciate what you have to say but when you say it in a way that they perceive harshly, they can't hear your pretty reasonable advice. I think you might care about this - albeit moderately - still, I think you'd reach a lot of people if they understood it in a different frame. Probably people don't understand that you're a one man powerhouse of anonymity and security projects (cables, Liberté Linux, etc), they probably stop thinking when they feel insulted or that you've insulted someone else. :( Great, constructive idea. I've also wanted to commend Nadim for making an honest, humble public apology and spending a lot of time publicly talking through what happened. (We don't see that kind of thing in the nonprofit world--I can't think of a single example). Certainly that was the right thing to do, but he could have been a defensive jerk about it. He has his eye on the ball--helping people at risk keep their communications safe in as accessible a way as possible. Both of you know that it's not a game. Kate Krauss Executive Director AIDS Policy Project www.AIDSPolicyProject.org User All the best, Jacob -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On 2013-07-09, at 10:29 AM, Jacob Appelbaum ja...@appelbaum.net wrote: Patrick Mylund Nielsen: On Tue, Jul 9, 2013 at 9:22 AM, Eugen Leitl eu...@leitl.org wrote: On Tue, Jul 09, 2013 at 09:12:21AM -0400, Patrick Mylund Nielsen wrote: If it's so easy, go ahead and produce a more secure alternative that people You mean something like http://dee.su/ ? And http://dee.su/cables ? No, I mean an alternative to Cryptocat (i.e. an OTR client with multiparty communication) that is more secure, and as easy to use. While Cryptocat has OTR - the multi-party communication is not the OTR protocol. Cables is as easy to use as email. Generally it is used with an email client. If you boot liberte - there is little to no configuration beyond establishing communication and verifying that you've done so correctly. Once that is done, you do not need to do it again - a key defense against active attackers. As I understand things this critical step (verification and persistence, or merely verification in a usable manner) cannot be done in CryptoCat at the moment. Active attackers will win against everyone without verification. The last bug ensured that *passive* attackers won against everyone on the main server and they would also win against everyone not using forward secret TLS modes. As I understand, we do not have numbers on how many users are using the less secure TLS modes. Please read this page: https://www.ssllabs.com/ssltest/analyze.html?d=crypto.cat On three computers near me, I see it using non-forward secret modes today - SSL_RSA_WITH_RC4_128_SHA - this isn't good news. Hi Jacob, You've said a lot about Cryptocat's SSL configuration — can you recommend a better configuration that is similarly compatible? Thanks, NK This also means that if CryptoCat's security may be reduced to SSL, it is now possible to reduce that to plaintext by forcing disclosure of the current website's key. This may happen legally or it may happen through exploitation. I'm not sure why CryptoCat doesn't just exclusively offer everything with forward secret modes, and encourage everyone else to upgrade their browser when they use a less secure mode? I suggested this to Nadim on another mailing list, I'm not sure if he is working on this already? Perhaps so? I hope so... In any case, more secure than CryptoCat is not a high bar during the time of this bug. Any CA could have subverted the very little security provided the web browser trust model. Also the security provided by non-forward secret TLS connections is a really serious problem. If you mean as easy to use as a plugin in a browser and that it can be as secure as just chatting over HTTPS protected servers without any other security, I think that the requirement is not proportional. Usability is absolutely critical - but we're not looking to build usable software without any security - if we were, we'd all be using Facetime, Skype, GChat and so on, without any complaints. All the best, Jacob -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
Here are more statistics on TLS modes failing back to less secure modes, and a semi-complete listing of affected browsers, published 2 days ago: http://jbp.io/2013/07/07/tls-downgrade/ Best, Jason Gulledge On Jul 9, 2013, at 4:29 PM, Jacob Appelbaum ja...@appelbaum.net wrote: Patrick Mylund Nielsen: On Tue, Jul 9, 2013 at 9:22 AM, Eugen Leitl eu...@leitl.org wrote: On Tue, Jul 09, 2013 at 09:12:21AM -0400, Patrick Mylund Nielsen wrote: If it's so easy, go ahead and produce a more secure alternative that people You mean something like http://dee.su/ ? And http://dee.su/cables ? No, I mean an alternative to Cryptocat (i.e. an OTR client with multiparty communication) that is more secure, and as easy to use. While Cryptocat has OTR - the multi-party communication is not the OTR protocol. Cables is as easy to use as email. Generally it is used with an email client. If you boot liberte - there is little to no configuration beyond establishing communication and verifying that you've done so correctly. Once that is done, you do not need to do it again - a key defense against active attackers. As I understand things this critical step (verification and persistence, or merely verification in a usable manner) cannot be done in CryptoCat at the moment. Active attackers will win against everyone without verification. The last bug ensured that *passive* attackers won against everyone on the main server and they would also win against everyone not using forward secret TLS modes. As I understand, we do not have numbers on how many users are using the less secure TLS modes. Please read this page: https://www.ssllabs.com/ssltest/analyze.html?d=crypto.cat On three computers near me, I see it using non-forward secret modes today - SSL_RSA_WITH_RC4_128_SHA - this isn't good news. This also means that if CryptoCat's security may be reduced to SSL, it is now possible to reduce that to plaintext by forcing disclosure of the current website's key. This may happen legally or it may happen through exploitation. I'm not sure why CryptoCat doesn't just exclusively offer everything with forward secret modes, and encourage everyone else to upgrade their browser when they use a less secure mode? I suggested this to Nadim on another mailing list, I'm not sure if he is working on this already? Perhaps so? I hope so... In any case, more secure than CryptoCat is not a high bar during the time of this bug. Any CA could have subverted the very little security provided the web browser trust model. Also the security provided by non-forward secret TLS connections is a really serious problem. If you mean as easy to use as a plugin in a browser and that it can be as secure as just chatting over HTTPS protected servers without any other security, I think that the requirement is not proportional. Usability is absolutely critical - but we're not looking to build usable software without any security - if we were, we'd all be using Facetime, Skype, GChat and so on, without any complaints. All the best, Jacob -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
Sorry, when I wrote scare normal users away from e.g. MSN, I meant scare normal users away from switching from e.g. MSN On Tue, Jul 9, 2013 at 12:31 PM, Patrick Mylund Nielsen cryptogra...@patrickmylund.com wrote: What I hear from you is a common idea: it is the idea is that people who don't build those systems don't have a right to voice negative or critical views. Absolutely not. If this is how I came across, I apologize. Let me try to express myself a little more clearly, and not via a phone. Your second reply resonated quite well with my underlying thoughts. When we degrade others for their criticisms by suggesting that they only get to speak if they've met some arbitrary bar for entry is dis-empowering. I know that we all do this but perhaps it isn't the best way to move forward? To be clear, the only thing I take objection to in this thread are the snarky, semi-arrogant replies that imply that e.g. Veracode's code reviews are useless, and that all the developers behind X are incompetent, while not actually providing a lot of constructive commentary. (Admittedly, I am already slightly annoyed from reading other comment threads about this same issue where the response was a fairly unanimous Omg, Cryptocat sucks! What a bunch of amateurs!, so this is more of a response to that collectively than to the comments of Maxim, specifically. That being said, I care very little for arguments from authority, unless they make sense.) There may be a language barrier, but despite being a non-native speaker myself, the comments still came across quite negatively. By no means should Cryptocat be immune to criticism--it's clear that it isn't--and there is no reason why somebody with knowledge on a subject can't comment on deficiencies, even if they don't make a competitor, or prove that they are able to. But there are several ways to do so--a few that I've seen recently in connection with Cryptocat are: 1. To turn to the developers of the software and/or contributing to the software itself, 2. By flaming the software and its authors on mailing lists and on blogs, in discussions that are most closely analogous to lol, noobs., and 3. A combination: finding vulnerabilities, informing the developers, and posting about it on blogs with added opinions that all the developers are incompetent. Obviously, I think #1 is the most useful. #3, while harsh, still is, since the vulnerabilities will inevitably be patched, whether or not you provide a solution. (Indeed, the history of responsible disclosure shows that this is often the only way to get something fixed.) #2 is entirely useless, in my opinion. So when I say if it's so easy, make a better one, I really mean why don't you switch from #2 to either #1 or #3. There obviously is a limit: where the authors of a piece of software are so incompetent, or the software is so badly written, that it should be avoided at all costs. I don't think that Nadim, et al, and Cryptocat are at or past that point, for several reasons: - They very clearly communicate that this is experimental software, that you shouldn't put your life on the line using it, and that it hasn't undergone a lot of scrutiny - Whenever there's been a new feature or new release, the main request from the authors themselves has been that people take a look at it and come to them if they see any problems. The authors recognize that they are not infallible experts on the subject. (Contrast with Silent Circle where their whole argument is that we are crypto experts and Navy SEALs, and you should trust our closed source software, but the software still has serious problems.) - Cryptocat is helping bring OTR to the masses I'm not sure if you're away but Maxim did exactly this many years ago. He wrote a system called cables: I was aware of its existence, although I'll admit I haven't used it recently. While I appreciate and recognize your description of its ease-of-use, I will say that I think most people aren't going to run a custom Linux distribution to communicate securely--and when I say most people, I mean the masses, not liberationtech. Which leads me to my main point... Usability is absolutely critical - but we're not looking to build usable software without any security - if we were, we'd all be using Facetime, Skype, GChat and so on, without any complaints. This is where your reply is in agreement with what was (granted, deeply) between the lines of my initial replies, where I continuously highlighted usability as a critical feature. I want secure software. I want something that lets me communicate with others securely. But when I, a fairly paranoid person by my own judgement, and somebody who writes cryptography and privacy software for a living, disable my Android device encryption because it doesn't let you use something other than the encryption passphrase to unlock the screen (even though it doesn't actually
Re: [liberationtech] DecryptoCat
On 07/09/2013 10:29 AM, Jacob Appelbaum wrote: Patrick Mylund Nielsen: On Tue, Jul 9, 2013 at 9:22 AM, Eugen Leitl eu...@leitl.org wrote: On Tue, Jul 09, 2013 at 09:12:21AM -0400, Patrick Mylund Nielsen wrote: If it's so easy, go ahead and produce a more secure alternative that people You mean something like http://dee.su/ ? And http://dee.su/cables ? No, I mean an alternative to Cryptocat (i.e. an OTR client with multiparty communication) that is more secure, and as easy to use. While Cryptocat has OTR - the multi-party communication is not the OTR protocol. Cables is as easy to use as email. Generally it is used with an email client. Email for someone that doesn't already have it: 1. Turn on _any_ computer. 2. Load up _any_ OS. 3. Run _any_ browser. 4. Go to www.gmail.com. 5. Sign up. 6. Send a message to b...@wherever.com, whose email address you recall from memory. What are the steps for sending Bob a message using Cables? This isn't rhetorical, I'd actually like to know what the steps are. -Jonathan If you boot liberte - there is little to no configuration beyond establishing communication and verifying that you've done so correctly. Once that is done, you do not need to do it again - a key defense against active attackers. As I understand things this critical step (verification and persistence, or merely verification in a usable manner) cannot be done in CryptoCat at the moment. Active attackers will win against everyone without verification. The last bug ensured that *passive* attackers won against everyone on the main server and they would also win against everyone not using forward secret TLS modes. As I understand, we do not have numbers on how many users are using the less secure TLS modes. Please read this page: https://www.ssllabs.com/ssltest/analyze.html?d=crypto.cat On three computers near me, I see it using non-forward secret modes today - SSL_RSA_WITH_RC4_128_SHA - this isn't good news. This also means that if CryptoCat's security may be reduced to SSL, it is now possible to reduce that to plaintext by forcing disclosure of the current website's key. This may happen legally or it may happen through exploitation. I'm not sure why CryptoCat doesn't just exclusively offer everything with forward secret modes, and encourage everyone else to upgrade their browser when they use a less secure mode? I suggested this to Nadim on another mailing list, I'm not sure if he is working on this already? Perhaps so? I hope so... In any case, more secure than CryptoCat is not a high bar during the time of this bug. Any CA could have subverted the very little security provided the web browser trust model. Also the security provided by non-forward secret TLS connections is a really serious problem. If you mean as easy to use as a plugin in a browser and that it can be as secure as just chatting over HTTPS protected servers without any other security, I think that the requirement is not proportional. Usability is absolutely critical - but we're not looking to build usable software without any security - if we were, we'd all be using Facetime, Skype, GChat and so on, without any complaints. All the best, Jacob -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
Nadim Kobeissi: Hi Jacob, You've said a lot about Cryptocat's SSL configuration — can you recommend a better configuration that is similarly compatible? Hi Nadim, I mentioned this on the cryptography list - I suggest several things. First up - either disable all non-forward secure SSL/TLS modes or configure a different website for those clients. In the latter case, the website could encourage them to download a new, likely more secure browser or it could simply inform them that you can't protect them against important threats with such an old browser. Secondly - I would suggest that you consider using a web-server that is type-safe, store any key in a hardware security module, and utilize a variety of entropy sources. See also this set of things that can go wrong with forward secrecy: https://www.imperialviolet.org/2013/06/27/botchingpfs.html CryptoCat likely makes a few mistakes listed there - if not - ensure that you document each issue, how it is mitigated and ensure you check in your configuration files as part of CryptoCat's codebase, so that there aren't obvious regressions. All the best, Jacob -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
Jonathan Wilkes: On 07/09/2013 10:29 AM, Jacob Appelbaum wrote: Patrick Mylund Nielsen: On Tue, Jul 9, 2013 at 9:22 AM, Eugen Leitl eu...@leitl.org wrote: On Tue, Jul 09, 2013 at 09:12:21AM -0400, Patrick Mylund Nielsen wrote: If it's so easy, go ahead and produce a more secure alternative that people You mean something like http://dee.su/ ? And http://dee.su/cables ? No, I mean an alternative to Cryptocat (i.e. an OTR client with multiparty communication) that is more secure, and as easy to use. While Cryptocat has OTR - the multi-party communication is not the OTR protocol. Cables is as easy to use as email. Generally it is used with an email client. Email for someone that doesn't already have it: 1. Turn on _any_ computer. 2. Load up _any_ OS. 3. Run _any_ browser. 4. Go to www.gmail.com. 5. Sign up. 6. Send a message to b...@wherever.com, whose email address you recall from memory. You are hilariously oversimplifying the problem. How did you find b...@wherever.com's address exactly? And while many people use email with a web browser, surely you don't suggest that people don't use heavy email clients (gmail app, thunderbird, outlook, applemail, claws, etc)? What are the steps for sending Bob a message using Cables? This isn't rhetorical, I'd actually like to know what the steps are. Roughly I think this is correct: 0. Download https://www.dee.su/liberte 1. Boot any modern computer with the usb disk inserted 2. launch Claws email client 3) write message to bob's cable address and press send If you have a supported platform, you can skip 0-2 and replace it with 'install cables' - as one might install a modern browser. If you're going to say that using Gmail easily happens in any browser on any OS, I guess I'd tend to disagree. If we add securely into the picture, I guess I'd just laugh and laugh and laugh. Sadly. It is really a bummer that PRISM exists and that Google appears to be under the boot of that system. Though accessing Gmail with Chrome is clearly better than any other choice! All the best, Jacob -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On 07/09/2013 06:25 PM, Petter Ericson wrote: What are the steps for sending Bob a message using Cables? This isn't rhetorical, I'd actually like to know what the steps are. Roughly I think this is correct: 0. Download https://www.dee.su/liberte 1. Boot any modern computer with the usb disk inserted 2. launch Claws email client 3) write message to bob's cable address and press send If you have a supported platform, you can skip 0-2 and replace it with 'install cables' - as one might install a modern browser. I do not think that installing a modern browser entails building it from source for most people. If you're going to say that using Gmail easily happens in any browser on any OS, I guess I'd tend to disagree. If we add securely into the picture, I guess I'd just laugh and laugh and laugh. Sadly. It is really a bummer that PRISM exists and that Google appears to be under the boot of that system. Though accessing Gmail with Chrome is clearly better than any other choice! Unfortunately, the question wasn't how to communicate _securely_, but how to communicate _at all_, which is what most people aim to do in the first place. Please do not pretend that hash@hash.onion is as easy to remember as j...@cervant.es or something similar, or that installing dependencies and building from source is similar to a one-click installer. Best /P Well, not be cynical, but I think people would have to exert a few more iotas of energy, and learn how use Tor or software like cables starting from now on. Unless their freedom is something not that important to them. I mean, people all over have learned how to lock their doors, right? It is definitely inconvenient for me to lock my damn doors at 8 o'clock in the morning, as I am rushing off to work. But I do it, because it has been impressed upon me that it is rather important to do so for obvious reasons. Maybe it's time to raise the bar just a bit, and start setting expectations for emailing that go beyond Go to gmail.com and start typing your message to your friend. The barrier is more ideological and a function of habituation, than a question of difficulty. I know those can be steep bars to overcome, but people all over have learned how to use the Windows control panel (a nightmare of poor design for an intended audience of non-sophisticated computer users, if you ask me), how to use their anti-virus checker, and how to communicate on Twitter in streams of 140 chars (not the most elegant or intuitive thing in the world, before it existed, and/or people were told that twitter is easy to use). Often one has to actually try something new to learn not to fear it's apparent complexity. All the best, Jacob -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On 10-07-13 00:57, h0ost wrote: On 07/09/2013 06:25 PM, Petter Ericson wrote: What are the steps for sending Bob a message using Cables? This isn't rhetorical, I'd actually like to know what the steps are. Roughly I think this is correct: 0. Download https://www.dee.su/liberte 1. Boot any modern computer with the usb disk inserted 2. launch Claws email client 3) write message to bob's cable address and press send If you have a supported platform, you can skip 0-2 and replace it with 'install cables' - as one might install a modern browser. I do not think that installing a modern browser entails building it from source for most people. If you're going to say that using Gmail easily happens in any browser on any OS, I guess I'd tend to disagree. If we add securely into the picture, I guess I'd just laugh and laugh and laugh. Sadly. It is really a bummer that PRISM exists and that Google appears to be under the boot of that system. Though accessing Gmail with Chrome is clearly better than any other choice! Unfortunately, the question wasn't how to communicate _securely_, but how to communicate _at all_, which is what most people aim to do in the first place. Please do not pretend that hash@hash.onion is as easy to remember as j...@cervant.es or something similar, or that installing dependencies and building from source is similar to a one-click installer. Best /P Well, not be cynical, but I think people would have to exert a few more iotas of energy, and learn how use Tor or software like cables starting from now on. Unless their freedom is something not that important to them. I mean, people all over have learned how to lock their doors, right? It is definitely inconvenient for me to lock my damn doors at 8 o'clock in the morning, as I am rushing off to work. But I do it, because it has been impressed upon me that it is rather important to do so for obvious reasons. I think, it is too much to ask of people to change their ways. Most of the front doors around here fall into closed mode with a gentle push. The wedge shape part makes that automatically. Especially in an 8 o'clock rush. The reason people lock these doors is fear of theft. With email, there is no fear, nor theft. And there is nothing to hide... I believe the only way forward is to make using security easier than not using security. Ie, secure/privacy by design. That's what cryptocat is trying, dee.su/cables appears to do so in a spectacular easy to use way. Will have to check it out. And so do I try to reach that holy grail too with my eccentric-authentication. Cheers, Guido. http://eccentric-authentication.org/ -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On 07/09/2013 02:33 PM, Jacob Appelbaum wrote: Jonathan Wilkes: On 07/09/2013 10:29 AM, Jacob Appelbaum wrote: Patrick Mylund Nielsen: On Tue, Jul 9, 2013 at 9:22 AM, Eugen Leitl eu...@leitl.org wrote: On Tue, Jul 09, 2013 at 09:12:21AM -0400, Patrick Mylund Nielsen wrote: If it's so easy, go ahead and produce a more secure alternative that people You mean something like http://dee.su/ ? And http://dee.su/cables ? No, I mean an alternative to Cryptocat (i.e. an OTR client with multiparty communication) that is more secure, and as easy to use. While Cryptocat has OTR - the multi-party communication is not the OTR protocol. Cables is as easy to use as email. Generally it is used with an email client. Email for someone that doesn't already have it: 1. Turn on _any_ computer. 2. Load up _any_ OS. Here I went overboard-- of course there are all kinds of computers and OSes that don't run modern browsers. I'm just thinking of the most common modern devices, like what someone brings into a coffee house or uses on public transit to send and receive messages. 3. Run _any_ browser. 4. Go to www.gmail.com. 5. Sign up. 6. Send a message to b...@wherever.com, whose email address you recall from memory. You are hilariously oversimplifying the problem. No, it's just that signing up for Gmail for people who are ignorant about the consequences to society of communicating insecurely over the internet is frighteningly simple. If you walk into a coffee house and look at the setup people have on their smartphones, tablets, and laptops, it's probably some form of leaving messages on a centralized service and accessing through a client or smartphone app; that way they don't have to worry about syncing, and setting up a new device is as easy as entering a human readable login and a password into an app and voila. Very few of those devices even have a usb connection and are locked down to the point where you couldn't even boot into a secure GNU/Linux distribution if you wanted to, so Cables is a nonstarter. I'm not proposing Gmail as a solution to the problem-- I'm saying your statement that using Cables is as easy as using email-- even on a machine where it's easy to install-- is not accurate. At the very least your statement ignores the problem of human unreadable addresses and only applies to uses of email where the messages reside on a single machine of the user that isn't accessible easily from other devices. That isn't the most usable form of sending messages insecurely so it isn't fair to compare it to the most usable form of sending messages securely. Put another way: the easiest way of using email is less of a hassle than the easiest way of using Cables. I think it's important to state that clearly, as well as say that using Cables is as easy as using encrypted email (in which case Cables would be superior as it has lots of features which sending end-to-end encrypted messages over a centralized email service would not). As far as the problem: yes, my use of a centralized service is a problem and I'd like to rectify it. How did you find b...@wherever.com's address exactly? And while many people use email with a web browser, surely you don't suggest that people don't use heavy email clients (gmail app, thunderbird, outlook, applemail, claws, etc)? What are the steps for sending Bob a message using Cables? This isn't rhetorical, I'd actually like to know what the steps are. Roughly I think this is correct: 0. Download https://www.dee.su/liberte 1. Boot any modern computer with the usb disk inserted 2. launch Claws email client 3) write message to bob's cable address and press send Thanks, I'll try out that setup. -Jonathan If you have a supported platform, you can skip 0-2 and replace it with 'install cables' - as one might install a modern browser. If you're going to say that using Gmail easily happens in any browser on any OS, I guess I'd tend to disagree. If we add securely into the picture, I guess I'd just laugh and laugh and laugh. Sadly. It is really a bummer that PRISM exists and that Google appears to be under the boot of that system. Though accessing Gmail with Chrome is clearly better than any other choice! All the best, Jacob -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On 2013-07-08, at 12:13 PM, Ralph Holz h...@net.in.tum.de wrote: Hi Tom, If you think this bug could never happen to you or your favorite pet project; if you think there's nothing you can learn from this incident - you haven't thought hard enough about ways it could have been prevented, and thus how you can prevent bugs in your own codebase. Amen to that. Thanks for the write-up; it was my feeling, too, that too many people have been uttering very sharp criticism in this particular case, and that wasn't helping anyone. There are projects that don't get nearly as much coverage but have a very poor security record. I personally know programmers with a hell of a global reputation whose code contained bugs found by peers. We should keep things in perspective. Thanks a lot for this kind call for perspective. The fact remains that we messed up. But I'm sticking to the project and I am certain that we will mess up less and less, and evolve. It took exemplary projects like Tor and PGP ten+ years to reach the reputable status they're in today (where, mind you, critical bugs still happen!) — it may take us even longer. But the goals are too important to give up. We're in a situation where accessibility has failed to evolve precisely because you're largely barren from taking risks. A license to take risks isn't a license to keep messing up, but it's still necessary to investigate real problems to which we haven't been able to find solutions as a community so far. If a bug like this happens again in the future, I will follow the same procedure of complete transparency and hold myself fully accountable for it. All the same, I am redoubling my efforts to bring in more cryptographers and auditors to Cryptocat — this is what I just spent my weekend in Germany doing. But quite frankly, for now, I really think I need a small vacation. :-p NK Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On Mon, Jul 8, 2013 at 4:34 AM, Tom Ritter t...@ritter.vg wrote: As one of the people on this list who does paid security audits, I both want to, and feel obligated to, weigh in on the topic. Thanks for your insight into code review process. Besides perhaps insinuating that Veracode didn't do their job properly, I don't see how it is in any way relevant to the Cryptocat incident discussed ITT. So, not avoid the hard problem, let's take this particular bug. What I would say is MOAR ABSTRACTION. […] Each of these classes is pretty modular, and is unit tested up the wazoo. That's all very interesting. Meanwhile, in the real world: https://github.com/cryptocat/cryptocat/tree/master/test If you think this bug could never happen to you or your favorite pet project; if you think there's nothing you can learn from this incident - you haven't thought hard enough about ways it could have been prevented, and thus how you can prevent bugs in your own codebase. I think you forgot that you are not in a presentation to PHBs. There is absolutely nothing I can learn from this incident. I know basic programming principles, and my job is not in providing consulting to software companies in a mess. I understand the unwillingness to accept criticism and the white-knighting, but look at it this way. If I told you that I found another vulnerability in Cryptocat, and am in a process of selling it to an intelligence agency, would you still proceed to lecture me on my thinking processes, and on best software practices? -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On 2013-07-08, at 3:34 AM, Tom Ritter t...@ritter.vg wrote:
On 7 July 2013 17:20, Maxim Kammerer m...@dee.su wrote:
This thread started off with discussion of peer review, so I have
shown that even expensive, well-qualified peer review (and I am sure
that Veracode people are qualified) didn't help in this case.
As one of the people on this list who does paid security audits, I
both want to, and feel obligated to, weigh in on the topic. I don't
work for Veracode, I have done audits for projects in the LibTech
space, I have not done one for Cryptocat. I would like to, and given
enough free time might get around to it,
Just a quick note out of your awesome email:
If you don't have enough free time, let me help you make some. I am able to
fund further auditing. Round up a team and get in touch!
I sincerely appreciate the perspective in the rest of your email.
NK
but like _everyone_ in this
space, doing something publicly and putting your name on it means
holding yourself to a certain standard, and that standard requires
time - a lot of time (on the order of 60-100 hours).
A good security audit will give you two things.
Firstly it will give you bugs. These bugs are usually constrained to
issues that are security vulnerabilities (but not always depending on
the issue/the auditor/the time available). We find these bugs through
meticulous testing and reading source code (see the 60-100 hours),
through checklists to make sure we don't omit anything (see
https://github.com/iSECPartners/LibTech-Auditing-Cheatsheet for a
Creative Commons version of mine), and through experience and hunches.
Usually an audit is time boxed so we don't literally read every line
- the 60-100 hours would balloon up considerably if it were the case.
We read a lot of code, we see and find a lot of bugs. The best
auditors are always reading about new bug classes and exploitation
vectors so we can recognise these bugs when they are in new projects.
The Cryptocat bug, using a random string (or decimal digits) instead
of bytes - I've seen before, as most people in my company have.
(Usually it's in the form of using a hexadecimal string instead of
converting the hexadecimal into bytes.)
I know Cryptocat has been audited by humans in this fashion before,
I've read their report, and it found good bugs. Of course, no auditor
is perfect - we never find every single bug that's in an application
and we can never say something is 'safe'. Which is why we give you
the second thing:
We give recommendations for making your codebase better. In older,
more mature codebases this usually takes the form of recommendations
like Everywhere you do file handling is wrong, and you need to
centralize it, fix it in the centralized version, and make sure
everyone uses that going forward. Those are the straightforward
ones. Sometimes they're more defensive, like You really like to use
the php system() function for doing stuff like removing files from the
filesystem and chmodding. You do really meticulous character
escaping, so we couldn't get command execution - but nonetheless, you
should really use the unlink() and chmod() functions, so you can be
sure a bug never makes it's way in.
Now those are pretty obvious examples. In a project where the
developers are making every effort they can to lock things down, where
they're making every effort to do things 'right' - if we still can't
provide examples, we're not doing a very good job.
There are a lot of defense in depth measures that can be applied to
web applications. Request preprocessors can look for global IDs, and
assert that the current session can access that object (in *addition*
to the page-level checks on object access). Database query logging
can assert that all queries that go into particular tables use a
certain column in the WHERE clause. I can go on and on. A good
source of these is an ex-coworker's talk Effective approaches to web
application security
http://www.slideshare.net/zanelackey/effective-approaches-to-web-application-security
(honestly, Etsy is driving the industry forward with their techniques
for proactive web app security.)
Defense in depth lends itself very easily to 'classically' exploitable
conditions around things like Cross Site Scripting, Direct Object
Reference, Command Injection, Code Execution. Weak RNG and
fundamental protocol flaws are much harder to talk about in terms of
defense in depth.
So, not avoid the hard problem, let's take this particular bug. What
I would say is MOAR ABSTRACTION. Now, I'm not actually a fan of
abstraction, I hate seeing a ton of one-line functions, but in this
case, to prevent a bug like this from happening again, I would
structure the code like this (taking into account I'm really bad at
naming things):
//rng.ext
///This class is a CSPRNG that outputs a stream of random bytes
class RandomNumberGenerator {
}
//rng-types.ext
Re: [liberationtech] DecryptoCat
On Mon, Jul 8, 2013 at 4:34 AM, Maxim Kammerer m...@dee.su wrote: On Mon, Jul 8, 2013 at 4:34 AM, Tom Ritter t...@ritter.vg wrote: As one of the people on this list who does paid security audits, I both want to, and feel obligated to, weigh in on the topic. Thanks for your insight into code review process. Besides perhaps insinuating that Veracode didn't do their job properly, I don't see how it is in any way relevant to the Cryptocat incident discussed ITT. [...] There is absolutely nothing I can learn from this incident. If it's all old review for you, I hope you will share even more specific suggestions for others. CryptoCat has been a useful object lesson, but already there is no shortage of threads for waggling the finger of shame and personal criticisms. It helps that the discussion goes to a more general discussion of review approaches and precautions. Tom's was the first message of the thread that was useful to forward to my own project. Some specific suggestions are now tasks in our bug tracker. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On 2013-07-08, at 2:00 PM, David Goulet dgou...@ev0ke.net wrote: Hi everyone, Very good post Tom! :) I would like to point out something here, no bashing, but rather possible improvements from my point of view. As Tom stated, basically if you don't do code, you'll have no bugs so in other words there will always be bugs! Now, what's troubling me with this disclosure is probably a lack of experience of the maintainers especially in open source software. There is 19 commits between Jul 9, 2011 and Jun 3, 2013 (see second table of the decryptocat post) which basically changes the keying scheme in production. There is 6 of those only in October 2011! In terms of peer review, this is just not possible to follow such a paste especially with so little testing upstream. Furthermore, looking at those lines of code, there is simply NO comments at all, nothing to help peer review, to explain why this or that is done that way and nothing linked to any design document. This is in my opinion VERY important that developers design their system/subsystem beforehand *especially* a crypto design in a public document. And, if it has to change, the design should be peer reviewed before even making one line of code. So, the technical critical issue, CryptoCat responded well, quickly but the point here is that there is a problem in terms of how development is done and how *little* the maintainability of the code is. Hold your horses. There is an *Absurd* amount of difference between Cryptocat in October 2011 and today. You simply cannot compare the two codebases. They are completely different as Cryptocat was rewritten completely from scratch twice since 2011. The current codebase is, even if I do say so myself, modestly maintainable and well-documented. But really, bringing up the October 2011 codebase is really beside the point. I appreciate the rest of your post. Thanks for your input, David. NK Those guys (CryptoCat) are learning and getting experience to run such a security critical open source project over the year and this episode should be a good wake up call to understand what when wrong and how to improve the situation. Shit happens, now it's up to them to address this work flow issue and the community should help them like Tom did with that post! Else, I'm pretty sure we are going to see more and more of those bugs over the year if the upstream code is treated like a development branch and is not documented explaining the why of things to facilitate peer review and maintainability. My two cents! Cheers! David Tom Ritter: On 7 July 2013 17:20, Maxim Kammerer m...@dee.su wrote: This thread started off with discussion of peer review, so I have shown that even expensive, well-qualified peer review (and I am sure that Veracode people are qualified) didn't help in this case. As one of the people on this list who does paid security audits, I both want to, and feel obligated to, weigh in on the topic. I don't work for Veracode, I have done audits for projects in the LibTech space, I have not done one for Cryptocat. I would like to, and given enough free time might get around to it, but like _everyone_ in this space, doing something publicly and putting your name on it means holding yourself to a certain standard, and that standard requires time - a lot of time (on the order of 60-100 hours). A good security audit will give you two things. Firstly it will give you bugs. These bugs are usually constrained to issues that are security vulnerabilities (but not always depending on the issue/the auditor/the time available). We find these bugs through meticulous testing and reading source code (see the 60-100 hours), through checklists to make sure we don't omit anything (see https://github.com/iSECPartners/LibTech-Auditing-Cheatsheet for a Creative Commons version of mine), and through experience and hunches. Usually an audit is time boxed so we don't literally read every line - the 60-100 hours would balloon up considerably if it were the case. We read a lot of code, we see and find a lot of bugs. The best auditors are always reading about new bug classes and exploitation vectors so we can recognise these bugs when they are in new projects. The Cryptocat bug, using a random string (or decimal digits) instead of bytes - I've seen before, as most people in my company have. (Usually it's in the form of using a hexadecimal string instead of converting the hexadecimal into bytes.) I know Cryptocat has been audited by humans in this fashion before, I've read their report, and it found good bugs. Of course, no auditor is perfect - we never find every single bug that's in an application and we can never say something is 'safe'. Which is why we give you the second thing: We give recommendations for making your codebase better. In older, more mature codebases this usually takes the form of recommendations
Re: [liberationtech] DecryptoCat
So introductory-level programming course mistakes are right out. In my experience it's quite often a really simple mistake that gets you, even when you're an experienced programmer. I'm quite afraid of simple off-by-one bug, places which I didn't fix in copypaste, basic logic mistakes etc. IMO Nadim's main mistake wasn't the actual bug, mistakes like that can happen to anybody, but it was designing a really weird API that invites mistakes. Nobody sane return decimal digits from a cryptographic PRNG. For example a really basic cryptography mistake is reusing a nonce in AES-CTR. Still it happens to people experienced in both coding and cryptography. For example Tarsnap had since vulnerability for several versions, despite a competent developer. http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-security-bug.html In my own programs I'm really careful about nonces and randomness, but still I wouldn't be surprised if a trivial bug slipped through in that area. Writing tests which detect such mistakes is really hard. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On 2013-07-07, at 2:25 PM, CodesInChaos codesinch...@gmail.com wrote: So introductory-level programming course mistakes are right out. In my experience it's quite often a really simple mistake that gets you, even when you're an experienced programmer. I'm quite afraid of simple off-by-one bug, places which I didn't fix in copypaste, basic logic mistakes etc. IMO Nadim's main mistake wasn't the actual bug, mistakes like that can happen to anybody, but it was designing a really weird API that invites mistakes. Nobody sane return decimal digits from a cryptographic PRNG. That's not what the CSPRNG does exactly, but we routed it through an all-purpose function that wields it to present types of data on demand, be it random ASCII lowercase, random ASCII uppercase, random digits, random bytes. And then I messed up and asked it to produce random digits instead of random bytes and BOOM — security disaster, end of the world etc. For the record, I feel deeply ashamed about this blunder. But I can't give up this project simply because bugs like this are bound to pop up for any project with this kind of goals and ambition, and our goals are, in my view, deeply necessary. NK For example a really basic cryptography mistake is reusing a nonce in AES-CTR. Still it happens to people experienced in both coding and cryptography. For example Tarsnap had since vulnerability for several versions, despite a competent developer. http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-security-bug.html In my own programs I'm really careful about nonces and randomness, but still I wouldn't be surprised if a trivial bug slipped through in that area. Writing tests which detect such mistakes is really hard. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
Hello Nadim, Don't be ashamed. Shit happens. I hope you don't get frustrated by all this. Keep working. It's easy to criticize the work of others, but whats hard is believing in and developing a great project such as cryptocat. This kind of work is really important. Of course, we have to be careful with these things, but... Keep going ;) gpg --keyserver pgp.mit.edu --search-keys EEE5A447http://pgp.mit.edu:11371/pks/lookup?search=0xEEE5A447op=vindex From: na...@nadim.cc Date: Sun, 7 Jul 2013 22:34:24 +0200 To: liberationtech@lists.stanford.edu Subject: Re: [liberationtech] DecryptoCat On 2013-07-07, at 2:25 PM, CodesInChaos codesinch...@gmail.com wrote: So introductory-level programming course mistakes are right out. In my experience it's quite often a really simple mistake that gets you, even when you're an experienced programmer. I'm quite afraid of simple off-by-one bug, places which I didn't fix in copypaste, basic logic mistakes etc. IMO Nadim's main mistake wasn't the actual bug, mistakes like that can happen to anybody, but it was designing a really weird API that invites mistakes. Nobody sane return decimal digits from a cryptographic PRNG. That's not what the CSPRNG does exactly, but we routed it through an all-purpose function that wields it to present types of data on demand, be it random ASCII lowercase, random ASCII uppercase, random digits, random bytes. And then I messed up and asked it to produce random digits instead of random bytes and BOOM — security disaster, end of the world etc. For the record, I feel deeply ashamed about this blunder. But I can't give up this project simply because bugs like this are bound to pop up for any project with this kind of goals and ambition, and our goals are, in my view, deeply necessary. NK For example a really basic cryptography mistake is reusing a nonce in AES-CTR. Still it happens to people experienced in both coding and cryptography. For example Tarsnap had since vulnerability for several versions, despite a competent developer. http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-security-bug.html In my own programs I'm really careful about nonces and randomness, but still I wouldn't be surprised if a trivial bug slipped through in that area. Writing tests which detect such mistakes is really hard. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
I see a ton of people criticizing left and right, conveniently leaving out that this didn't apply to the OTR implementation. I don't see a lot of people producing more secure or as-easy-to-use alternatives, which presumably they're more than capable of. Criticizing is easy. It's okay to feel bad that you made a mistake, but you don't really have anything to answer for. You clearly stated that you shouldn't put your life on the line using cryptocat, and that not enough eyes had looked at it yet. For the open source vs. proprietary argument: Proprietary is clearly better, PR-wise at least, as long as you don't have enough eyes. Open source means nothing if you don't have more qualified good people looking at it than bad people. Virtually everyone in the history of cryptography engineering, as with software engineering in general, has made mistakes. Critics should lay off the holier-than-thou nonsense, and spend more time looking at the code so any outstanding issues can be fixed responsibly. On Sun, Jul 7, 2013 at 4:34 PM, Nadim Kobeissi na...@nadim.cc wrote: On 2013-07-07, at 2:25 PM, CodesInChaos codesinch...@gmail.com wrote: So introductory-level programming course mistakes are right out. In my experience it's quite often a really simple mistake that gets you, even when you're an experienced programmer. I'm quite afraid of simple off-by-one bug, places which I didn't fix in copypaste, basic logic mistakes etc. IMO Nadim's main mistake wasn't the actual bug, mistakes like that can happen to anybody, but it was designing a really weird API that invites mistakes. Nobody sane return decimal digits from a cryptographic PRNG. That's not what the CSPRNG does exactly, but we routed it through an all-purpose function that wields it to present types of data on demand, be it random ASCII lowercase, random ASCII uppercase, random digits, random bytes. And then I messed up and asked it to produce random digits instead of random bytes and BOOM — security disaster, end of the world etc. For the record, I feel deeply ashamed about this blunder. But I can't give up this project simply because bugs like this are bound to pop up for any project with this kind of goals and ambition, and our goals are, in my view, deeply necessary. NK For example a really basic cryptography mistake is reusing a nonce in AES-CTR. Still it happens to people experienced in both coding and cryptography. For example Tarsnap had since vulnerability for several versions, despite a competent developer. http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-security-bug.html In my own programs I'm really careful about nonces and randomness, but still I wouldn't be surprised if a trivial bug slipped through in that area. Writing tests which detect such mistakes is really hard. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On Sun, Jul 7, 2013 at 3:25 PM, CodesInChaos codesinch...@gmail.com wrote: So introductory-level programming course mistakes are right out. In my experience it's quite often a really simple mistake that gets you, even when you're an experienced programmer. I'm quite afraid of simple off-by-one bug, This thread started off with discussion of peer review, so I have shown that even expensive, well-qualified peer review (and I am sure that Veracode people are qualified) didn't help in this case. There is a misconception as to what peer review is supposed to achieve, and what it can't deal with, and I believe this misconception is similarly true for both academia and engineering. Academic peer review is not supposed to deal with fraud. Engineering peer review will have a hard time dealing with incompetence (unless talking about a specific notion of peer review where e.g. a team lead seats with a junior programmer, closely reviewing every commit after thorough discussion). The examples you have given are either algorithmic mistakes (nonce reuse) or frequent mistakes due to lack of attention (off-by-one). Both can be handled with during peer review — expert analysis in the first case, and e.g. automatic static analysis using proprietary tools and extensive testing in the second case (which I guess was partly what Veracode did). But if you do something stupid, peer review probably won't help, unless the reviewer is ready to do something akin to implementing everything from scratch himself, and thoroughly comparing the implementations. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On 07/07/2013 05:20 PM, Maxim Kammerer wrote: On Sun, Jul 7, 2013 at 3:25 PM, CodesInChaos codesinch...@gmail.com wrote: So introductory-level programming course mistakes are right out. In my experience it's quite often a really simple mistake that gets you, even when you're an experienced programmer. I'm quite afraid of simple off-by-one bug, This thread started off with discussion of peer review, so I have shown that even expensive, well-qualified peer review (and I am sure that Veracode people are qualified) didn't help in this case. Paying a company to do an audit (or getting one for free) is not peer review. The link that started off the thread is an example of peer review. And an inexpensive one at that. :) -Jonathan -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On 7 July 2013 17:20, Maxim Kammerer m...@dee.su wrote:
This thread started off with discussion of peer review, so I have
shown that even expensive, well-qualified peer review (and I am sure
that Veracode people are qualified) didn't help in this case.
As one of the people on this list who does paid security audits, I
both want to, and feel obligated to, weigh in on the topic. I don't
work for Veracode, I have done audits for projects in the LibTech
space, I have not done one for Cryptocat. I would like to, and given
enough free time might get around to it, but like _everyone_ in this
space, doing something publicly and putting your name on it means
holding yourself to a certain standard, and that standard requires
time - a lot of time (on the order of 60-100 hours).
A good security audit will give you two things.
Firstly it will give you bugs. These bugs are usually constrained to
issues that are security vulnerabilities (but not always depending on
the issue/the auditor/the time available). We find these bugs through
meticulous testing and reading source code (see the 60-100 hours),
through checklists to make sure we don't omit anything (see
https://github.com/iSECPartners/LibTech-Auditing-Cheatsheet for a
Creative Commons version of mine), and through experience and hunches.
Usually an audit is time boxed so we don't literally read every line
- the 60-100 hours would balloon up considerably if it were the case.
We read a lot of code, we see and find a lot of bugs. The best
auditors are always reading about new bug classes and exploitation
vectors so we can recognise these bugs when they are in new projects.
The Cryptocat bug, using a random string (or decimal digits) instead
of bytes - I've seen before, as most people in my company have.
(Usually it's in the form of using a hexadecimal string instead of
converting the hexadecimal into bytes.)
I know Cryptocat has been audited by humans in this fashion before,
I've read their report, and it found good bugs. Of course, no auditor
is perfect - we never find every single bug that's in an application
and we can never say something is 'safe'. Which is why we give you
the second thing:
We give recommendations for making your codebase better. In older,
more mature codebases this usually takes the form of recommendations
like Everywhere you do file handling is wrong, and you need to
centralize it, fix it in the centralized version, and make sure
everyone uses that going forward. Those are the straightforward
ones. Sometimes they're more defensive, like You really like to use
the php system() function for doing stuff like removing files from the
filesystem and chmodding. You do really meticulous character
escaping, so we couldn't get command execution - but nonetheless, you
should really use the unlink() and chmod() functions, so you can be
sure a bug never makes it's way in.
Now those are pretty obvious examples. In a project where the
developers are making every effort they can to lock things down, where
they're making every effort to do things 'right' - if we still can't
provide examples, we're not doing a very good job.
There are a lot of defense in depth measures that can be applied to
web applications. Request preprocessors can look for global IDs, and
assert that the current session can access that object (in *addition*
to the page-level checks on object access). Database query logging
can assert that all queries that go into particular tables use a
certain column in the WHERE clause. I can go on and on. A good
source of these is an ex-coworker's talk Effective approaches to web
application security
http://www.slideshare.net/zanelackey/effective-approaches-to-web-application-security
(honestly, Etsy is driving the industry forward with their techniques
for proactive web app security.)
Defense in depth lends itself very easily to 'classically' exploitable
conditions around things like Cross Site Scripting, Direct Object
Reference, Command Injection, Code Execution. Weak RNG and
fundamental protocol flaws are much harder to talk about in terms of
defense in depth.
So, not avoid the hard problem, let's take this particular bug. What
I would say is MOAR ABSTRACTION. Now, I'm not actually a fan of
abstraction, I hate seeing a ton of one-line functions, but in this
case, to prevent a bug like this from happening again, I would
structure the code like this (taking into account I'm really bad at
naming things):
//rng.ext
///This class is a CSPRNG that outputs a stream of random bytes
class RandomNumberGenerator {
}
//rng-types.ext
///This class outputs a random stream of the specified type
static class RandomSequences {
///Return a random upper,lowercase alphabetic string
static string RandomAlphaString() ...
///Return a random sequence of base 10 digits
static string RandomDigits() ...
///Return a random sequence of bytes
static byte[] RandomBytes() ...
}
//rng-objects.ext
///This class produces a specific
Re: [liberationtech] DecryptoCat
On Thu, Jul 4, 2013 at 12:36 PM, KheOps khe...@ceops.eu wrote: Just came accross this: http://tobtu.com/decryptocat.php Any comment? Clearly false, since Cryptocat earned “[leading application security team] Veracode Level 2 classification highlighted by a Security Quality Score of 100/100” [1] during the related time period. So introductory-level programming course mistakes are right out. [1] https://blog.crypto.cat/2013/02/cryptocat-passes-security-audit-with-flying-colors/ -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
On Thu, Jul 4, 2013 at 11:36 AM, KheOps khe...@ceops.eu wrote: Just came accross this: http://tobtu.com/decryptocat.php Eep! It seems like the saying given enough eyeballs, all bugs are shallow has become obsolete, huh? Peer review is an integral part to developing secure cryptography implementations, but unfortunately this fundamentally crashes with the hacker mantra of just do it. It's a shame that this project did not get this kind of attention until after people started relying on it---that could have saved a lot of people from a lot of shouting in any case. So what do we do about this? Opening the source code as an argument for security no longer suffices. How can we raise money for rigid and independent quality assurance of software that in this case is designed to potentially saving lives? And how can we make sure that this money flows into the fund and out to the QAers on a regular basis? I don't know, sadly, but I'd love to discuss it. JC -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
Hello everyone, I urge you to read our response at the Cryptocat Development Blog, which strongly clarifies the situation: https://blog.crypto.cat/2013/07/new-critical-vulnerability-in-cryptocat-details/ Thank you, NK On 2013-07-04, at 12:18 PM, Jens Christian Hillerup j...@hillerup.net wrote: On Thu, Jul 4, 2013 at 11:36 AM, KheOps khe...@ceops.eu wrote: Just came accross this: http://tobtu.com/decryptocat.php Eep! It seems like the saying given enough eyeballs, all bugs are shallow has become obsolete, huh? Peer review is an integral part to developing secure cryptography implementations, but unfortunately this fundamentally crashes with the hacker mantra of just do it. It's a shame that this project did not get this kind of attention until after people started relying on it---that could have saved a lot of people from a lot of shouting in any case. So what do we do about this? Opening the source code as an argument for security no longer suffices. How can we raise money for rigid and independent quality assurance of software that in this case is designed to potentially saving lives? And how can we make sure that this money flows into the fund and out to the QAers on a regular basis? I don't know, sadly, but I'd love to discuss it. JC -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
Jens Christian Hillerup j...@hillerup.net writes: So what do we do about this? Opening the source code as an argument for security no longer suffices. How can we raise money for rigid and independent quality assurance of software that in this case is designed to potentially saving lives? And how can we make sure that this money flows into the fund and out to the QAers on a regular basis? For what it's worth: OpenITP's Peer Review Board [1] is intended to help with exactly this. It's under development; Eleanor Saitta on this list can give a better sense of where things stand at this point, but I wanted to let you know the effort is under way. By the way, I don't agree with the original blog post's [2] ad hominem remarks about Cryptocat's developers. The most popular programs are always where people are most excited to find bugs. It's therefore hard to compare Cryptocat's development against that of other security projects, given that many of those projects are not as popular as Cryptocat -- in other words, it's hard to establish what the baseline is or should be. So I wish people would be more circumspect about flinging around words like incompetent; it just sets a bad tone and doesn't help anything. Cryptocat's response [3] is exemplary. -Karl [1] http://wiki.openitp.org/peerreviewboard:start [2] http://tobtu.com/decryptocat.php [3] https://blog.crypto.cat/2013/07/new-critical-vulnerability-in-cryptocat-details/ -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] DecryptoCat
I think he missed a prime opportunity to call his post DecipherDog ;-) ~Griffin -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
