openssh unix dev - Jan 2020 - Adding SNI support to SSH

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>

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

Hi,

On Mon, Jan 13, 2020 at 10:52:15PM +0100, Nico Schottelius
wrote:
> 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.
Sure.  But if you do it that way, the client loses information on which
server implementation it is talking to - and given the number of bugs
and caveats that are worked around in the client based on the 
"SSH-2.0-$product" message, I see this as non-optimal way forward.

> > (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.
IPv6 is, at least here in DE, nicely happening in many access networks
(cable, DSL, mobile - vodafone.DE started supporting it recently!).

Where IPv6 is quite lacking is "content", so I applaud your efforts
:-)

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

On 01/13/2020 07:55 PM, Gert Doering wrote:
> 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")
Actually doing it that way - and I admit that I can't think of a better
one off the top of my head - does *not* strike me as a change *to the
SSH protocol*. The SSH protocol would still happen, unchanged, through a
transparent connection between client and (v6/backend) server; "on the
wire", you'ld merely add a prologue (and possibly an epilogue) to the
data exchanged so as to initiate (and tear down) said transparent
connection.

However, that's essentially what SSH proxying solutions (SOCKS, HTTP
CONNECT) do, too, and all the reasons to have proxying separated from
the actual OpenSSH code and handed to separate ProxyCommand helper
applications should, I'ld guess, apply here as well.

In particular, for the v4/v6 switching as described, I'ld say that one
would want to implement a helper that works along the following pseudocode:
-- Get called by ssh (including being given "a target host" that
   may be a host name or an IP)
-- Second-guess whether a plain ssh would/could connect to it with v4
   or v6
   (yes, I've seen machines with default-enabled v6 support sitting in
   v4-only networks that would fail to connect to any v6-enabled hosts
   including dual stack, because they would see and prioritize the AAAA
   RRs in the DNS ... v6 support was simply *that much* out of scope
   for the people maintaining those network domains)
-- If v6, establish an equivalent connection (maybe by exec'ing
   netcat/nc as the helper's helper ;-) and hand it to ssh
-- If v4, open the connection (which will actually connect to the v4
   frontend), send the "SNI" (in whatever format whatever software
   running on the frontend requires it to be, my guess would be that
   HAproxy would already be well equipped to handle HTTP CONNECT
   requests ...), wait for the frontend to put you through to the
   requested backend, then hand the connection to ssh

Thinking back to other proxying helpers like netcat/nc or corkscrew,
I'ld say that the new helper (3rd party software) might well have a
better "time to market" than an equivalent feature implemented in
OpenSSH itself ...

Regards,
-- 
Jochen Bern
Systemingenieur

T  +49 6151 9067-231
F  +49 6151 9067-290
E  jochen.bern at binect.de
W  www.binect.de

Binect GmbH
Robert-Koch-Stra?e 9
64331 Weiterstadt

Gesch?ftspost. Einfach. Besser.
Wir sind zertifiziert: https://www.binect.de/zertifikate.html
Melden Sie sich zum Newsletter: https://www.binect.de/newsletter.html

Die Portoerh?hung ist da!
https://www.binect.de/portoerhoehung-2019?utm_source=email&utm_medium=button&utm_campaign=portoerhoehung
https://de-de.facebook.com/binect/ -
https://www.linkedin.com/company/binect-gmbh -
https://www.xing.com/xbp/pages/binect-gmbh
Binect Erkl?rvideo ansehen: https://www.youtube.com/watch?v=LhL1BZ8fci0

Gesch?ftsf?hrung: Dr. Frank Wermeyer
Unternehmenssitz: Weiterstadt
Register:         Amtsgericht Darmstadt, HRB 94685
Umsatzsteuer-ID:  DE 221 302 264

MAX 21-Unternehmensgruppe
?
Diese E-Mail kann vertrauliche Informationen enthalten. Wenn Sie nicht
der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese
E-Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser
Mail oder von Teilen dieser Mail ist nicht gestattet. Jede von der
Binect GmbH versendete Mail ist sorgf?ltig erstellt worden, dennoch
schlie?en wir die rechtliche Verbindlichkeit aus; sie kann nicht zu
einer irgendwie gearteten Verpflichtung zu Lasten der Binect GmbH
ausgelegt werden. Wir haben alle verkehrs?blichen Ma?nahmen unternommen,
um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu
minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf
alle Anh?nge an dieser Nachricht durchzuf?hren.
Wir schlie?en, au?er f?r den Fall von Vorsatz oder grober
Fahrl?ssigkeit, die Haftung f?r jeglichen Verlust oder Sch?den durch
virenbefallene Software oder E-Mail aus.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of contents of this
e-mail is strictly prohibited. All Binect GmbH emails are created
thoroughly, nevertheless we do not accept any legal obligation for the
information and wording contained herein. Binect GmbH has taken
precautionary measures to reduce the risk of possible distribution of
virus infected software or emails. However, we advise you to check
attachments to this email for viruses. Except for cases of intent or
gross negligence, we cannot accept any legal obligation for loss or
damage by virus infected software.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4278 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20200114/18bd52b6/attachment-0001.p7s>