ssh/transport2.c | 8 4 + 4 - 0 !
1 file changed, 4 insertions(+), 4 deletions(-)

 fix check for "ext-info-s".

ssh2_scan_kexinits must check to see whether it's behaving as an SSH
client or server, in order to decide whether to look for "ext-info-s"
in the server's KEXINIT or "ext-info-c" in the client's, respectively.

This check was done by testing the pointer 'server_hostkeys' to see if
it was non-NULL. I think I must have imagined that a variable of that
name meant "the host keys we have available to offer the client, if we
are the server", as the similarly named parameter 'our_hostkeys' in
write_kexinit_lists in fact does mean. So I expected it to be non-NULL
for the server and NULL for the client, and coded accordingly.

But in fact it's used by the client: it collects host key types the
client has _seen_ from the server, in order to offer them as cross-
certification actions in the specials menu. Moreover, it's _always_
non-NULL, because in the server, it's easier to leave it present but
empty than to get rid of it.

So this code was always behaving as if it was the server, i.e. it was
looking for "ext-info-c" in the client KEXINIT. When it was in fact
the client, that test would always succeed, because we _sent_ that
KEXINIT ourselves!

But nobody ever noticed, because when we're the client, it doesn't
matter whether we saw "ext-info-c", because we don't have any reason
to send EXT_INFO from client to server. We're only concerned with
server-to-client EXT_INFO. So this embarrassing bug had no actual
effect.

ssh/transport2.c | 29 17 + 12 - 0 !
1 file changed, 17 insertions(+), 12 deletions(-)

 factor out the check for ext-info-* keyword.

I'm about to want to use the same code to check for something else.
It's only a handful of lines, but even so.

Also, since the string constants are mentioned several times, this
seems like a good moment to lift them out into reusable static const
ptrlens.

console.c | 14 2 + 12 - 0 !
proxy/sshproxy.c | 48 38 + 10 - 0 !
putty.h | 24 12 + 12 - 0 !
ssh.h | 6 6 + 0 - 0 !
ssh/common.c | 73 73 + 0 - 0 !
ssh/login1.c | 2 1 + 1 - 0 !
ssh/server.c | 4 2 + 2 - 0 !
ssh/transport2.c | 21 9 + 12 - 0 !
stubs/null-seat.c | 6 4 + 2 - 0 !
unix/console.c | 56 35 + 21 - 0 !
unix/dialog.c | 96 51 + 45 - 0 !
unix/platform.h | 4 2 + 2 - 0 !
utils/tempseat.c | 4 2 + 2 - 0 !
windows/console.c | 64 36 + 28 - 0 !
windows/dialog.c | 112 56 + 56 - 0 !
windows/platform.h | 4 2 + 2 - 0 !
16 files changed, 331 insertions(+), 207 deletions(-)

 refactor confirm_weak to use seatdialogtext.

This centralises the messages for weak crypto algorithms (general, and
host keys in particular, the latter including a list of all the other
available host key types) into ssh/common.c, in much the same way as
we previously did for ordinary host key warnings.

The reason is the same too: I'm about to want to vary the text in one
of those dialog boxes, so it's convenient to start by putting it
somewhere that I can modify just once.

ssh/bpp.h | 6 4 + 2 - 0 !
ssh/bpp2.c | 12 10 + 2 - 0 !
ssh/transport2.c | 88 81 + 7 - 0 !
ssh/transport2.h | 2 2 + 0 - 0 !
4 files changed, 97 insertions(+), 11 deletions(-)

 support openssh's new strict kex feature.

This is enabled via magic signalling keywords in the kex algorithms
list, similarly to ext-info-{c,s}. If both sides announce the
appropriate keyword, then this signals two changes to the standard SSH
protocol:

 1. NEWKEYS resets packet sequence numbers: following any NEWKEYS, the
    next packet sent in the same direction has sequence number zero.

 2. No extraneous packets such as SSH_MSG_IGNORE are permitted during
    the initial cleartext phase of the SSH protocol.

These two changes between them defeat the 'Terrapin' vulnerability,
aka CVE-2023-48795: a protocol-level exploit in which, for example, a
MITM injects a server-to-client SSH_MSG_IGNORE during the cleartext
phase, and deletes an initial segment of the server-to-client
encrypted data stream that it guesses is the right size to be the
server's SSH_MSG_EXT_INFO, so that both sides agree on the sequence
number of the _following_ server-to-client packet. In OpenSSH's
modified binary packet protocol modes this attack can go completely
undetected, and force a downgrade to (for example) SHA-1 based RSA.

(The ChaCha20/Poly1305 binary packet protocol is most vulnerable,
because it reinitialises the IV for each packet from scratch based on
the sequence number, so the keystream doesn't get out of sync.
Exploiting this in OpenSSH's ETM modes requires additional faff to
resync the keystream, and even then, the client likely sees a
corrupted SSH message at the start of the stream - but it will just
send SSH_MSG_UNIMPLEMENTED in response to that and proceed anyway. CBC
modes and standard AES SDCTR aren't vulnerable, because their MACs are
based on the plaintext rather than the ciphertext, so faking a correct
MAC on the corrupted packet requires the attacker to know what it
would decrypt to.)

crypto/aes-select.c | 16 10 + 6 - 0 !
1 file changed, 10 insertions(+), 6 deletions(-)

 add missing flags to aes selector vtables.

They ought to have the same data as the real AES implementations they
will hand off to.

ssh.h | 10 9 + 1 - 0 !
ssh/common.c | 32 26 + 6 - 0 !
ssh/login1.c | 2 1 + 1 - 0 !
ssh/transport2.c | 90 83 + 7 - 0 !
ssh/transport2.h | 4 4 + 0 - 0 !
5 files changed, 123 insertions(+), 15 deletions(-)

 warn about terrapin vulnerability for unpatched servers.

If the KEXINIT exchange results in a vulnerable cipher mode, we now
give a warning, similar to the 'we selected a crypto primitive below
the warning threshold' one. But there's nothing we can do about it at
that point other than let the user abort the connection.

ssh/transport2.c | 83 64 + 19 - 0 !
1 file changed, 64 insertions(+), 19 deletions(-)

 remove fatal-error reporting from scan_kexinits.

This will allow it to be called in a second circumstance where we're
trying to find out whether something _would_ have worked, so that we
never want to terminate the connection.

ssh.h | 1 1 + 0 - 0 !
ssh/common.c | 11 11 + 0 - 0 !
ssh/transport2.c | 138 138 + 0 - 0 !
3 files changed, 150 insertions(+)

 terrapin warning: say if reconfiguration can help.

The Terrapin vulnerability affects the modified binary packet protocol
used with ChaCha20+Poly1305, and also CBC-mode ciphers in ETM mode.
It's best prevented by the new strict-kex mode, but if the server
can't handle that protocol alteration, another approach is to change

crypto/hmac.c | 45 43 + 2 - 0 !
ssh.h | 5 5 + 0 - 0 !
2 files changed, 48 insertions(+), 2 deletions(-)

 add an extra hmac constructor function.

Add an extra HMAC constructor function.

This takes a plain ssh_hashalg, and constructs the most natural kind
of HMAC wrapper around it, taking its key length and output length
to be the hash's output length. In other words, it converts SHA-foo
into exactly the thing usually called HMAC-SHA-foo.

It does it by constructing a new ssh2_macalg vtable, and including it
in the same memory allocation as the actual hash object. That's the
first time in PuTTY I've done it this way.

Nothing yet uses this, but a new piece of code is about to.

crypto/CMakeLists.txt | 1 1 + 0 - 0 !
crypto/dsa.c | 116 3 + 113 - 0 !
crypto/ecc-ssh.c | 14 4 + 10 - 0 !
crypto/rfc6979.c | 359 359 + 0 - 0 !
defs.h | 2 2 + 0 - 0 !
ssh.h | 15 11 + 4 - 0 !
test/cryptsuite.py | 249 245 + 4 - 0 !
test/testcrypt-func.h | 6 6 + 0 - 0 !
test/testsc.c | 59 59 + 0 - 0 !
9 files changed, 690 insertions(+), 131 deletions(-)

 switch to rfc 6979 for dsa nonce generation.

This fixes a vulnerability that compromises NIST P521 ECDSA keys when
they are used with PuTTY's existing DSA nonce generation code. The
vulnerability has been assigned the identifier CVE-2024-31497.

PuTTY has been doing its DSA signing deterministically for literally
as long as it's been doing it at all, because I didn't trust Windows's
entropy generation. Deterministic nonce generation was introduced in
commit d345ebc2a5a0b59, as part of the initial version of our DSA
signing routine. At the time, there was no standard for how to do it,
so we had to think up the details of our system ourselves, with some
help from the Cambridge University computer security group.

More than ten years later, RFC 6979 was published, recommending a
similar system for general use, naturally with all the details