tree 22ffec96b2b7be87931b6d9012681fe2024d1bfb
parent dd1f6f4fbae4d420062fb7d7810badc754a909e2
author David Benjamin <davidben@chromium.org> 1448132744 -0500
committer Adam Langley <alangley@gmail.com> 1452888532 +0000

Consider session if the client supports tickets but offered a session ID.

This is a minor regression from
https://boringssl-review.googlesource.com/5235.

If the client, for whatever reason, had an ID-based session but also
supports tickets, it will send non-empty ID + empty ticket extension.
If the ticket extension is non-empty, then the ID is not an ID but a
dummy signaling value, so 5235 avoided looking it up. But if it is
present and empty, the ID is still an ID and should be looked up.

This shouldn't have any practical consequences, except if a server
switched from not supporting tickets and then started supporting it,
while keeping the session cache fixed.

Add a test for this case, and tighten up existing ID vs ticket tests so
they fail if we resume with the wrong type.

Change-Id: Id4d08cd809af00af30a2b67fe3a971078e404c75
Reviewed-on: https://boringssl-review.googlesource.com/6554
Reviewed-by: Adam Langley <alangley@gmail.com>