We'll have to change some stuff that Google deprecated (e.g. the tabs in
the ActionBar) and that requires changing the theme at least in activities.
Since that would look a bit inconsistent we'll change it globally and
use parts of the support library.
This allows using manual priorities for traps, which have a lower
base priority than the resulting IPsec policies. This could otherwise
be problematic if, for example, swanctl --install/uninstall is used while
an SA is established combined with e.g. IPComp, where the trap policy does
not look the same as the IPsec policy (which is now otherwise often the case
as the reqids stay the same).
It also orders policies by selector size if manual priorities are configured
and narrowing occurs.
This could interfere with cleanup handlers that try to acquire
mutexes while other threads holding these try to e.g. cancel the threads.
As cleanup handlers are only queued by the threads themselves we don't need
any synchronization to access the list.
Fixes#1401.
This allows two CHILD_SAs with reversed subnets to install two FWD
policies each. Since the outbound policy won't have a reqid set we will
end up with the two inbound FWD policies installed in the kernel, with
the correct templates to allow decrypted traffic.
We can't set a template on the outbound FWD policy (or we'd have to make
it optional). Because if the traffic does not come from another (matching)
IPsec tunnel it would get dropped due to the template mismatch.
If there is a DROP shunt that matches outbound forwarded traffic it
would get dropped as the FWD policy we install only matches decrypted
inbound traffic. That's because the Linux kernel first checks the FWD
policies before looking up the OUT policy and SA to encrypt the packets.
This allows us to install more than one FWD policy. We already do this
in the kernel-pfkey plugin (there the original reason was that not all
kernels support FWD policies).
GnuTLS, which can get loaded by the curl plugin, does not properly cleanup
some allocated memory when deinitializing. This causes invalid frees if
leak detective is active. Other invalid frees are related to time
conversions (tzset).
References #1382.
While building against this level in general would break our app on
older systems, the NDK will automatically use this level for 64-bit
ABI builds (which are not supported in older levels). So to build
against 64-bit ABIs we have to support this API level.
A thread might check out a new IKE_SA via checkout_new() or
checkout_by_config() and start initiating it while the daemon is
terminating and the IKE_SA manager is flushed by the main thread.
That SA is not tracked yet so the main thread is not waiting for it and
the other thread is able to check it in and creating an entry after flush()
already terminated causing a memory leak.
Fixes#1348.
Running or undoing start actions might require enumerating IKE_SAs,
which in turn might have to enumerate peer configs concurrently, which
requires acquiring a read lock. So if we keep holding the write lock while
enumerating the SAs we provoke a deadlock.
By preventing other threads from acquiring the write lock while handling
actions, and thus preventing the modification of the configs, we largely
maintain the current synchronous behavior. This way we also don't need to
acquire additional refs for config objects as they won't get modified/removed.
Fixes#1185.
This allows e.g. modified versions of xl2tpd to set the mark in
situations where two clients are using the same source port behind the
same NAT, which CONNMARK can't restore properly as only one conntrack entry
will exist with the mark set to that of the client that sent the last packet.
Fixes#1230.
By settings a matchmask that covers the complete rule we ensure that the
correct rule is deleted (i.e. matches and targets with potentially different
marks are also compared).
Since data after the passed pointer is actually dereferenced when
comparing we definitely have to pass an array that is at least as long as
the ipt_entry.
Fixes#1229.
This adds the p-cscf plugin that can request P-CSCF server addresses from
an ePDG via IKEv2 (RFC 7651). Addresses of the same families as requested
virtual IPs are requested if enabled in strongswan.conf for a particular
connection. The plugin currently writes received addresses to the log.
With these changes initiators of make-before-break reauthentications
suspend online revocation checks until after the new IKE_SA and all
CHILD_SAs are established. See f1cbacc5d1 for details why that's
necessary.
We do these checks after the SA is fully established.
When establishing an SA the responder is always able to install the
CHILD_SA created with the IKE_SA before the initiator can do so.
During make-before-break reauthentication this could cause traffic sent
by the responder to get dropped if the installation of the SA on the
initiator is delayed e.g. by OCSP/CRL checks.
In particular, if the OCSP/CRL URIs are reachable via IPsec tunnel (e.g.
with rightsubnet=0.0.0.0/0) the initiator is unable to reach them during
make-before-break reauthentication as it wouldn't be able to decrypt the
response that the responder sends using the new CHILD_SA.
By delaying the revocation checks until the make-before-break
reauthentication is completed we avoid the problems described above.
Since this only affects reauthentication, not the original IKE_SA, and the
delay until the checks are performed is usually not that long this
doesn't impose much of a reduction in the overall security.
On failure the SA is deleted and reestablished as configured. The task
is activated after the REAUTH_COMPLETE task so a make-before-break reauth
is completed before the new SA might get torn down.
We already do this in the trusted public key enumerator (which
internally uses the trusted certificate enumerator) but should do so
also when this enumerator is used directly (since the public key
enumerator has the read lock the additional call will just be skipped
there).
Our default config files are very charon specific. So to avoid
confusion when only charon-systemd is installed we just default to all
settings defined for charon. Since charon-systemd probably won't be used
together with charon this should not cause conflicts (settings may still
be overridden via the charon-systemd section).
Because settings are already accessed in library_init(), calling
add_fallback() externally after calling library_init() is not ideal.
This way namespaces already serve as fallback while library_init() is
executed and they are also in the correct order so that libstrongswan is
always the last root section.
This also restores the charon.signature_authentication_constraints
functionality, that is, if no explicit IKE signature schemes are
configured we apply all regular signature constraints as IKE constraints.
Tobias Brunner