Date:   Mon, 30 Jul 2018 06:31:23 +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

Sorry for a delayed response.
Kindly see inline.

> -----Original Message-----
> From: Dave Watson [mailto:davejwatson@...com]
> Sent: Wednesday, July 25, 2018 9:30 PM
> 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
> 
> 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? 

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.

> Or, why do you need to hand off the fd to the client program
> before the handshake is completed?
  
The fd is always owned by the client program..
The client program opens up the socket, TCP bind/connect it and then
hands it over to SSL stack as a transport handle for exchanging handshake
messages. This is how it works today whether we use kernel TLS or not.
I do not propose to change it.

In my proposal, the applications poll their own tcp socket using read/recvmsg etc.
If they get handshake record, they forward it to the entity running handshake agent.
The handshake agent could be a linux daemon or could run on a separate security
processor like 'Secure element' or say arm trustzone etc. The applications
forward any handshake message it gets backs from handshake agent to the
connected tcp socket. Therefore, the  applications act as a forwarder of the handshake 
messages between the peer tls endpoint and handshake agent.
The received data messages are absorbed by the applications themselves (bypassing ssl stack
completely). Similarly, the applications tx data directly by writing on their socket.

> Waiting until after handshake solves both of these issues.
 
The security sensitive check which is 'Wait for handshake to finish completely before 
accepting data' should not be the onus of the application. We have enough examples
in past where application programmers made mistakes in setting up tls correctly. The idea
is to isolate tls session setting up from the applications.

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

Sending data records before sending finished message is a protocol error.
A good tls library never does that. But an attacker can exploit it if applications can receive
the  data records before handshake is finished. With current kernel TLS, it is possible to do so.

Further, as per tls RFC it is ok to piggyback the data records after the finished handshake
message. This is called early data. But then it is the responsibility of applications to first
complete finished message processing before accepting the data records.

The proposal is to disallow application world seeing data records before handshake finishes.

> 
> >
> > 	- 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.

IIRC, any kind handshake message post handshake-completion is a problem for kernel tls.
This includes renegotiation, post handshake client-auth etc.

Please correct me if I am wrong.

> 
> 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.

TLS1.3 uses separate keys for handshake and data transfer phases.
This would allow handshake agent to decrypt the handshake messages on its own.
So, till the time tls1.3 handshake is finished, kernel TLS socket is not going
to do any record decryption.

(This is in contrast to TLS1.2 which uses the same session keys for finished
message. It basically entangles the data transfer and handshake phases).

Our take is that TLS 1.3 could take few years from getting adopted widely.
TLS1.2 is not going to die away so soon. 

TLS1.0/1.1 are still alive much..
https://www.ssllabs.com/ssl-pulse/

Powered by blists - more mailing lists