netdev - Re: [PATCH RFC v3 net-next] net/tls: Implement getsockopt SOL_TLS 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]

Message-ID: <20200831113010.0107dc5e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Mon, 31 Aug 2020 11:30:10 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Yutaro Hayakawa <yhayakawa3720@...il.com>
Cc:     netdev@...r.kernel.org, michio.honda@...ac.uk
Subject: Re: [PATCH RFC v3 net-next] net/tls: Implement getsockopt SOL_TLS
 TLS_RX

On Mon, 31 Aug 2020 04:07:13 +0900 Yutaro Hayakawa wrote:
> From: Yutaro Hayakawa <yhayakawa3720@...il.com>
> 
> Implement the getsockopt SOL_TLS TLS_RX which is currently missing. The
> primary usecase is to use it in conjunction with TCP_REPAIR to
> checkpoint/restore the TLS record layer state.
> 
> TLS connection state usually exists on the user space library. So
> basically we can easily extract it from there, but when the TLS
> connections are delegated to the kTLS, it is not the case. We need to
> have a way to extract the TLS state from the kernel for both of TX and
> RX side.
> 
> The new TLS_RX getsockopt copies the crypto_info to user in the same
> way as TLS_TX does.
> 
> We have described use cases in our research work in Netdev 0x14
> Transport Workshop [1].
> 
> Also, there is an TLS implementation called tlse [2] which supports
> TLS connection migration. They have support of kTLS and their code
> shows that they are expecting the future support of this option.
> 
> [1] https://speakerdeck.com/yutarohayakawa/prism-proxies-without-the-pain
> [2] https://github.com/eduardsui/tlse
> 
> Signed-off-by: Yutaro Hayakawa <yhayakawa3720@...il.com>

Reviewed-by: Jakub Kicinski <kuba@...nel.org>