dc3da93899
This mostly[*] doesn't matter for TLS since the message would have been rejected anyway, but, in DTLS, if the peer rejects our Finished, it will send an encrypted alert. This will then cause it to hang, which isn't very helpful. I've made the change on both TLS and DTLS so the two protocols don't diverge on this point. It is true that we're accepting nominally encrypted and authenticated alerts before Finished, but, prior to ChangeCipherSpec, the alerts are sent in the clear anyway so an attacker could already inject alerts. A consumer could only be sensitive to it being post-CCS if it was watching msg_callback. The only non-debug consumer of msg_callback I've found anywhere is some hostapd code to detect Heartbeat. See https://code.google.com/p/webrtc/issues/detail?id=4403 for an instance where the equivalent behavior in OpenSSL masks an alert. [*] This does change behavior slightly if the peer sends a warning alert between CCS and Finished. I believe this is benign as warning alerts are usually ignored apart from info_callback and msg_callback. The one exception is a close_notify which is a slightly new state (accepting close_notify during a handshake seems questionable...), but they're processed pre-CCS too. Change-Id: Idd0d49b9f9aa9d35374a9f5e2f815cdb931f5254 Reviewed-on: https://boringssl-review.googlesource.com/3883 Reviewed-by: Adam Langley <agl@google.com> |
||
|---|---|---|
| crypto | ||
| doc | ||
| include/openssl | ||
| ssl | ||
| tool | ||
| util | ||
| .clang-format | ||
| .gitignore | ||
| BUILDING | ||
| CMakeLists.txt | ||
| codereview.settings | ||
| STYLE | ||