[Patch] TCP MD5SIG for OpenSSH

[Thomas ☃ Habets]

On 15 January 2016 at 12:07, Alex Bligh <alex at alex.org.uk> wrote:
> 1. If configured to be on server side (default is off), server says
>    "I am capable of TCP-MD5SIG, and here is the address/port pair
>    I see for you", else proceeds as normal. However, prior to sending
>    this it sends a TCP ECHO option (option 8).
>
> 2. If configured to be on client side (default is off), client
>    examines address/port pair, and checks it against its own
>    version, to detect SNAT at client side. If it wants it says
>    "I am also capable of TCP-MD5SIG, and here is the address/port
>    pair I see for you", else proceeds as normal. But before sending
>    the response, it ensures the TCP ECHO reply (option 9) has been
>    sent.

What is the point of the TCP ECHO?
[ah… middleboxes]

> 3. Server compares supplied address/port pair with what it sees
>    (to detect DNAT like Amazon elastic IPs), and if they are the
>    same, it waits for the TCP ECHO reply, and if it gets it
>    says "Excellent, let's apply TCP-MD5SIG, here is a
>    random key", and from that point on TCP-MD5SIG is applied
>    both times, else proceeds as normal.
>
> I don't see the advantage in hashing a session key (which should
> be kept private) over using a random key.

Are you saying the random key should be sent in the clear? Or are you
saying this negotiation should be done after the encryption has
already been established? I'll assume the latter, 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.

The bigger problem here is still though that it assumes the normal
crypto negotiation has already taken place, and any security problems
with it are not helped by this MD5 signature. Compare again to port
knocking. (I consider port knocking to be the wrong implementation,
personally, since what almost all implementations do is "send a
password in the clear", but are pretending that's not what they're
doing because it's supposedly more stealthy (security through
obscurity). This is a separate topic though)

Putting the negotiation later and under crypto could make it harder to
sync exactly when to turn it on, because TCP segments may contain
partial crypto blocks and may already be sent before the setsockopt()
call on the receiver.

> The random key could
> be hashed with the session key I suppose if the concern was
> entropy.

That probably fixes the concerns I just mentioned with RNG etc.

> 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.

> 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? 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.

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

> Lastly I think you are using TCP-MD5SIG aka RFC2385.

Yes.

> 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.

It's from 2010 and I've been unable to find any spec sheet (that love
to list RFCs they support) that list 5925. I did find a brief mention
of a patch in FreeBSD[1], but it was unclear if it was just "skip this
option" handling or part of a bigger set of patches actually handling
it. Author

In my opinion 5925 implements some trivial parts of key management,
while leaving the big parts completely unaddressed. Maybe the hardest
part of crypto is key management, and TCP-AO provides a hook for some,
but just hand waves the hardest part of cryptography. Yes, it has
better hooks if application layer (e.g. SSH protocol) wants to rotate
keys, and has better replay protection for really long lived
connections (in terms of bytes). But really both of these are much
more important for a plaintext protocol than for SSH. Except for a
possible future preimage attack on MD5 TCP-MD5SIG is just fine for
SSH. (disclaimer: IANACryptographer)

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.

> 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

-- 
☢ Thomas ☢