Protocol Version Exchange: the comments field and an idea how to use it

[Hannes Hörl]

Hi.

On 11/13/2013 06:59 PM, Daniel Kahn Gillmor wrote:

> On 11/13/2013 08:25 AM, Hannes Hörl wrote:
>
>> This all is just my imaginary use case. Anyhow, I think you could call
>> the thing I'm thinking about "poor man's SNI[0] for SSH" ...
>
> I'm not sure why it would be "poor man's" -- your proposal sounds very
> similar to SNI from TLS.

"poor man's" because its just fiddling with the "Protocol Version 
Exchange" string and not introducing new stuff in the protocol ...

> [ ... Problems of SNI ... ]

> Note that SNI (in either TLS or in your SSH proposal) is not
> "negotiated" in a strict sense. Is it offered by the client to the
> server in the clear, in the hopes that it will be supported by the
> server (but willing to be ignored if it is not supported).

Yes, that's exactly how i thought about it ...

>> So my question(s) rephrased:
>> Why isn't there anything like SNI for SSH? For security reasons? Is
>> there no demand? Is there a better solution which I don't know of?

> Is it worth having clients advertise the server's name in the clear on
> the network if there is no proxy in use?  Your proposal neatly avoids
> this question by making it disabled by default.

What is the problem, when the client advertises it? In the case that I'm 
thinking about the DNS advertises the fact, that some hostname is in my 
net directly or NATed or whatever) anyways.
If I'd setup portforwarding on different ports on the proxy to reach the 
sshd of the different backend machines and having multiple hostnames 
(for my http proxy) point to the same proxy IP, how would this be safer?

Anyways, I wouldn't make it a default to send the hostname, because it's 
just ignored on any server except my proxy thingy and therefor useless 
in all other cases.

> You should also realize that some distributors patch their clients to
> add a comment string there anyway (e.g. Debian openssh puts "Debian" in
> the comment there).

Ah ok, I didn't realize this while playing with (obviously) just the 
unpatched version.

> So your proxy could get quite confused if it tries
> to hand the connection off to the "Debian" backend.

Mh. If the proxy doesn't know about a backend machine "Debian" there 
would be no problem. If there is a backend machine with said name a 
connection would be established, but the user (hopefully) cannot 
authenticate.

> If this is a space for hiding other sorts of cleartext connection "hints", then you
> probably want to distinguish your "SNI" hint from other hints.  you
> could perhaps do this by declaring it with a specialized prefix, like
> "Host:", to distinguish it from othe uses of the comment field.  That
> way a comment like "limburger Host:server.example.net" would be cleanly
> parseable.

That's something I thought about an would somehow be possible. But If I 
understood the RFC, the max length is 253 (\r\n not counted). So packing 
to much stuff in the comments field isn't even possible anyway.

> If you decide this is really something that you want, I'd recommend
> modeling your change on the patches that added the VersionAddendum
> configuration option for sshd (but you're talking about adding it to ssh):
>
> (from ChangeLog):
> djm at cvs.openbsd.org 2012/04/12 02:42:32
>   [servconf.c servconf.h sshd.c sshd_config sshd_config.5]
>   VersionAddendum option to allow server operators to append some arbitrary
>   text to the SSH-... banner; ok deraadt@ "don't care" markus@
>
> and then making that string interpret the standard %-escapes, so a
> client who wants to use this feature could do:
>
>   ssh -oVersionAddendum=Host:%h server.example.net
>
> That configuration option seems flexible and generic enough that it
> would fit with the rest of the ssh interface (and it would enable
> distros like debian to drop diffs like
> debian/patches/package-versioning.patch in favor of a one-line addition
> to /etc/ssh/ssh_config).

Thank you for the pointer, I will look into this.

But anyway: the information would have to be transfered in the first 
(unencrypted) line. And - even more when distributors or other clients 
already use the comment field - space there is rare.
Any other implementation of my idea would need updates in the protocol 
itself, and I think i don't want to got there ... ;)

> I'm not convinced that a feature like this is
> orth allocating one of the few remaining short option flags (-H) though :)

Haha ... I think you realized, this was just an example ... :)

> Another thought about your proposed proxy: ssh's DH key exchange results
> in a shared secret based on the exact contents of a bunch of stuff,
> including the connection strings.  Either all of your backend servers
> need to offer the exact same connection string as your proxy offers, or
> your proxy needs to wait to receive the client's connection string
> before forwarding the connection to the backend server.

Yes.

> If you choose the former, then when dealing with system upgrades [...]

No, that's not what I intended. This sure is a PITA.

> If you choose the latter, and there are any SSH clients out there that
> wait for the server's connection string before sending their own, then
> those clients will deadlock when connecting to your proxy.

Ok. Somehow I was convinced, the client has to send its connection 
string first; I must have gotten confused at some point. After your 
description and a short test it's obvious this is not the case. So my 
approach (waiting for the client to send its connection string) would 
exactly have the problems you pointed out.


However, you answered most of the questions I had in mind and pointed 
out problems with my approach. Thank you very much!

Nevertheless: I definitely would like to have some kind of SNI or 
similar for SSH :)


Thanks again & bye, Hannes