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: <DB7PR04MB42522A3C774880D4532F38728B2C0@DB7PR04MB4252.eurprd04.prod.outlook.com>
Date:   Thu, 2 Aug 2018 17:23:44 +0000
From:   Vakul Garg <vakul.garg@....com>
To:     Dave Watson <davejwatson@...com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Peter Doliwa <peter.doliwa@....com>,
        Boris Pismenny <borisp@...lanox.com>
Subject: RE: Security enhancement proposal for kernel TLS



> -----Original Message-----
> From: Dave Watson [mailto:davejwatson@...com]
> Sent: Thursday, August 2, 2018 2:17 AM
> To: Vakul Garg <vakul.garg@....com>
> Cc: netdev@...r.kernel.org; Peter Doliwa <peter.doliwa@....com>; Boris
> Pismenny <borisp@...lanox.com>
> Subject: Re: Security enhancement proposal for kernel TLS
> 
> 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.

The current kernel implementation assumes record sequence number to start from '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 
part of the interface through which key is transferred.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ