Re: Terrapin

> Brian Pence <[email protected]> writes:
>> OpenSSH supports a number of transport-layer hardening measures under a
>> "strict KEX" feature.

> Ugh, another incompletely-specified [*] homebrew add-on kludged onto
> SSH without any public consultation, to fix the problems caused by the
> first incompletely-specified homebrew add-on kludged onto SSH without
> any public consultation. What happened to publishing RFCs and getting
> public review and feedback in case there are problems?

That seems a bit unfair to me. Yes, you'd like protocol changes to be
reviewed and widely agreed on. But you _also_ want existing known
vulnerabilities to have a fix deployed (a) reasonably quickly, (b)
before you tell absolutely everyone what they are. It's hard to see how
you can have both!

I'd completely support the idea of _now_ trying to come up with a
better, futureproof, longer-term fix that the general consensus prefers
to strict-kex. But I don't think it was silly to do _something_ quickly.

(I'm not defending this out of self-interest, incidentally; I was
notified in advance so PuTTY could implement the fix, but I didn't get
significant input into what the fix was going to _be_.)

>> During initial KEX, terminate the connection if any unexpected or
>> out-of- sequence packet is received. This includes terminating the
>> connection if the first packet received is not SSH2_MSG_KEXINIT.
>> [...]
> Are there any implementations that would break if you did this anyway?
> Assuming that what it's trying to say is "terminate the connection if
> the first packet isn't SSH2_MSG_KEXINIT".

"This includes": that's _one_ of the things it's trying to say, but not
only that. The idea is that the whole sequence of KEX packets should
contain only the ones absolutely necessary for the KEX, e.g. two
KEXINITS, an ECDH_INIT, an ECDH_REPLY and a pair of NEWKEYS, or the
equivalent for other systems. An SSH_MSG_IGNORE or MSG_DEBUG appearing
as an additional packet _anywhere_ in that sequence violates the
strict-kex constraint.

(By the literal wording, so would SSH_MSG_UNIMPLEMENTED, but I think we
can presume that anyone sending that during initial KEX is not expecting
the KEX to conclude without incident anyway!)

It seems very plausible to me that there could be implementations whose
core transport layer is well detached from the key exchange, and which
could be configured to send SSH_MSG_IGNORE as a keepalive on a timer,
and perhaps that timer might carry on running while the implementation
was still sitting at, say, a host key confirmation prompt. So an
SSH_MSG_IGNORE would show up in the cleartext part of the connection
before key exchange had completed to the point of exchanging NEWKEYS and
going secure.

Cheers,
Simon

-- 
import hashlib; print((lambda p,q,g,y,r,s,m: (lambda w:(pow(g,int(hashlib.sha1(
m.encode('ascii')).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r
and s%q!=0 and m)(12342649995480866419, 2278082317364501, 1670428356600652640,
5398151833726432125, 645223105888478, 1916678356240619, "<[email protected]>"))