Good evening Gert,
Gert Doering <gert@xxxxxxxxxxxxxx> 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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
