3 ms·

We certainly share an interest. > Yet, the Tor project themselves answer this one: it's vulnerable to a global, passive adversary. Vulnerable to traffic analy

• nickpsecurity 10y ago
  "Vulnerable to traffic analysis, I'm sure certain organizations wouldn't mind seeing that vulnerability include cleartext." Well, certainly. Depends on what this guy's role is supposed to be in the organization. One can always relegate the riskier people to stuff that can't harm them much. In any case, NSA can already do what you mentioned given leaks mention active targeting. Catalog includes regular malware, 0-days on stuff, and implants. Tor is the LTD they aim at themselves with optional LGB's following from QUANTUM and such. So, it would be a matter of already-vulnerable people or services getting more so. "I've never seen an Underhanded Ada Contest, but I'm pretty confident that a bad actor could still introduce vulnerabilities that would pass a reasonable code review and be deniable" Well, sure. Just remember, though, that what you're saying already applies to the Tor project. Any of the contributors, maintainers, relay hosts, and so on might be malicious. That's why A1 class called for protection throughout whole lifecycle which my framework below expanded on. SAP security guides showed most areas requiring protection. Examples below: http://pastebin.com/y3PufJ0V http://pastebin.com/y3PufJ0V http://www.dss.mil/documents/odaa/nispom2006-5220.pdf http://www.dss.mil/documents/odaa/nispom2006-5220.pdf Now, from here, we have to ask what can be done to mitigate potential exploits. Well, we know the protocol itself is subject to strong, peer review by parties more than willing to publish problems and organization that corrects them. The main problems occur in crypto libraries, protocol engines, interfaces, type checks, memory errors, parsing, handling time, and error handling. A type-safe, memory-safe, low-level language along lines of Ada/SPARK, Go, Rust, or Modula-3 plus specific libraries and guidance on aforementioned can knock out vast majority of the risk. Well, that along with parser/protocol generators already available in academia with hand-checked code and design-by-contract to encode constraints. OpenBSD people probably do considerably more work on their code than what would be necessary to take care of this in safer language while focusing on areas most likely to be hit. So, I think we can get plenty mileage without full, formal verification. There will be flaws just as there are in protocol itself. Yet, it will work most of the time with people finding problems so long as plenty are on it motivated to do so. " I think a good half measure would be: fully spec'd pure functions don't need human code review - just feed patches to the theorem prover and regression tester, all the trusted human labor can then focus on things that touch global state." They still need review. You have to specify what you're going to do, what security properties it maintains, how it maintains that, and the implementation correspondence. Usually also show compiler didn't screw it up. That's tricky. Pure functions are fine but covert channel analysis means it's going to be an imperative language for final implementation. Old model was basically decomposing functional components into state machines representing every permissible state. Can check by eye that they either should work securely or fail-safe. Still keeping my eye out for CompSci tech that can derive imperative from simple, functional languages in human-readable form. "Thought getting people to trade C performance was tough? Try getting them to intentionally delay all comparison operations... in the entire software stack :)" Oh my god, I've been there. Mainstream INFOSEC totally ignored that problem saying it was unnecessary until recently rediscovering it under "side channel" label. Running wild with it. I called out Freenet on Schneier's blog as probably having plenty due to use of Java. Meanwhile, old methods of handling timing channels were reducing precision, fixed-rate, maximum-time, turning off caches (extra painful on Core i7), masking, and my favorite being asynchronous, randomized execution. I was going to put the latter in a CPU then found someone else already did that. Clever. Partitioned caches are another popular strategy. I just stick with Red/Black model in my designs with trusted part being dedicated chip with timing mitigation for just needed part. Still performance hit no matter what. Anyway, I did a write-up for someone on how to secure a service like Tor here: https://www.schneier.com/blog/archives/2014/09/identifying_dre.html#c6678915 https://www.schneier.com/blog/archives/2014/09/identifying_d...
  • woodman 10y ago
    > In any case, NSA can already do what you mentioned given leaks mention active targeting. I see it as a massive difference: dragnet scope, loss of forward security due to precomputed magic numbers, etc. While the threat is hypothetical, unlike traffic analysis and active targeting, the consequences elevate it to a point where it deserves its own consideration. > ...on aforementioned can knock out vast majority of the risk. I'm usually a one bite at a time sort of guy when it comes to eating elephants, but I think a language switch should bring a little bit more benefit - especially considering the unsolved compiler optimizing security away problem (outside of language subsets enforced by self discipline). It is dangerous, and it has led to the slow death of many projects, but I'd recommend some time spent on custom tooling. The furthest I'd suggest would be language extensions, likely implemented as external llvm modules, nothing crazy - retaining array size metadata in function arguments instead of throwing the information away. ACSL for contract specification would be nice, or at least fix frama-c so that it isn't so awful. > They still need review. You have to specify... I was speaking of implementation changes to already specd functions, but after further consideration I want to double down. Any changes to code further down stream of well specified functions shouldn't need code review. That wouldn't be a very good way to go about it, one massive function specification instead of a composition, but it would still be secure. > ...covert channel analysis means it's going to be an imperative language for final implementation. Yeah I didn't mean a functional language like haskell, as I've yet to write any production quality code in it after several years of trying... I was thinking more along the lines of the function __attribute__((const)). This might make my no review suggestion not work, but that custom tooling might be able to help with detecting information leaks through variable loop iteration counts. Lots of ways to tackle the problem. > Mainstream INFOSEC totally ignored that problem... I can sympathize, I recognize it as a problem - and I try not to think about it because it makes me very sad.
    • nickpsecurity 10y ago
      "the consequences elevate it to a point where it deserves its own consideration." Well, it does but maybe not here. Let's remember the situation. The consideration is only applying because a person openly said they're ex-CIA. So, we apply these considerations when people say that. Result? Instead of risk going away, they just stop saying they're ex-CIA. Maybe start talking about privacy, crypto, Anonymous, blockchains, and so on. Infiltration 101 applied to Tor project. Filtering out anyone claiming to be ex-government doesn't filter out ex-government except for those specific cases. This level of consideration, if infiltration risk is high, has to be all or nothing. "The furthest I'd suggest would be language extensions, likely implemented as external llvm modules, nothing crazy" It's a reasonable proposition. I considered something like Cyclone, a security-aware scheme for managing heap, and with JIF-style labels for information flow. Might knock out a lot of problems while keeping code mostly the same and able for C programmers to handle. https://en.wikipedia.org/wiki/Cyclone_(programming_language) https://en.wikipedia.org/wiki/Cyclone_(programming_language) https://www.cs.cornell.edu/jif/ https://www.cs.cornell.edu/jif/ " Any changes to code further down stream of well specified functions shouldn't need code review. " This is ambiguous. Are you saying that, with how they all interface, that any changes to lower-level functions should preserve interface invariants enough that higher-level stuff shouldn't have to be re-reviewed? If so, that would be reasonable. If not, please elaborate.