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.
Just to pick one current example, JUS[0] presently has a capacity of 1.28 terabits per second.
If, for some reason, we were to run it at an even 1tbps, piping all data through a single spiped connection, the security requirement would be broken after just over 4.25 years of continuous operation.
8 streams of uncompressed 4320p@60fps video multiplexed into a single spiped connection would also break that requirement in a bit over twice as much time.
These are contrived but possible scenarios with present commercial technology. In 10-20 years, that assumption might not be so safe.
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.
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."
Apparently my comment is being misinterpreted (evident by the downvotes) :/
To clarify:
It's simply amazing the scale at which you have to get to for spiped to need a new key. It's a tribute to its design and its author.
If I understand it right, in order for this to be a real issue, an attacker would have to spend decades or centuries diligently recording either 18 quintillion connections or 18 billion gigabytes of your encrypted traffic in order to even begin to try cracking the key in any serious way.
The solution to this "vulnerability"? Switch out your key (takes a few seconds tops).
I laugh because of Colin's dry humor matter-of-factness about this mind-blowing level of scale. If you missed his own poking fun at it, read his other comments in this thread :)
2050s had called and asked for spiped to have a default behavior to terminate the connection in such cases, so accidental disclosure would be prevented no matter what.
I hope you mean the 2020s. It's optimistic to think we would still be allowed to run custom software in the 2050s, and pessimistic that we wouldn't have multi-terabit connections before 2050.
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.
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.
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)
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.
"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.
> 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.
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.
... 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.
It is part of the Tarsnap bug bounty (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.
>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?
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.
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?
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.
>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?
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.
>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.
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!
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?
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.
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.
Not quite sure I understand where int he process you need it to be on, but is putting a config script ('/scripts') in the EB deployment repo that sets things up and/or turns on the SSH forwarding that you need?
A quick sed script to replace the SSH forwarding line with one that turns it on and a HUP to the daemon, and you'd be good to go?
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.
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:
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) 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?
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.
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.
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.
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?
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".
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)
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.
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.
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.
Ironic - the timing of your comment, " And given that spiped is a younger project than say OpenSSL will mean less eyeballs applied to finding bugs. " given todays announcement regarding the absolutely epic OpenSSL bug.
What are your thoughts now on not exposing yourself to all of the complexity of OpenSLL?
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).
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.
MANPATH is a directive to man to tell it where to look for man pages. Typically it includes multiple directories.
MAN1DIR is just a variable name I picked. I was assuming that most people would be installing this code via some sort of packaging system which could set that variable appropriately.
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:
"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