mirror of
https://github.com/yuzu-emu/mbedtls
synced 2024-11-24 08:18:23 +00:00
498e632b08
The ssl-opt.sh test cases using session resumption tend to fail occasionally on the CI due to a race condition in how ssl_server2 and ssl_client2 handle the reconnection cycle. The server does the following in order: - S1 send application data - S2 send a close_notify alert - S3 close the client socket - S4 wait for a "new connection" (actually a new datagram) - S5 start a handshake The client does the following in order: - C1 wait for and read application data from the server - C2 send a close_notify alert - C3 close the server socket - C4 reset session data and re-open a server socket - C5 start a handshake If the client has been able to send the close_notify (C2) and if has been delivered to the server before if closes the client socket (S3), when the server reaches S4, the datagram that we start the new connection will be the ClientHello and everything will be fine. However if S3 wins the race and happens before the close_notify is delivered, in S4 the close_notify is what will be seen as the first datagram in a new connection, and then in S5 this will rightfully be rejected as not being a valid ClientHello and the server will close the connection (and go wait for another one). The client will then fail to read from the socket and exit non-zero and the ssl-opt.sh harness will correctly report this as a failure. In order to avoid this race condition in test using ssl_client2 and ssl_server2, this commits introduces a new command-line option skip_close_notify to ssl_client2 and uses it in all ssl-opt.sh tests that use session resumption with DTLS and ssl_server2. This works because ssl_server2 knows how many messages it expects in each direction and in what order, and closes the connection after that rather than relying on close_notify (which is also why there was a race in the first place). Tests that use another server (in practice there are two of them, using OpenSSL as a server) wouldn't work with skip_close_notify, as the server won't close the connection until the client sends a close_notify, but for the same reason they don't need it (there is no race between receiving close_notify and closing as the former is the cause of the later). An alternative approach would be to make ssl_server2 keep the connection open until it receives a close_notify. Unfortunately it creates problems for tests where we simulate a lossy network, as the close_notify could be lost (and the client can't retransmit it). We could modify udp_proxy with an option to never drop alert messages, but when TLS 1.3 comes that would no longer work as the type of messages will be encrypted. Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com> |
||
|---|---|---|
| .. | ||
| CMakeLists.txt | ||
| dtls_client.c | ||
| dtls_server.c | ||
| mini_client.c | ||
| query_config.c | ||
| ssl_client1.c | ||
| ssl_client2.c | ||
| ssl_fork_server.c | ||
| ssl_mail_client.c | ||
| ssl_pthread_server.c | ||
| ssl_server.c | ||
| ssl_server2.c | ||