Question

我正在使用与UDP不同的网络传输协议构建DTLS-Server和客户端设置。但是这个协议也是不可靠的，因此需要DTLS。该协议使用无线电网络将数据从客户端传输到服务器，反之亦然。为了使其与DTLS兼容，接收的数据然后通过UDP客户端转发到服务器端的DTLS服务器，并通过UDP服务器转发到客户端的DTLS客户端，两者都在localhost上工作。

作为基础，我正在使用mbedTLS的programs / ssl目录中给出的DTLS示例实现。由于所使用的协议在发送的情况下不是紧固件的事实，我通过使用mbedtls_ssl_conf_handshake_timeout函数来调整握手超时，使得没有任何可能干扰实际数据传输的早期重传。这可以根据需要运作。

服务器在大约2分钟后收到第一个握手消息（ClientHello）。服务器使用VerifyRequest回答，并在另外3分钟后，服务器收到客户端的答案（ClientHello + Cookie）。但是，服务器不是发送ServerHello，而是使用另一个VerifyRequest回答，例如他忘记了第一次初始化ClientHello。

我将收到的ClientHello消息与DTLS-Handshake使用相同设置但UDP作为网络协议产生的一些消息进行了比较，它们几乎相同（除了随机部分和cookie）。

我是否需要调整另一个超时计时器，以便服务器等待第二个ClientHello更长时间？还是有其他我忽略的事情？

如果您需要进一步描述问题，我会尝试给他们。

我会对任何想法或提示表示感谢。

Answer 1

我为延迟回复而道歉正如您在code中看到的那样，如果Cookie验证失败，则会发送验证请求消息：

if( ssl->conf->transport == MBEDTLS_SSL_TRANSPORT_DATAGRAM &&
    ssl->handshake->verify_cookie_len != 0 )
{
    MBEDTLS_SSL_DEBUG_MSG( 2, ( "client hello was not authenticated" ) );
    MBEDTLS_SSL_DEBUG_MSG( 2, ( "<= write server hello" ) );

    return( ssl_write_hello_verify_request( ssl ) );
}

您应该检查f_cookie_check中的mbedtls_ssl_conf_dtls_cookies()实施集。根据您的描述，我假设您使用的是默认cookie检查，因此您应该检查mbedtls_ssl_cookie_check()的原因问候，
Mbed TLS团队成员
罗恩

在第二个ClientHello

1 个答案: