While we currently have no need for messages larger than 65KB, we should design
the protocol to be future-proof, as we plan to keep at least to lowest protocol
layer stable.
To avoid any allocation issues, we currently keep the message size limit at
512KB.
As select() and finally the watcher may signal an FD even if it does not
actually have data, we must make a non-block read to avoid hanging in the
read callback.
Uses separate locks for socket read and write operations. While holding the
socket reader lock, a different thread can still claim the socket write lock.
This allows to asynchronously send event messages while holding the read
lock.
During shutdown, waiting for callbacks might never complete, as queued
callbacks might not get executed under certain conditions. Not the clean fix,
but works good enough for now.
Seen on Windows in vici tests.
While we don't add FDs with an active callback to the watched FDSET, we still
can get notifications for callbacks active due the asynchronous processing
of the same.
To avoid queue multiple callbacks, we check for queued callbacks before
activating new ones.
Using the same mechanism as the METHOD macro, the CALLBACK macro defines
a hybrid function signature. It strictly uses a weak void* for the first
function parameter, in contrast to the dynamic METHOD object "this" type.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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