netdev - Re: [PATCH net-next v5 22/25] ovpn: kill key and notify userspace in case of IV exhaustion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5d8ecc8e-bf89-4c62-acda-0ce280d19849@openvpn.net>
Date: Wed, 17 Jul 2024 15:38:13 +0200
From: Antonio Quartulli <antonio@...nvpn.net>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: netdev@...r.kernel.org, kuba@...nel.org, ryazanov.s.a@...il.com,
 pabeni@...hat.com, edumazet@...gle.com, andrew@...n.ch
Subject: Re: [PATCH net-next v5 22/25] ovpn: kill key and notify userspace in
 case of IV exhaustion

On 17/07/2024 15:26, Sabrina Dubroca wrote:
> 2024-07-17, 13:03:11 +0200, Antonio Quartulli wrote:
>> On 17/07/2024 12:42, Sabrina Dubroca wrote:
>>> I don't see any way for userspace to know the current IV state (no
>>> notification for when the packetid gets past some threshold, and
>>> pid_xmit isn't getting dumped via netlink), so no chance for userspace
>>> to swap keys early and avoid running out of IVs. And then, since we
>>> don't have a usable primary key anymore, we will have to drop packets
>>> until userspace tells the kernel to swap the keys (or possibly install
>>> a secondary).
>>>
>>> Am I missing something in the kernel/userspace interaction?
>>
>> There are two events triggering userspace to generate a new key:
>> 1) time based
>> 2) packet count based
>>
>> 1) is easy: after X seconds/minutes generate a new key and send it to the
>> kernel. It's obviously based on guestimate and normally our default works
>> well.
>>
>> 2) after X packets/bytes generate a new key. Here userspace keeps track of
>> the amount of traffic by periodically polling GET_PEER and fetching the
>> VPN/LINK stats.
> 
> Oh right, that's what I was missing. TX packet count should be
> equivalent to packetid. Thanks.

np!

> 
> 
>> A future improvement could be to have ovpn proactively notifying userspace
>> after reaching a certain threshold, but for now this mechanism does not
>> exist.
> 
> If it's not there from the start, you won't be able to rely on it
> (because the userspace client may run on a kernel that does not
> provide the notification), so you would still have to fetch the stats,
> unless you have a way to poll for the threshold notification feature
> being present.

You're right. Then scratch that because userspace is not ready for this.

> 
> 
>> I hope it helps.
> 
> Yup, thanks. Can you add this explanation to the commit message for
> this patch in the next version? Documenting a bit the expectations of
> the kernel/userspace interactions would be helpful, also for the
> sequencing of key installation/key swap operations. I'm guessing it
> goes something like this:

Sure, will document how this works.

> 
>   1. client sets up a primary key (key#1) and uses it
>   2. at some point, it sets up a secondary key (key#2)
>   3. later, keys are swapped (key#2 is now primary)
>   4. after some more time, the secondary (key#1) is removed and a new
>      secondary (key#3) is installed
>   [steps 3 and 4 keep repeating]
> 
> And from reading patch 21, both the TX and RX key seem to be changed
> together (swap and delete operate on the whole keyslot, and set
> requires both the ENCRYPT_DIR and DECRYPT_DIR attributes).

You are correct. Encryption and decryption keys are derived from the 
same key material that is exchanged/generated upon each "renegotiation".

> 
> A rough description of the overall life of a client (opening sockets
> and setting up the ovpn device/peers) could also be useful alongside
> the code.
> 

ok, will add it too!

Thanks!


-- 
Antonio Quartulli
OpenVPN Inc.