[Patch] TCP MD5SIG for OpenSSH

[Alex Bligh]

Thomas,

> Are you saying the random key should be sent in the clear?

No!

> Or are you
> saying this negotiation should be done after the encryption has
> already been established? I'll assume the latter,

Yes

> in which case sure,
> you can have a new random key. IIRC the session key is DH-negotiated
> though, which means neither side gets to *choose* the key. If the
> server just chooses a "random" key it could actually be a backdoored
> key. I don't see a harmful attack here, but it would allow one side of
> the connection to deceive the other about how secure their connection
> is, and leaking key material, even if it's only for this outer layer
> of auth. Hopefully DH is also more secure in the face of passive
> attackers so that *both* sides need to have bad RNG to leak the
> session key as opposed to just one side.

OK, I now understand why you are proposing that. So use a hash
of the DH session key and a randomly generated nonce sent in
plaintext? And then turn it on before crypto is negotiated for
the reasons you suggest.

>> The idea would be for this to detect NAT (without revealing private
>> IP addresses)
> 
> Except for those who do SNAT/DNAT to "bounce" a connection, where it
> would leak other addresses.

I don't /think/ it does. It's only

a) leaking to the client the IP address the server thinks the client has,
   which the client can already discover from the SSH_CONNECTION
   variable. This is only if the option is switched on at the server side.

b) leaking to the server the IP address the client thinks the server has,
   which is only if the option is switched on at both the server and the
   client side, and I find it difficult to see why that would be a problem.

IE if you turn it on server side, you leak something you'd leak already
if a connection fully establishes. If you turn it on both ends, the client
leaks the IP it's trying to connect to.

And of course you'd have to select a non-default option for this to
happen.

>> and avoid TCP-MD5SIG if it's in use, but for TCP-MD5SIG
>> to be off by default anyway. The reason for this is that it might not
>> detect middleboxen (e.g. firewalls) that effectively proxy the TCP
>> session or strip the packets. A couple of dummy ECHO/ECHO REPLY TCP
>> options are used in order to detect such stripping.
> 
> Is this assuming that a middlemox that strips MD5 would also strip
> ECHO?

Yes

> Seems plausible to me, but I don't have the data. If this
> assumption is incorrect it would break SSH through these by default,
> which would be bad.

It would only break such connections *IF* it were turned on on both
client and server (which I am not suggesting would be the default) AND
there was no NAT in the path AND the middlebox in question stripped
some TCP options but not others.

> I don't have enough experience with these boxes to know if they do this.

Summary of Ray's work: middleboxen do every possible bad thing under the
sun, to the extent it is inadvisable to work around the worst of them.

>> This has been
>> obsoleted by RFC5925 (TCP-AO) though I'm not sure how wide support
>> that has.
> 
> My crystal ball says TCP-AO will not happen. 2385 was implemented so
> that Unix boxes could play BGP, so that's a *need*. But anyone who
> implements 5925 will also support 2385, and it's "good enough" (heavy
> quotes here, I'm not defending it), so it's not a *need* for anyone.
> I'm sure someone will implement it eventually in OSS stuff of course.
...
> In any case my patch, and the suggested external tool and your
> post-encryption negotiation, are not in any way blocking future TCP-AO
> implementation, and could be used in parallel. And because of OS
> support, *if* we want TCP-AO then I'd say we *also* want TCP-MD5SIG.
> Maybe in 20 years the latter can be dropped, if that's the case. But
> today TCP-AO can't perhaps even be implemented since it's blocked on
> kernel implementations.

Agree

>> I suspect some of the above may be reinvention of wheels already within RFC5925.
> 
> No, my reading doesn't find anything like that. In fact it explicitly
> states that "NAT breaks this" (section 9.2), so NAT is not handled.
> 
> [1] http://lists.freebsd.org/pipermail/svn-src-user/2013-March/006156.html

OK. I admit I should have read that one more carefully.

-- 
Alex Bligh