On 15 January 2016 at 12:07, Alex Bligh <alex@xxxxxxxxxxx> 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 ☢ _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
