Hi
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.
- 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).
Kindly comment.
Regards
Vakul
