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@xxxxxxxxx
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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
