simon-git: putty (main): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  b22e26f0 Support receiving RFC 8332 rsa-sha2-* host keys.
  1243be89 Support receiving RFC 8308 SSH2_MSG_EXT_INFO.
  33de96ff Support sending RFC 8332 rsa-sha2-* userauth keys.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: main
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2020-11-21 15:16:43

commit b22e26f07bd84eb8c5ef45d7995d4057c0adee21
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=b22e26f07bd84eb8c5ef45d7995d4057c0adee21;hp=40e648db46bae513652079f5fe0c2cc1ecb258e9
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Nov 21 12:45:35 2020 +0000

    Support receiving RFC 8332 rsa-sha2-* host keys.
    
    This is the cleanest part of the RFC 8332 support: I simply add two
    more RSA-based SSH-2 key algorithm vtables, both almost identical to
    the existing one, with different ssh_id strings and signature flags.
    
    Adding those to the HOSTKEY_ALGORITHMS list macro is enough to ensure
    that we advertise support for the new identifiers in our client
    KEXINIT, select the appropriate algorithm if the server announces one
    or both of them too, and use the right version of the signature
    validation.

 ssh.h           |  2 ++
 ssh2transport.h |  2 ++
 sshrsa.c        | 71 ++++++++++++++++++++++++++++++++++++++++++---------------
 3 files changed, 56 insertions(+), 19 deletions(-)

commit 1243be890a9c9f838dd3d1c2a0d21c06c44b727c
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=1243be890a9c9f838dd3d1c2a0d21c06c44b727c;hp=b22e26f07bd84eb8c5ef45d7995d4057c0adee21
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Nov 21 14:29:30 2020 +0000

    Support receiving RFC 8308 SSH2_MSG_EXT_INFO.
    
    We now add the appropriate advertisement to our KEXINIT that indicates
    a willingness to receive EXT_INFO. Code in the BPP enforces that it
    must appear in one of the permitted locations in the protocol (in
    particular, this ensures a pre-key-exchange MITM can't get away with
    inserting it into the initial cleartext segment of the protocol). And
    when we receive it, we look through it for extension names we know
    about.
    
    No functional change (except for the advertisement in KEXINIT): we
    don't yet actually do anything in response to any extension reported
    in EXT_INFO.

 ssh.h           |  1 +
 ssh2bpp-bare.c  | 12 ++++++++++++
 ssh2bpp.c       | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 ssh2transport.c | 37 +++++++++++++++++++++++++++++++++++++
 sshbpp.h        |  3 +++
 5 files changed, 110 insertions(+)

commit 33de96ffa96c19955a4f078a9235e0c7284670dd
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=33de96ffa96c19955a4f078a9235e0c7284670dd;hp=1243be890a9c9f838dd3d1c2a0d21c06c44b727c
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Nov 21 14:44:46 2020 +0000

    Support sending RFC 8332 rsa-sha2-* userauth keys.
    
    We parse enough of EXT_INFO to spot when the server advertises support
    for them, and if it does, we upgrade the key algorithm name from
    "ssh-rsa" to one of the other two, and set appropriate signing flags.
    
    This doesn't actually end up using the ssh_rsa_sha256 / ssh_rsa_sha512
    vtables I set up two commits ago, because it's easier to just vary the
    flags word we pass to ssh_key_sign.
    
    The upgrade is done by ad-hoc special-case code in ssh2userauth.c. I
    could have done it by introducing a new ssh_keyalg vtable method for
    'please upgrade to your favourite version of yourself according to
    some set of flags from the BPP', but it just didn't seem like a good
    idea at this stage, because it presupposes that quirks in the
    algorithm selection are going to follow a consistent pattern, and I
    think it's much more likely that the next weird thing in this area
    will be something totally different. So I've left it as a localised
    bodge for now, and we can always refactor it into something nicer once
    we have more information and know what the nicer thing _is_.

 ssh2transport.c | 27 +++++++++++++++++++++++++++
 ssh2userauth.c  | 51 ++++++++++++++++++++++++++++++++++++++++-----------
 2 files changed, 67 insertions(+), 11 deletions(-)