Previously, there was non-consistent usage of constans SSH_KEX_METHODS,
KEX_METHODS_SIZE and of magic number 10 to reference the arrays used
for algorithm negotiation by peers. This commit settles down to the single
constant and its usage throughout the whole codebase.
Fixes T195
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Replace all occurrences of the deprecated function ssh_print_hexa() with
the introduced ssh_log_hexdump().
Signed-off-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Previously, if the SSH_OPTIONS_HOSTKEYS option was set by any mean,
including the client configuration file, the keys in known_hosts files
wouldn't be considered before advertising the list of wanted host keys.
This could result in the client requesting the server to provide a
signature using a key not present in the known_hosts files (e.g. when
the first wanted algorithm in SSH_OPTIONS_HOSTKEYS is not present in the
known_hosts files), causing a host key mismatch and possible key
rejection.
Now, the keys present in the known_hosts files are prioritized over the
other wanted keys. This do not change the fact that only keys of types
present in the list set in SSH_OPTIONS_HOSTKEYS will be accepted and
prioritized following the order defined by such list.
The new wanted list of hostkeys is given by:
- The keys present in known_hosts files, ordered by preference defined
in SSH_OPTIONS_HOSTKEYS. If the option is not set, a default order
of preference is used.
- The other keys present in the same option are appended without adding
duplicates. If the option is not set, the default list of keys is
used.
Fixes: T156
Signed-off-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Previously, if the client supported rsa-sha2-256 or rsa-sha2-512, the
server would advertise the extensions as supported without checking its
own list of allowed algorithms. Now the server will only advertise
allowed signature algorithms.
Signed-off-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
When in FIPS mode, filter the algorithms to enable only the allowed
ones. If any algorithm is explicitly set through options or
configuration file, they are kept.
Signed-off-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
The default order of preference for signature algorithms were not
consistent. This makes the following order of preference to be the
default order:
* ssh-ed25519
* ecdsa-sha2-nistp521
* ecdsa-sha2-nistp384
* ecdsa-sha2-nistp256
* rsa-sha2-512
* rsa-sha2-256
* ssh-rsa
* ssh-dss
Signed-off-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Replace the old tokens handling functions usage with the new implementation.
Signed-off-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
The added functions allow splitting chains of tokens separated by a
given character (usually ','), and extracting matching parts between two
chains of tokens.
The previously existing functions in kex.c were replaced by the
introduced ones.
Signed-off-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
In preparation for deferring computation on DH secret material to
crypto library specific backends
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Rename and refactor how some variables are held in ssh_crypto_struct.
Refactor allocation of dh exchange public keys.
This is in preparation for switching the code to use openssl native DH
handling and allowed to better reason about the code and the overall API.
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Cleanup the KDF function to use only one function per crypto backend.
Improve the KDF function to properly handle requested lenght and to
avoid unnecessarily reallocating buffers.
In OpenSSL use the new EVP_KDF API if available.
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This patch simply reworks the code to make it more understandable and
reduce if() branches.
It also avoids reallocs, and instead uses a support buffer to hold
intermediate results of the hmac function so that no buffer overrides
happen when the requested size is not an exact mutiple of the digest_len.
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This adds the OpenSSH HMACs that do encrypt then mac. This is a more
secure mode than the original HMAC. Newer AEAD ciphers like chacha20 and
AES-GCM are already encrypt-then-mac, but this also adds it for older
legacy clients that don't support those ciphers yet.
Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
Reviewed-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Ensure to honor the client preference ordering when enabling one of
the RFC8332 RSA signature extensions (`rsa-sha2-{256,512}`).
Before this change, libssh unconditionally selects the `rsa-sha2-512`
algorithm for clients which may have offered "rsa-sha2-256,rsa-sha2-512".
The change can be observed before-and-after with the pkd tests:
./pkd_hello -t torture_pkd_openssh_rsa_rsa_sha2_256_512
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
By default, the list of already stored known host types is preferred,
but this selection so far ignored the SHA2 extension and excluded these
keys in the KEXINIT list leading to not using this extension if not
explicitly enabled from configuration.
This commit extends the default list with the SHA2 signatures algoritms
and compares only base types so they can be listed in the KEXINIT list.
This adjust the tests to expect the full list of algorithms to pass.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
If the server had an RSA host key, it provided unconditionally SHA2
signatures without consulting the client proposed list of supported host
keys.
This commit implements more fine-grained detection of the extension
to provide the client with valid signatures according to RFC 8332
Section 3.1.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
The default rekeying recommendations are specified in
RFC4344 Section 3 (First and Second Rekeying Recommendations).
Additionally, the rekeying can be specified in configuration
file/options allowing us to turn the rekeying off, base it
on time or make it more strict.
The code is highly inspired by the OpenSSH rekeying code.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Daiki Ueno <dueno@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This is more reliable fix than 83f2ac4a, which was failing for the
server initialized rekeying, because the session_state is altered
by receiving the KEXINIT from server.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
The RFC 8308 clearly says, that the additional ext-info-c should
be added only to the first SSH_MSG_KEXINIT.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Previously, not all of the host keys algorithms were used for algorithm
negotiation. This verifies the algorithms list is sane and ordered
with the key types from known hosts in the first place.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Previously, only the algorithms we had a keys for in known_hosts
were used, which could lead to no-matching algorithms errors if the
one key we used to depend on was removed from the server.
This commit adds also the other algorithms, but lists them only after
all the key types we have in known_hosts file.
Resolves: T105
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
The code as it was written used only the first algorithm from
preferred_hostkeys array and compared it with the list returned
from the known hosts.
This commit is fixing the code so we actually compare each of the
algorithms from both of the lists and returns the intersection.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
The commit also propares the internals throughout the code base
for the inclusion of a new AEAD cipher, because previously, the
source code counted only with chacha20-poly1305 cipher, which
is very specific in many cases.
The SSH_HMAC_AEAD_GCM mac algorithm is not actually used, but the name
needed to be defined so we can match in the algorithms selection per
OpenSSH specification (MACs are ignored in case GCM is select as a cipher [1]).
If the provided OpenSSL does not provide EVP_aes_128_gcm() function,
the AES-GCM ciphers will not be compiled in.
[1] https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL.chacha20poly1305?annotate=HEAD
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This includes intercepting the ext-info-c string from
the client kex proposal, configuring the server to allow using
this extension and sending the SSH_MSG_EXT_INFO packet back
to the client after the new keys are in use.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This effectively allows to disable using the SHA2 extension, disable
other old public key mechanisms out of the box (hello DSA) or force
the new SHA2-based key algorithm types if needed.
This exposes the default_methods array from kex.c.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
