From b2a86c3e012b94a20d9407360a730b2b5e3118ee 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 ed97f233ff..44743d4a1d 100755 --- a/tests/ssl-opt.sh +++ b/tests/ssl-opt.sh @@ -8005,8 +8005,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" \