tun-device: Use SIOCAIFADDR to set IP address on FreeBSD 10
FreeBSD 10 deprecated the SIOCSIFADDR etc. commands, so we use this
newer command to set the address and netmask. A destination address
is now also required.
Adds support for GCC's __atomic* built-ins and improves the performance
of logging (for ignored log levels) and half-open IKE_SA checking under
high loads.
Also fixes two potential race conditions in the load-tester plugin.
bus: Add a fast-path if log messages don't have to be logged
For some rwlock_t implementations acquiring the read lock could be quite
expensive even if there are no writers (e.g. because the implementation
requires acquiring a mutex to check for writers) particularly if the
lock is highly contended, like it is for the vlog() method.
Due to an unprotected incrementation, two load-tester initiators occasionally
use the same SPI under high load, and hence generate 2 IPsec SAs with the same
identifier. The responder IPsec stack will refuse to configure the second SA.
Use an atomic incrementation to avoid this race condition.
load-tester: Fix race condition issuing same identity
Due to an unprotected incrementation, two load-tester initiators occasionally
use the same identifier under high load. The responder typically drops one of
the connections.
Use an atomic incrementation to avoid this race condition.
ike-sa-manager: Improve scalability of half-open IKE_SA checking
This patch is based on one by Christoph Gouault.
Currently, to count the total number of half_open IKE_SAs,
get_half_open_count sums up the count of each segment in the SA hash
table (acquiring a lock for each segment). This procedure does not scale
well when the number of segments increases, as the method is called for
each new negotiation.
Instead, lets maintain a global atomic counter.
This optimization allows the use of big values for charon.ikesa_table_size
and charon.ikesa_table_segments.
These are available since GCC 4.7 and will eventually replace the __sync
operations. They support the memory model defined by C++11. For instance,
by using __ATOMIC_RELAXED for some operations on the reference counters we
can avoid memory barriers, which are required by __sync operations (whose
memory model essentially is __ATOMIC_SEQ_CST).
utils: Add ref_cur() to retrieve the current value of a reference counter
On many architectures it is safe to read the value directly (those
using cache coherency protocols, and with atomic loads for 32-bit
values) but it is not if that's not the case or if we ever decide to
make refcount_t 64-bit (load not atomic on x86).
So make sure the operation is actually atomic and that users do not
have to care about the size of refcount_t.
- get_cpi function was implemented to retrieve a CPI from the kernel.
- add_sa/update_sa/del_sa were updated to accommodate for IPComp SA.
- Updated add_policy_internal to update the SPD to support IPComp.
Martin Willi [Thu, 10 Apr 2014 09:25:32 +0000 (11:25 +0200)]
ikev2: Reject CHILD_SA creation/rekeying while deleting an IKE_SA
If one peer starts reauthentication by deleting the IKE_SA, while the other
starts CHILD_SA rekeying, we run in a race condition. To avoid it, temporarily
reject the rekey attempt while we are in the IKE_SA deleting state.
RFC 4306/5996 is not exactly clear about this collision, but it should be safe
to reject CHILD_SA rekeying during this stage, as the reauth will re-trigger the
CHILD_SA. For non-rekeying CHILD_SA creations, it's up to the peer to retry
establishing the CHILD_SA on the reauthenticated IKE_SA.
Martin Willi [Thu, 10 Apr 2014 08:24:34 +0000 (10:24 +0200)]
ikev2: Apply extensions and conditions before starting rekeying
The extensions and conditions apply to the rekeyed IKE_SA as well, so we should
migrate them. Especially when using algorithms from private space, we need
EXT_STRONGSWAN to properly select these algorithms during IKE rekeying.
Martin Willi [Mon, 14 Apr 2014 12:42:27 +0000 (14:42 +0200)]
ikev1: Add an option to accept unencrypted ID/HASH payloads
Even in Main Mode, some Sonicwall boxes seem to send ID/HASH payloads in
unencrypted form, probably to allow PSK lookup based on the ID payloads. We
by default reject that, but accept it if the
charon.accept_unencrypted_mainmode_messages option is set in strongswan.conf.
ikev2: Fix reauthentication if peer assigns a different virtual IP
Before this change a reqid set on the create_child_t task was used as
indicator of the CHILD_SA being rekeyed. Only if that was not the case
would the local traffic selector be changed to 0.0.0.0/0|::/0 (as we
don't know which virtual IP the gateway will eventually assign).
On the other hand, in case of a rekeying the VIP is expected to remain
the same, so the local TS would simply equal the VIP.
Since c949a4d5016e33c5 reauthenticated CHILD_SAs also have the reqid
set. Which meant that the local TS would contain the previously
assigned VIP, basically rendering the gateway unable to assign a
different VIP to the client as the resulting TS would not match
the client's proposal anymore.
Martin Willi [Tue, 1 Apr 2014 12:53:28 +0000 (14:53 +0200)]
Merge branch 'tls-unit-tests'
Add some initial unit-tests to libtls, testing all supported cipher suites
against self, both with and without client authentication, for all supported
TLS versions.
Martin Willi [Tue, 25 Mar 2014 13:14:37 +0000 (14:14 +0100)]
unit-tests: Catch timeouts during test runner deinit function
The test runner deinit function often cancels all threads from the pool. This
operation might hang on error conditions, hence we should include that hook in
the test timeout to fail properly.
Martin Willi [Mon, 24 Mar 2014 16:17:50 +0000 (17:17 +0100)]
unit-tests: Prevent a failing worker thread to go wild after it fails
A worker raises SIGUSR1 to inform the main thread that the test fails. The main
thread then starts cancelling workers, but the offending thread should be
terminated immediately to prevent it from test continuation.
Martin Willi [Mon, 31 Mar 2014 14:17:57 +0000 (16:17 +0200)]
Merge branch 'tls-aead'
Adds AEAD support to the TLS stack, currently supporting AES-GCM. Brings fixes
for TLS record fragmentation, enforcing TLS versions < 1.2 and proper signature
scheme support indication.
Martin Willi [Tue, 25 Mar 2014 09:50:51 +0000 (10:50 +0100)]
tls: Include TLS version announced in Client Hello in encrypted premaster
While a hardcoded 1.2 version is fine when we offer that in Client Hello, we
should include the actually offered version if it has been reduced before
starting the exchange.
Martin Willi [Fri, 21 Mar 2014 08:29:44 +0000 (09:29 +0100)]
tls: Check for minimal TLS record length before each record iteration
Fixes fragment reassembling if a buffer contains more than one record, but
the last record contains a partial TLS record header. Thanks to Nick Saunders
and Jamil Nimeh for identifying this issue and providing a fix for it.
Martin Willi [Mon, 3 Feb 2014 12:20:46 +0000 (13:20 +0100)]
tls: Separate TLS protection to abstracted AEAD modes
To better separate the code path for different TLS versions and modes of
operation, we introduce a TLS AEAD abstraction. We provide three implementations
using traditional transforms, and get prepared for TLS AEAD modes.
Martin Willi [Fri, 31 Jan 2014 14:53:38 +0000 (15:53 +0100)]
aead: Support custom AEAD salt sizes
The salt, or often called implicit nonce, varies between AEAD algorithms and
their use in protocols. For IKE and ESP, GCM uses 4 bytes, while CCM uses
3 bytes. With TLS, however, AEAD mode uses 4 bytes for both GCM and CCM.
Our GCM backends currently support 4 bytes and CCM 3 bytes only. This is fine
until we go for CCM mode support in TLS, which requires 4 byte nonces.
Martin Willi [Mon, 31 Mar 2014 12:44:50 +0000 (14:44 +0200)]
Merge branch 'ocsp-constraints'
Limits cached OCSP verification to responses signed by the CA, a directly
delegated signer or a pre-installed OCSP responder certificate. Disables
auth config merge for revocation trust-chain strength checkin, as it breaks
CA constraints in some scenarios.
Martin Willi [Tue, 25 Mar 2014 13:34:58 +0000 (14:34 +0100)]
revocation: Restrict OCSP signing to specific certificates
To avoid considering each cached OCSP response and evaluating its trustchain,
we limit the certificates considered for OCSP signing to:
- The issuing CA of the checked certificate
- A directly delegated signer by the same CA, having the OCSP signer constraint
- Any locally installed (trusted) certificate having the OCSP signer constraint
The first two options cover the requirements from RFC 6960 2.6. For
compatibility with non-conforming CAs, we allow the third option as exception,
but require the installation of such certificates locally.