This is quite helpful to debug why a pattern didn't match.
As it could produce quite a lot of output if something is not found in a
log file, the complete output is only printed in verbose mode, otherwise,
`head` is used to print the first 10 lines of output.
We only get stdout from SSH, so the stderr redirection is only really
for errors ssh itself produces.
Allow charon to start as a non-root user without CAP_CHOWN and still be
able to change the group on files that need to be accessed by charon
after capabilities have been dropped. This requires the user charon starts
as to have access to socket/pidfile directory as well as belong to the
group that charon will run as after dropping capabilities.
Closesstrongswan/strongswan#105.
Stater will lose update/reload commands when there is a second signal
coming in when the previous is still processed. This can happen more
easily with big configurations.
Closesstrongswan/strongswan#101.
In case the PRF's set_key() or allocate_bytes() method failed, skeyseed
was not initialized and the chunk_clear() call later caused a crash.
This could have happened with OpenSSL in FIPS mode when MD5 was
negotiated (and test vectors were not checked, in which case the PRF
couldn't be instantiated as the test vectors would have failed).
MD5 is not included in the default proposal anymore since 5.6.1, so
with recent versions this could only happen with configs that are not
valid in FIPS mode anyway.
Fixes: CVE-2018-10811
We continue to parse them but remove the documentation because mixing the two
sets of keywords in the same config might result in unexpected behavior.
References #2663.
Adds new options to force the local destruction of an IKE_SA (after
trying to send a DELETE first). This might be useful in situations where
it's known the other end is not reachable or already deleted the IKE_SA so
there is no point in retransmitting the DELETE and waiting for a response.
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.
We now check if there are other routes tracked for the same destination
and replace the installed route instead of just removing it. Same during
installation, where we previously didn't replace existing routes due to
NLM_F_EXCL. Routes with virtual IPs as source address are preferred over
routes without.
This should allow using trap policies with virtual IPs on Linux.
Fixes#85, #2162.
This fixes several issues that came up via BSI's Certification Path
Validation Test Tool (CPT):
1) In compliance with RFC 4945, section 5.1.3.2, we now enforce that a
certificate used for IKE authentication either does not contain a keyUsage
extension (like the ones produced by pki --issue) or that they include
digitalSignature or nonRepudiation.
2) CRLs that are not yet valid are now rejected as that could be a
problem in scenarios where expired certificates are removed from CRLs and
the clock on the host doing the revocation check is trailing behind that
of the host issuing CRLs.
3) Results other than revocation (e.g. a skipped check because the CRL
couldn't be fetched) are now stored also for intermediate CA certificates
and not only for end-entity certificates, so a strict CRL policy can be
enforced in such cases.
If the certificate is revoked, we immediately returned and the chain was
invalid, however, if we couldn't fetch the CRL that result was not stored
for intermediate CAs and we weren't able to enforce a strict CRL policy
later.
Andreas Steffen