Could you elaborate on this? I am familiar with PKI so the first part makes sense, but I am not familiar with the intricacies of VPNs so I am not sure what this means.
Some EAP authentication methods (namely, EAP-MSCHAPv2 and EAP-TLS) export Master Session Key, which is exported to StrongSwan via MS-MPPE-Send-Key/MS-MPPE-Recv-Key EAP attributes. [2] So, MSK derived on RADIUS side and sent to StrongSwan. Eavesdropper with knowledge of RADIUS secret key capable to intercept and decrypt such EAP payload.
[1] - https://wiki.strongswan.org/projects/strongswan/wiki/EAPRadi...
Assuming their IPsec was enabled with it (and OpenVPN should be enabled by default), them leaking their keys does not matter. The sessions can not be decrypted even if the master key is leaked.
TLS also has perfect forward secrecy by default.
Impersonation is an issue, but the article stated the CA keys have already been rotated and are out of date.
EDIT: I meant to reply to the post below me, but this is fine. Sorry about that!
They were not rotated back then in 2018, so we can only guess if MITM had place. Their line of defence appealing to keys which are NOW outdated is just ridiculous.
> Read up on "Perfect forward secrecy": https://en.wikipedia.org/wiki/Forward_secrecy
> The sessions can not be decrypted even if the master key is leaked.
It's not true. PFS provides cryptographic isolation between long-term keys and session key used to encrypt data. Obviously, if MSK compromised it is irrevelant, how it was inferred: with PFS or not.
MITM could have taken place anyway because the attacker was on the machines. They did not need the key.
> It's not true. PFS provides cryptographic isolation between long-term keys and session key used to encrypt data. Obviously, if MSK compromised it is irrevelant, how it was inferred: with PFS or not.
PFS implementations have the session key rotated automatically in software and dependent on the implementation multiple session keys are in use at any given time dependent on flow. The PFS session key would also be different for every VPN server in the NordVPN environment. The only possible way to compromise a session on another VPN node (that was not compromised itself) would have been to intercept it at the time of the session being created and MITM by injecting your own PFS session key.
That is why it is called "Forward secrecy": the session can not be decrypted in the future, only in the present.
Unless your assumption is that this is a state actor with the ability to MITM connections in the first place, or a rogue ISP BGP hijacking that would have been obviously seen on something like BGPStream [https://bgpstream.com/], it is safe to say that no other VPN node's traffic was compromised. Only traffic on this single host in this single location.
More reading: https://www.speaknetworks.com/what-is-ipsec-vpn-pfs-perfect-... (Step 5)
"Instead of making use of the DH Keys Calculated during Phase-1, PFS forces DH-Key calculation during Phase-2 Setup as well as Phase-2 periodic Rekey. The PFS ensures that the same key will not be generated and used again."
OpenVPN (using TLS) also uses PFS by default. There is a reason it is called "Perfect."
EDIT: PFS is commonly also implemented by Diffie-Hellmen (DHE) key exchange: https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange
EDIT 2: I am not defending them as well. I just believe extrapolating the technical details is fear mongering at best. Believe it is best to focus on the facts as it makes for a stronger argument.
There are two distinct severe security issues. First one is leaked CA key, which allows to certify any key as a valid key for NordVPN server certificate key. I think it is not necessary to argue about this: traffic decryption to any Nord OpenVPN server became simple as network MITM. Not likely a state-level BGP hijack, but local attack targeting channel of small group of users. Anyway, we do not have cryptographical guarantees since this point.
Second issue is leaked RADIUS key. Why it is a problem for encryption? Because EAP authentication and key derivation runs between VPN client and RADIUS, and VPN server receives derived keys as attributes of EAP message: https://wiki.strongswan.org/projects/strongswan/wiki/EAPRadi...
> The eap-radius plugin does not implement an EAP method directly, but it redirects the EAP conversation with a client to a RADIUS backend server. On the gateway, the EAP packets get extracted from the IKE messages and encapsulated into the RADIUS protocol, and vice versa. The gateway itself does not need special support for a specific EAP method, as it handles the EAP conversation between the client and the RADIUS backend more or less transparently.
> For EAP methods providing an MSK, the RADIUS server must include the key within the MPPE-Send/Receive Keys; Unfortunately, FreeRADIUS before 2.1.10 did not include these attributes when used with EAP-MSCHAPv2.
So, despite session encryption key is not bound directly to long-term secrets which server possesses, they can be extracted from communication between StrongSwan and RADIUS server.
PFS has nothing to do with all of it. In first case it is possible to issue VALID certificate for eavesdrop VPN server and redirect users traffic to it. In second case MSK probably can be extracted communication between VPN server and RADIUS server (I can't say if it will require MITM of RADIUS session or it is possible to decrypt EAP payload with passive sniffing and posession of RADIUS secret key).
Official response hides fact OpenVPN CA keys also leaked, so attacker could impersonate any other NordVPN server: https://gist.githubusercontent.com/Snawoot/85f77356e229d77aa...
RADIUS secret key also leaked, so propably it is possible to break into EAP session which infers session secret key for StrongSwan.