This adds support for configuring split-tunneling and per-app VPN, adds
a simple HTTP/S fetcher and enables the revocation plugin, makes the log
view more efficient, imports profiles via SAF and changes multiple other
things.
A second property will control if only the selected apps have access to
the VPN or if the selected apps are excluded from the VPN, or if the
functionality is disabled.
We register when the service connects but also in onStart() (as we
unregister in onStop() to avoid updates when not shown). So this could
theoretically cause the listener to get registered twice if the service
is connected before onStart() is called (it seems it usually isn't).
If we find a redundant CHILD_SA (the peer probably rekeyed the SA before
us) we might not want to delete the old SA because the peer might still
use it (same applies to old CHILD_SAs after rekeyings). So only delete
them if configured to do so.
Fixes#2358.
Unlike mpz_powm() its secure replacement mpz_powm_sec() has the additional
requirement that the exponent must be > 0 and the modulus has to be odd.
Otherwise, it will crash with a floating-point exception.
Fixes: CVE-2017-9022
Fixes: 3e35a6e7a1 ("Use side-channel secured mpz_powm_sec of libgmp 5, if available")
traffic_selector_t::to_subnet() always sets the net/host (unless the
address family was invalid).
Fixes: 3070697f9f ("ike: support multiple addresses, ranges and subnets in IKE address config")
Interestingly, this doesn't show up in the regression tests because the
compiler removes the first assignment (and thus the allocation) due to
-O2 that's included in our default CFLAGS.
When charon is started via service command LEAK_DETECTIVE_LOG is not set
because the command strips the environment. Since we only want the
variable to be set during the automated test runs we can't just set it
in /etc/default/charon. Instead, we do so in this wrapper when charon is
started and remove the variable again when it is stopped.
This adds several changes to enumerator_t and linked_list_t to improve
portability. In particular to Apple's ARM64 iOS platform, whose calling
convention for variadic and regular functions are different. This means
that assigning a non-variadic function to a variadic function pointer,
as we did with our enumerator_t::enumerate() implementations and several
callbacks, will result in crashes as the called function will access the
arguments differently than the caller provided them.
To avoid this issue the enumerator_t interface is now fully variadic.
A new mandatory method is added, venumerate(), that takes a va_list with
the arguments provided while enumerating. enumerate() is replaced with
a generic implementation that prepares a va_list and calls the
enumerator's venumerate() implementation. As this allows passing the
arguments of one enumerator to another it avoids the five pointer hack
used by enumerator_create_nested() and enumerator_create_cleaner().
To simplify the implementation of venumerate() a helper macro is provided
that assigns values from a given va_list to local variables.
The signature of the callback passed to enumerator_create_filter() has
also changed significantly. It's now required to enumerate over the
original enumerator in the callback as this avoids the previous in/out
pointer hack. The arguments to the outer enumerator are provided in a
va_list.
Similar changes to avoid such five pointer hacks affect the signatures
of the callbacks for linked_list_t's invoke_function() and find_first()
methods. For the latter the return type also changed from status_t to
bool, which is important as SUCCESS is defined as 0, so checks for ==
SUCCESS will now fail.
This will allow us to implement e.g. enumerator_cleaner without having to
use that unportable 5 pointer forwarding or having to define a callback for
each instance.
A generic implementation for enumerate() is provided so only venumerate()
has to be implemented, which may be simplified by using the VA_ARGS_VGET()
macro.
Since 6a8a44be88 the certificate received by the client is verified
first, before checking the cached certificates for any with matching
identities. So we usually don't have to attempt to verify the signature
with wrong certificates first and can avoid this message.
Adds an option to locally configure 96-bit truncation for HMAC-SHA256
when negotiated using the official algorithm identifier. This is for
compatibility with peers that incorrectly use this shorter truncation
(like Linux does by default).
Fixes#1353.
The correct truncation is 128-bit but some implementations insist on
using 96-bit truncation. With strongSwan this can be negotiated using
an algorithm identifier from a private range. But this doesn't work
with third-party implementations. This adds an option to use 96-bit
truncation even if the official identifier is used.
This changes the behavior during IKEv2 CHILD_SA rekeyings to avoid
traffic loss. When responding to a CREATE_CHILD_SA request to rekey a
CHILD_SA the responder already has everything available to install and
use the new CHILD_SA. However, this could lead to lost traffic as the
initiator won't be able to process inbound packets until it processed the
CREATE_CHILD_SA response and updated the inbound SA. To avoid this the
responder now only installs the new inbound SA and delays installing the
outbound SA until it receives the DELETE for the replaced CHILD_SA. The
messages transporting these DELETEs could reach the peer before packets
sent with the deleted outbound SAs reach the respective peer. To reduce
the chance of traffic loss due to this the inbound SA of the replaced
CHILD_SA is not removed for a configurable amount of seconds after
the DELETE has been processed.
Fixes#1291.
After deleting a rekeyed CHILD_SA we uninstall the outbound SA but don't
destroy the CHILD_SA (and the inbound SA) immediately. We delay it
a few seconds or until the SA expires to allow delayed packets to get
processed. The CHILD_SA remains in state CHILD_DELETING until it finally
gets destroyed.
The responder has all the information needed to install both SAs before
the initiator does. So if the responder immediately installs the outbound
SA it might send packets using the new SA which the initiator is not yet
able to process. This can be avoided by delaying the installation of the
outbound SA until the replaced SA is deleted.
Using install() for the inbound SA and register_outbound() for the
outbound SA followed by install_policies(), will delay the installation of
the outbound SA as well as the installation of the outbound policies
in the kernel until install_outbound() is called later.
Tobias Brunner