netdev - Re: [PATCH 17/17] nvmet-tcp: peek icreq before starting TLS

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]

Date: Mon, 14 Aug 2023 22:05:30 +0300
From: Sagi Grimberg <sagi@...mberg.me>
To: Hannes Reinecke <hare@...e.de>, Christoph Hellwig <hch@....de>
Cc: Keith Busch <kbusch@...nel.org>, linux-nvme@...ts.infradead.org,
 Jakub Kicinski <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>,
 Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org
Subject: Re: [PATCH 17/17] nvmet-tcp: peek icreq before starting TLS



On 8/14/23 16:18, Hannes Reinecke wrote:
> On 8/14/23 14:11, Sagi Grimberg wrote:
>>
>>> Incoming connection might be either 'normal' NVMe-TCP connections
>>> starting with icreq or TLS handshakes. To ensure that 'normal'
>>> connections can still be handled we need to peek the first packet
>>> and only start TLS handshake if it's not an icreq.
>>
>> That depends if we want to do that.
>> Why should we let so called normal connections if tls1.3 is
>> enabled?
> 
> Because of the TREQ setting.
> TREQ can be 'not specified, 'required', or 'not required'.
> Consequently when TSAS is set to 'tls1.3', and TREQ to 'not required' 
> the initiator can choose whether he wants to do TLS.
> 
> And we don't need this weird 'select TREQ required' when TLS is active;
> never particularly liked that one.

The guideline should be that treq 'not required' should be the explicit
setting in tls and not the other way around. We should be strict by
default and permissive only if the user explicitly chose it, and log
a warning in the log.