Mailing List Archive

client to support SNI
Hi.

Looks like every ~2 Years raises someone the question about SNI support in the
openssh client.

2015: https://marc.info/?l=openssh-unix-dev&m=143248436518985&w=2
2017: https://marc.info/?l=openssh-unix-dev&m=150204655205911&w=2

I have read the docs and haven't seen anything about that this feature is
already available in SSH.

https://man.openbsd.org/ssh.1
https://man.openbsd.org/ssh_config.5

It looks like that the OpenSSH community don't like to implement such a feature,
from my point of vies. Maybe there is a possibility to use the ProxyCommand for
a solution?

https://man.openbsd.org/ssh_config.5#ProxyCommand

The Server http://www.rutschle.net/tech/sslh/README.html offers the possibility
to handle HTTPS & SSH on the same port therefore it would be nice to have a
client witch helps HTTPS front doors to select the right backend based on SNI
Header.

Any suggestions for a possible solution?

Best regards
Alex
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: client to support SNI [ In reply to ]
On 12/06/2019 11:56 PM, Aleksandar Lazic wrote:
> Looks like every ~2 Years raises someone the question about SNI support in the
> openssh client.

(ObRant(*): I refuse to call that "SNI".)

> It looks like that the OpenSSH community don't like to implement such a feature

That doesn't surprise me. When you look at an SSH connection with a
packet sniffer, you'll see that the first data going through the TCP
connection comes from the server (or, in your scenario, the "backend"),
and effectively contains identifying information on it. That would need
to be changed so as to allow the client to "dial" the desired backend
first - in other words, the two sides are not even speaking the SSH(2)
protocol anymore. *Definitely* rather low on the OpenSSH developers'
priorities list.

> Maybe there is a possibility to use the ProxyCommand for a solution?

Sure. Make the frontend a HTTP proxy with support for the CONNECT
command (say, squid - and be *real* careful when configuring the auth)
and you can use the likes of corkscrew for a ProxyCommand. Or install a
SOCKS proxy for a frontend (same caveat, and, e.g., using nc/netcat as
ProxyCommand). Or allow users to ssh (sans a shell, if you insist) into
the frontend so that they can use OpenSSH's "-D" option to run their own
SOCKS proxy to connect to the backend through. Moving the extra
functionality into an outer tunnel / proxying solution, rather than
shoehorning it into "the SSH protocol" itself, IMHO is *the* way to go here.

Note that it also circumvents the problem of ssh having to
learn/store/verify all the *backends'* host pubkeys with only the
*frontend's* IP+port to use as their identifier in the currentl
KnownHostsFile format (assuming that the "number dialed" may *not* be
IP+port based, or difficult to inject into the existing
KnownHostsFile-handling code).

(*) "SNI" is the established name for one *specific* solution of the
general "client connects and *then* selects from several available but
different backends" feature, namely, the one integrated into SSL *and*
interacting with the verification of the server's/backends' X.509
certificate. If anything, the patch proposals you referred to rather
resemble the "Host:" header introduced into HTTP with protocol version
1.1, to implement name-based web servers in *pre*-SSL times ...

Kind regards,
--
Jochen Bern
Systemingenieur

Binect GmbH
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: client to support SNI [ In reply to ]
On Sat, 7 Dec 2019, Jochen Bern wrote:

> (*) "SNI" is the established name for one *specific* solution of the
> general "client connects and *then* selects from several available but
> different backends" feature, namely, the one integrated into SSL *and*
> interacting with the verification of the server's/backends' X.509
> certificate. If anything, the patch proposals you referred to rather
> resemble the "Host:" header introduced into HTTP with protocol version
> 1.1, to implement name-based web servers in *pre*-SSL times ...

SNI is just a rather bad, privacy-violating, excuse to not use the
current version of the Internet Protocol, hiding behind useless crap
like NAT or vhosts. I am appalled that TLSv1.3 now requires it and
would rather see it utterly abolished.

bye,
//mirabilos
--
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database” (#nosec) ??? Please let MySQL and MariaDB finally die!
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev