[Swan] ECDSA Re: Libreswan 4.6: connection IKEv2 win10 to Linux freezes soon after Android device connects

Mirsad Goran Todorovac mirsad.todorovac at alu.unizg.hr
Mon Jan 17 16:41:12 EET 2022

Hi Manfred,

On 15.1.2022. 21:04, Manfred wrote:
> Hi Mirasd,
> I ran into the issue about ECDSA certs with Windows 10 a while ago, 
> and Paul explained to me that there is in fact a problem with 
> exchanging ECDSA certs between Libreswan and Windows 10.
> Here is what I have found (taken from a 2020 post from me on this list):
>> If you use authby=ecdsa libreswan will authenticate according to 
>> RFC7427, but for this type of authentication (EC digital signatures) 
>> Windows uses RFC4754:
>> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12 
>> They are both valid standard proposals, the one used by libreswan 
>> (RFC7427) is more recent and is meant to be a common standard that 
>> generalizes different authentication methods including ECDSA.
>> But apparently RFC7427 is not backwards compatible to RFC4754, so 
>> Windows and libreswan can't exchange ECDSA digital signatures.
>> RFC4754 is not obsoleted by RFC7427, so it is likely that Windows 
>> will keep using it until they have reason not to.
> If something has changed in the meantime, I'd love to hear.
I have taken a slight view of both RFCs, and from what I can tell, 
RFC7427 method is better because it doesn't require change to the 
protocol for each new authentication certificate encryption algorithm 
and hash function.

However, knowing Microsoft, it will probably be ages before they 
implement it on their clients and servers :-(

I don't know what happened in upgrades 21H1 and 21H2 and in Windows 11, 

Then it is the interoperability problem and not my wrongdoing. Good to 
know that. Then it is no more use in trying.

> As a side note, following this thread, if I am not mistaken you are 
> using MODP1024, which is known to be weak.
> It is actually possible to use MODP2048 (and maybe higher) with 
> Windows 10, by using the Powershell function 
> "Set-VpnConnectionIPsecConfiguration".
> Windows 10 still defaults to MODP1024, but using that function you can 
> configure an IKEv2 VPN connection to use MODP2048 (aka DH Group 14).

I use only USE_DH2=true as the compilation flag, which enables Android 
native L2TP client to connect. I am also hoping this requirement will go 
away soon, as Android 11 should abandon obsoleted and weak MODP1024 
a.k.a. DH2. It doesn't allow change unless the Android device is 
"rooted", which voids the warranty.

As for Windows 10, I use the "Negotiate2048" registry hack on clients, 
and pluto session log confirm Windows 10 is connecting with MODP2048. 
Unfortunately, it apparently falls back to MODP1024 in rekeying, 
requiring the ms-dh-downgrade=yes conn configuration parameter.

I guess it is the problem with closed source systems.

Kind regards,

Mirsad Todorovac
CARNet system engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb
Republic of Croatia, the European Union
CARNet sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu

More information about the Swan mailing list