The race goes this way:
1. ssl_recv() succeeds (ie no signal received yet)
2. processing the message leads to aborting handshake with ret != 0
3. reset ret if we were signaled
4. print error if ret is still non-zero
5. go back to net_accept() which can be interrupted by a signal
We print the error message only if the signal is received between steps 3 and
5, not when it arrives between steps 1 and 3.
This can cause failures in ssl-opt.sh where we check for the presence of "Last
error was..." in the server's output: if we perform step 2, the client will be
notified and exit, then ssl-opt.sh will send SIGTERM to the server, but if it
didn't get a chance to run and pass step 3 in the meantime, we're in trouble.
The purpose of step 3 was to avoid spurious "Last error" messages in the
output so that ssl-opt.sh can check for a successful run by the absence of
that message. However, it is enough to suppress that message when the last
error we get is the one we expect from being interrupted by a signal - doing
more could hide real errors.
Also, improve the messages printed when interrupted to make it easier to
distinguish the two cases - this could be used in a testing script wanted to
check that the server doesn't see the client as disconnecting unexpectedly.
This commit adds four tests to tests/ssl-opt.sh:
(1) & (2): Check behaviour of optional/required verification when the
trusted CA chain is empty.
(3) & (4): Check behaviour of optional/required verification when the
client receives a server certificate with an unsupported curve.
SHA-1 is now disabled by default in the X.509 layer. Explicitly enable
it in our tests for now. Updating all the test data to SHA-256 should
be done over time.
The sample application programs/ssl/ssl_server2.c was previously
modifies to use inttypes.h to parse a string to a 64-bit integer.
However, MSVC does not support C99, so compilation fails. This
patch modifies the sample app to use the MSVC specific parsing
functions instead of inttypes.h.
Add a test to ssl-opt.sh to ensure that in DTLS a 6 byte record counter
is compared in ssl_check_ctr_renegotiate() instead of a 8 byte one as in
the TLS case. Because currently there are no testing facilities to check
that renegotiation routines are triggered after X number of input/output
messages, the test consists on setting a renegotiation period that
cannot be represented in 6 bytes, but whose least-significant byte is 2.
If the library behaves correctly, the renegotiation routines will be
executed after two exchanged.
This is not very useful for TLS as mbedtls_ssl_write() will automatically
fragment and return the length used, and the application should check for that
anyway, but this is useful for DTLS where mbedtls_ssl_write() returns an
error, and the application needs to be able to query the maximum length
instead of just guessing.
