Moxie Marlinspike

I trust Moxie more than governments or companies, so this really makes me happy. If you've read things on his website (http://www.thoughtcrime.org) you'll know how important remaining secure from the government is to him. This is a huge step in the right direction. I'd also like to congratulate WhatsApp on their decision, I have a lot more respect for them now. Congrats Moxie and team. You guys are doing a great thing for humanity.

Moxie on GPG: > The protocol reflects layers of cruft built up over the 20 years that it took for cryptography (and software engineering) to really come of age, and the fundamental architecture of PGP also leaves no room for now critical concepts like forward secrecy. [0] > We could try to slap a GUI on top of it, but I don't believe great products are made that way. Good UX requires thinking about interactions all the way down to the protocol. [1] [0] http://www.thoughtcrime.org/blog/gpg-and-me/ [1] https://news.ycombinator.com/item?id=9104562

The Cryptographic Doom principle strikes again! http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/ The article refers to it more precisely as "similar to the padding oracle attack discovered by Vaudenay", but this root problem -- malleability -- keeps coming up so often even in relatively mature attempts at crypto that the appeal-to-emotion "Doom" name seems worth using.

GnuPG is great, but it is not for real-time messaging. Real-time messaging protocol should have forward secrecy, which OpenPGP can't have because it is not an interactive protocol. Related: http://www.thoughtcrime.org/blog/gpg-and-me/

>Most acquaintances ... just don't care "as long as I'm safe". Moxie Marlinspike wrote a great blogpost 2 years ago titled "Why we should all have something to hide". [0] I suggest that you read it so that you have some ammunition against those who are uninformed about why their privacy matters so much in the future. [0] http://www.thoughtcrime.org/blog/we-should-all-have-something-to-hide/

Can we please stop decrying black hats without nuance? Because that whole "CMU is blackhat now" thing? That's not what happened here. Selling exploits exclusively to assist the government is very much like a large swath of white hats. What do you think Infragard is? It's Feds rubbing elbows with crooked pro-government technologists. But they're the white hats, remember. At the end of the day, you only have green hats (the color of money), and people who don't wear hats at all. The black/white distinction has become meaningless. Recommended reading: http://www.thoughtcrime.org/blog/saudi-surveillance/

In case you hadn't noticed, the authenticity model of SSL was an afterthought and is completely broken. I recommend listening to Moxie's talk about this: https://www.youtube.com/watch?v=pDmj_xe7EIQ http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/

as linked elsewhere in the thread, moxie offers an excellent explanation: http://www.thoughtcrime.org/blog/telegram-crypto-challenge/

Moxie is a fellow of the Foundation: https://www.shuttleworthfoundation.org/fellowship/fellows/current-fell… But it appears he personally only "helps" Open Whisper Systems: http://www.thoughtcrime.org/blog/we-should-all-have-something-to-hide/ "I help work on Open Source security and privacy apps at Open Whisper Systems" On more accurate side, see also 2013 report of Open Technology Fund which granted 445K USD directly to the Open Whisper Systems in 2013.

Moxie's criticism of portknocking implementations [1] has several facets that apply to fwknop. I would not recommend using fwknop in general. Unrelated to security, but practical experience from using fwknop in the past: port-knocking tools that depend on timestamped packets are a great way to get locked out of your server if you have time skew between server and client. EC2 instances will drift a lot over their lifetime, so if you're not running NTP you will likely eventually fall outside the portknocking implementation's grace period, and then be unable to access your server at all, short of rebooting it or figuring out how skewed the clock is. Not fun. [1] http://www.thoughtcrime.org/software/knockknock/

I see no mention of Google Sharing, which is interesting, cuz I have been using that for two or more years now. Just do not use the default googlesharing.net. The link says it is gone, but in fact is now corporately owned for what I imagine what the original intent was trying to prevent. https://addons.mozilla.org/en-US/firefox/addon/googlesharing/reviews/5… It was originally a Moxie project, I would love if he said why he stopped pushing it. Maybe it is a drop in the bucket. http://www.thoughtcrime.org/software.html

It's actually an app with no clear business model based on archaic security primitives chosen by recent math grads who "know best" even though virtually every crypto engineer or cryptographer that has looked at the code has advised them to not make a custom protocol, but just use something that works. http://www.thoughtcrime.org/blog/telegram-crypto-challenge/

Exactly, though depending on the subject's intelligence I also like to provide Moxie's excellent post [0]. [0]: http://www.thoughtcrime.org/blog/we-should-all-have-something-to-hide/

DANE isn't without its own problems. Moxie Marlinspike wrote an excellent blog post about it. http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/#d…

Do you have anything on certificate verification? Not that I actually know anything about it, but.. here, I think these words from Moxie Marlinspike about sum it up: "I’m not actually a supporter of the general adage “never roll your own crypto.” I believe that cryptography is a fairly closed system, and that it’s relatively straightforward to learn how to carefully use cryptographic primitives to build protocols securely. Certificate validation, on the other hand, is something that I would recommend people avoid doing themselves, if possible. It’s mired in cruft and gotchas."[1] Moxie covers a few examples in the link, but it would be interesting to see some more along those lines. [1] http://www.thoughtcrime.org/blog/strongtrustmanager-mitm/

Funny enough, logging in to Evernote was the first thing I did after laying in bed spending 1hr+ watching this amazing video about http/https man-in-the-middle attacks using sslstrip http://www.thoughtcrime.org/software/sslstrip/ . Not a good way to start my morning.

This post is the third installment of a special Hn series on optimizing your material possessions. Optimize for Quality: http://dcurt.is/the-best Optimize for Experience: http://www.thoughtcrime.org/blog/the-worst/ Optimize for Utility: http://teddy.fr/2013/02/10/about-not-owning-shit/

Moxie, I read your "Money Machine"[1] in print and loved it. After becoming aware of your security work and browsing your website, I discovered you are the author. Small world. My partner and I often fall asleep together listening to "Letters of Insurgents". Thank you for that! [1] http://www.thoughtcrime.org/stories/money-machine/

Moxie Marlinspike has an excellent argument that DANE doesn't make the problem better, it makes it worse, by concentrating all power in the hands of a single third party. http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/

Moxie Marlinspike wrote a great blog post about this: http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/

A long time ago I used to have a general purpose server on a DSL line with port 22 open. I thought everything was fairly secure, patched up, etc... I never thought brute forcers would be able to guess one of my accounts (which was a friend's account actually). The kicker? The password was the username. I found out about the rootkit a few days after they got in. I tell ya, kids these days just don't know how to hide a backdoor. A really good port knocker is your best defense against rogue attackers of an external service (because there is no defense against a 0-day). For an iptables-supported system I recommend Knockknock by Moxie Marlinspike (http://www.thoughtcrime.org/software/knockknock/).

Some smart-ass made the comment on the article: "I feel bad for that animal on his head." EDIT: Marlinspike's web-page ( http://www.thoughtcrime.org/ ), for those interested in making non-smart-ass comments. :)

That's Moxie Marlinspike, great hacker who had some recent SSL findings: http://www.thoughtcrime.org/papers/null-prefix-attacks.pdf and http://www.blackhat.com/html/bh-usa-09/bh-usa-09-archives.html#Marlins… http://www.defcon.org/html/links/dc-archives/dc-17-archive.html#Marlin…

I don't see why this is modded down. /menu.gpxe seems to be the entry point. Looking at that page shows us that /menu.cfg is the next hop, which points directly to kernel inages, such as /3018/boot.gpxe. I don't see anything that would allow you to authenticate netboot.me in these files, and given the recent null-prefix flaws in SSL (linked from http://www.thoughtcrime.org/software/sslsniff/), I wouldn't feel confident that the netboot code has got SSL implemented correctly, if it's even used for netboot.me. I would consider MITM attacks on netboot.me to be worthy of investigation before using netboot.me, especially if they add WiFi support. The gPXE security page (http://www.etherboot.org/wiki/safebootmode) seems to indicate that security for gPXE in general is a work in progress.

http://www.thoughtcrime.org/blog/lavabit-critique/ The whole thing is worth a read but here's the gist "Unlike the design of most secure servers, which are ciphertext in and ciphertext out, this is the inverse: plaintext in and plaintext out. The server stores your password for authentication, uses that same password for an encryption key, and promises not to look at either the incoming plaintext, the password itself, or the outgoing plaintext. The ciphertext, key, and password are all stored on the server using a mechanism that is solely within the server’s control and which the client has no ability to verify. There is no way to ever prove or disprove whether any encryption was ever happening at all, and whether it was or not makes little difference... The operator can at any time stop averting their eyes, an attacker who compromises the server can log the password a user transmits, and an attacker who can intercept communication to the server can obtain the password as well as the plaintext email."

The proposal for forward secrecy in the spec (https://darkmail.info/downloads/dark-internet-mail-environment-decembe… is not great and does not reflect the current state of the art: > PFS for message objects, as the description above suggests, is far more difficult, and contrary to the nature of email. It recommends just rotating public keys every few days with a paranoid mode. A much better solution is to implement the Axolotl Ratchet pioneered by Open Whisper Systems for TechSecure: https://www.whispersystems.org/blog/advanced-ratcheting/ https://github.com/trevp/axolotl/wiki With Axolotl Ratchet, you get: * forward secrecy - disclosure of private keys doesn't let an attacker in the future go back and read encrypted communication * future secrecy - disclosure of ephemeral private keys doesn't disclose (much) future content I also get the feeling from a glance reading the spec that way too much trust is being placed on service providers. That there is even such a category as "trustful" where the server has access to your private keys is a huge red flag and that was exactly the problem with lavabit: http://www.thoughtcrime.org/blog/lavabit-critique/

> DNSSEC does one task extremely well – but it does only this one task: DNSSEC ensures that the information the operator of a domain[..] put into DNS is the exact same information that a user gets out of DNS when they request info for a domain. Even this is not true. DNSSEC is an abysmal protocol. To quote from [1]: DNSSEC suggests a complicated mechanism to essentially re-create many of the same problems with X509 and CAs in DNS itself, by providing a chain of trust to untrustworthy entities. Its intended goal is to secure DNS and thereby assure clients that when they ask for apple.com, they are actually visiting apple.com. This proposal does not protect against MITM attacks [2]. It suffers from extreme and unnecessary complexity, a systemic fault that's antithetical to secure systems. See also this list of resources on why DNSSEC is considered harmful [3]. [1] http://okturtles.com/#oktvs [2] http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/ [3] http://ianix.com/pub/dnssec-outages.html

> mixing of HTTP/HTTPS content This is ALWAYS a bad idea. A few points: - The only purpose of HTTPS and encrypting communications in general is to prevent MITM attacks. - If your server is even willing to serve unencrypted requests it exposes your users to sslstrip attacks (http://www.thoughtcrime.org/software/sslstrip/). In reality you still should serve HTTP requests but only to force a redirect to HTTPS. In addition you should use the 'Strict-Transport-Security' header. It's the ONLY way to prevent future sslstrip attacks. - Even worse, if you don't set the 'secure' flag on session cookies at a minimum (thus forcing logged in users to HTTPS only) you expose your users to session hijacking without even putting up a fight. - If you aren't going to bother with forcing HTTPS all the time then there's not much point as you've opened up your users to simple sslstrip attacks followed by session hijacking or even worse, script injection or redirects. One fundamental concept many people seem to forget as well is that the dangers of not encrypting communications extends beyond snooping. Attackers can actually modify the data stream to inject and/or replace content or even redirect users entirely. Also, even if you only serve secure content yourself but you include insecure content on your page it exposes security vulnerabilities. Let's say you include unencrypted images on your site and you have users that are using a client with an image rendering engine vulnerability that…

Vuln reward programs that payout at this level are broken. 1) They don't achieve their objective of securing a product. Moxie eloquently captured why here: http://thoughtcrime.org/blog/telegram-crypto-challenge/ 2) At this level of payout, they are inefficient and unsustainable. There were less expensive ways to discover implementation flaws, and certainly more direct ways to discover design flaws. Was the lesson they just learned really worth $100 grand from some random dude on the Internet? Seems to me you could find more problems per dollar by directly engaging with some of the top class security consultancies out there. So to summarize, telegram's reward was an extremely inefficient stunt that did not achieve it's likely real objective. I imagine the team is licking it's wounds right now and regretting their approach. We'll be able to tell by whether or not they continue their offer under the same rules and same budget. I expect this to continue for another couple of rounds because random security people on the Internet will be smelling blood right now.