[Patch] TCP MD5SIG for OpenSSH

[Alex Bligh]

On 15 Jan 2016, at 11:44, Thomas ☃ Habets <habets at google.com> wrote:

> On 15 January 2016 at 08:48, Alex Bligh <alex at alex.org.uk> wrote:
>>> The socket option is enabled *after* connection establishment, thus
>>> doesn't protect against SYN floods. This is because server doesn't
>>> know (in userspace) what the address of the peer is until they
>>> connect. Again because signed addresses.
>> So could they exchange a secret as part of the session, obviating
>> the need for any set up?
> 
> They could. Making it part of the protocol does expose more code to be
> vulnerable to any preauth attacks though. One of the main benefits is
> that if the remote end doesn't have the right key then the data won't
> even be parsed. IIRC this has protected OpenVPN installations with its
> tls-auth option when there's been OpenSSL and/or OpenVPN bugs.
> 
> You could, for example, set the key to SHA256(SSH session key) or
> something, since a session key is already negotiated for the
> connection. (this is just what comes immediately to mind)

I'm guessing I was thinking of something like this (designed so
neither end reveals its 'inside-NAT' IP address):

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.

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. The random key could
be hashed with the session key I suppose if the concern was
entropy.

The idea would be for this to detect NAT (without revealing private
IP 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.

Ray Bellis did some work on analysing all the evil things NAT devices
and other middleboxen might do in a different context (DNS/UDP),
  https://www.icann.org/committees/security/sac035.pdf
and detecting NAT. There's this draft:
  https://tools.ietf.org/html/draft-bellis-behave-natpresent-00
but I don't think it got anywhere. So we are left with heuristics.

Lastly I think you are using TCP-MD5SIG aka RFC2385. This has been
obsoleted by RFC5925 (TCP-AO) though I'm not sure how wide support
that has. I suspect some of the above may be reinvention of wheels
already within RFC5925.

-- 
Alex Bligh