Edward Snowden: The Internet Is Broken

He's still not getting it or fully recommending it any more than most have. The funny thing is that I recently read a 150 page interview with one of founders of INFOSEC, Dr Schell, that showed his employer was the same way: ignored "COMPUSEC" as useless in favor of "COMSEC" solutions to all security problems. Schell, Karger, and Anderson's tiger teams smashed every mainframe and crypto using system put in front of them due to hardware and software bugs. They bypassed it.

Like Schell and Karger said for 30 years, what we need is to start deploying high-assurance security practices, protocols, systems, methods... everything that's proven to get the job done in various ways. We need them deployed pervasively. More private protocols and encryption by default, too, but who gives a shit if it runs on systems so insecure it doesn't need backdoors?

Let's go back to 1960's moving toward the 70's and 80's on hardware stuff. Burroughs stuff was tagged so everything in memory was code or data, pointers protected, arrays bounds-checked, arguments checked on function calls, and OS tried to isolate apps from each other. Some LISP machines had GC's for memory management. System/38 had capability-security & built-in database. Solo had safe concurrency at OS level. One had read-only firmware you couldn't change without physically moving it with a nucleus that handle protected functions that OS's built on. Two implemented a secure, Ada runtime that enforced the language's safety properties. SAFE (crash-safe.org), Cambridge's CHERI, and Sandia's SSP/Score processors follow these traditions.

Now let's look at how Schell et al said to do assurance. Precise, math/flowcharts/whatever description of functional and security requirements to avoid ambiguities & resulting vulnerabilities. Similar for design with attention to simplicity. Implementation in safest language you can with simpler subset and style easy to analyze. Every module proven to match a requirement/spec so no subversion (well, a start on it...). Strict modularity, layering, and interface checks all over the place. Success and failure states modeled then shown to follow a precise, security policy. If you can't state it precisely, then you can't secure it because you don't know what security means for you. Code review, tests of each function, formal proofs if possible, static analysis if possible, covert channel analysis of info flows, configuration management that assumes malicious developers, source to object code verification, trusted distribution of HW/SW to customers, onsite verification/generation from source, and configuration guidance. All of this independently verified by at least one set of professionals that know what they're doing.

That was security in 1970's-1980's. Far from red tape some here claim, every method above was proven by researchers, field users, and pentesters to catch serious problems. The only dispute was what caught most and where to spend most money. Even those questions had decent answers. Well, plus specific design and modeling decisions but INFOSEC was in infancy & that was evolving. I'm talking assurance activities: getting it done right whatever it is. Fast forward today to find that all the problems Schell, Karger, etc predicted have happened and consistently in systems that don't use those methods whereas systems that do avoid many more problems.

So, here's the solution: raise assurance of our systems across the board using methods that go back to 1961. That's right, Burroughs engineers were doing a better job on security before that was even a thing just trying to improve reliability. This is 2016. We have better specs, better languages, better static analysis, easier formal tools, automated test generation, tons of sample code, fast dev machines... you name it. There's no excuse, outside willful ignorance or apathy, for security-focused developers (esp in FOSS) to not use everything at their disposal that's proven to work at reducing risk. Even less excuse for the stuff they make to still be less secure than tech from the friggin 60's and 70's.

Shout out to the exceptions that are trying to do it right. Groups like GenodeOS, Dresden, NICTA/OKL4, Carlisle's IRONSIDES DNS, Bernstein's stuff, Galois, JX OS, ETH, INRIA, Secure64, Sentinel HYDRA (minus bodacion crap lol), Combex, and even NativeClient since they knocked off OP browser. Enough stuff like this and NSA will be begging us to ban INFOSEC books and shit since their info will dry up haha.

Yeah, he's full of it. We in high-assurance community and even the cypherpunks have been telling people forever it was being abused. Because people were abusing it and its design practically asked for it. These were ignored as externalities by people motivated by convenience, feature bloat, price, and/or profit. Even getting it down to almost identical cost/speed didn't help if it lacked unnecessary feature X.

This was censorship by business and security communities plus apathy by consumers. Plain and simple. The business communities didn't want to spend crap on INFOSEC. The ones that did faced two obstacles: (a) low volume meant real deal was ridiculously expensive with slower development; (b) mainstream INFOSEC conned companies with bandaids or fake security because they made more money that way. Constantly charging to fix problems they left in or upgrades people didn't need.

So, result was everything is shit security and stays that way. Neither proprietary nor FOSS learn from lessons 99% of the time. All due to what Schneier always called "perverse incentives" that keep bad stuff produced.

TrueCrypt has been subjected to an independent security audit. As have successors like VeraCrypt. Any alternatives likely haven't.

"Without Stallman's foresight of the need for public domain open source software, there would only be proprietary software, all subject to PRISM."

Or proprietary, shared-source software provided by nonprofits or companies in jurisdictions that aren't surveillance heavy. No, you don't need FOSS to avoid PRISM lol. It has its advantages in resisting totalitarianism for sure but you don't actually need them. More of author or organization's intent and licensing that really matters. Many models available.

Btw, the first, secure-ish mainframe OS (MCP of Tron fame) was sold in source form by Burroughs with fixes/updates allowed to be submitted. In 1963. High-assurance stuff under Orange Book similarly had to deliver source that was reviewed and provided a way to know you had same copy. Just to support my claim that there's proprietary models for it but most just wanted money instead. ;)

We didn't know but it wasn't paranoid to assume it. The reason was the Echelon leaks and what was done about those. The answer: nothing.