JDK-8132942 : ServerHandshaker should not throw SSLHandshakeException when CertificateStatus constructor is called with invalid arguments
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-08-03
  • Updated: 2016-06-13
  • Resolved: 2016-03-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b110Fixed
Related Reports
Relates :  
JDK-8046321 - JEP 249: OCSP Stapling for TLS
Description
The current implementation for OCSP stapling has ServerHandshaker trying to construct a CertificateStatus message, but if the arguments are invalid it throws SSLHandshakeException.  This results in an unnecessary TLS fatal alert condition which could be handled more gracefully by checking the arguments before calling the constructor.  There are at least a couple ways invalid data could be handled:

If the checks can happen before the ServerHello message is sent, simply do not assert status_request or status_request_v2.
If the checks have to happen after ServerHello, do not construct and send a CertificateStatus message.

Either approach is legal per the protocol, option 1 is probably the better solution, if feasible.