If a called script interacts with the daemon or one of its plugins
another thread might have to acquire the write lock (e.g. to configure a
fallback or set a value). Holding the read lock prevents that, potentially
resulting in a deadlock.
fgetc() returns an int and EOF is usually -1 so when this gets casted to
a char the result depends on whether `char` means `signed char` or
`unsigned char` (the C standard does not specify it). If it is unsigned
then its value is 0xff so the comparison with EOF will fail as that is an
implicit signed int.
This fixes DNS server installation if make-before-break reauthentication
is used as there the new SA and DNS server is installed before it then
is removed again when the old IKE_SA is torn down.
If running resolvconf fails handle() fails release() is not called, which
might leave an interface file on the system (or depending on which script
called by resolvconf actually failed even the installed DNS server).
We don't need them for drop policies and they might even mess with other
routes we install. Routes for policies with protocol/ports in the
selector will always be too broad and might conflict with other routes
we install.
Using the source address to determine the interface is not correct for
net-to-net shunts between two interfaces on which the host has IP addresses
for each subnet.
Other threads are free to add/update/delete other policies.
This tries to prevent race conditions caused by releasing the mutex while
sending messages to the kernel. For instance, if break-before-make
reauthentication is used and one thread on the responder is delayed in
deleting the policies that another thread is concurrently adding for the
new SA. This could have resulted in no policies being installed
eventually.
Fixes#1400.
If a pseudonym changed a new entry was added to the table storing
permanent identity objects (that are used as keys in the other table).
However, the old mapping was not removed while replacing the mapping in
the pseudonym table caused the old pseudonym to get destroyed. This
eventually caused crashes when a new pseudonym had the same hash value as
such a defunct entry and keys had to be compared.
Fixesstrongswan/strongswan#46.
If two CHILD_SAs with mark=%unique are created concurrently they could
otherwise end up with either the same mark or different marks in both
directions.
This is the case for the IKE_SA_INIT and the initial IKEv1 messages, which
are pre-generated in tasks as at least parts of it are used to generate
the AUTH payload. The IKE_SA_INIT message will never be fragmented, but
the IKEv1 messages might be, so we can't just call generate_message().
Fixes#1478.
Some peers send an INITIAL_CONTACT notify after they received our XAuth
username. The XAuth task waiting for the third XAuth message handles
this incorrectly and closes the IKE_SA as no configuration payloads are
contained in the message. We queue the INFORMATIONAL until the XAuth
exchange is complete to avoid this issue.
Fixes#1434.
The versioning scheme used by Python (PEP 440) supports the rcN suffix
but development releases have to be named devN, not drN, which are
not supported and considered legacy versions.
This provides a fix if symmetrically overlapping policies are
installed as e.g. the case in the ikev2/ip-two-pools-db scenario:
carol 10.3.0.1/32 ----- 10.3.0.0/16, 10.4.0.0/16 moon
alice 10.4.0.1/32 ----- 10.3.0.0/16, 10.4.0.0/16 moon
Among others, the following FWD policies are installed on moon:
src 10.3.0.1/32 dst 10.4.0.0/16
...
tmpl ...
src 10.4.0.0/16 dst 10.3.0.1/32
...
src 10.4.0.1/32 dst 10.3.0.0/16
...
tmpl ...
src 10.3.0.0/16 dst 10.4.0.1/32
...
Because the network prefixes are the same for all of these they all have the
same priority. Due to that it depends on the install order which policy gets
used. For instance, a packet from 10.3.0.1 to 10.4.0.1 will match the
first as well as the last policy. However, when handling the inbound
packet we have to use the first one as the packet will otherwise be
dropped due to a template mismatch. And we can't install templates with
the "outbound" FWD policies as that would prevent using different
IPsec modes or e.g. IPComp on only one of multiple SAs.
Instead we install the "outbound" FWD policies with a lower priority
than the "inbound" FWD policies so the latter are preferred. But we use
a higher priority than default drop policies would use (in case they'd
be defined with the same subnets).
After adding the read callback the state is WATCHER_QUEUED and it is
switched to WATCHER_RUNNING only later by an asynchronous job. This means
that a thread that sent a Netlink message shortly after registration
might see the state as WATCHER_QUEUED. If it then tries to read the
response and the watcher thread is quicker to actually read the message
from the socket, it could block on recv() while still holding the lock.
And the asynchronous job that actually read the message and tries to queue
it will block while trying to acquire the lock, so we'd end up in a deadlock.
This is probably mostly a problem in the unit tests.
If there is currently no route to reach the other peer we just default
to left=%any. The local address is only really used to resolve
leftsubnet=%dynamic anyway (and perhaps for MIPv6 proxy transport mode).
Fixes#1375.
Metrics are basically defined to order routes with equal prefix, so ordering
routes by metric first makes not much sense as that could prefer totally
unspecific routes over very specific ones.
For instance, the previous code did break installation of routes for
passthrough policies with two routes like these in the main routing table:
default via 192.168.2.1 dev eth0 proto static
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.10 metric 1
Because the default route has no metric set (0) it was used, instead of the
more specific other one, to determine src and next hop when installing a route
for a passthrough policy for 192.168.2.0/24. Therefore, the installed route
in table 220 did then incorrectly redirect all local traffic to "next hop"
192.168.2.1.
The same issue occurred when determining the source address while
installing trap policies.
Fixes 6b57790270 ("kernel-netlink: Respect kernel routing priorities for IKE routes").
Fixes#1416.
An old (already rekeyed) CHILD_SA would get switched back into CHILD_REKEYING
state. And we actually want to change the currently installed CHILD_SA to
that state and later CHILD_REKEYED and properly call e.g. child_rekey() and
not do this again with an old CHILD_SA. Instead let's only check installed
or currently rekeying CHILD_SAs (in case of a rekey collision). It's also
uncommon that there is a CHILD_SA in state CHILD_REKEYED but none in state
CHILD_INSTALLED or CHILD_REKEYING, which could happen if e.g. a peer deleted
and recreated a CHILD_SA after a rekeying. But in that case we don't want
to treat the new CHILD_SA as rekeying (e.g. in regards to events on the bus).
This fixes an interoperability issue with Windows Server 2012 R2 gateways.
They insist on using modp1024 for IKE, however, Microsoft's IKEv2
implementation seems only to consider the first 15 DH groups in the proposal.
Depending on the loaded plugins modp1024 is now at position 17 or even
later, causing the server to reject the proposal. By removing some of
the weaker and rarely used DH groups from the default proposal we make
sure modp1024 is among the first 15 DH groups. The removed groups may
still be used by configuring custom proposals.
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.
The kernel policy now considers src and dst port masks as well as
restictions to a given network interface. The base priority is
100'000 for passthrough shunts, 200'000 for IPsec policies,
300'000 for IPsec policy traps and 400'000 for fallback drop shunts.
The values 1..30'000 can be used for manually set priorities.
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).
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.
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.
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.
This allows for different signature schemes for IKE authentication and
trustchain verification.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
An attacker could blindly send a message with invalid nonce data (or none
at all) to DoS an initiator if we just destroy the SA. To prevent this we
ignore the message and wait for the one by the correct responder.
If the SA got redirected this would otherwise cause a reauthentication with
the original gateway. Reestablishing the SA to the original gateway, if e.g.
the new gateway is not reachable makes sense though.
We handle this similar to how we do reestablishing IKE_SAs with all CHILD_SAs,
which also includes the one actively queued during IKE_AUTH.
To delete the old SA we use the recently added ike_reauth_complete task.
To prevent the creation of the CHILD_SA we set a condition on the
IKE_SA. We also schedule a delete job in case the client does not
terminate the IKE_SA (which is a SHOULD in RFC 5685).
According to the mode-config draft there is no prefix sent for
IPv6 addresses in IKEv1. We still accept 17 bytes long addresses for
backwards compatibility with older strongSwan releases.
Fixes#1304.
When charon rekeys a CHILD_SA after a soft limit expired, it is only
deleted after the hard limit is reached. In case of packet/byte limits
this may not be the case for a long time since the packets/bytes are
usually sent using the new SA. This may result in a very large number of
stale CHILD_SAs and kernel states. With enough connections configured this
will ultimately exhaust the memory of the system.
This patch adds a strongswan.conf setting that, if enabled, causes the old
CHILD_SA to be deleted by the initiator after a successful rekeying.
Enabling this setting might create problems with implementations that
continue to use rekeyed SAs (e.g. if the DELETE notify is lost).
If it was necessary to pass the local certificates we could probably
clone the config (but we don't do that either when later looking for the
key to actually authenticate).
Passing auth adds the same subject cert to the config over and over
again (I guess we could also try to prevent that by searching for
duplicates).
The structs that make up a message sent to the kernel have all to be
aligned with XT_ALIGN. That was not necessarily the case when
initializing the complete message as struct.
Fixes#1212.
If there is no path to the other peer there is no point in trying to
send a NAT keepalive.
If the condition changes back and forth within the keepalive interval there
is a chance that multiple jobs get queued.
This logger can be used to easily register custom logging instances
using __attribute__((constructor)) benefiting from the global reload
mechanism (with reset of log levels).
Note that this is not intended to be used from plugins, which are loaded
after loggers have already been initialized.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
This could be helpful when debugging deadlocks that manifest around
wait_for_entry(), as it helps identifying other involved threads (the
thread object is seen in the thread_main() call in each thread's backtrace).
If the IKEv2 initiator acting as a TNC server receives invalid TNC measurements
from the IKEv2 responder acting as a TNC clienti, the exchange of PB-TNC batches
is continued until the IKEv2 responder acting as a TNC server has also finished
its TNC measurements.
In the past if these measurements in the other direction were correct
the IKEv2 responder acting as EAP server declared the IKEv2 EAP authentication
successful and the IPsec connection was established even though the TNC
measurement verification on the EAP peer side failed.
The fix adds an "allow" group membership on each endpoint if the corresponding
TNC measurements of the peer are successful. By requiring a "allow" group
membership in the IKEv2 connection definition the IPsec connection succeeds
only if the TNC measurements on both sides are valid.
If DPD timeout is set but to a value smaller than the DPD delay the code
in task_manager_v1.c:queue_liveliness_check will run into an integer
underrun.
With IKEv1 we have to reuse IKE_SAs as otherwise the responder might
detect the new SA as reauthentication and will "adopt" the CHILD_SAs of
the original IKE_SA, while the initiator will not do so. This could
cause CHILD_SA rekeying to fail later.
Fixes#1236.
Otherwise, libcharon's dependency on kernel-ipsec can't be satisfied.
This changed with db61c37690 ("kernel-interface: Return bool for
kernel interface registration") as the registration of further
kernel-ipsec implementations now fails and therefore even if other
plugins are loaded the dependency will not be satisfied anymore.
References #953.
When handling a rekey collision we might have to delete an already
installed redundant CHILD_SA (or expect the other peer to do so).
We don't want to trigger updown events for these as neither do we do
so for successfully rekeyed CHILD_SAs.
Fixes#853.
To handle Phase 2 exchanges on the other HA host we need to sync the last
block of the last Phase 1 message (or the last expected IV). If the
gateway is the initiator of a Main Mode SA the last message is an
inbound message. When handling such messages the expected IV is not
updated until it is successfully decrypted so we can't sync the IV
when processing the still encrypted (!plain) message. However, as responder,
i.e. if the last message is an outbound message, the reverse applies, that
is, we get the next IV after successfully encrypting the message, not
while handling the plain message.
Fixes#1267.
It is required for IKEv1 to determine the DH group of the CHILD SAs
during rekeying. It also fixes the status output for HA SAs, which so
far haven't shown the DH group on the passive side.
Fixes#1267.
If the retransmit of an initial message is processed concurrently with the
original message it might not have been handled as intended as the
thread processing the retransmit might not have seen the correct value
of entry->processing set by the thread handling the original request.
For IKEv1, i.e. without proper message IDs, there might still be races e.g.
when receiving a retransmit of the initial IKE message while processing the
initiator's second request.
Fixes#1269.
- Switch.pm, which was implemented as a source filter, has been deprecated in
Perl 5.10 and was later removed from the core modules in Perl 5.14 or so.
Unfortunately, its replacement, the given/when/default construct, has since
been downgraded to "experimental" status because of problems with the underlying
"smart-match" operator.
Thus, as of Perl 5.22, Perl still has no actually usable "switch"-like construct.
So just use boring, old and ugly "if/elsif/else" constructs instead, which are
compatible with almost any Perl version.
- None of the Perl modules here does anything that would require "AutoLoader".
- "Exporter" can be used to export plain functions into another modules name
space. But the things that were exported here are meant to be called as
methods. In this case, it is neither necessary nor advisable to export those
symbols.
Just export nothing (the POD documentation already said so).
- It is usually the calling script that enables (or does not enable) warnings
globally. When a module says "use warnings;" however, the caller looses control
over what warnings should be enabled in that module.
The default ESP cipher suite is now
AES_CBC-128/HMAC_SHA2_256_128
and requires SHA-2 HMAC support in the Linux kernel (correctly implemented
since 2.6.33).
The default IKE cipher suite is now
AES_CBC-128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
if the openssl plugin is loaded or
AES_CBC-128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072
if ECC is not available.
The use of the SHA-1 hash algorithm and the MODP_2048 DH group has been
deprecated and ENCR_CHACHA20_POLY1305 has been added to the default
IKE AEAD algorithms.
The certificate_printer class allows the printing of certificate
information to a text file (usually stdout). This class is used
by the pki --print and swanctl --list-certs commands as well as
by the stroke plugin.
If two IKE configurations have CHILD configurations with the same name,
we have no control about the CHILD_SA that actually gets controlled. The
new "ike" parameter specifies the peer config name to find the "child" config
under.
In some situations the vici client is not interested in waiting for a
timeout at all, so don't register a logging callback if the timeout argument
is negative.
If we mistakenly detect a new IKE_SA as a reauthentication the client
won't request the previous virtual IP, but since we already migrated
it we already triggered the assign_vips() hook, so we should reassign
the migrated virtual IP.
Fixes#1152.
Since we don't use the kernel-netlink plugin anymore and the headers
in the NDK are reasonably recent, we don't need this anymore (at least
when building the app).
Fixes#1172.
We already did so during Phase 1 but because all three Quick Mode
message have the same message ID we occasionally dropped the third
message as retransmit, so we do it there too. For INFORMATIONAL
and TRANSACTION exchanges we don't expect more than one inbound message
with the same message ID so we still use them there.
Fixes#1198.
This ensures we don't pass data (via msg_control) defined in a different
scope to sendmsg(). Actually, some compilers (e.g. GCC 5.2.1) might
optimize the memcpy() call away causing the packets not to get sent from
the intended source address.
It also makes the code clearer than with all these ifdefs.
Fixes#1171.
In some scenarios an IKE_SA might get restarted multiple times (e.g.
due to retransmits and delayed INVALID_KE_PAYLOAD notifies) so that
two IKE_SA_INIT messages might be sent that only differ in the
previously randomly generated NAT_DETECTION_SOURCE_IP payload.
This could cause an authentication failure on the responder if the two
peers don't use the same IKE_SA_INIT message in their InitiatorSignedOctets.
While the payload is generated in a reproducible way it will still change
when the daemon is restarted, which should make detecting the payloads
as fake a bit harder (compared to e.g. just using 0.0.0.0:0 as address).
Fixes#1131.
If the job gets queued for a newly created IKE_SA it might not yet be
checked in when the job is running, reschedule the job in that case.
This should fix the two p2pnat test scenarios, which occasionally
failed because one of the peers did not initiate the connection to
the mediation server.
In some cases we call wait_for_entry() but don't actually check out the
entry afterwards (e.g. because it doesn't match certain criteria). So
there won't be a call to checkin() for such entries causing waiting
threads to get signaled. Instead, such threads would be blocked until
another thread properly checks out/in the entry (or does a blocking
enumeration).
The `nat-local` and `nat-remote` keys contain information on the NAT
status of the local and remote IKE endpoints, respectively. If a
responder did not detect a NAT but is configured to fake a NAT situation
this is indicated by `nat-fake` (if an initiator fakes a NAT situation
`nat-local` is set). If any NAT is detected or faked `nat-any` is set.
Closesstrongswan/strongswan#16.
Tobias Brunner