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>
This will make it easier to do Encrypt-then-MAC checks as those will be
on the direct encrypted data received before decrypting which means they
are not allocated in an ssh buffer at that point yet.
Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
Reviewed-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
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>
And remove most of the direct access to the structure throughout the code
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Daiki Ueno <dueno@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
If the rekey is initialized by client, it sends the first KEXINIT
message, changes to the INIT_SENT state and waits for the KEXINIT
message from the server. This was not covered in the current filter.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Daiki Ueno <dueno@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
When the server requests rekey, it can send the SSH2_MSG_EXT_INFO. This
message was being filtered out by the packet filtering. This includes a
test to enforce the filtering rules for this packet type.
Signed-off-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
The packet filter checks required states for the incoming packets and
reject them if they arrived in the wrong state.
Fixes T101
Signed-off-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This removes the allocation for the header buffer for each packet we
send.
Signed-off-by: Andreas Schneider <asn@cryptomilk.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
RFC 8308: The extension negotiation in Secure Shell (SSH) Protocol
RFC 8332: Use of RSA Keys with SHA-256 and SHA-512
in the Secure Shell (SSH) Protocol
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
As ssh_buffer_get_len() actually calls ssh_buffer_get_rest_len(), let's
just use the first one. This is a preparatory step for removing
ssh_buffer_get_rest_len().
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Having "ssh_" prefix in the functions' name will avoid possible clashes
when compiling libssh statically.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Having "ssh_" prefix in the functions' name will avoid possible clashes
when compiling libssh statically.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
In packet_send2, rather than issue two separate buffer_prepend_data calls
(each of which may entail realloc + memmove + memcpy), elide the prepend
work into a single buffer_prepend_data: the header information is computed
locally, and a single 5 byte prepend operation is now done instead of
prepending 1, then 4 bytes.
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
After discussion with Aris and it was not obvious enough to understand
the issue we decided to refactor it.
Reviewd-by: Aris Adamantiadis <aris@0xbadc0de.be>
If we receive a packet of length exactly blocksize, then
packet_decrypt gets called on a buffer of size 0. The check at the
beginning of packet_decrypt indicates that the function should be
called on buffers of at least one blocksize, though the check allows
through zero length. As is packet_decrypt can return -1 when len is 0
because malloc can return NULL in this case: according to the ISO C
standard, malloc is free to return NULL or a pointer that can be freed
when size == 0, and uclibc by default will return NULL here (in
"non-glibc-compatible" mode). The net result is that when using
uclibc connections with libssh can anomalously fail.
Alternatively, packet_decrypt (and probably packet_encrypt for
consistency) could be made to always succeed on len == 0 without
depending on the behavior of malloc.
Thanks to Josh Berlin for bringing conneciton failures with uclibc to
my attention.
Signed-off-by: Alan Dunn <amdunn@gmail.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
