From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Watson Subject: Re: Security enhancement proposal for kernel TLS Date: Wed, 1 Aug 2018 13:46:47 -0700 Message-ID: <20180801204647.GA6180@davejwatson-mba.dhcp.thefacebook.com> References: <20180725155946.GA37315@davejwatson-mba.local> <20180730211611.GA48199@glawler-mbp.dhcp.thefacebook.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "netdev@vger.kernel.org" , Peter Doliwa , Boris Pismenny To: Vakul Garg Return-path: Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:33226 "EHLO mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729623AbeHAWdi (ORCPT ); Wed, 1 Aug 2018 18:33:38 -0400 Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: 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 receiving '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 only. > > Please refer to following Boris's patch on openssl. The commit log says: > " We choose to set this option at the earliest - just after CCS is complete". I agree that Boris' patch does what you say it does - it sets keys immediately 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.