SNI for ssh [was: Re: Protocol Version Exchange: the comments field and an idea how to use it]

[Daniel Kahn Gillmor]

On 11/13/2013 08:25 AM, Hannes Hörl wrote:

> This all is just my imaginary use case. Anyhow, I think you could call
> the thing I'm thinking about "poor man's SNI[0] for SSH" ...

I'm not sure why it would be "poor man's" -- your proposal sounds very
similar to SNI from TLS.

There is currently a lot of discussion on tls at ietf.org about problems
with SNI -- in particular, that it leaks the name of the desired host to
a passive network attacker.  In general, it's wise to be wary of
cleartext connection hints that are used in the negotiation of a secure
channel.

One of the ideas from the discussion about TLS is to move SNI within a
layer of crypto based on an anonymous DHE handshake, which puts it out
of reach of a passive attacker (of course, an active attacker who is
willing to cause a connection failure can still extract this information).

Note that SNI (in either TLS or in your SSH proposal) is not
"negotiated" in a strict sense. Is it offered by the client to the
server in the clear, in the hopes that it will be supported by the
server (but willing to be ignored if it is not supported).

> So my question(s) rephrased:
> Why isn't there anything like SNI for SSH? For security reasons? Is
> there no demand? Is there a better solution which I don't know of?

Is it worth having clients advertise the server's name in the clear on
the network if there is no proxy in use?  Your proposal neatly avoids
this question by making it disabled by default.

You should also realize that some distributors patch their clients to
add a comment string there anyway (e.g. Debian openssh puts "Debian" in
the comment there).  So your proxy could get quite confused if it tries
to hand the connection off to the "Debian" backend.  If this is a space
for hiding other sorts of cleartext connection "hints", then you
probably want to distinguish your "SNI" hint from other hints.  you
could perhaps do this by declaring it with a specialized prefix, like
"Host:", to distinguish it from othe uses of the comment field.  That
way a comment like "limburger Host:server.example.net" would be cleanly
parseable.

If you decide this is really something that you want, I'd recommend
modeling your change on the patches that added the VersionAddendum
configuration option for sshd (but you're talking about adding it to ssh):

(from ChangeLog):
djm at cvs.openbsd.org 2012/04/12 02:42:32
 [servconf.c servconf.h sshd.c sshd_config sshd_config.5]
 VersionAddendum option to allow server operators to append some arbitrary
 text to the SSH-... banner; ok deraadt@ "don't care" markus@

and then making that string interpret the standard %-escapes, so a
client who wants to use this feature could do:

 ssh -oVersionAddendum=Host:%h server.example.net

That configuration option seems flexible and generic enough that it
would fit with the rest of the ssh interface (and it would enable
distros like debian to drop diffs like
debian/patches/package-versioning.patch in favor of a one-line addition
to /etc/ssh/ssh_config).  I'm not convinced that a feature like this is
worth allocating one of the few remaining short option flags (-H) though :)

Another thought about your proposed proxy: ssh's DH key exchange results
in a shared secret based on the exact contents of a bunch of stuff,
including the connection strings.  Either all of your backend servers
need to offer the exact same connection string as your proxy offers, or
your proxy needs to wait to receive the client's connection string
before forwarding the connection to the backend server.

If you choose the former, then when dealing with system upgrades, you'll
need to upgrade your entire server farm at once, so that the connection
strings stay synchronised.  This kind of "flag day" makes maintenance
difficult.

If you choose the latter, and there are any SSH clients out there that
wait for the server's connection string before sending their own, then
those clients will deadlock when connecting to your proxy.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20131113/296aebb8/attachment.bin>