So RMS was right after all, OpenSource gives you visible security where proprietary products are encumbered with all sorts of unwated and even dangerous "features".
my 2c
my 2c
I know it is not perfect (you still have to trust the AMD chips and so forth) but it seems a lot better than just buying a linksys and hoping it works with OpenWRT.
Since the “detection” I’m referring to is already extremely difficult before the chip even leaves the legitimate chip manufacturer’s facility, what hope could someone have of opening a modern IXP-scale router and determining if any of the zillion chips inside has been trojaned by double-0-mailman?
How do your comments in this thread relate to the fact that nothing can ever be perfect, and different degrees of sophistication in security can only ever reduce the probability of an attacker's success, or the percentage of attackers that make it through everything?
Take DHKE. It "defends" against MITM. But it doesn't strictly prevent it. An attacker could perform the protocol with both Alice and Bob separately, then guard the line and tamper with any communications on that channel that attempt to confirm the shared secret. The attacker couldn't win against a determined Alice and Bob, though, because A&B could theoretically use other channels, or even publicly broadcast some confirmation of the shared secret. So the smart attacker is "probably discouraged" from the noisy MITM.
But how many key exchange implementations actually use separate (availability ensuring) channels to confirm no one is in the middle? It's prohibitively expensive to verify no one's attacking something that no one ever attacks.
But then again, things no defender verifies are attractive to attackers. And some attackers are willing to get noticed 9 times out of 10 to land the one payout. "Tolerance for getting caught" is not always zero, that's another variable that complicates our Nash equilibrium here...
On the one hand, yes: keeping security out of the middle of the network and pushing it to the endpoints is something that The End To End Argument In System Design predicted several decades ago, and is (to my eyes) clearly the right design principle for this problem.
On the other hand, the endpoints doing the encryption are also going to be COTS equipment sourced from major industrial centers and acquired at a scale that probably precludes individual hardware verification, at least at the price point that enables their widespread deployment today.
Adding unique delay variance patterns for packets from a specific set of packets (source address, payload type etc). This makes it easier to detect and follow interesting traffic.
You can also copy certain packets, divert packets, inducer errors (to cause resend that in turn triggers repetitions in higher layers that might be usable for info leakage from the protection mechanism.
The router really is your friendly, silent mitm helper gnome.
Of course not. Just a small handful of people would have to scrutinize it and keep up a credible threat of catching out any skullduggery. These things are mass produced. The efficiency benefits of design-once/copy-many also translate into audit-once/benefit-many.
NSA has a program of intercepting shipments to targets and silently replacing the gear with identical (but backdoored) equipment. There's even a catalog of the equipment they have ready-made replacements for and a price sheet (presumably for internal cost accounting) that leaked a few months ago.
Like many private-sector security consulting companies, they also do security research - looking for vulnerabilities accidentally left behind by naive programmers. They leaked a catalog of exploits written for vulnerabilities discovered (or bought) but not disclosed. Failure to disclose these is a violation of its mission to protect the security of US infrastructure, but I can't say I'm surprised that an intelligence agency that pays hackers has some exploits to show for it.
Aside from doubt cast onto the validity of NSA's advice on cryptography standards, there is not evidence that NSA actually introduces backdoors into the design of mass-produced products.
If you're not interesting enough for the NSA to physically intercept your package from, say, Cisco, (or, for the more cynical, ask Cisco to put the "special" version of IOS on your router) your inspection of the gear says nothing about what's running on an apparently identical unit headed for a foreign government.
Granted, "only" targeting a handful communications companies may well give them access to most of the world's communications, but this "NSA is deliberately backdooring everything" business is vastly exaggerated from the evidence.
I'm well aware of the program you're refering to. Have you seen some of the unit costs? That doesn't even include operating costs. The US is already near-bankrupt! Intercepting shipments with look-alike models doesn't really scale to mass surveillance, which is kind of a key point.
With a router on a key network segment, you're bulk-exploiting a large sector of the population (though there may be other means of doing this).
Generally, device interdiction doesn't scale, it's the sort of targeted surveillance Schneier more-or-less is supportive of.
Stating that "...you'd still need to inspect the hardware/software as shipped..." seems to suggest that it's necessary to check each and every unit of a given design. I was just addressing that part of the parent comment directly, along with it's general bias towards what can't be done as opposed to what can.
I wasn't trying to suggest that open codebases are a silver bullet -- but you can improve something without having a complete and comprehensive solution.
OR we might want to go back to shopping anonymously "offline", hoping that the NSA will not bother backdooring every device on the market.
There's some research [2] into using authenticated, encrypted bitstreams, but even if the implementation matches the theory (and after all, it's crypto, we know how that goes...) this only reaches the same level of security as a fixed-configuration ASIC, since FPGAs are vulnerable to the same nefarious fab attacks as ASICs.
1: http://www.cmpe.boun.edu.tr/caslab/publications/selfreconf_f...
Also, just transitioning to a more open process with an open codebase has the effect of "keeping them honest". Once the code is out there, they have no way of knowing who might be scrutinizing it and have no chance to retroactively cover something up.
This is why it's such a big deal when companies make a commitment to openness (the real kind -- not the buzzword kind). It's a statement of being willing to forego most of the dirty tactics that being closed source allows and to playing a fair(er) game.
The topic keeps coming up from time to time to time, since it's not a straightforward thing to fix, but only manifests itself with publicity. I've written a few comments before as to what I see are some of ultimate contours:
https://news.ycombinator.com/item?id=3658800
Just not always particularly pragmatic. Or agreeable.
He knows exactly what he's doing when he takes a hard line. Being weak-spirited and compromising isn't a very good way to get noticed.
How would 'open source' protect you from this? If the 'stuff' is firmware, then reflashing your own firmware after you get the device would protect you from it, but it doesn't particularly matter if the firmware you flash is open source or not. If the 'stuff' is hardware, then only someone inspecting the insides who's qualified to detect such hardware would protect you, and it's still got not much to do with open source.
Some linux distributions, for instance, try very hard to only every download source from the internet, and compile it locally. This is very slow (some things can take a very long time to compile).
Gentoo is one such distribution.
Hardware based rootkits can do pretty much everything to an OS running on that, and be undetectable from that OS.