[Update]: JEP 249 (OCSP Stapling for TLS)

Xuelei Fan xuelei.fan at oracle.com
Wed Jul 1 01:04:07 UTC 2015

On 7/1/2015 6:39 AM, Jamil Nimeh wrote:
>> src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java
>> ==================================================================
>> line 713/714, 730/731 throws SSLHandshakeException for extension
>> constructor in server side.  That's unlikely to happen, I think.  I was
>> wondering, if CertificateStatus cannot be constructed, the server may
>> not want to send the message, rather than terminate the connection
>> immediately.
> I think you're right.  While the exception is unlikely, I'd like to have
> the HandshakeMessage throw the exception if something bad happens.  I do
> however, agree that we shouldn't make it a fatal error.  I'll catch the
> exception in ServerHandshaker, log it, and just not send the message as
> you suggested since that is legal.  OK?
I have not read the server side implementation.  I would like firstly
check whether the message should be delivered, and than new the
instance.  Exception catching is not performance friendly, and looks a
little bit not-straightforward.  I think you may want a static method
for the validity checking in CertificateStatus class,  instead.

It's OK to throw exception if something bad happens.  For easy reading,
please have a comment that it is unlikely to happen if you keep the
throw exception blocks.


More information about the security-dev mailing list