summaryrefslogtreecommitdiff
path: root/src/lib/libssl/ssl_sess.c
diff options
context:
space:
mode:
authorjsing <>2014-09-22 12:36:06 +0000
committerjsing <>2014-09-22 12:36:06 +0000
commitf0cda88b271cabe457d56240d785628f22bb3992 (patch)
tree2d6ce4054b3f35aec05209d0b9a3f8a375250cf1 /src/lib/libssl/ssl_sess.c
parenta8592cce042623e644ebf9efa4c148c78b46d064 (diff)
downloadopenbsd-f0cda88b271cabe457d56240d785628f22bb3992.tar.gz
openbsd-f0cda88b271cabe457d56240d785628f22bb3992.tar.bz2
openbsd-f0cda88b271cabe457d56240d785628f22bb3992.zip
It is possible (although unlikely in practice) for peer_finish_md_len to
end up with a value of zero, primarily since ssl3_take_mac() fails to check the return value from the final_finish_mac() call. This would then mean that an SSL finished message with a zero-byte payload would successfully match against the calculated finish MAC. Avoid this by checking the length of peer_finish_md_len and the SSL finished message payload, against the known length already stored in the SSL3_ENC_METHOD finish_mac_length field (making use of a previously unused field). ok miod@ (a little while back)
Diffstat (limited to 'src/lib/libssl/ssl_sess.c')
0 files changed, 0 insertions, 0 deletions