[hueving]

>You don't need to be running sshd. Given the relative complexities of the two daemons, it's vastly more likely that your server will be compromised via a vulnerability in sshd than via a vulnerability in spiped. (In fact, if you need to run SSH for the benefit of interactive logins, you're probably better off having sshd only listening on 127.0.0.1 and connecting to it via spiped.)

This is a really bad argument. It may be generally true that increased complexity leads to more vulnerabilities in general, but it's not necessary that increased size leads to a large increase in complexity. Poor software design that involves a lot of strange relationships between components inside of an application leads to vulnerabilities. Unless your code base is so small you can provide formal proofs of security, you can make absolutely no assertions based on code size that your code is more or less vulnerably than larger code bases.

Additionally, the number of attempts to break OpenSSH because of the massive user-base gives it a stronger security foundation than you to imply. Put another way, there are massive economic incentives for hackers to pour hours into finding vulnerabilities in OpenSSH since it's the gateway to millions of *nix systems on the Internet. Has spiped been subject to that level of scrutiny?

As a security-minded person, you should not be making grandiose claims about freshly released software being so much more secure than OpenSSH that it should be used to protect OpenSSH endpoints. Would you trust a newly released symmetric crypto algorithm more than AES just because it performed fewer operations?

[tptacek]

I agree with Colin. I feel much safer with spiped than I would with OpenSSH, even though my opinion of OpenSSH is reasonably high (I trust it more than nginx, for instance). I'm familiar with both codebases, and spiped is just a lot simpler than OpenSSH.

[hueving]

Have you performed a full security audit of the spiped code? If not, the only way you can sanely make that argument is via an appeal to authority, which is probably acceptable given tarsnap's reputation. Is that what you're doing here?

[tptacek]

Ok, two things.

First, an "appeal to authority" is fallacious when the authority isn't relevant. In a discussion of cryptosystems, an appeal to Colin Percival's authority is a valid argument! It's obviously not dispositive, but it's not something you can simply dismiss; you'd need to rebut it with countervailing arguments. Technically, the authority I appealed to in my comment was my own. I happen to think that's also a valid argument, albeit one requiring fewer countervailing arguments. :)

The term "appeal to authority" is misused about as often as "ad hominem".

Second, if you reread my comment more carefully, you'll see that it pre-rebuts the argument you've made here.

I am absolutely prepared to have a debate about the relative safety of spiped and OpenSSH. Please, feel free to marshall some arguments in favor of OpenSSH. A comparative code review of the two projects sounds like a pleasant way to spend a lazy Sunday.

[hueving]

>First, an "appeal to authority" is fallacious when the authority isn't relevant. In a discussion of cryptosystems, an appeal to Colin Percival's authority is a valid argument! It's obviously not dispositive, but it's not something you can simply dismiss; you'd need to rebut it with countervailing arguments. Technically, the authority I appealed to in my comment was my own. I happen to think that's also a valid argument, albeit one requiring fewer countervailing arguments. :)

If you read my comment, you would see that I said it was probably valid in this case due to tarsnap's reputation. I was just clarifying the argument you were making to see if you actually had already performed a code review of spiped. However, an appeal to authority is still not valid (in academia at least), it's just a useful tool to shortcut arguments. When it gets down to the nitty-gritty of talking about showing that something is secure, if something is not dispositive, you can and you must dismiss it without regard.

>I am absolutely prepared to have a debate about the relative safety of spiped and OpenSSH. Please, feel free to marshall some arguments in favor of OpenSSH. A comparative code review of the two projects sounds like a pleasant way to spend a lazy Sunday.

Reread my comment in response to his, you should understand that the burden of proof lies with anyone claiming product X is more secure than OpenSSH. You cannot come in and claim spiped is simply more secure than OpenSSH on an argument of code-size alone. The security community is better than that.

Also, I already gave an argument in favor of OpenSSH in its current state from the economic perspective. There is a nearly limitless treasure chest of computing power and bandwidth available to people who discover vulnerabilities in OpenSSH. In that regard, it's received orders of magnitude more scrutiny than spiped. From the academic side, OpenSSH is a popular target for experiments in static and dynamic analysis because a new automated method that discovers a vulnerability in something like OpenSSH will guarantee citations and top venue.

On a related note, vulnerabilities so egregious that require you to shield OpenSSH using spiped implies that OpenSSH is fundamentally broken. If that's the case, what's the expected method of installing spiped and the symmetric keys on something like an EC2 instance?

[tptacek]

You're right: there is more incentive to find OpenSSH vulnerabilities than spiped vulnerabilities, and so the absence of OpenSSH vulnerabilities is more telling than the absence of spiped vulnerabilities.

But spiped is so much simpler than OpenSSH that more is going on: it's not merely that fewer people are looking, but that there is less to find.

Look over the history of OpenSSH vulnerabilities and reduce them to the subset that could possibly have affected spiped and you'll see what I mean. spiped benefits from having less mechanism than OpenSSH.

The idea behind deploying spiped is that you leave OpenSSH exposed for the tiny window of time required to get spiped deployed, and then you turn it off. Even if OpenSSH is totally broken, you still benefit from the fact that attackers aren't omniscient. A similar, weaker property is the reason every host running nginx hasn't been owned up.

[hueving]

>Look over the history of OpenSSH vulnerabilities and reduce them to the subset that could possibly have affected spiped and you'll see what I mean. spiped benefits from having less mechanism than OpenSSH.

This is true, but if you were using them to solve the same use-cases (fixed tunneling between hosts), how often would those OpenSSH vulnerabilities have been exploitable?

I apologize for arguing with you. The votes my comments are receiving have indicated to me that my input on this subject is not welcome in this community.