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

Xuelei Fan xuelei.fan at oracle.com
Wed Jul 1 02:42:29 UTC 2015

On 7/1/2015 10:02 AM, Jamil Nimeh wrote:
> On 06/30/2015 06:04 PM, Xuelei Fan wrote:
>> 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.
> As it is written today, the ServerHandshaker will only create a new
> CertificateStatus instance if the following is true:
>   * Stapling has already been activated in the server (meaning that the
>     client requested it and the server has the feature enabled)
>   * A "get" operation was done from the StatusResponseManager and at
>     least one OCSP response was returned.  In other words, if no
>     responses can be brought back from the SRM, then there's no point in
>     even asserting status_request[_v2] in the ServerHello.
> I don't see the advantage of making a static method that does what is
> already accomplished in two lines of code in ServerHandshaker (873-4).
Good you can accomplish it in ServerHandshaker.

>> 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.
> Okay, I can definitely do that.  There are some cases where I think we
> need to throw an exception, particularly on the constructor from a
> HandshakeInStream.
It's the expected behavior to throw exception for reading issues.  What
we are talking about previously is for write side constructor.


> That's a case where we want the client to Alert if
> the server asserts some weird/unsupported/illegal type or does something
> like type = ocsp and a zero length response (also illegal according to
> the spec).  Zero length responses are OK for ocsp_multi, though.

More information about the security-dev mailing list