The cookie is only needed in SSL_HANDSHAKE, so there's no need to retain it for the lifetime of the connection. (SSL_HANDSHAKE is released after the handshake completes.) Back when DTLS1_COOKIE_LENGTH was 32, storing it inline made some sense. Now that RFC 6347 increased the maximum to 255 bytes, just indirect it with an Array<uint8_t>. Along the way, remove the DTLS1_COOKIE_LENGTH checks. The new limit is the largest that fits in the length prefix, so it's always redundant. In fact, the constant was one higher was allowed anyway. Add some tests for the maximum length, as well as zero-length cookies. I considered just repurposing the plain cookie field, used in HelloRetryRequest (as opposed to HelloVerifyRequest), as they're mutually exclusive, even in DTLS 1.3. But, when we get to DTLS 1.3, that'll get a little hairy because ssl_write_client_hello will need extra checks to know whether hs->cookie is meant to go in the ClientHello directly or in extensions. Change-Id: I1afedc7ce31414879545701bf8fe4658657ba66f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54466 Reviewed-by: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>chromium-5359
parent
91e0b11eba
commit
361e3e0aba
7 changed files with 57 additions and 18 deletions
Loading…
Reference in new issue