If a CRL server is unresponsive, all threads trying to fetch this CRL will
block execution. If a recent previous attempt to fetch the CRL failed, it
is likely that it will fail again. While it makes sense to retry fetching
the CRL on demand with one thread, it hardly does to block additional
threads while the first one is blocked during the fetch.
So remember the timestamp of the last CRL fetch failure per URL, and do
not block more than one thread in the CRL fetch for some time. This time
is a multiple of the configured fetch timeout, so that it works well for
any configured value. With the default configuration, a failing CRL fetch
will impact concurrent CRL fetches for the same URL for 30s.
When handling many connection attempts from peers using the same CA, a slow
or non-responsive CRL distribution point can lead to concurrent fetches of
the same CRL by multiple threads. This is not only inefficient, but results
in all threads blocking for the full fetch timeout, potentially blocking
all threads in the pool.
As a first step, synchronize CRL fetches using a global mutex and a per-URL
condvar, so threads can wait for the CRL if another is already fetching it.
This reduces the number of useless concurrent CRL fetches, and allows threads
joining the party late to get blocked only until the first fetch completes
or times out.
The URL entry is preserved in the hashtable after completing the fetch.
This will allow subsequent optimizations to store the last fetch result
and act accordingly. The CRL itself is not, as CRLs can be rather large
and caching them can be done using existing mechanisms controlled via
corresponding options.
Before adding stateful CRL fetching extensions, refactor CRL fetching to
a helper class for better separation. While there are currently no plans
to extend OCSP fetching, move it as well for consistency.
As future commits will require shared state during fetch operations, a common
context is required. So pass along the "this" parameter in various revocation
functions.
When sending a TS_UNACCEPTABLE notify, a ALERT_TS_MISMATCH is sent, but
not when receiving one. This seems inconsistent compared to proposal
mismatch handling, so extend the child_create task to raise such an alert.
The bus alert infrastructure is currently exposed through the error-notify
plugin using a dedicated socket using a rather archaic message format.
Vici clients would need a dedicated socket connection just to receive such
alert messages, making their implementation more complex.
With vici, it is rather trivial to expose bus alerts through a dedicated
event message that vici clients may subscribe to. Add such an "alert"
event type to vici. Alert names are mapped to strings for simple consumption by
clients.
For now, the error-notify string message is omitted from events, as it mostly
contains static information without much value; instead add the IKE_SA details
for alerts associated to an IKE_SA. Other alert specific data may be added in
the future if needed; preferably using a structured format instead of the
arbitrary string messages used by error-notify. To allow future extensions,
wrap IKE_SA details under a dedicated "ike-sa" property.
The refcount_t for allocating unique marks and interface IDs may overflow or
hit the special value for unique marks/if_ids, in the worst case not setting it
on CHILD_SAs that should have one.
As (potentially two) marks/if_ids are allocated only for newly created CHILD_SAs,
but not for rekeying, this not very likely. Still, if a setup uses
aggressive re-authentication and or re-creates CHILD_SAs every minute,
a gateway with 100'000 tunnels may hit the overflow within a month uptime.
CHILD_SA unique identifier allocation starts at 1. If the counter overflows,
a unique ID of 0 is assigned to an CHILD_SA, which may have unclear
consequences.
Overflowing the unique ID counter is theoretical for most setups, but on
a Gateway terminating 100'000 tunnels and rekeying CHILD_SAs every 60s
overflows the counter after a month uptime. So avoid a 0 unique identifier
by using ref_get_nonzero().
IKE_SA unique identifier allocation starts at 1. If the counter overflows,
a unique ID of 0 is assigned to an IKE_SA, which may have unclear consequences.
Overflowing the unique ID counter is theoretical for most setups, but on
a Gateway terminating 100'000 tunnels and rekeying the IKE_SA every 60s
overflows the counter after a month uptime. So avoid a 0 unique identifier
by using ref_get_nonzero().
A refcount variable is used to allocate sequential unique identifiers for
Netlink sequence numbers, subject to overflows. The risk of an overflow
has so far not been considered practical, as it requires 2^32 netlink
requests.
It seems that this issue is not only theoretical. A host with thousands
of tunnels doing aggressive rekeying and/or aggressive status checking
(via vici list-sas) may trigger the overflow after a few weeks uptime.
The consequences are rather devastating: Once the refcount overflows, a
Netlink request is sent with sequence number 0. This request is answered
by the kernel, but can't be matched to the request, resulting in the error:
"received unknown netlink seq 0, ignored". Without Netlink timeouts, the
thread indefinitely waits for a response while holding the Netlink mutex,
bringing all threads to a halt.
So at all costs avoid zero sequence numbers. Also, start at sequence number
1 instead of the arbitrary 201, so the same range is used on start and after
an overflow.
When issuing a deregistration message, some last events may still be sent
by the daemon before deregistration completes. Ignore such event messages
silently during deregistration, avoiding exceptions like:
vici.exception.SessionException:
Unexpected response type 7, expected '5' (EVENT_CONFIRM)
The architecture of the Python client is completely blocking, which is fine
for many simple scripts. For more complex applications that do other I/O
and listen for vici events, the most feasible way to integrate the client is
to use a dedicated thread.
Unfortunately, Python has no simple support for thread cancellation. And
having that thread in a blocking recv() does not allow to terminate the
thread gracefully with an Event or the like.
As a way out, add a timeout to the listen() call, so the thread can
periodically do other things, like checking for termination Event and
react on it. Returning from listen() on timeout can be suboptimal, though,
as it involves registration/deregistration for events, including the risk
for missing events while not registered. So return a (None, None) tuple
instead on timeout, allowing the caller to periodically do other things
while staying registered for the events and continue in listen().
The timeout applies to the socket recv() for the start of the header, only,
so a message is either read in full or times out, avoiding the risk
of breaking message framing on the stream with partial reads.
Content-Transfer-Encoding is actually not a valid HTTP header, but a MIME
header, and must not be used. The original RFC7030 specifies this wrong,
and an errata discusses this issue.
The use of base64 encoding has been clarified in RFC8951, and the
recommendation is to always use/expect base64 encoding, but not send/expect
the Content-Transfer-Encoding header.
The commit mentioned below adds an AES-GCM default proposal for ESP. That
proposal does not include any ESN or non-ESN transform to indicate if
extended sequence numbers are supported.
A standards-compliant peer will include one or more ESN support transforms,
and will be unable to select this proposal due to a proposal mismatch.
Fix the default AES-GCM proposal by adding a NO_ESN algorithm. While ESN has
been supported in the Linux kernel for a while, having it in the default
proposal can be problematic with kernel-libipsec or on other platforms.
Fixes: c7bef954ee ("proposal: Add AES-GCM to the ESP default AEAD proposal")
Closesstrongswan/strongswan#868
strongSwan logs all syslog messages using LOG_INFO for historical reasons,
regardless of the strongSwan loglevel used producing the log message.
In some setups with advanced logging infrastructure, it may be feasible
to be more verbose when logging in strongSwan, but then filter messages
on the syslog server. While this may be possible by custom syslog filtering
rules matching the log level included with the log_level setting, this is
not super convenient.
So add a new map_level setting, which can map strongSwan loglevels to
syslog loglevels. By default this is disabled, keeping the existing
behavior. If enabled, it maps strongSwan loglevels to syslog loglevels
at a given syslog loglevel offset.
Closesstrongswan/strongswan#859
RFC3779 requires to validate the addrblocks of issuer certificates strictly,
that is, they must contain the extension and the claimed addrblock, up to
the root CA.
When working with third party root CAs that do not have the extension,
this makes using the plugin impossible. So add a depth setting that limits
the number of issuer certificates to check bottom-up towards the root CA.
A depth value of 0 disables any issuer check, the default value of -1
checks all issuers in the chain, keeping the existing behavior.
Closesstrongswan/strongswan#860
Commit 27756b081c (revocation: Check that nonce in OCSP response matches)
introduced strict nonce validation to prevent replay attacks with OCSP
responses having a longer lifetime. However, many commercial CAs (such as
Digicert) do not support nonces in responses, as they reuse once-issued OCSP
responses for the OCSP lifetime. This can be problematic for replay attack
scenarios, but is nothing we can fix at our end.
With the mentioned commit, such OCSP responses get completely unusable,
requiring the fallback to CRL based revocation. CRLs don't provide any
replay protection either, so there is nothing gained security-wise, but may
require a download of several megabytes CRL data.
To make use of replay protection where available, but fix OCSP verification
where it is not, do nonce verification only if the response actually contains
a nonce. To be safe against replay attacks, one has to fix the OCSP responder
or use a different CA, but this is not something we can enforce.
Fixes#3557.
This is a prominent example where the identity based CA constraint is
benefical. While the description of the test claims a strict binding
of the client to the intermediate CA, this is not fully true if CA operators
are not fully trusted: A rogue OU=Sales intermediate may issue certificates
containing a OU=Research.
By binding the connection to the CA, we can avoid this, and using the identity
based constraint still allows moon to receive the intermediate over IKE
or hash-and-url.
Enforcing CA based constraints previously required the CA certificate file
to be locally installed. This is problematic from a maintencance perspective
when having many intermediate CAs, and is actually redundant if the client
sends its intermediate cert in the request.
The alternative was to use Distinguished Name matching in the subject
identity to indirectly check for the issuing CA by some RDN field, such as OU.
However, this requires trust in the intermediate CA to issue only certificates
with legitime subject identities.
This new approach checks for an intermediate CA by comparing the issuing
identity. This does not require trust in the intermediate, as long as
a path len constraint prevents that intermediate to issue further
intermediate certificates.
When missing gperf, the redirection generates an empty file, which must
be manually removed after gperf has been installed. This is difficult
to diagnose, as the produced build error is cryptic.
Use --output-file of gperf instead to avoid creating an empty file if
gperf is missing. This still requires the user to re-run ./configure
after installing gperf, though.
For inbound processing, it can be rather useful to apply the mark to the
packet in the SA, so the associated policy with that mark implicitly matches.
When using %unique as match mark, we don't know the mark beforehand, so
we most likely want to set the mark we match against.
%unique (and the upcoming %same key) are usable in specific contexts only.
To restrict the user from using it in other places where it does not get the
expected results, reject such keywords unless explicitly allowed.
The keylength fix for ChaCha20Poly1305 (5a7b0be2) removes the keylength
attribute from the AEAD transform. This breaks compatibility between
versions with the patch and those without. The ChaCha20Poly1305 AEAD
won't match in proposals between such versions, and if no other algorithm
is available, negotiating SAs fails.
As a migration strategy, this patch introduces a new string identifier for a
ChaCha20Poly1305 proposal keyword which uses the explicit keylength, exactly
as it was used before the mentioned patch. Administrators that care about
the use of that AEAD with old clients can temporarily add this keyword to
the list of proposals, until all clients have been upgraded.
The used approach is the least invasive, as it just adds an additional
keyword that can't do any harm if not explicitly configured. Nontheless
allows it the administrator to smoothly keep ChaCha20Poly1305 working,
even if upgrading all peers simultaneously is not an option. It requires
manual configuration edits, though, but we assume that ChaCha20Poly1305
is not that widely used, and not as the only transform in proposals.
Removing the compat keyword in a future version is an option; it might
be helpful for other implementations, though, that falsely use an
explicit key length in ChaCha20Poly1305 AEAD transforms.
If a daemon PID file references the process that does the check, it is safe
to ignore it; no running process can have the same PID. While this is rather
unlikely to get restarted with the same PID under normal conditions, it is
quite common when running inside PID namespaced containers: If a container
gets stopped and restarted with a PID file remaining, it is very likely that
the PID namespace assigns the same PID to our service, as they are assigned
sequentially starting from 1.
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.
If a the original responder narrows the selectors of its peer in addrblock,
the peer gets a subset of that selectors. However, once the original responder
initiates rekeying of that CHILD_SA, it sends the full selectors to the peer,
and then narrows the received selectors locally for the installation, only.
This is insufficient, as the peer ends up with wider selectors, sending traffic
that the original responder will reject to the stricter IPsec policy. So
additionally narrow the selectors when rekeying CHILD_SAs before sending the
TS list to the peer.
Previously, the client had to propose no wider selectors than the certificate
permits, otherwise the complete CHILD_SA was rejected. However, with IKEv2
we can dynamically narrow the selectors to what the certificate allows. This
makes client and gateway configurations very simple by just proposing 0.0.0.0/0,
narrowed to selectors the client is permitted to route into the network.
This allows a gateway to enforce the addrblock policy on certificates that
actually have the extension only. For (legacy) certificates not having the
extension, traffic selectors are validated/narrowed by other means, most
likely by the configuration.
While RFC 3779 says we SHOULD mark it is critical, this has severe side effects
in practice. The addrblock extension is not widely used nor implemented, and
only a few applications can handle this extension. By marking it critical,
none of these applications can make use of such certificates where included
addrblocks do not matter, such as TLS/HTTPS.
If an application wants to make use of addrblocks, that is usually an explicit
decision. Then the very same application obviously can handle addrblocks, and
there is no need for the extension to be critical. In other words, for local
policy checks it is a local matter to handle the extension, hence making it
critical is usually not of much help.
When multihomed, a setup might prefer to dynamically stay on the cheapest
available path by using MOBIKE migrations. If the cheapest path goes away and
comes back, we currently stay on the more expensive path to reduce noise and
prevent potential migration issues. This is usually just fine for links not
generating real cost.
If we have more expensive links in the setup, it can be desirable to always
migrate to the cheapest link available. By setting charon.prefer_best_path,
charon tries to migrate to the path using the highest priority link, allowing
an external application to update routes to indirectly control MOBIKE behavior.
This option has no effect if MOBIKE is unavailable.
For table dumps the kernel accepts RTA_PREFSRC to filter the routes, which is
what we do when doing userspace route calculations. For kernel-based route
lookups, however, the RTA_PREFSRC attribute is ignored and we must specify
RTA_SRC for policy based route lookups.
For gateways with many connections, installing routes is often disabled,
as we can use a static route configuration to achieve proper routing with
a single rule. If this is the case, there is no need to dump all routes and
do userspace route lookups, as there is no need to exclude routes we installed
ourself.
Doing kernel-based route lookups is not only faster with may routes, but also
can use the full power of Linux policy based routing; something we can hardly
rebuild in userspace when calculating routes.
When using vici over RPyC and its (awesome) splitbrain, encoding and decoding
strings fails in vici, most likely because of the Monkey-Patch magic splitbrain
uses.
When specifying the implicit UTF-8 as encoding scheme explicitly, Python uses
the correct method to encode/decode the string, making vici useable in
splitbrain contexts.
Recent research demonstrates that at least for 1024-bit DH groups, it is
possible to create specially crafted primes having a backdoor. From the
prime itself this is not detectable, creating a perfect NOBUS attack.
http://eprint.iacr.org/2016/961
For the primes defined in RFC 5114 no information is provided on how these
have been selected. In the default proposal we included one of the 2048-bit
primes only, where it is questionable if constructing a backdoored prime is
feasible. Nevertheless, this patch removes the group from the set of default
proposals as well.
If the af-alg plugin is enabled, but kernel support is missing, we get
an error line during startup for each probed algorithm. This is way too
verbose, so just skip probing if AF_ALG is unsupported.
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.
With LinuxThreads, poll() is unfortunately no cancellation point. It seems
that poll gets woken up after cancellation, but we actively must check
for cancellation before re-entering poll to properly shut down the watcher
thread.
Previously the constraints in the authentication configuration of an
initiator were enforced only after all authentication rounds were
complete. This posed a problem if an initiator used EAP or PSK
authentication while the responder was authenticated with a certificate
and if a rogue server was able to authenticate itself with a valid
certificate issued by any CA the initiator trusted.
Because any constraints for the responder's identity (rightid) or other
aspects of the authentication (e.g. rightca) the initiator had were not
enforced until the initiator itself finished its authentication such a rogue
responder was able to acquire usernames and password hashes from the client.
And if a client supported EAP-GTC it was even possible to trick it into
sending plaintext passwords.
This patch enforces the configured constraints right after the responder's
authentication successfully finished for each round and before the initiator
starts with its own authentication.
Fixes CVE-2015-4171.
Martin Willi