| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
While this change results in the correct add/update flag during installation,
it exchanges all other values in the child_sa->install() call. We should pass
the correct flag, but determine the add/update flag by other means.
This reverts commit e722ee5d.
|
|
|
|
|
|
| |
TKM can't verify such signatures so we'd fail in the authorize hook.
Skipping the algorithm identifier doesn't help if the peer uses
anything other than SHA-1, so config changes would be required.
|
|
|
|
| |
functions
|
|
|
|
|
|
| |
Previously, we failed without recovery if a private key did not support
a selected signature scheme (based on key strength and the other peer's
supported hash algorithms).
|
| |
|
|
|
|
|
|
|
| |
Especially callback jobs might refer to memory that gets invalid after
the plugins got unlaoded, so make sure we destroy these jobs before.
References #840.
|
|
|
|
| |
References #840.
|
|
|
|
|
|
|
|
|
| |
failed to load
Since we can't get rid of all unmet dependencies (at least not in every
possible plugin configuration) the message is more confusing than
helpful. In particular because a detailed warning about plugin features
that failed to load due to unmet dependencies is only logged on level 2.
|
|
|
|
|
|
|
|
|
| |
In case a CA certificate uses the same subject DN as the server the
previous code could end up trying to verify the server's signature with
the CA certificate's public key. By comparing the certificate with the
one sent by the peer we make sure to use the right one.
Fixes #849.
|
|
|
|
| |
References #873.
|
|
|
|
| |
Fixes #873.
|
|
|
|
|
|
|
| |
Some tokens might not fail when creating EC public keys in the incorrect
format, but they will later not be able to use them to verify signatures.
References #872.
|
|
|
|
|
|
|
| |
This is the correct encoding but we internally only use unwrapped keys
and some tokens return them unwrapped.
Fixes #872.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This avoids confusion and makes identifying the changes needed for each
scenario easier.
|
|
|
|
| |
According to NEWS it was created to support kernels < 2.6.16.
|
| |
|
|
|
|
|
|
|
| |
The payload we sent before is not compliant with RFC 2407 and thus some
peers might abort negotiation (e.g. with an INVALID-PROTOCOL-ID error).
Fixes #819.
|
|
|
|
|
|
|
|
|
| |
Some CAs don't use SHA-1 hashes of the public key as subjectKeyIdentifier and
authorityKeyIdentifier. If that's the case we can't force the
calculation of the hash to compare that to authorityKeyIdentifier in the CRL,
instead we use the subjectKeyIdentifier stored in the issuer certificate, if
available. Otherwise, we fall back to the SHA-1 hash (or comparing the
DNs) as before.
|
|
|
|
|
|
|
|
| |
If many requests are sent to the kernel the events generated by these
requests may fill the receive buffer before the daemon is able to read
these messages.
Fixes #783.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds support for RFC 7427 signature authentication in IKEv2,
enabling the use of stronger signature schemes (e.g. RSA with SHA-2)
for IKE authentication.
Public key constraints defined in `rightauth` are now also checked
against IKEv2 signature schemes (may be disabled via strongswan.conf).
Fixes #863.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
openssl-ikev2/ecdsa-certs scenario
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If this is disabled the schemes configured in `rightauth` are only
checked against signature schemes used in the certificate chain and
signature schemes used during IKEv2 are ignored.
Disabling this could be helpful if existing connections with peers that
don't support RFC 7427 use signature schemes in `rightauth` to verify
certificate chains.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Because SHA-256 is now used for signatures the size of the two IKE_AUTH
messages changed.
|
| |
| |
| |
| |
| | |
RFC 7427 signature authentication is now used between strongSwan hosts
by default, which causes the actual signature schemes to get logged.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This is really just a fallback to "classic" IKEv2 authentication if the other
peer supports no stronger hash algorithms.
|
| |
| |
| |
| |
| | |
By enumerating hashes we'd use SHA-1 by default. This way stronger
signature schemes are preferred.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This enables late connection switching based on the signature scheme used
for IKEv2 and allows to enforce stronger signature schemes.
This may break existing connections with peers that don't support RFC 7427
if signature schemes are currently used in `rightauth` for certificate chain
validation and if the configured schemes are stronger than the default used
for IKE (e.g. SHA-1 for RSA).
|
| |
| |
| |
| | |
This is mostly for testing.
|
| |
| |
| |
| |
| |
| | |
We use the new signature authentication instead for this. This is not
backward compatible but we only released one version with BLISS support,
and the key format will change anyway with the next release.
|
| | |
|
| | |
|