Spiped – symmetric, encrypted, authenticated pipes between sockets
tarsnap.com
tarsnap.com
"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
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 :)
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.
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.
(But for the ultra paranoid - spiped sounds like a better deal)
... which is what TCP keepalives are for.
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.
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.
It turns on TCP_KEEPALIVE by default. The -j option disables them.
> The simplicity of the code ... makes it unlikely that spiped has any security vulnerabilities.
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.
Anyone have a list or collection of these? I feel like I'm missing out on a whole world considering I just learned about spiped from this post.
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 )
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?
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.
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?
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.
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.
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!
Doesn't that make you sad inside?
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?
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.
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.
Try changing the sshd config and send the sshd a reload signal.
Normally that keeps existing connections alive. YMMV.
Not sure if that is any easier on eb though. Some other ideas: http://stackoverflow.com/questions/13476138/setting-up-priva...
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:
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/custom...
Container commands run 'before' your app is deployed, so you can pull in deps/etc.
But being tied to what's in OpenSSL is scary.
I have been doing what spiped/spipe does using curvecpserver/curvecpclient.
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.
openssl dgst -sha256 spiped-1.3.1.tgz gpg --print-md sha256cperciva, why serve http at all or not at least redirect people to https by default?
Any sane packaging system will check hashes against known good values after downloading, so using https just opens up more attack surface.
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".
spipes builds upon well-understood primitives and provides a simple, clear, and likely to be correct implementation.
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.
What are your thoughts now on not exposing yourself to all of the complexity of OpenSLL?
* Does not require X.509 processing, which is a huge source of TLS implementation bugs.
* Uses secure-by-default ciphersuite which, unlike TLS's, was designed after the most important work in authenticated encryption was published.
* Does not include legacy ciphersuites with known flaws.
* Mutually authenticated without invoking TLS corner case subprotocols like client certificates and session resumption.
* Small enough to be auditable.
FYI - the man pages still say version 1.3.0 :)
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.
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.
brew install https://raw.githubusercontent.com/bbatsell/homebrew/spiped-1.3.1-fixmanpage/Library/Formula/spiped.rb
brew update;brew reinstall spiped[1] http://www.daemonology.net/blog/2009-09-28-securing-https.ht...