Adding SNI support to SSH

[Gert Doering]

Hi,

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
(and back to square one, might take longer to roll out upgraded clients
than to roll out v6 to those clients).

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             gert at greenie.muc.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3614 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20200113/c46401a0/attachment.bin>