On 15 January 2016 at 08:48, Alex Bligh <alex@xxxxxxxxxxx> 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) It'd be hard to automate and make default though, since if done when the connection goes through NAT it will fail the connection. You could work around that by only enabling it for IPv6, and hope that nobody's doing IPv6 NAT. It'd still protect against other attacks like third parties fiddling with an already established connection, be it by RSTing because they know the accepted RST window or more sophisticated attacks. But again, only solves a subset of the problems. -- ☢ Thomas ☢ _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
