All,
I wanted first to thank Michael for all the work put into creating the Apple Configuration Profiles feature for IPSec. It’s really quite nice to use.
Anyhow, I was surprised to find that the ciphers used included MODP_1024, which IPFire lists as “Broken”. Now, I’m the first to admit that I do not fully grasp the intricacies of selecting a cipher suite, but this seemed odd to me. I also noticed that the Profile is written to select DH Group 21 (ECP_521), not MODP_1024, which is what ends up getting used.
Using the default configuration profile from IPFire, this is what StrongSwan Reports in the log:
charon: 08[CFG] selected proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_1024 charon: 07[CFG] selected peer config ‘MyConnection' charon: 07[CFG] selected proposal: ESP:AES_GCM_16_256/NO_EXT_SEQ
If I modify the Configuration Profile to use 256 bit AES-CBC, though, then ECP_521ends up getting used.
charon: 05[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_521 Feb 6 09:50:09 stream charon: 13[CFG] selected peer config 'TomMacOS' Feb 6 09:50:09 stream charon: 13[CFG] selected proposal: ESP:AES_GCM_16_256/NO_EXT_SEQ
Is that an improvement, or does the elimination of GCM actually set things back?
Tom
Hello Tom,
On 6 Feb 2022, at 15:01, Tom Rymes tom@rymes.net wrote:
All,
I wanted first to thank Michael for all the work put into creating the Apple Configuration Profiles feature for IPSec. It’s really quite nice to use.
Very glad that it works like a charm.
Anyhow, I was surprised to find that the ciphers used included MODP_1024, which IPFire lists as “Broken”. Now, I’m the first to admit that I do not fully grasp the intricacies of selecting a cipher suite, but this seemed odd to me. I also noticed that the Profile is written to select DH Group 21 (ECP_521), not MODP_1024, which is what ends up getting used.
When I developed this, MODP-1024/2048 was all that iOS supported. I tried to create a little table on the wiki to reflect that:
https://wiki.ipfire.org/configuration/services/ipsec/host-to-net/apple
It is a but further down the page:
• iOS 14: AES-GCM-256-128 / SHA2-256 / MODP-2048 • iOS 13: AES-256/192/128-GCM/CBC, SHA512/384/256, MODP-1024 only • Catalina 10.15.7: AES-GCM-256-128 / SHA2-256 / MODP-1024 • High Sierra 10.13.6: AES-GCM-16-256 / SHA2-512 / MODP-1024
It looks like this changed again with iOS 15. ECC is always the preferred option because it will perform a lot better.
With Apple being generally very good and making sure that everyone is on the latest software, we can probably drop the like for iOS 13 already.
With macOS, the upgrade process seems to be somewhat slower and I have no idea what market shares those releases have.
Using the default configuration profile from IPFire, this is what StrongSwan Reports in the log:
charon: 08[CFG] selected proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_1024 charon: 07[CFG] selected peer config ‘MyConnection' charon: 07[CFG] selected proposal: ESP:AES_GCM_16_256/NO_EXT_SEQ
If I modify the Configuration Profile to use 256 bit AES-CBC, though, then ECP_521ends up getting used.
charon: 05[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_521 Feb 6 09:50:09 stream charon: 13[CFG] selected peer config 'TomMacOS' Feb 6 09:50:09 stream charon: 13[CFG] selected proposal: ESP:AES_GCM_16_256/NO_EXT_SEQ
Yeah, Apple does not seem to give the user that many options. Just use the latest stuff. Not the worst idea I would say.
Is that an improvement, or does the elimination of GCM actually set things back?
No, GCM is the way to go.
-Michael
Tom
-
Michael Tremer -
Tom Rymes