openssh unix dev - Aug 2017 - [PATCH] add support for VersionAddendum to the client to support SNI & other uses

Patch is here: https://bugzilla.mindrot.org/show_bug.cgi?id=2745

A few years back, there was discussion on the mailing list about adding
server name indication (SNI) support to SSH by fiddling with the version
banner exchange at the very beginning of the protocol exchange, before the
encrypted channel is created. SNI, if you don't remember, is the feature
that allows multiple websites to be hosted on a single webserver as
"virtual hosts". SNI sends the hostname during the unencrypted header
exchange to support virtual hosts over HTTPS.

Daniel Gillmor at the time suggested that if this was to be done for
OpenSSH, using the VersionAddendum mechanism might be a good way to do it:

https://lists.mindrot.org/pipermail/openssh-unix-dev/2013-November/031811.html

This patch does that.

For example, a user might want to do
ssh -oVersionAddendum=X-Host:realhost.site.com sharedIpAddr.site.com

With the patch, someone who wanted to put in place a quick proxy running on
port 22 of sharedIpAddr.site.com that looked for a string like
X-Host:realhost.site.com
could then proxy the connection to realhost.site.com.

The patch supports '%h' per Daniel's suggestion, so you can do:
ssh -oVersionAddendum=Host:%h server.example.net

or just put VersionAddendum in your configuration file.

The caveats that Daniel warned about in 2013 are still true - this may not
be something an admin wants to turn on by default so you're not leaking the
actual host you're connecting to over the unencrypted banner exchange
(though if you have a shared secret with the proxy you could encrypt the
host string). Also, because the banner strings are used as part of the key
exchange if the proxy sends something different than what the actual end
host sends key exchange will fail.

I largely copied the code from how the server side handles VersionAddendum.
The big change is that I passed around the 'host' variable in
ssh_connect.c
so the %h expansion would work when the banner string is actually
constructed - if there's a global I could read from I wouldn't need to
change the calls up the stack. Other expansions don't work, like %u or %p,
because the data for those are not passed along right now.

I didn't add anything to ssh_api.c - it doesn't look like that file uses
the config settings so I don't think VersionAddendum would get picked up
there, but maybe I'm not reading it right.

If it's easier for folks to read or use, this patch is in the
client_version_addendum branch here:
https://github.com/epaulson/openssh-portable/commit/69daef3b8a99d6c85f357f200c4aaa06fe28eaff

SNI is my use case, but other use cases where having some additional
headers early in the protocol might be out there and this could be a way to
help prototype them.

Thanks!

-Erik

On Sun 2017-08-06 13:59:30 -0500, Erik Paulson wrote:
> Daniel Gillmor at the time suggested that if this was to be done for
> OpenSSH, using the VersionAddendum mechanism might be a good way to do it:
>
>
https://lists.mindrot.org/pipermail/openssh-unix-dev/2013-November/031811.html
>
> This patch does that.
>
> For example, a user might want to do
> ssh -oVersionAddendum=X-Host:realhost.site.com sharedIpAddr.site.com
>
> With the patch, someone who wanted to put in place a quick proxy running on
> port 22 of sharedIpAddr.site.com that looked for a string like
> X-Host:realhost.site.com
> could then proxy the connection to realhost.site.com.
>
> The patch supports '%h' per Daniel's suggestion, so you can do:
> ssh -oVersionAddendum=Host:%h server.example.net
>
> or just put VersionAddendum in your configuration file.
>
> The caveats that Daniel warned about in 2013 are still true - this may not
> be something an admin wants to turn on by default so you're not leaking
the
> actual host you're connecting to over the unencrypted banner exchange
> (though if you have a shared secret with the proxy you could encrypt the
> host string). Also, because the banner strings are used as part of the key
> exchange if the proxy sends something different than what the actual end
> host sends key exchange will fail.
for the record, i do *not* think this is a good idea to add to SSH.
we've got a lot of work ahead of us in TLS to fix all the cleartext data
that leaks in the handshake.

SSH is actually doing the right thing here by *not* leaking data in the
handshake, and it'd be a shame to see it backslide.  Arguably, the
version strings should be made even more generic to avoid leaking
identifiable information.
> SNI is my use case, but other use cases where having some additional
> headers early in the protocol might be out there and this could be a way to
> help prototype them.
please, let's not add additional cleartext data in the ssh handshake.
anonymous DH first, then pass whatever parameters you like.  SSH is
already doing this right, let's not go backward.

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170807/8c4fcbcf/attachment.asc>

Erik Paulson <epaulson at unit1127.com> writes:
> A few years back, there was discussion on the mailing list about
> adding server name indication (SNI) support to SSH [...]  I largely
> copied the code from how the server side handles VersionAddendum.
I have no opinion on the SNI part og the patch, but FreeBSD has had
VersionAddendum both server-side and client-side since 2002 (ten years
before it was added upstream, server-side only).  I would suggest using
that code instead of reinventing the wheel.

(Yes, I have submitted it before.  I never even got a reply.)

DES
-- 
Dag-Erling Sm?rgrav - des at des.no