| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
If there is a default drop policy forwarded traffic might otherwise not
be allowed by a specific passthrough policy (while local traffic is
allowed).
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
was called
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 also update the auth config so the constraints are not enforced.
|
|
|
|
| |
IKE_SA
|
| |
|
|
|
|
| |
enumerator
|
|
|
|
| |
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
| |
|
|
|
|
| |
As we use a different rule we can always store the scheme.
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
This will eventually allow tasks to pre-process and verify received
messages.
|
|
|
|
| |
Also don't query redirect providers in this case.
|
| |
|
|
|
|
|
|
| |
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).
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
The same encoding is also used for the REDIRECT_FROM notifies.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This will allow e.g. plugins to decide whether a connecting client is
redirected to a different gateway using RFC 5685.
|
|
|
|
| |
This moves hydra->kernel_interface to charon->kernel.
|
|
|
|
|
|
|
|
| |
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).
|