netdev - Re: Security enhancement proposal for kernel 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:   Wed, 25 Jul 2018 08:59:46 -0700
From:   Dave Watson <davejwatson@...com>
To:     Vakul Garg <vakul.garg@....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

You would probably get more responses if you cc the relevant people.
Comments inline

On 07/22/18 12:49 PM, Vakul Garg wrote:
> The kernel based TLS record layer allows the user space world to use a decoupled TLS implementation.
> The applications need not be linked with TLS stack. 
> The TLS handshake can be done by a TLS daemon on the behalf of applications.
> 
> Presently, as soon as the handshake process derives keys, it pushes the negotiated keys to kernel TLS . 
> Thereafter the applications can directly read and write data on their TCP socket (without having to use SSL apis).
> 
> With the current kernel TLS implementation, there is a security problem. 
> Since the kernel TLS socket does not have information about the state of handshake, 
> it allows applications to be able to receive data from the peer TLS endpoint even when the handshake verification has not been completed by the SSL daemon. 
> It is a security problem if applications can receive data if verification of the handshake transcript is not completed (done with processing tls FINISHED message).
> 
> My proposal:
> 	- Kernel TLS should maintain state of handshake (verified or unverified). 
> 	In un-verified state, data records should not be allowed pass through to the applications.
> 
> 	- Add a new control interface using which that the user space SSL stack can tell the TLS socket that handshake has been verified and DATA records can flow. 
> 	In 'unverified' state, only control records should be allowed to pass and reception DATA record should be pause the receive side record decryption.

It's not entirely clear how your TLS handshake daemon works -   Why is
it necessary to set the keys in the kernel tls socket before the
handshake is completed?  Or, why do you need to hand off the fd to the
client program before the handshake is completed?  

Waiting until after handshake solves both of these issues.

I'm not aware of any tls libraries that send data before the finished
message, is there any reason you need to support this?

> 
> 	- The handshake state should fallback to 'unverified' in case a control record is seen again by kernel TLS (e.g. in case of renegotiation, post handshake client auth etc).

Currently kernel tls sockets return an error unless you explicitly
handle the control record for exactly this reason.

If you want an external daemon to handle control messages after
handshake, there definitely might be some synchronization that would
make sense to push in the kernel.  However, with TLS 1.3 removing
renegotiation (and currently reneg is not implemented in kernel tls
anyway), there's much less reason to do so.