On 15 Jan 2016, at 11:44, Thomas ☃ Habets <habets@xxxxxxxxxx> wrote: > 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) 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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
