From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vakul Garg Subject: RE: Security enhancement proposal for kernel TLS Date: Thu, 2 Aug 2018 17:23:44 +0000 Message-ID: References: <20180725155946.GA37315@davejwatson-mba.local> <20180730211611.GA48199@glawler-mbp.dhcp.thefacebook.com> <20180801204647.GA6180@davejwatson-mba.dhcp.thefacebook.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "netdev@vger.kernel.org" , Peter Doliwa , Boris Pismenny To: Dave Watson Return-path: Received: from mail-eopbgr20063.outbound.protection.outlook.com ([40.107.2.63]:60048 "EHLO EUR02-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726938AbeHBTPv (ORCPT ); Thu, 2 Aug 2018 15:15:51 -0400 In-Reply-To: <20180801204647.GA6180@davejwatson-mba.dhcp.thefacebook.com> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: > -----Original Message----- > From: Dave Watson [mailto:davejwatson@fb.com] > Sent: Thursday, August 2, 2018 2:17 AM > To: Vakul Garg > Cc: netdev@vger.kernel.org; Peter Doliwa ; Boris > Pismenny > Subject: Re: Security enhancement proposal for kernel TLS >=20 > On 07/31/18 10:45 AM, Vakul Garg wrote: > > > > IIUC, with the upstream implementation of tls record layer in > > > > kernel, the decryption of tls FINISHED message happens in kernel. > > > > Therefore the keys are already being sent to kernel tls socket > > > > before handshake is > > > completed. > > > > > > This is incorrect. > > > > Let us first reach a common ground on this. > > > > The kernel TLS implementation can decrypt only after setting the keys = on > the socket. > > The TLS message 'finished' (which is encrypted) is received after recei= ving > 'CCS' > > message. After the user space TLS library receives CCS message, it > > sets the keys on kernel TLS socket. Therefore, the next message in the > > socket receive queue which is TLS finished gets decrypted in kernel onl= y. > > > > Please refer to following Boris's patch on openssl. The commit log say= s: > > " We choose to set this option at the earliest - just after CCS is comp= lete". >=20 > I agree that Boris' patch does what you say it does - it sets keys immedi= ately > after CCS instead of after FINISHED message. I disagree that the kernel = tls > implementation currently requires that specific ordering, nor do I think = that it > should require that ordering. The current kernel implementation assumes record sequence number to start f= rom '0'. If keys have to be set after FINISHED message, then record sequence number = need to be communicated from user space TLS stack to kernel. IIRC, sequence number = is not=20 part of the interface through which key is transferred.