cmdline.c | 8 8 + 0 - 0 !
config.c | 4 4 + 0 - 0 !
doc/config.but | 43 43 + 0 - 0 !
pscp.c | 2 2 + 0 - 0 !
psftp.c | 2 2 + 0 - 0 !
putty.h | 1 1 + 0 - 0 !
settings.c | 2 2 + 0 - 0 !
ssh.c | 4 3 + 1 - 0 !
ssh1login.c | 14 13 + 1 - 0 !
ssh2userauth.c | 20 16 + 4 - 0 !
sshppl.h | 2 1 + 1 - 0 !
unix/uxplink.c | 2 2 + 0 - 0 !
windows/winhelp.h | 1 1 + 0 - 0 !
windows/winplink.c | 2 2 + 0 - 0 !
14 files changed, 100 insertions(+), 7 deletions(-)

 new option to reject 'trivial' success of userauth.

Suggested by Manfred Kaiser, who also wrote most of this patch
(although outlying parts, like documentation and SSH-1 support, are by
me).

This is a second line of defence against the kind of spoofing attacks
in which a malicious or compromised SSH server rushes the client
through the userauth phase of SSH without actually requiring any auth
inputs (passwords or signatures or whatever), and then at the start of
the connection phase it presents something like a spoof prompt,
intended to be taken for part of userauth by the user but in fact with
some more sinister purpose.

Our existing line of defence against this is the trust sigil system,
and as far as I know, that's still working. This option allows a bit of
extra defence in depth: if you don't expect your SSH server to
trivially accept authentication in the first place, then enabling this
option will cause PuTTY to disconnect if it unexpectedly does so,
without the user having to spot the presence or absence of a fiddly
little sigil anywhere.

Several types of authentication count as 'trivial'. The obvious one is
the SSH-2 "none" method, which clients always try first so that the
failure message will tell them what else they can try, and which a
server can instead accept in order to authenticate you unconditionally.
But there are two other ways to do it that we know of: one is to run
keyboard-interactive authentication and send an empty INFO_REQUEST
packet containing no actual prompts for the user, and another even
weirder one is to send USERAUTH_SUCCESS in response to the user's
preliminary *offer* of a public key (instead of sending the usual PK_OK
to request an actual signature from the key).

This new option detects all of those, by clearing the 'is_trivial_auth'
flag only when we send some kind of substantive authentication response
(be it a password, a k-i prompt response, a signature, or a GSSAPI
token). So even if there's a further path through the userauth maze we
haven't spotted, that somehow avoids sending anything substantive, this
strategy should still pick it up.

(cherry picked from commit 5f5c710cf3704737e24ffceb2c918e412a2a674f)

doc/man-pl.but | 9 9 + 0 - 0 !
doc/man-pscp.but | 9 9 + 0 - 0 !
doc/man-psft.but | 9 9 + 0 - 0 !
doc/man-putt.but | 9 9 + 0 - 0 !
doc/plink.but | 2 2 + 0 - 0 !
doc/pscp.but | 2 2 + 0 - 0 !
doc/using.but | 9 9 + 0 - 0 !
7 files changed, 49 insertions(+)

 document -no-trivial-auth more thoroughly.

misc.h | 4 4 + 0 - 0 !
1 file changed, 4 insertions(+)

 new macro ptrlen_decl_literal.

This is like PTRLEN_LITERAL, but you can use it in a _declaration_ of
a compile-time constant ptrlen, instead of a literal in expression
context. 'const ptrlen foo = PTRLEN_DECL_LITERAL("bar");'

ssh.h | 1 1 + 0 - 0 !
sshcommon.c | 9 7 + 2 - 0 !
2 files changed, 8 insertions(+), 2 deletions(-)

 extra utility function add_to_commasep_pl.

Just like add_to_commasep, but takes a ptrlen.

ssh2bpp.c | 12 10 + 2 - 0 !
ssh2transport.c | 84 78 + 6 - 0 !
ssh2transport.h | 2 2 + 0 - 0 !
sshbpp.h | 6 4 + 2 - 0 !
4 files changed, 94 insertions(+), 10 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.)

[backport: also pulled in kexinit_keyword_found from commit f2e7086902b3605]

ssh.h | 26 19 + 7 - 0 !
sshmd5.c | 26 13 + 13 - 0 !
sshsh256.c | 100 55 + 45 - 0 !
sshsh512.c | 35 15 + 20 - 0 !
sshsha.c | 97 52 + 45 - 0 !
5 files changed, 154 insertions(+), 130 deletions(-)

 refactor the ssh_hash vtable. (nfc)

Refactor the ssh_hash vtable. (NFC)

The idea is to arrange that an ssh_hash object can be reused without
having to free it and allocate a new one. So the 'final' method has
been replaced with 'digest', which does everything except the trailing
free; and there's also a new pair of methods 'reset' and 'copyfrom'
which overwrite the state of a hash with either the starting state or
a copy of another state. Meanwhile, the 'new' allocator function has
stopped performing 'reset' as a side effect; now it _just_ does the
administrative stuff (allocation, setting up vtables), and returns an
object which isn't yet ready to receive any actual data, expecting
that the caller will either reset it or copy another hash state into
it.

In particular, that means that the SHA-384 / SHA-512 pair no longer
need separate 'new' methods, because only the 'reset' part has to
change between them.

This commit makes no change to the user-facing API of wrapper
functions in ssh.h, except to add new functions which nothing yet
calls. The user-facing ssh_hash_new() calls the new and reset methods
in succession, and the copy and final methods still exist to do
new+copy and digest+free.

ssh.h | 5 5 + 0 - 0 !
sshhmac.c | 48 45 + 3 - 0 !
2 files changed, 50 insertions(+), 3 deletions(-)

 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.

[backport]
- Drop nullmac_next_message uses that is not used in this bullseye version

Makefile.am | 24 12 + 12 - 0 !
Recipe | 9 7 + 2 - 0 !
defs.h | 2 2 + 0 - 0 !
rfc6979.c | 359 359 + 0 - 0 !
ssh.h | 15 11 + 4 - 0 !
sshdss.c | 116 3 + 113 - 0 !
sshecc.c | 14 4 + 10 - 0 !
test/cryptsuite.py | 253 249 + 4 - 0 !
testcrypt.h | 5 5 + 0 - 0 !
testsc.c | 60 60 + 0 - 0 !
10 files changed, 712 insertions(+), 145 deletions(-)

 switch to rfc 6979 for dsa nonce generation.

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