Document behaviour of mbedtls_ssl_get_peer_cid() for empty CIDs

This commit is contained in:
Hanno Becker 2019-05-03 12:54:52 +01:00
parent 5a29990367
commit c5f2422116
2 changed files with 11 additions and 5 deletions

View File

@ -1628,6 +1628,13 @@ int mbedtls_ssl_set_cid( mbedtls_ssl_context *ssl,
* progress, this function will attempt to complete * progress, this function will attempt to complete
* the handshake first. * the handshake first.
* *
* \note If CID extensions have been exchanged but both client
* and server chose to use an empty CID, this function
* sets `*enabled` to #MBEDTLS_SSL_CID_DISABLED
* (the rationale for this is that the resulting
* communication is the same as if the CID extensions
* hadn't been used).
*
* \return \c 0 on success. * \return \c 0 on success.
* \return A negative error code on failure. * \return A negative error code on failure.
*/ */

View File

@ -165,11 +165,10 @@ int mbedtls_ssl_get_peer_cid( mbedtls_ssl_context *ssl,
if( ssl->state != MBEDTLS_SSL_HANDSHAKE_OVER ) if( ssl->state != MBEDTLS_SSL_HANDSHAKE_OVER )
return( MBEDTLS_ERR_SSL_BAD_INPUT_DATA ); return( MBEDTLS_ERR_SSL_BAD_INPUT_DATA );
/* What shall we report if we have exchanged if both client /* We report MBEDTLS_SSL_CID_DISABLED in case the CID extensions
* and server have used the CID extension, but negotiated * were used, but client and server requested the empty CID.
* empty CIDs? This is indistinguishable from not using the * This is indistinguishable from not using the CID extension
* CID extension in the first place, and we're reporting * in the first place. */
* MBEDTLS_SSL_CID_DISABLED in this case. */
if( ssl->transform_in->in_cid_len == 0 && if( ssl->transform_in->in_cid_len == 0 &&
ssl->transform_in->out_cid_len == 0 ) ssl->transform_in->out_cid_len == 0 )
{ {