[strongSwan] swanctl.conf - requiring PFS with 'default' IKE/ESP ciphers?
Noel Kuntze
noel.kuntze+strongswan-users-ml at thermi.consulting
Mon Nov 4 23:19:43 CET 2019
Hello Todd,
The default proposal depends on which ciphers are available on your system, so they won't change.
Just define a proposal you require (choice of algorithms, key strengths) statically and use it in your conns.
Kind regards
Noel
Am 03.11.19 um 00:41 schrieb Todd Cunningham:
> Hello, I am wondering if there are any ways it is possible to guarantee a tunnel with PFS using the 'default' keywords for both the <conn>.proposals and <conn>.children.<child>.esp_proposals fields within the swanctl.conf file. Is there another field which can be used to denote a requirement for PFS or some other way this can be achieved?
>
> I am currently running strongswan 5.8.1. Currently I believe this is not possible as it appears the default ciphers include options without DH groups, though I am finding the default proposal source (src/libstrongswan/crypto/proposal/proposal.h/.c) a bit hard to follow (is there a documented list of these defaults available anywhere else?) My understanding is that the tunnel will achieve PFS if both tunnel endpoints support matching ciphers with a DH group however if not the fallback will be an alternative non-PFS cipher. However, my goal is to require PFS rather than enable PFS.
>
> Would the easiest workaround for this requirement be to hardcode a subset of the default ciphers with DH groups into swanctl.conf?
>
> As an additional clarification for perfect forward secrecy in general, the security recommendations page states that PFS can be achieved by using a DH group with ESP. Is it sufficient to declare an IKE cipher with a DH group and leave the ESP proposal to 'default', or does ESP still require a DH group explicitly in the proposal?
>
> Alternatively, does it make any sense to leave the IKE cipher as 'default' while specifying an esp_proposal with a DH group? Under these circumstances it seems like we may run into a proposal mismatch during rekeying.
>
> Thanks in advance for any advice anyone can provide!
>
> Todd Cunningham
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191104/2fb06cbe/attachment.sig>
More information about the Users
mailing list