
Protecting sshd using spiped - cperciva
http://www.daemonology.net/blog/2012-08-30-protecting-sshd-using-spiped.html
======
planckscnst
I have only recently started casually studying cryptography. I just yesterday
learned about GCM mode, which provides similar features to CTR with GMAC. Is
there any specific reason you chose to use CTR with HMAC in spiped rather than
GCM?

I ask because I have the impression that using GCM would further
simplify/reduce the amount of code and because I'm interested in learning what
goes into these decisions. BTW, I'm perfectly happy with an answer of "I can't
even explain it because you don't know enough yet." if that's the case.

[EDIT] Extra information for not-yet-crypto-nerds:

The "modes" i'm referring to are cipher block modes. Cipher block modes allow
repeated application of a block cipher to long messages (because a block
cipher's input must be a fixed length - that's what makes it a "block" cipher
rather than a "stream" cipher).

Using a block cipher only gives you confidentiality; it does not verify the
inegrity or the source of the message. For those, a message authentication
code (MAC) is needed. There are several MAC algorithms.

There are some block cipher modes (including GCM) that provide both
authentication and encryption because they include a MAC algorithm.

<http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation>

<http://en.wikipedia.org/wiki/Message_authentication_code>

~~~
cperciva
I covered this in a blog post a few years ago -- probably best if I point you
at it rather than trying to cover everything here:
[http://www.daemonology.net/blog/2009-06-24-encrypt-then-
mac....](http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html)

~~~
planckscnst
Wow. That was more than I hoped for. I especially appreciated the closing
paragraph. Thanks for taking the time to write it and to point it out here.

However, one of the points you made as an argument against authenticated
encryption modes is actually a point for it, unless I'm not getting something.
The point I'm referring to is that people write bad code and that every line
of code includes a potential security vulnerability. Every time someone uses
CTR+MAC, they're writing code to glue those together, and there are
opportunities for missteps. Furthermore, that code that is viewed by a small
number of people. By using an authenitcated encrytion mode, one can reduce the
lines of code you're writing because it the functionality is provided by the
implementation, which will certainly have been looked at more times than one's
own project.

[Edit]

Maybe this is what I was missing: "Encrypt-then-MAC is essentially impossible
to get cryptologically wrong."

------
rd0
Here is a better idea. If it looks like a duck, walks like a duck and quacks
like a duck, is it a duck? Run ssh on port 443 at the same time you run a web
server on the same port. <http://www.rutschle.net/tech/sslh.shtml> I've seen
implementatios in about a page of C, which I can vet.

~~~
cperciva
That is terrifyingly evil. And I mean that in the best possible way.

~~~
yungchin
As someone who doesn't have a very subtle understanding in English, I can't
figure out if this is an endorsement, or very much not one? (serious question!
I'd rather fly by your crypto-intuitions than my own...)

~~~
cperciva
It's incredibly cool. Not something I'd necessarily want to actually use in
production, though.

------
peterwwillis
I can't help but notice that this tool was created to circumvent private
networks. If you just wanted to write a crypto tool, kudos, but this is not a
good idea for production data. I also recommend focusing on system hardening
versus throwing crypto and fewer lines of code at the problem. The net benefit
is ten times that of a more complex set-up that only protects a corner case.

Take your original example: 17 servers and you want to share data between them
on the internet. The most effective way to do this is to put them all on one
or two hosting providers and use private IPs to connect them all via the same
backend. This way there is no surface to attack (if the hoster VLAN'd your
hosts correctly). Back in the day we used to do this by putting a private
switch in a rack that nothing else could touch, but it seems the days of
private cage monkeying has disappeared.

The other way is by using a VPN. A VPN is simply a network interconnect. Based
on some authentication data, allow a host to connect to a private network. If
done properly, there is no service to take advantage of and the daemon can run
completely without any capabilities or system access, save of course network
traffic. You then add firewalling to ensure only the right hosts get to the
right services. You can even make this a single stand-alone VPS host to add
granularity and separation of privilege, not to mention reduced attack
surface.

Your tool is theoretically simpler in practice than either of those methods (I
don't find setting up a VPN to be complex, but others might). But it comes
with the same risks as OpenSSH, save that (I imagine?) you could set it up to
be network-access-only like a VPN. The difference for a VPN being you wouldn't
need to configure multiple instances of an application.

~~~
cperciva
You seem to be under the misapprehension that VPN code never has any bugs in
it.

~~~
peterwwillis
Everything has bugs. If you're trying to make a point about the idea that this
software was created with the intent that "it's small so it can't have any
bugs", you're right, that probably has bugs too, and relying on that factor
alone would be a horrible way to secure a network service. Hence why I
suggested a VPN segregated from the rest of the system, or systems on the
whole.

------
jcr
Colin, I've always thought of running SSH on some other port as the equivalent
of painting your front door camouflage with the hope attackers might overlook
it -- in other words, pointless. It might stop some of the "log spam" from
dumb brute force attacks on port 22, but if a port scan was done to find the
sshd listening port (i.e. a smart attacker), then you still get attacked and
log spammed. As far as I know, this issue is best handled by pf.

I'm probably missing something obvious, but I don't understand how
spipe/spiped on another port fixes (or helps) the brute force problem?

~~~
cperciva
People can connect to spiped, but nothing will go through to sshd unless they
can complete the handshake (which requires an unfeasible amount of work unless
the person connecting holds the spiped secret).

~~~
jcr
Interesting. I'll check it out. Thanks!

I've always wanted something like spamd(8) for ssh, so everyone who normally
blocks inbound port 22 can work together to thwart the brute force attacks by
providing a honeypot/sandtrap/tarpit for the attack scripts to waste all of
their time and resources.

------
alexchamberlain
The title made me laugh. Let's protect a very secure, well tested and popular
codebase by one that isn't as well tested or popular. Hmmmmm.

~~~
cperciva
Let's protect a large and complicated codebase which has a long history of
security vulnerabilities with a very small and easily audited utility.

~~~
alexchamberlain
What are you protecting? You _can't_ brute force key-based authentication for
SSHd.

~~~
cperciva
I'm talking about security vulnerabilities in OpenSSH.

~~~
lmm
Is there really a history of security vulnerabilities in OpenSSH? (not openssh
as patched by idiotic linux distributions)

~~~
alexchamberlain
There have been problems... <http://www.openssh.org/security.html>

~~~
lmm
So technically those are all "vulnerabilities in openssh", but most of those
are either attacks on the key generation process, X11 forwarding, or privilege
escalation on the host machine from a legitimate login - none of which would
be protected against by the suggestion in the story.

The first one I see where this defense would actually be helpful is the
"September 23, 2003: Portable OpenSSH Multiple PAM vulnerabilities", which
only applies against a nonstandard PAM configuration, where enabling PAM at
all is something openssh doesn't recommend. The next is "April 21, 2002:
Buffer overflow in AFS/Kerberos token passing code" - again, an obscure login
protocol that's disabled by default.

The first vulnerability that would affect "normal" users is the "Feb 8, 2001:
SSH-1 Daemon CRC32 Compensation Attack Detector Vulnerability", 11 years ago.
Even if you want to count the "nonstandard config" vulnerabilities, we're
still talking 8 years since any real attack, for possibly the most high-
profile encryption software in the world. That's a track record I'd put more
faith in than spiped's.

If you want to secure your openssh you'd get a better return on your time
(IMO) by disabling any login methods you don't use (or, even better, switching
entirely to single-use keys), and rate limiting login attempts from a single
IP.

~~~
alexchamberlain
I completely agree, but I thought it only fair to list the vulnerabilities. On
the other hand, most of it didn't make sense to me... Though that should worry
me more than you and thanks for your explanation. :)

Having said that, the vulnerability you pointed out was in SSH1, right? Isn't
that depreciated?

~~~
lmm
>Having said that, the vulnerability you pointed out was in SSH1, right? Isn't
that depreciated?

It is now. I'm not sure it was in 2001.

------
casca
This feature seems to be offering similar functionality to OpenVPN's tls-auth
which requires an additional key before a connection is allowed. Another
option to get similar functionality would be to use port knocking [1][2] but
spiped gives other useful functionality too.

[1] <http://www.portknocking.org/> [2]
<http://www.thoughtcrime.org/software/knockknock/>

~~~
cperciva
I was intending to mention port knocking in that blog post but didn't find a
convenient point to fit it in. Yes, it's definitely an alternative solution to
the "let me connect to sshd but not anyone else" problem.

------
tezza
This looks incredibly useful, thanks.

I'd been kinda using two methods to do this already

    
    
      * OpenVPN plus tun firewalling
      * stunnel
    

Your solution is just so much a better fit for small-scale ( socket level
protection ), it hurts.

How ready-for-production is the toolset ?

~~~
cperciva
Yeah, there's several ways to do this -- 'ssh -L' is probably the most common,
followed by stunnel, followed by various types of VPN -- but for the use cases
I care about none of them fit very well.

 _How ready-for-production is the toolset?_

I've been using spiped in production for the past year. I've been using spipe
for about two days (since I only wrote it two days ago). I'd characterize both
as being very production-ready; the amount of code is small enough (about 4000
lines of code, of which 3/4 is library code shared with other projects I've
released) that there's very little room for bugs to hide.

------
eli
I realize it's not quite the same thing, but how do you think this compares to
Port Knocking?

