Re: Terrapin

--000000000000e29f31060d8156ae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>From the OpenSSH PROTOCOL document:

1.10 transport: strict key exchange extension

OpenSSH supports a number of transport-layer hardening measures under
a "strict KEX" feature. This feature is signalled similarly to the
RFC8308 ext-info feature: by including a additional algorithm in the
initial SSH2_MSG_KEXINIT kex_algorithms field. The client may append
"[email protected]" to its kex_algorithms and the server
may append "[email protected]". These pseudo-algorithms
are only valid in the initial SSH2_MSG_KEXINIT and MUST be ignored
if they are present in subsequent SSH2_MSG_KEXINIT packets.

When an endpoint that supports this extension observes this algorithm
name in a peer's KEXINIT packet, it MUST make the following changes to
the protocol:

a) 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.
   Unexpected packets for the purpose of strict KEX include messages
   that are otherwise valid at any time during the connection such as
   SSH2_MSG_DEBUG and SSH2_MSG_IGNORE.
b) After sending or receiving a SSH2_MSG_NEWKEYS message, reset the
   packet sequence number to zero. This behaviour persists for the
   duration of the connection (i.e. not just the first
   SSH2_MSG_NEWKEYS).


Brian Pence
Celestial Software
901-283-1970 <http://voice.google.com/calls?a=3Dnc,%2B19012831970>
http://www.celestialsoftware.net


On Wed, Dec 27, 2023 at 9:08=E2=80=AFAM Brian Pence <bpence@celestialsoftwa=
re.net>
wrote:

> And at least one claim that some implementations knew about this about a
> month before public disclosure, so they were working on 'strict kex' for =
a
> while.
>
> This protocol vulnerability was pre-disclosed to us by Fabian B=C3=A4umer=
,
> Marcus Brinkmann, and J=C3=B6rg Schwenk, on 17 November 2023. For full de=
tails
> of their report, see their dedicated website about the Terrapin attack
> <https://terrapin-attack.com/>.
>
>
> Brian Pence
> Celestial Software
> 901-283-1970 <http://voice.google.com/calls?a=3Dnc,%2B19012831970>
> http://www.celestialsoftware.net
>
>
> On Wed, Dec 27, 2023 at 9:06=E2=80=AFAM Brian Pence <bpence@celestialsoft=
ware.net>
> wrote:
>
>> This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT,
>> Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before
>> 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh
>> before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.=
4.6,
>>
>> Then each of the 'fixed' packages will have some kind of documentation
>> describing their use of 'strict kex'
>> For example putty 0.80:
>>
>> https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-terrapi=
n.html
>>
>> To mitigate the vulnerability, the OpenSSH project has defined a SSH
>> extension called 'strict KEX' (documented in their PROTOCOL
>> <https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL?rev=3DHEAD&content-=
type=3Dtext/x-cvsweb-markup> document),
>> which PuTTY 0.80 implements.
>>
>>
>>
>>
>> Brian Pence
>> Celestial Software
>> 901-283-1970 <http://voice.google.com/calls?a=3Dnc,%2B19012831970>
>> http://www.celestialsoftware.net
>>
>>
>> On Mon, Dec 25, 2023 at 1:58=E2=80=AFAM Peter Gutmann <[email protected]=
nd.ac.nz>
>> wrote:
>>
>>> Brian Pence <[email protected]> writes:
>>>
>>> >Related publication at NIST:
>>> https://nvd.nist.gov/vuln/detail/CVE-2023-48795
>>> >
>>> >Implementation versions that are identified as NOT VULNERABLE have all
>>> >recently implemented "strict key exchange"
>>>
>>> Where are you seeing that?  I can't find that text anywhere on the page=