From e03eb7bb640ff4f33cec839e4b593489fc9e6ade Mon Sep 17 00:00:00 2001 From: Hanno Becker Date: Fri, 19 Jul 2019 15:43:09 +0100 Subject: [PATCH] Don't disallow 'record from another epoch' log msg in proxy ref test It happens regularly in test runs that the server example application shuts down a connection, goes into waiting mode for a new connection, and then receives the encrypted ClosureAlert from the client. The only reason why this does currently not trigger the 'record from another epoch' message is that we handle ClientHello parsing outside of the main record stack because we want to be able to detect SSLv2 ClientHellos. However, this is likely to go away, and once it happens, we'll see the log message. Further, when record checking is used, every record, including the mentioned closure alert, is passed to the record checking API before being passed to the rest of the stack, which leads to the log message being printed. In summary, grepping for 'record from another epoch' is a fragile way of checking whether a reordered message has arrived. A more reliable way is to grep for 'Buffer record from epoch' which is printed when a record from a future epoch is actually buffered, and 'ssl_buffer_message' which is the function buffering a future handshake message. --- tests/ssl-opt.sh | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tests/ssl-opt.sh b/tests/ssl-opt.sh index 1ea58dfc9..f117a695a 100755 --- a/tests/ssl-opt.sh +++ b/tests/ssl-opt.sh @@ -7872,8 +7872,10 @@ run_test "DTLS proxy: reference" \ 0 \ -C "replayed record" \ -S "replayed record" \ - -C "record from another epoch" \ - -S "record from another epoch" \ + -C "Buffer record from epoch" \ + -S "Buffer record from epoch" \ + -C "ssl_buffer_message" \ + -S "ssl_buffer_message" \ -C "discarding invalid record" \ -S "discarding invalid record" \ -S "resend" \