This way we avoid having to pre-generate the message when it could
theoretically still get modified by a task that follows or from a plugin
via message() hook.
In particular as responder, this delays costly cryptographic operations
until the IKE_AUTH request is received, which is preferable to reduce
the impact of DoS attacks.
Another advantage is that the key material is not changed until all tasks
built or processed a message.
This way we avoid parsing messages with unexpected message IDs, which
might not even be possible if we don't have the keys anymore. However,
the next commit should avoid the latter and this way we avoid deriving
keys for retransmits or unexpected messages.
This also changes how retransmits for fragmented messages are triggered.
Previously, we waited for all fragments and reconstructed the message
before retransmitting the response. Now we only track the first
fragment and if we receive a retransmit of it respond immediately
without waiting for other fragments (which are now ignored). This is in
compliance with RFC 7383, section 2.6.1, and can avoid issues if there
are lots of fragments.
This way we can use the IKE_REKEYED state for both redundant and old SAs
to suppress ike_updown().
In the ike-delete task we don't suppress events in state IKE_REKEYING as
that's the case when we delete an SA the peer is currently rekeying with
multiple key exchanges.
This gives us more flexibility with tasks that return NEED_MORE (currently
none of the colliding tasks do, but that will change with multi-KE
rekeyings). The active task has to check itself if the passive task is
done and should be removed from the task manager.
Since f67199378d ("ike-rekey: Handle undetected collisions also if
delete is delayed") we only ever track tasks of type TASK_IKE_REKEY, so
there is no need to check the type or use the generic task_t interface.
Also changed some of the comments to clarify collision handling.
If the peer successfully rekeyed the SA it gets marked as IKE_REKEYED
and it remains until the peer deletes it (or a timeout). There is no
point in rekeying such SAs again.
IKE_REKEYING will be relevant if we have multi-KE rekeyings and are
waiting for followup key exchanges for a passive rekeying.
This avoids the use of a variable length array, which should probably
be avoided in general due to potential performance, portability and
security issues (not in this particular case, though).
Closesstrongswan/strongswan#1095
The compiler warned that a dangling pointer might be used because `name`,
which is returned from the function via `ima_name`, might point into the
locally determined `uri`. Determining the URI outside and passing it to
the function fixes this.
GCC assumes this->b is zero (or may be zero) and spits out the following
warning (or error with -Werror):
src/libstrongswan/plugins/fips_prf/fips_prf.c:124:12: error: array subscript 18446744073709551615 is above array bounds of ‘uint8_t[<U8090>]’ {aka ‘unsigned char[<U8090>]’} [-Werror=array-bounds]
124 | one[this->b - 1] = 0x01;
| ~~~^~~~~~~~~~~~~
Even though the assignment of `removed` to `out_row` is tied to the
`found_removed` flag, which is only set if `removed` is set, the
compiler complains that it may be used uninitialized.
GCC 12 produces weird code when a callback is called directly (e.g.
parse_bool() via parse_option() in vici_config.c). Instead of the actual
pointer, it explicitly passes 0 as first argument, which likely causes
a segmentation fault. It doesn't happen when called indirectly via
function pointer that has void* as first argument, which this patch
kinda replicates for direct calls to avoid the issue.
Closesstrongswan/strongswan#1053
These only apply to the usage reports that are available via
`stroke memusage`, not to leak reports when executables are terminated,
which always include all non-whitelisted leaks.
This should make it clearer to what the log messages generated by
verify_trust_chain() are related (in particular if building the chain
fails or the cert has expired).
Adds support for GTK 4. Two versions of the UI are built as shared
objects, the plugin dynamically loads and instantiates the appropriate one
based on the determined GTK version.
Closesstrongswan/strongswan#961
GTK4 does not support buttons at the bottom, so we put them in a header
bar, which is the preferred layout by current desktop environments. And
while it doesn't look ideal on older desktops, it also works with GTK3
and changing it avoids having to maintain multiple UI files.
Note that this layout is not supported by glade, so we generally can't
use it to edit the GUI anymore (it also doesn't support GTK4 in general).
This ensures the plugin is available if AES-based PRFs could get used or
none of the third-party crypto plugins is enabled and it's required for
HMAC-based PRFs as well.
References strongswan/strongswan#1026
A recent security fix for Git added a fatal error if the directory that
contains the .git directory is not owned by the user that runs git in
that directory tree:
Determine strongSwan version fatal: unsafe repository ('...' is owned by someone else)
To avoid this, we call the git commands as owner of the source
directory (the script has to run as root, so this is no problem).
The user/group ID and name is now also determined via `stat(1)` so it
directly depends on the actual source dir and should work even when not
using sudo.
mallinfo() is deprecated because it uses `int` for the members of the
returned struct, whereas mallinfo2() uses `size_t`. It's available
since glibc 2.33.
The external-id parameter takes an int32 and the generated run_id was
apparently not valid lately, resulting in undocumented 404 errors when
submitting patches (the API endpoint probably doesn't like negative numbers
because the last accepted id was 2059658094, rejected ids were e.g.
2167472705 or 2168792083).
More of this code was already removed with previous commits.
While versions < 1.1.1 are not officially supported anymore, 1.0.2 might
still be in use because before 3.x that was the latest version with
official FIPS support (OpenSSL apparently also provides extended commercial
support for it).
The old API has been deprecated with OpenSSL 3 and direct access to the
state isn't possible via EVP API. In the future we might just remove this
implementation but we'd probably have to implement EAP-AKA' first, which
uses HMAC-SHA-256 with IKEv2's prf+ construct to derive keys instead
of this weird construct (plus what fips-prf builds around it) that's used
by EAP-AKA.
This modularizes the IKEv2 key derivation, which makes certification (e.g.
FIPS) easier because it allows the two steps (PRF/prf+) to be implemented
by already certified third-party libraries.
For the existing third-party libraries, the two KDFs are implemented via
the respective library's HKDF implementation. A generic implementation,
based on existing PRFs, is provided by the new kdf plugin.
Tobias Brunner