
Spiped – symmetric, encrypted, authenticated pipes between sockets - malandrew
http://www.tarsnap.com/spiped.html
======
mattjaynes
Amazing project. And I love the understated tone of this in the README:

"Security Requirements: The user is responsible for ensuring that any
individual connection does not transmit more than 2^64 bytes."

If you don't happen to know how big 2^64 bytes is, it's over 18 BILLION
GIGABYTES! We can probably safely assume most of us will never hit that limit
on a single connection, haha.

Ref:
[https://code.google.com/p/spiped/source/browse/trunk/README](https://code.google.com/p/spiped/source/browse/trunk/README)

~~~
cperciva
You also have to ensure that you don't create more than 2^64 connections using
the same key.

~~~
tokenizerrr
Do you have any recommendations on how to manage this? I realize this number
is quite huge, and likely will never become an issue for me, but I'm not sure
how I would manage or monitor the amount of connections a third party
application creates.

~~~
cperciva
Don't try to count, just establish an upper bound. "I have 1000 servers using
this shared key, and they each open at most 1000000 connections per second, so
as long as I change the key in the next 500 years I should be fine."

------
b6
I use spiped every day the same way I would ssh tunnels, except spiped is
rock-solid, dealing with flaky network with no problems. I highly recommend
it.

~~~
cperciva
_except spiped is rock-solid, dealing with flaky network with no problems_

In case anyone is wondering about this: When you set up an SSH tunnel, you
have a single persistent TCP connection which everything runs through. If
there's a network glitch which kills that TCP connection, everything dies.
With spiped on the other hand, a separate TCP connection is used for each
"pipe", so a network glitch won't kill a connection which isn't actively
sending data, nor will it prevent future connections from being established.

~~~
beagle3
Everything you say is true; but in some cases, you _want_ to know that things
have disconnected and data won't be coming through even if it should. ssh -L
(with ClientAliveInterval / ServerAliveInterval) does that. Also, autossh is
good at keeping connections up.

(But for the ultra paranoid - spiped sounds like a better deal)

~~~
cperciva
_in some cases, you want to know that things have disconnected and data won 't
be coming through even if it should_

... which is what TCP keepalives are for.

~~~
beagle3
First of all - does spiped give you an option to set TCP_KEEPALIVE on its
socket? The README doesn't mention it, and if I understand correctly, unless
spiped does it, the application has no way to do it either. But even if not -
don't rush to add it:

TCP keepalives is the common but practically wrong answer. TCP keepalives kick
in after 2 hrs (default), and I've used TCP stacks that wouldn't let you
configure it to less than 60 mins. For almost any use over a fragile
connection, I'd like to know the connection failed within minutes, not hours.

Just to be clear: spiped gives you the same "disconnection detection"
guarantee that the underlying TCP gives you in a local network; if you have a
connection to another computer, and it unexpectedly reboots / panics / shuts
down, and you don't transmit anything - you'll never know the connection is
dead with either a TCP connection or a spiped connection (until you try to
send something, OR you've configured TCP keepalive _and_ it's been more than 2
hours).

However, with ssh using ServerAliveInterval and ClientAliveInterval settings,
you'll get active detection and immediate notification when the disconnect is
detected. (With ServerAliveInterval 60 and default count of 3, it'll take up
to 4 minutes). autossh will also give you automatic reconnect (whether you
pipe through the main shell or use -L / -R).

Using ssh's keep alive to detect connection problems is a kludge; if you
really need this functionality, build it into your protocol. However, if you
use it to forward a service you cannot modify (e.g. tunneling HTTP connections
from browser to server), I find that it is very useful to let ssh figure out
that a connection is borked, rather than wait for hours until the TCP stack of
browser realizes that.

In fact, I am ashamed to admit that I've used sshuttle on a LAN just so that I
get quick disconnect notifications from a computer that had kernel panics.
It's ugly, but it does work.

~~~
ghshephard
"TCP keepalives kick in after 2 hrs (default), and I've used TCP stacks that
wouldn't let you configure it to less than 60 mins."

We were doing some interoperability testing with an IEC-61850 stack, and the
vendor's library, set the TCP-Keepalive to 100 milliseconds. Needless to say
this caused issues on our 30 kbit links.

------
robbles

      > The simplicity of the code ... makes it unlikely that spiped has any security vulnerabilities.
    

Famous last words :)

On a serious note - this looks like a really useful addition to the toolbox of
"low-level unix flavored tools". I can see this being a simple basis for
connecting infrastructure together without exposing potentially sensitive
data.

~~~
cperciva
_Famous last words :)_

Please audit the code! Just like tarsnap, spiped is eligible for bug bounties.

 _I can see this being a simple basis for connecting infrastructure together
without exposing potentially sensitive data._

Yes, that's exactly it. The use case is "I have a bunch of servers and I want
them to talk to each other securely". Ten years ago this would have just been
a matter of stringing cat5 between them, but Cloud changes that.

~~~
PeterisP
... and as recent public revelations have shown, having dedicated cat5 or
fiber between your servers/datacenters doesn't prevent attackers from reading
that data; this approach would inconvenience NSA more than that.

------
eliteraspberrie
It is part of the Tarsnap bug bounty
([http://www.tarsnap.com/bugbounty.html](http://www.tarsnap.com/bugbounty.html)).
When I first heard of the bounty I gave it a shot but could never find
anything. I ended up learning from the code, which is priceless.

------
tezza
I've been using spiped in production now for a few years, ever since the
initial announcement here.

I tunnel Zabbix health monitoring communications to and from the server.

I don't have to worry about setting up users, and each node 'config' is only 1
shared keyfile.

If a node is compromised, I can cut it off with one move ( changing the shared
key )

------
aba_sababa
Wondering - what's wrong with SSH? Is it considered insecure?

~~~
cperciva
Probably easiest to answer this with the blog post I wrote when I released
this code: [http://www.daemonology.net/blog/2011-07-04-spiped-secure-
pip...](http://www.daemonology.net/blog/2011-07-04-spiped-secure-pipe-
daemon.html)

~~~
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.

~~~
tptacek
Breathe. The downvotes you got (I wasn't one of them) indicated that people
disagree with you. Probably by default, because they know who me and Colin
are.

It's also a useful point that not all of OpenSSH's additional mechanism is
implicated when doing point-to-point tunneling. But look at the actual
vulnerabilities: some of them are!

~~~
hueving
>The downvotes you got (I wasn't one of them) indicated that people disagree
with you. Probably by default, because they know who me and Colin are.

Doesn't that make you sad inside?

------
malandrew
OP here. So quick technical question for those reading this thread since I
came across spiped while trying to find a solution to a problem that I believe
should be solvable without resorting to spiped or socat.

The manpage for sshd_config says that turning off AllowAgentForwarding still
doesn't prevent users from setting up their own forwarders. If I have ssh-
agent set up to forward to the host I am connecting to, but it has
AllowAgentForwarding turned off, is it possible to set up my own forwarder in
sshd without changing having to enable it and reconnect with a new session?
i.e. is there a way to get the SSH_AUTH_SOCK unix domain socket on my
localhost forwarded to the host machine I'm currently sshed into using only
the tools likely to be installed on a typical linux box or is the only way to
do it with tools like spiped or socat?

~~~
tezza
If I understand you correctly, the admin of sshd has turned off forwarding.

You'll have to set you your own userspace forwarder if the admin hasn't also
clamped down the firewall config too tight.

If they HAVE clamped down the config, you could still invoke netcat on the
remote side and use some form of kermit tunneling to get to the remote target
side.

~~~
malandrew
Not quite. The server is an amazon elastic beanstalk image that comes with it
turned off. I can turn it back on after the machine is provisioned, but I want
to be able to turn it on before the machine is provisioned so that the npm
install with git urls pointing to private repos works.

Basically, once I SSH and I'm root during the provisioning process, how do I
programmatically set up ssh-agent for an in progress ssh session so that all
future commands have access to the SSH_AUTH_SOCKET on my localhost.

~~~
Robin_Message
That sounds like the wrong way to do it tbh. What about a deployment key?

Not sure if that is any easier on eb though. Some other ideas:
[http://stackoverflow.com/questions/13476138/setting-up-
priva...](http://stackoverflow.com/questions/13476138/setting-up-private-
github-access-with-aws-elastic-beanstalk-and-ruby-container)

~~~
malandrew
Tried that. I got it to work, but it's super hackish and brittle. Basically,
Github supports deployment keys, but they need to be unique per repo, so if I
have many repos I want to clone (for each private npm module) I will need to
clone multiple keys. Then since ssh only allows different keys based on the
hostname or username, and all git clones are git@github.com, you have to
create a script for the GIT_SSH env var to choose the right key based on the
value of $2 passed to the GIT_SSH script. The only way a deployment key makes
sense is to make a dummy user with read only access to the repos you need,
which is yet another undesirable hack.

~~~
malandrew
Turns out what I want to do is impossible without something like spiped. I dug
into the source of the cli tool and it looks like it doesn't rely on ssh at
all. Instead it does all the provisioning through amazon APIs. i.e. Amazon is
sshing into the machine for provisioning purposes, not my machine.

Basically, I need to expose my ssh-agent socket to the world via a TCP socket
exposed to the world. The server would then install spiped, get the symmetric
key that allows it to connect to my ssh-agent-port and set up the
SSH_AUTH_SOCK to proxy requests to my machine.

This is still more secure than ever letting your private key ever leave your
machine.

While I don't think I need it anymore since I can mount the unix domain socket
anywhere, I did find this script useful and think others here may as well:

[https://github.com/wwalker/ssh-find-agent/](https://github.com/wwalker/ssh-
find-agent/)

------
yp_master
It's such a simple and useful idea.

But being tied to what's in OpenSSL is scary.

I have been doing what spiped/spipe does using curvecpserver/curvecpclient.

~~~
cperciva
_But being tied to what 's in OpenSSL is scary._

OpenSSL is scary, but spiped only uses a very very small corner of the OpenSSL
code. In particular, it doesn't use any SSL code.

------
natch
To check the sha256 checksum on a system with openssl, in terminal find the
download and do:

    
    
        openssl dgst -sha256 spiped-1.3.1.tgz

~~~
jedbrown
Note that the SHA256 hashes on the linked website are served over HTTP, which
is no security against a MITM. If you use the HTTPS site
([https://www.tarsnap.com/spiped.html](https://www.tarsnap.com/spiped.html))
then the tarball links are also HTTPS (same security). Why are we asking
people to manually verify hashes when the hash and content enjoy the same
level of security?

~~~
malandrew
I should have posted the https link. If a mod wants to edit the url for this,
twould be appreciated.

cperciva, why serve http at all or not at least redirect people to https by
default?

~~~
cperciva
_why serve http at all_

Any sane packaging system will check hashes against known good values after
downloading, so using https just opens up more attack surface.

~~~
hueving
If they're not using http, where exactly do the known good values come from?

~~~
cperciva
The GPG-signed release announcement.

~~~
hueving
While valid, this is an extremely user hostile response. Requiring
administrators to dig up release notes and hoping they actually have your gpg
key and know what to do with it is essentially giving the middle finger to
admins that don't understand crypto well.

~~~
jasomill
Not really, because admins that don't bother to read release notes or to
verify GPG keys should probably be using package management systems maintained
by those who do.

~~~
hueving
That would be fine if there were never a case where a package management
system fell out of date due to a package maintainer not staying on top of
things.

------
stock_toaster
I have been using spiped for years. Works great!

------
swordswinger12
Just read the full protocol description - does anyone know why PBKDF-SHA256 is
used in steps 3 and 7? As far as I can tell, the input key material in both
cases is high-entropy; what does a PBKDF do that e.g. HKDF couldn't?

~~~
cperciva
PBKDF2-SHA256 is used with an iteration count of 1, so it doesn't make the
computation any more expensive.

I'm using PBKDF2-SHA256 to fulfill the role of "something which has the same
cryptographic strength as SHA256, but produces an arbitrary length output".

~~~
swordswinger12
Have you looked at the new SHA-3 for this? Seems like you're looking for
something like a sponge function. (It's obviously fine as-is, I was just
curious)

~~~
cperciva
That would have worked fine. Except it didn't exist yet when I wrote spiped.
;-)

------
ig1
Is this for unix domain sockets or network sockets ? - the description of
"unix sockets" makes me think the first but the reference to "SSH -L" makes me
think it's the second.

~~~
icebraining
Both.

------
acqq
Anybody to explain advantages and disadvantages of spipes over using TLS?

~~~
nanofortnight
If you have actually tried to implement TLS yourself, there are a lot of
places where you can go wrong. There are some places in TLS where it is easy
to make implementation errors, and you can't confidently say there are
unlikely to be any vulnerabilities in an implementation.

spipes builds upon well-understood primitives and provides a simple, clear,
and likely to be correct implementation.

~~~
lmb
That seems to be a non-argument to me: you shouldn't implement TLS yourself
anyways. And given that spiped is a younger project than say OpenSSL will mean
less eyeballs applied to finding bugs. And the cryptographic primitives spiped
uses are available in TLS as well.

TLS and spiped are simply two different tools, for two different purposes.
Control only one of the endpoints? You'll have to use TLS. Want to secure
communication between infrastructure you control? Check out spiped.

~~~
makomk
Even if you're just implementing TLS using an existing TLS library it's easy
to get that wrong. TLS is a pain.

------
damian2000
Anyone know of any blog posts with some more usage examples? The README is ok,
but I couldn't follow the given examples (probably a sign I shouldn't be using
it at all).

~~~
cperciva
You might fine this useful:
[http://www.daemonology.net/blog/2012-08-30-protecting-
sshd-u...](http://www.daemonology.net/blog/2012-08-30-protecting-sshd-using-
spiped.html)

------
ing33k
never heard about this tool, thanks for posting. I installed this but was not
able to find manpages for this.. any how found instructions in README ..

~~~
cperciva
If you define MAN1DIR then the man pages will be installed.

~~~
malandrew
What about the MANPATH env var? Is that considered as well?

Either way, `brew install spiped` fails on OSX if $MAN1DIR is set because brew
works without sudo and all the directories in /usr/share/man are only
writeable by root. Obviously not your problem, but just putting it out there.
Is MAN1DIR a FreeBSD env var or is it used by other distros?

I was bummed out that spiped was not in Red Hat's yum package registry. I
wonder if it's in the other distro registries.

~~~
bbatsell
FYI, I just submitted a pull request fixing this in homebrew. They're usually
pretty good about merging PRs fast, but if you'd like your manpage right now,
you can run:

    
    
      brew install https://raw.githubusercontent.com/bbatsell/homebrew/spiped-1.3.1-fixmanpage/Library/Formula/spiped.rb
    

Edit: 1 hour later, it's already been merged.

    
    
      brew update;brew reinstall spiped

~~~
malandrew
Most awesome.

------
sunyc
reinvented stunnel.

~~~
icebraining
The author uses stunnel to terminate SSL connections[1], so if he reinvented
it, it's because he thought it necessary.

[1] [http://www.daemonology.net/blog/2009-09-28-securing-
https.ht...](http://www.daemonology.net/blog/2009-09-28-securing-https.html)

