5 ms·

I don't agree with this statement from the article: This, and Tor’s history of US government sponsorship, has led to series of really embarrassing conspiracy t

I don't agree with this statement from the article: This, and Tor’s history of US government sponsorship, has led to series of really embarrassing conspiracy theories from the likes of PandoDaily. This is why non-technical journalists should not write about technical subjects. If you’re going to suggest that open-source software has dark ulterior vulnerabilities, you need to point at exactly where they are in the code (or deployment process), or you will quite rightly be laughed out of the room. Funding and relationships are not unimportant — and I’m sure Pando will now write me off as part of the shadowy conspiracy, as Tor developer Jacob Appelbaum is an old friend — but it’s the running code that actually matters. Sadly, non-engineers don’t seem to understand this, or how laughably ridiculous they look as a result. The author, Jon Evans, seems to imply this is a widely accepted standard, which is not my experience. It also doesn't seem realistic: While it's great that open source software's source code is available, it's not possible to review it all much less to catch subtle exploits that might have been introduced by security agencies - we can't even catch many unintentional exploits. Also, we know from leaks that security agencies have tried and have succeeded at times. Realistically it comes down to trust. Think of it this way: How many HN readers, a sophisticated population, have reviewed Tor's code? How many feel they have no choice but to choose either to trust them or not? Also, how many open source projects have had security audits performed by anyone?

rodgerd 11y ago
> it's not possible to review it all much less to catch subtle exploits that might have been introduced by security agencies - we can't even catch many unintentional exploits Precisely. In the wake of Shellshock and Heartbleed the sneering tone of the passage you've cited should profoundly embarrass the author. It does not accord well with the facts.
- moxie 11y ago
  People tend to cite heartbleed as an example of how "open source" has no intrinsic security value. While I agree that something being "open source" does not automatically make it secure, I think that it does allow us to gauge the security of the project. In the case of heartbleed, anyone who has ever spent more than 30 seconds looking at OpenSSL can tell you that it is not secure software and never will be. We can't identify and remedy every possible vulnerability, but we do have enough information to know that events like heartbleed will happen again and again.
  - leohutson 11y ago
    People that claim open source has no security value seem to believe that just because you can't catch every vulnerability through public review, you may as well not bother at all. That logic is obviously faulty, I can't imagine they would apply the same rationale to cancer screening.
    - rodgerd 11y ago
      > People that claim open source has no security value Nice strawman you got there.
Karunamon 11y ago
There's a difference between being aware and a conspiracy theorist - and claiming backdoors exist in a given piece of software without the slightest shred of proof is the latter.
dandelion_lover 11y ago
>How many HN readers, a sophisticated population, have reviewed Tor's code? "Who actually reads the code?" https://www.fsf.org/blogs/community/who-actually-reads-the-code https://www.fsf.org/blogs/community/who-actually-reads-the-c...
api 11y ago
It's also not possible to catch all systematic design flaws. It's possible for someone who is deeply knowledgable in an area like crypto to deliberately introduce strategic design weaknesses into a system that might seem like reasonable choices to anyone who doesn't understand the exact context. I have always been suspicious of Tor's choice of long-lived circuits over packet-level onion routing. It seems like each packet should follow a different path. It would also be easier in a packet-based scheme to implement some level of noise / decoy traffic generation to make statistical analysis of traffic more difficult. It seems like a design choice that would make statistical inference easier by someone who has a God's-eye view of traffic. Large powerful nation states absolutely have this, while smaller ones may not, making it an ideal asymmetric vulnerability. But that's just one example. A true deliberately-introduced weakness might be something far more subtile than this: a choice of order of operations or timing for example.
ikeboy 11y ago
Friendly reminder that SELinux was developed by the NSA, and is now part of Linux. So clearly the open source community doesn't care too much about who created a piece of code. Case study 2: bitcoin.
- andreyf 11y ago
  Also, Tor is not designed to be resistant against traffic analysis by a global passive adversary. That isn't the kind of evidence that can be used in a US court, but intelligence agencies aren't primarily interested in bringing cases in front of courts, anyway.
  - olefoo 11y ago
    Although there has been more than a little evidence of "Parallel Construction" happening where the aforementioned global passive adversary pushes a treasure map to the local law enforcement agencies with indicators as to where to look...
- grubles 11y ago
  Case study 1: the US Department of Defense created ARPANET, the first network to implement TCP/IP.
  - deleted 11y ago
    [deleted]
  - ikeboy 11y ago
    I think for that, in particular, there's a very strong argument to be made that any backdoors would have been discovered by now.

rodgerd 11y ago

> it's not possible to review it all much less to catch subtle exploits that might have been introduced by security agencies - we can't even catch many unintentional exploits Precisely. In the wake of Shellshock and Heartbleed the sneering tone of the passage you've cited should profoundly embarrass the author. It does not accord well with the facts.

moxie 11y ago
People tend to cite heartbleed as an example of how "open source" has no intrinsic security value. While I agree that something being "open source" does not automatically make it secure, I think that it does allow us to gauge the security of the project. In the case of heartbleed, anyone who has ever spent more than 30 seconds looking at OpenSSL can tell you that it is not secure software and never will be. We can't identify and remedy every possible vulnerability, but we do have enough information to know that events like heartbleed will happen again and again.
- leohutson 11y ago
  People that claim open source has no security value seem to believe that just because you can't catch every vulnerability through public review, you may as well not bother at all. That logic is obviously faulty, I can't imagine they would apply the same rationale to cancer screening.
  - rodgerd 11y ago
    > People that claim open source has no security value Nice strawman you got there.

Karunamon 11y ago

There's a difference between being aware and a conspiracy theorist - and claiming backdoors exist in a given piece of software without the slightest shred of proof is the latter.

dandelion_lover 11y ago

>How many HN readers, a sophisticated population, have reviewed Tor's code? "Who actually reads the code?" https://www.fsf.org/blogs/community/who-actually-reads-the-code https://www.fsf.org/blogs/community/who-actually-reads-the-c...

api 11y ago

It's also not possible to catch all systematic design flaws. It's possible for someone who is deeply knowledgable in an area like crypto to deliberately introduce strategic design weaknesses into a system that might seem like reasonable choices to anyone who doesn't understand the exact context. I have always been suspicious of Tor's choice of long-lived circuits over packet-level onion routing. It seems like each packet should follow a different path. It would also be easier in a packet-based scheme to implement some level of noise / decoy traffic generation to make statistical analysis of traffic more difficult. It seems like a design choice that would make statistical inference easier by someone who has a God's-eye view of traffic. Large powerful nation states absolutely have this, while smaller ones may not, making it an ideal asymmetric vulnerability. But that's just one example. A true deliberately-introduced weakness might be something far more subtile than this: a choice of order of operations or timing for example.

ikeboy 11y ago

Friendly reminder that SELinux was developed by the NSA, and is now part of Linux. So clearly the open source community doesn't care too much about who created a piece of code. Case study 2: bitcoin.

andreyf 11y ago
Also, Tor is not designed to be resistant against traffic analysis by a global passive adversary. That isn't the kind of evidence that can be used in a US court, but intelligence agencies aren't primarily interested in bringing cases in front of courts, anyway.
- olefoo 11y ago
  Although there has been more than a little evidence of "Parallel Construction" happening where the aforementioned global passive adversary pushes a treasure map to the local law enforcement agencies with indicators as to where to look...
grubles 11y ago
Case study 1: the US Department of Defense created ARPANET, the first network to implement TCP/IP.
- deleted 11y ago
  [deleted]
- ikeboy 11y ago
  I think for that, in particular, there's a very strong argument to be made that any backdoors would have been discovered by now.