| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
This way we only have to pass the traffic selectors once.
|
|
|
|
| |
Only install outbound fallback policies.
|
|
|
|
|
| |
This makes sure we use the same set of traffic selectors when installing
the SAs and installing the policies.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
That's not correct Base64 but invalid data could trigger this. Since
outlen would get reduced four times, but is only ever increased three
times per iteration, this could result in an integer underflow and then
a potential buffer overflow.
|
|
|
|
|
| |
This avoids evaluating %N. An alternative would be to define a printf-hook
for plugin features.
|
|
|
|
| |
This avoids a warning about the custom %Y printf specifier.
|
|
|
|
|
|
| |
This avoids the evaluation of %N even if the thread pool is never used.
We need to avoid as many custom printf specifiers as possible when
fuzzing our code to avoid excessive log messages.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately, we can't just add the generated C file to the sources in
Makefile.am as the linker would remove that object file when it notices
that no symbol in it is ever referenced. So we include it in the file
that contains the library initialization, which will definitely be
referenced by the executable.
This allows building an almost stand-alone static version of e.g. charon
when building with `--enable-monolithic --enable-static --disable-shared`
(without `--disable-shared` libtool will only build a version that links
the libraries dynamically). External libraries (e.g. gmp or openssl) are
not linked statically this way, though.
|
|
|
|
| |
Using a Python script so this works in cross-compilation situations.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enabled when building monolithically and statically.
This should allow us to work around the -whole-archive issue with
libtool. If the libraries register the plugin constructors they provide
they reference the constructors and will therefore prevent the linker from
removing these seemingly unused symbols from the final executable.
For use cases where dlsym() can be used, e.g. because the static libraries
are manually linked with -whole-archive (Linux) or -force-load (Apple),
this can be disabled by passing ss_cv_static_plugin_constructors=no to
the configure script.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
By using the total retransmit timeout, modifications of timeout settings
automatically reflect on the value of xfrm_acq_expires. If set, the
value of xfrm_acq_expires configured by the user takes precedence over
the calculated value.
|
| |
|
|
|
|
|
| |
Also adds an optional limit to avoid very high retransmission timeouts
with high numbers of retries.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When establishing a traffic-triggered CHILD_SA involves the setup of an
IKE_SA more than one exchange is required. As a result the temporary
acquire state may have expired -- even if the acquire expiration
(xfrm_acq_expires) time is set properly (165 by default). The expire
message sent by the kernel is not processed in charon since no trap can
be found by the trap manager.
A possible solution could be to track allocated SPIs. But since this is
a corner case and the tracking introduces quite a bit of overhead, it
seems much more sensible to add a new state if the update of a state
fails with NOT_FOUND.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
|
|
|
|
|
| |
Upcoming FreeBSD kernels will support updating the addresses of existing
SAs with new SADB_X_EXT_NEW_ADDRESS_SRC|DST extensions for the SADB_UPDATE
message.
|
| |
|
|
|
|
| |
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Makes it potentially easier to add new flags.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
During initialization of the plugins the thread pool is not yet
initialized so there is no watcher thread that could handle the queued
Netlink message and the main thread will wait indefinitely for a
response.
Fixes #2199.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Linux, setting the source address is insufficient to force a packet to be
sent over a certain path. The kernel uses the best route to select the outgoing
interface, even if we set a source address of a lower priority interface. This
is not only true for interfaces attaching to the same subnet, but also for
unrelated interfaces; the kernel (at least on 4.7) sends out the packet on
whatever interface it sees fit, even if that network does not expect packets
from the source address we force to.
When a better interface becomes available, strongSwan sends its MOBIKE address
list update using the old source address. But the kernel sends that packet over
the new best interface. If that network drops packets having the unexpected
source address from the old path, the MOBIKE update fails and the SA finally
times out.
To enforce a specific interface for our packet, we explicitly set the interface
index from the interface where the source address is installed. According to
ip(7), this overrules the specified source address to the primary interface
address. As this could have side effects to installations using multiple
addresses on a single interface, we disable the option by default for now.
This also allows using IPv6 link-local addresses, which won't work if
the outbound interface is not set explicitly.
|
|
|
|
| |
fragments
|
|
|
|
|
|
| |
There was a direct call to load_key() for unencrypted keys that didn't
remove the key ID from the hashtable, which caused keys to get unloaded
when --load-creds was called multiple times.
|
|
|
|
|
| |
We already do this for load-token and this should simplify client
implementations.
|