[gnutls-devel] GnuTLS | ktls: API (!1477)

[Read-only notification of GnuTLS library development activities]

Daniel P_ Berrangé started a new discussion on lib/system/ktls.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1477#note_708918978

> + * Since: 3.7.2
> + **/
> +int gnutls_ktls_enable(gnutls_session_t session, int sockin, int sockout)
> +{
> +	if (setsockopt (sockin, SOL_TCP, TCP_ULP, "tls", sizeof ("tls")) < 0)
> +		return gnutls_assert_val(GNUTLS_E_INTERNAL_ERROR);
> +
> +	session->internals.recv_fd = sockin;
> +	session->internals.send_fd = sockin;
> +
> +	if (sockin != sockout){
> +		if (setsockopt (sockout, SOL_TCP, TCP_ULP, "tls", sizeof ("tls")) < 0)
> +			return gnutls_assert_val(GNUTLS_E_INTERNAL_ERROR);
> +		session->internals.send_fd = sockout;
> +	}
> +

The caller of this method ignores the error return value and carries on with the intent to doing userspace TLS.

In the 2 file descriptor case, the code here allows for the scenario that the first FD gets kTLS enabled, but the second FD fails to get it enabled. So the caller could end up carrying on with usrspace TLS, despite 1 of the 2 FDs having kTLS enabled. Admittedly it is pretty unlikely that we'd get into this situation, but from a code robustness POV, I think we ought to handle that, by disabling kTLS on the first FD again if the second fails to enable it.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1477#note_708918978
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20211020/e399e7e5/attachment-0001.html>