[strongSwan] Cipher Suite proposals changed in the course of 5.6.0 to 5.6.2

[Noel Kuntze]

Does my address look like a developer's?
1) Sane defaults are more important
2) People with legacy setups (which they are told, that they are)

It should be obvious that there are third party legacy setups - and they are the majority, because companies are lazy and uncaring in that regard - that can only handle old, insecure ciphers.
It should also be obvious that legacy setups must not be allowed to impact the security of other software in regards to negotiable settings.

If people don't configure their setups correctly (meaning specifically for the stuff they need, in regards to the proposals), then that's their fault and their problem.

There are lists of cipher keywords on the IKEv1CipherSuites and IKEv2CipherSuites pages.

Kind regards

Noel


On 19.03.2018 05:36, Dr. Rolf Jansen wrote:
> After some trials I found it:
> 
>    ike = aes256-sha1-modp1024
> 
> Obvious, isn't it?
> 
> Do you know the Robustness Principle of software design? According to this, IMHO, in the reponder (server) role strongSwan would be well advised to accept the best cipher of the otherwise too low security ciphers, because the alternative for the client would be no VPN at all, which would be the absolute worst case. In the initiator (client) role it should of course propose the most secure ciphers it knows of -- and perhaps like Postfix does, enforce this by a flag or even not, depending on the user's choice.
> 
> See: https://en.wikipedia.org/wiki/Robustness_principle
> 
> Anyway, never mind, best regards.
> 
> Rolf Jansen
> 
> 
>> Am 18.03.2018 um 22:08 schrieb Dr. Rolf Jansen <rj at obsigna.com <mailto:rj at obsigna.com>>:
>>
>> I tried already adding the following line to my ipsec.conf:
>>
>>   ike = AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
>>
>> But as expected, this did not work because the syntax for specifying the ciphers is different from the syntax for the actually used proposals. I searched half the day for sort of a translation table or translation aid before I gave up and simply patched the sources.
>>
>> That said, what would be the correct ike directive for getting charon simply to accept the above proposal?
>>
>> Thank you ver much
>>
>> Rolf Jansen
>>
>>
>>> Am 18.03.2018 um 20:01 schrieb Noel Kuntze <noel.kuntze+strongswan-users-ml at thermi.consulting <mailto:noel.kuntze+strongswan-users-ml at thermi.consulting>>:
>>>
>>> Hello,
>>>
>>> I know that everything looks like a nail, if you only got a hammer, but you only needed to add a corresponding ike and/or esp line in ipsec.conf to configure the right ciphers for that particular IKE SA configuration. The ciphers were removed because they were insecure and now there's an RFC for that. Take a look at the UsableExamples page.
>>>
>>> Kind regards
>>>
>>> Noel
>>>
>>> On 18.03.2018 23:48, Dr. Rolf Jansen wrote:
>>>> I am still using an iPhone 4 with iOS 7.1.2 which cannot be updated to a more recent iOS.
>>>>
>>>> When I am on travel, I use the builtin L2TP/IPsec client in order to connect to my FreeBSD home server providing the respective VPN service via net/mpd5 + security/strongswan (both of which are installed from the ports collection).
>>>>
>>>> After a recent update from strongSwan 5.6.0 to v5.6.2, my iPhone 4 cannot connect anymore. In the server's log I see:
>>>>
>>>> Mar 18 18:33:05 example charon: 15[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
>>>> Mar 18 18:33:05 example charon: 15[CFG] configured proposals: IKE:AES_GCM_16_128/PRF_HMAC_SHA2_256/MODP_3072, IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/AES_CMAC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048, IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048
>>>> Mar 18 18:33:05 example charon: 15[IKE] no proposal found
>>>>
>>>>
>>>> I dug into the strongSwan sources, and I found, that some ciphers were disabled. As a hot fix I added on my FreeBSD server a patch file to /usr/ports/security/strongswan/files/patch-zz-add-classic-ciphers.local (s. attachment), then I executed make deinstall install clean. For the time being, this restored the iPhone 4 L2TP/IPsec connectivity.
>>>>
>>>> I know the iPhone 4 is almost 8 years old, however, mine looks like I bought it yesterday, and the battery is still in a perfect shape, and I don't want to buy a new one in the foreseeable future. Please may I ask to pick the best cipher from the above list which iOS 7.1.2 is aware of, and add it to the list of proposals which strongSwan wants to accept.
>>>>
>>>> Best regards
>>>>
>>>> Rolf Jansen
>>>>
>>>
>>
> 

-------------- 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/20180319/0c4ff9ff/attachment.sig>