- An additional key was defined for a PSK being base64 encoded. All existing PSK's that
are not base64 encoded will have that key empty. This enables base64 encoded PSK's and
non base64 encoded PSK'sd to be differentiated.
- If the PSK connection is disabled and then enabled with a non base64 encoded PSK the PSK
will be left as it is. If the edit page is selected and Save pressed, even if nothing
has been modified, then the PSK will be converted to a base64 encoded PSK.
- The old style and new style PSK was tested out on my vm system and worked without any
issue.
- Using an old non base64 encoded PSK the IPSec connection worked without any problems.
If the PSK was tehn converted to basse64 encoding by saving from the Edit page without
changing anything, then the client IPSec connection was successfully made without any
indication of a change. The conversion from non base64 to base64 encoded PSK occurred
seamlessly without any hiccup.
Fixes: Bug13029
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- This adds the base64 encoded PSK into the config file and when the ipsec.secrets file
is created the PSK is base64 decoded to write it to the file. The ipsec.secrets file
surrounds the PSK with single quotation marks so that character is not allowed to be
used in the PSK but anything else can be.
- Tested out on my vm system and shown to be working. New PSK with various characters
characters including commas was base64 encoded before putting into the config file
and therefore was accepted by the code. If a single quotation mark was used in the
PSK then the error message about invalid characters was shown.
Fixes: Bug13029
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This is required to configure a user FQDN which some VPN peers might
send.
This patch also allows setting a key ID using @#.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This is necessary since we now have a much shorter lifetime for the host
certificate. However, it is complicated to do this is which is why we
are copying the previous certificate and generate a new CSR. This is
then signed.
A caveat of this patch is that we do not rollover the key.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The function did not evaluate the return code which is why it used a
hack to figure out if some output is an error or not.
This is being fixed in this commit and the entire output is being
returned if the return code is non-zero.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- The change to openssl-3.x results in the openssl commands that start with ca failing
with the error message
OpenSSL produced an error: <br>40E7B4719B730000:error:0700006C:configuration file
routines:NCONF_get_string:no value:crypto/conf/conf_lib.c:315:group=<NULL>
name=unique_subject
- The fix for this is to include the unique_subject = yes line into
/var/ipfire/certs/index.txt.attr
- Additionally, based on the learnings from bug#13137 on OpenVPN, any openssl commands
dealing with pkcs12 (.p12) files that were created with openssl-1.1.1x fail when being
accessed with openssl-3.x due to the no longer supported algorithm. These can be
accessed if the -legacy option is added to every openssl command dealing with pkcs12
Fixes: Bug#13138
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
We already moved away from 2048-MODP in Core Update 170. Similarly,
German Federal Office for Information Security (BSI) recommends shifting
away from RSA keys below 3,000 bits by the end of 2022 at the latest.
The only place left in IPFire 2.x where we generate such keys is for
IPsec and OpenVPN host certificates. This patch increases their key
sizes to 4,096 bits as well - CA certificates already have this length.
Existing VPN connections cannot be migrated automatically. However, only
the respective host certificate has to be regenerated - thanks to the CA
certificates' key length being sufficient, there is no need to replace
the entire VPN CA.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf (released in
2015) recommends "to use primes of 2048 bits or larger", to which BSI's
techical guideline BSI-TR-02102 (https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf?__blob=publicationFile&v=5)
concurs. The latter also recommends not to use DH groups comprising of
less than 2000 bits after 2022, and shift to 3000 bit DH groups earlier
as a precaution.
According to RFC 3526, section 8, MODP-1536 provides an estimated
security between 90 and 120 bits, a value that can be reasonably
considered broken today, as it has been so for other types of
cryptographic algorithms already, and per section 2.4 in the
aforementioned paper, breaking 1024-bit DH is considered feasible for
the NSA in 2015, which does not inspire confidence for MODP-1536 in
2022.
Therefore, this patch suggests to mark MODP-1536 as broken, since it
de facto is, and tag MODP-2048 as weak. The latter is also removed from
the default selection, so newly created VPN connections won't use it
anymore, to follow BSI's recommendations of using DH groups >= 3000 bits
in 2022 and later.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Acked-by: Michael Tremer <michael.tremer@ipfire.org>
This was supposed to be enabled by default. Due to a copy-and-paste
error, it was, however, not selected for IKE, but only for ESP.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Reviewed-by: Peter Müller <peter.mueller@ipfire.org>
This reverts commit a81cbf6127.
It was no longer possible to generate the root/host certificates.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This is the IP address or FQDN which will be written into
Apple Configuration profiles as public peer address.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This disables the theme support and makes it impossible to use any other
themes than the ipfire default theme.
The only intention of this patch is to hardcode the theme to ipfire.
To change any cgi we have is an ugly way, but the only way to do this
fast. The colour handling needs certainly to be improved as well, but
this will and should be done in other patches.
Signed-off-by: Jonatan Schlag <jonatan.schlag@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
It could happen that the remote peer re-established the connection
before "ipsec reload" removed it from the daemon.
Now, we write the configuration files first, reload them
and then bring down any connections that are still established.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Some IPsec implementations such as OpenIKED require SubjectAlternativeName
data on certificates and refuse to establish connections otherwise.
The StrongSwan project also recommends it (see:
https://wiki.strongswan.org/projects/strongswan/wiki/SimpleCA) although
it is currently not enforced by their IPsec software.
For convenience purposes and to raise awareness, this patch adds a default
SubjectAlternativeName based on the machines hostname or IP address. Existing
certificates remain unchanged for obvious reasons.
The third version of this patch fixes a duplicate DNS query reported by Michael.
Fixes#11594
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Cc: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
File uploads did not work since Perl was upgraded. This patch
fixes that problem by only checking if an object was returned
instead of performing a string comparison.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
