| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
We have to make sure we compare every selected traffic selector with every
other in the list.
Fixes #577.
|
| |
|
|
|
|
|
|
|
| |
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.
Signed-off-by: Christophe Gouault <christophe.gouault@6wind.com>
|
|
|
|
|
|
|
|
|
|
| |
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.
Signed-off-by: Christophe Gouault <christophe.gouault@6wind.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
If any other IKE or CHILD_SA operation takes places, we should not start
initiating reauthentication to avoid any potential races.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
Initial patch courtesy of Paul Stewart.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Fixes #553.
|
|
|
|
|
|
|
| |
Prevents a responder peer to trick us into established state by starting
IKE_SA rekeying before the IKE_SA has been authenticated during IKE_AUTH.
Fixes CVE-2014-2338.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Works around issues related to system time changes and kernel backends using
that system time, such as Linux XFRM.
|
|
|
|
|
| |
Simply using the pointer is not optimal for our hash table
implementation, which simply masks the key to determine the bucket.
|
|
|
|
|
|
| |
accouting updates
Fixes #528.
|
|
|
|
| |
Fixes #533.
|
|
|
|
|
|
|
|
| |
The DH transform is optional for ESP/AH proposals. The initiator can
include NONE (0) in its proposal to indicate that while it prefers to
do a DH exchange, the responder may still decide to not do so.
Fixes #532.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
config
|
| |
|
| |
|
|
|
|
| |
References #516.
|
| |
|
|
|
|
| |
References #518.
|
|
|
|
|
|
|
|
|
| |
While it really would be desirable to allow stream destruction during on_read()
callbacks, this does not work anymore since e49b2998. Until we have a proper
solution for this issue, use asynchronous disconnects for the only user doing
so.
Fixes #518.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This allows us to install the schemas if either the attr-sql or sql
plugin is enabled, since both use the same schema (at least in parts).
|