Adding SNI support to SSH

[Nico Schottelius]

Good evening Gert,

Gert Doering <gert at greenie.muc.de> writes:
> On Mon, Jan 13, 2020 at 03:16:00PM +0000, Jochen Bern wrote:
>> Out of interest:
>> 1. If an extended mechanism were to be implemented, which server pubkey
>>    do you expect to be seen/stored/verified by the client? The proxy's
>>    / v4 middlebox's, or the v6 backend's? Or would you require that all
>>    server-side machines use the *same* host keypairs?
>
> I'd do the "SNI" part before exchanging server host keys ("just as it is
> done in https, for good reason").  That way, every backend can have its
> own key.  The "middle box" would see some unencrypted handshake, but
> afterwards would have no more knowledge of the connection than any
> IP router or proxy in the path.
>
> Actually *doing* it sounds like you need a protocol change (more than
> "just an option after the key handshake"), as the server sends it
> "SSH-2.0..." message first, which would have to be deferred until the
> client tells it where it wants to connect to... so, not really trivial

I tend do disagree with the non-trivial statement here, but it might
only be because I am a simple minded person. In the last message where I
sent the haproxy configure you might have noticed the 5 second
delay/buffer.

Even with the server sending first, this does not look very hard to
me. As a sketch:

client->proxy [tcp connect]
proxy->client [SSH-2.0-Proxy_1]
client->proxy [SNI]
proxy->endhost [tcp connect]
endhost->proxy [SSH-2.0-OpenSSH_8.1]
proxy->endhost [SNI]

>From this state on the proxy can forward all traffic from both sides.

> (and back to square one, might take longer to roll out upgraded clients
> than to roll out v6 to those clients).

That's quite an interesting challenge. I'd love you being right here.

Cheers,

Nico

--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch