| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
We are actually not in rekeying state, but just trigger a separate, new IKE_SA
as a replacement for the current IKE_SA. Switching to the REKEYING state
disables the invocation of both IKE and CHILD_SA updown hooks as initiator,
preventing the removal of any firewall rules.
Fixes #885.
|
| |
|
|
|
|
|
|
| |
While a passively installed IKE_SA does not queue a DPD timeout job, one that
switches from active to passive might execute it. Ignore such a queued job if
the IKE_SA is in passive state.
|
|
|
|
|
| |
Similar to other kernel interfaces, the libipsec backends uses the flag for
different purposes, and therefore should get separate flags.
|
|
|
|
|
|
|
|
|
|
|
| |
The current "inbound" flag is used for two purposes: To define the actual
direction of the SA, but also to determine the operation used for SA
installation. If an SPI has been allocated, an update operation is required
instead of an add.
While the inbound flag normally defines the kind of operation required, this
is not necessarily true in all cases. On the HA passive node, we install inbound
SAs without prior SPI allocation.
|
|
|
|
|
|
|
|
|
| |
While the the meaning of the "inbound" flag on the kernel_interface->add_sa()
call is not very clear, we still need that update logic to allow installation of
inbound SAs without SPI allocation. This is used in the HA plugin as a passive
node.
This reverts commit 698ed656.
|
|
|
|
|
|
|
|
| |
While this change results in the correct add/update flag during installation,
it exchanges all other values in the child_sa->install() call. We should pass
the correct flag, but determine the add/update flag by other means.
This reverts commit e722ee5d.
|
|
|
|
| |
functions
|
|
|
|
|
|
| |
Previously, we failed without recovery if a private key did not support
a selected signature scheme (based on key strength and the other peer's
supported hash algorithms).
|
|
|
|
|
|
|
| |
Especially callback jobs might refer to memory that gets invalid after
the plugins got unlaoded, so make sure we destroy these jobs before.
References #840.
|
| |
|
|
|
|
|
|
|
| |
The payload we sent before is not compliant with RFC 2407 and thus some
peers might abort negotiation (e.g. with an INVALID-PROTOCOL-ID error).
Fixes #819.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If this is disabled the schemes configured in `rightauth` are only
checked against signature schemes used in the certificate chain and
signature schemes used during IKEv2 are ignored.
Disabling this could be helpful if existing connections with peers that
don't support RFC 7427 use signature schemes in `rightauth` to verify
certificate chains.
|
| |
|
|
|
|
|
| |
This is really just a fallback to "classic" IKEv2 authentication if the other
peer supports no stronger hash algorithms.
|
|
|
|
|
| |
By enumerating hashes we'd use SHA-1 by default. This way stronger
signature schemes are preferred.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This enables late connection switching based on the signature scheme used
for IKEv2 and allows to enforce stronger signature schemes.
This may break existing connections with peers that don't support RFC 7427
if signature schemes are currently used in `rightauth` for certificate chain
validation and if the configured schemes are stronger than the default used
for IKE (e.g. SHA-1 for RSA).
|
|
|
|
| |
This is mostly for testing.
|
|
|
|
|
|
| |
We use the new signature authentication instead for this. This is not
backward compatible but we only released one version with BLISS support,
and the key format will change anyway with the next release.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The previous code allowed an attacker to slip in an IKE_SA_INIT with
both SPIs and MID 1 set when an IKE_AUTH would be expected instead.
References #816.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is mandated by the RFCs and it is expected by the task managers.
Initial messages with invalid MID will be treated like regular messages,
so no IKE_SA will be created for them. Instead, if the responder SPI is 0
no SA will be found and the message is rejected with ALERT_INVALID_IKE_SPI.
If an SPI is set and we do find an SA, then we either ignore the message
because the MID is unexpected, or because we don't allow initial messages
on established connections.
There is one exception, though, if an attacker can slip in an IKE_SA_INIT
with both SPIs set before the client's IKE_AUTH is handled by the server,
it does get processed (see next commit).
References #816.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts 8f727d800751 ("Clean up IKE_SA state if IKE_SA_INIT request
does not have message ID 0") because it allowed to close any IKE_SA by
sending an IKE_SA_INIT with an unexpected MID and both SPIs set to those
of that SA.
The next commit will prevent SAs from getting created for IKE_SA_INIT messages
with invalid MID.
Fixes #816.
|
|
|
|
|
|
|
|
|
| |
While the comment is rather clear that we should not adopt live CHILD_SAs
during reauthentication in IKEv2, the code does nonetheless. Add an additional
version check to fix reauthentication if the reauth responder has a replace
uniqueids policy.
Fixes #871.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This makes these CA certificates independent from the purge issued by reread
commands. Certificates loaded by CA sections can be removed through ipsec.conf
update/reread, while CA certificates loaded implicitly from ipsec.d/cacerts
can individually be reread using ipsec rereadcacerts.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under some conditions it can happen that the CREATE_CHILD_SA exchange for
rekeying the IKE_SA initiated by the peer is successful, but the delete message
does not follow. For example if processing takes just too long locally, the
peer might consider us dead, but we won't notice that.
As this leaves the old IKE_SA in IKE_REKEYING state, we currently avoid actively
initiating any tasks, such as rekeying or scheduled DPD. This leaves the IKE_SA
in a dead and unusable state. To avoid that situation, we schedule a timeout
to wait for the DELETE message to follow the CREATE_CHILD_SA, before we
actively start to delete the IKE_SA.
Alternatively we could start a liveness check on the SA after a timeout to see
if the peer still has that state and we can expect the delete to follow. But
it is unclear if all peers can handle such messages in this very special state,
so we currently don't go for that approach.
While we could calculate the timeout based on the local retransmission timeout,
the peer might use a different scheme, so a fixed timeout works as well.
Fixes #742.
|
|
|
|
|
|
|
| |
Referencing $(srcdir) in the gemspec is not really an option, as "gem build"
includes the full path in the gem, so we need to build in $(srcdir). As there
does not seem to be a way to control the output of "gem build", we manually
move the gem to $(builddir) in OOT builds.
|
|
|
|
|
|
|
|
|
| |
The inbound flag is used to determine if we have to install an update or a new
SA in the kernel. As we do not have allocated SPIs and therefore can't update
an existing SA in the HA plugin, always set the flag to FALSE.
Before 698ed656 we had extra logic for that case, but handling it directly in
the HA plugin is simpler.
|
|
|
|
| |
On Travis we compile with -Werror.
|
|
|
|
|
| |
This ensures the library is available. On Debian/Ubuntu it is a dynamic
library provided by the iptables-dev package.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently supports transport mode connections using IPv4 only, and requires
a unique mark configured on the connection.
To select the correct outbound SA when multiple connections match (i.e.
multiple peers connected from the same IP address / NAT router) marks must be
configured. This mark should usually be unique, which can be configured in
ipsec.conf using mark=0xffffffff.
The plugin inserts CONNMARK netfilter target rules: Any peer-initiated flow
is tagged with the assigned mark as connmark. On the return path, the mark
gets restored from the conntrack entry to select the correct outbound SA.
|