handshaker: kick PRNG when resuming in UNSAFE_DETERMINISTIC_MODE.
In fuzzing builds, session resumptions fail if the PRNG behaves the
same as in the initial session. Not sure of the reason, but a kick to
the PRNG fixes the problem and doesn't compromise determinism, so
... *shrug*?
Change-Id: I8181d98fdff16ae82255e9cda33ce5c4c40b5399
Reviewed-on: https://boringssl-review.googlesource.com/30284
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
diff --git a/ssl/test/handshaker.cc b/ssl/test/handshaker.cc
index 01c7151..9888876 100644
--- a/ssl/test/handshaker.cc
+++ b/ssl/test/handshaker.cc
@@ -18,6 +18,7 @@
#include <unistd.h>
#include <openssl/bytestring.h>
+#include <openssl/rand.h>
#include <openssl/ssl.h>
#include "../internal.h"
@@ -136,6 +137,16 @@
}
const TestConfig *config = initial_config.handshaker_resume
? &resume_config : &initial_config;
+#if defined(BORINGSSL_UNSAFE_DETERMINISTIC_MODE)
+ if (initial_config.handshaker_resume) {
+ // If the PRNG returns exactly the same values when trying to resume then a
+ // "random" session ID will happen to exactly match the session ID
+ // "randomly" generated on the initial connection. The client will thus
+ // incorrectly believe that the server is resuming.
+ uint8_t byte;
+ RAND_bytes(&byte, 1);
+ }
+#endif // BORINGSSL_UNSAFE_DETERMINISTIC_MODE
// read() will return the entire message in one go, because it's a datagram
// socket.
