[gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777)

[Development of GNU's TLS library]

Nikos Mavrogiannopoulos commented on a discussion on lib/priority.c:

>  	session->internals.priorities = priority;
>  	gnutls_atomic_increment(&priority->usage_cnt);
>  
> -	/* set the current version to the first in the chain.
> -	 * This will be overridden later.
> -	 */
> +	/* set the current version to the first in the chain, if that's
> +	 * the call before the initial handshake. This will be overridden by
> +	 * the handshake call. */
>  	if (session->internals.priorities->protocol.algorithms > 0 &&
> -	    !session->internals.handshake_in_progress) {
> +	    !session->internals.handshake_in_progress &&
> +	    !session->internals.initial_negotiation_completed) {
>  		if (_gnutls_set_current_version(session,

> What happens if a client wants to downgrade the protocol version during a rehandshake? That is not possible now right? Do we want to allow that?
That's uncharted territory. I do not know if that's possible now, but certainly it shouldn't. There is no reason to do that (i.e., reduce the security level of a subsequent handshake) thus if happens it should be well prohibited. So no I do not think we should support something like that :)

> What happens when a client wants to upgrade the protocol version from 1.1 to 1.2 during a rehandshake? That won't work either right?

That shouldn't work either. Any rehandshake should result in the same protocol version or fail. Again I'm not sure whether we have tests for that.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777#note_110198074
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/20181019/ff4d0901/attachment-0001.html>