Re: Security enhancement proposal for kernel TLS
On 08/02/18 05:23 PM, Vakul Garg wrote:
> > 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.
The setsockopt call struct takes the key, iv, salt, and seqno:
struct tls12_crypto_info_aes_gcm_128 {
struct tls_crypto_info info;
unsigned char iv[TLS_CIPHER_AES_GCM_128_IV_SIZE];
unsigned char key[TLS_CIPHER_AES_GCM_128_KEY_SIZE];
unsigned char salt[TLS_CIPHER_AES_GCM_128_SALT_SIZE];
unsigned char rec_seq[TLS_CIPHER_AES_GCM_128_REC_SEQ_SIZE];
};
RE: Security enhancement proposal for kernel TLS
> -Original Message- > From: Dave Watson [mailto:davejwat...@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 > > 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.
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.
RE: Security enhancement proposal for kernel TLS
> -Original Message- > From: Dave Watson [mailto:davejwat...@fb.com] > Sent: Tuesday, July 31, 2018 2:46 AM > To: Vakul Garg > Cc: netdev@vger.kernel.org; Peter Doliwa ; Boris > Pismenny > Subject: Re: Security enhancement proposal for kernel TLS > > On 07/30/18 06:31 AM, Vakul Garg wrote: > > > 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. > > 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". -- commit a01dd062a32c687630b2a860b4bb053008f09ff5 Author: Boris Pismenny Date: Sun Mar 11 16:18:27 2018 +0200 ssl: Linux TLS Rx Offload This patch adds support for the Linux TLS Rx socket option. It completes the previous patch for TLS Tx offload. If the socket option is successful, then the receive data-path of the TCP socket is implemented by the kernel. We choose to set this option at the earliest - just after CCS is complete. -- The fact that keys are handed over to kernel TLS socket can also be verified by putting a log in tls_sw_recvmsg(). I would stop here for you to confirm my observation first. Regards. Vakul > Currently the kernel TLS implementation decrypts > everything after you set the keys on the socket. I'm suggesting that you > don't set the keys on the socket until after the FINISHED message. > > > > 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.. > > > > 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. > > It's not clear to me what you gain by putting this 'handshake finished' > notification in the kernel instead of in the client's tls library - you're > already > forwarding the handshake start notification to the daemon, why can't the > daemon notify them back in userspace that > the handshake is finished? > > If you did want to put the notification in the kernel, how would you handle > poll on the socket, since probably both the handshake daemon and client > might be polling the socket, but one for control messages and one for data? > > The original kernel TLS RFC did split these to two separate sockets, but we > decided it was too complicated, and that's not how userspace TLS clients > function today. > > Do you have an implementation of this? There are a bunch of tricky corner > cases here, it might make more sense to have something concrete to discuss. > > > Further, as per tls RFC it is ok to piggyback the data records after > > the finished handshake message. This is called early data
Re: Security enhancement proposal for kernel TLS
On 07/30/18 06:31 AM, Vakul Garg wrote: > > 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. This is incorrect. Currently the kernel TLS implementation decrypts everything after you set the keys on the socket. I'm suggesting that you don't set the keys on the socket until after the FINISHED message. > > 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.. > > 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. It's not clear to me what you gain by putting this 'handshake finished' notification in the kernel instead of in the client's tls library - you're already forwarding the handshake start notification to the daemon, why can't the daemon notify them back in userspace that the handshake is finished? If you did want to put the notification in the kernel, how would you handle poll on the socket, since probably both the handshake daemon and client might be polling the socket, but one for control messages and one for data? The original kernel TLS RFC did split these to two separate sockets, but we decided it was too complicated, and that's not how userspace TLS clients function today. Do you have an implementation of this? There are a bunch of tricky corner cases here, it might make more sense to have something concrete to discuss. > 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. You're talking about the TLS 1.3 0-RTT feature, which is indeed an interesting case. For in-process TLS libraries, it's fairly easy to punt, and don't set the kernel TLS keys until after the 0-RTT data + handshake message. For an OOB handshake daemon it might indeed make more sense to leave the data in kernelspace ... somehow. > > > - 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. You are correct, but currently kernel TLS sockets return an error unless you explicitly handle the control message. This should be enough already to implement your proposal.
RE: Security enhancement proposal for kernel TLS
Sorry for a delayed response. Kindly see inline. > -Original Message- > From: Dave Watson [mailto:davejwat...@fb.com] > Sent: Wednesday, July 25, 2018 9:30 PM > To: Vakul Garg > Cc: netdev@vger.kernel.org; Peter Doliwa ; Boris > Pismenny > 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 k
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.
