On 8/14/18 1:56 PM, Anthony Scarpino wrote:
On 08/13/2018 12:42 PM, Sean Mullan wrote:
On 8/10/18 3:49 PM, Anthony Scarpino wrote:
On 8/9/2018 4:25 AM, Sean Mullan wrote:
On 8/8/18 5:29 PM, Xuelei Fan wrote:
The "Default" algorithm defined in the SunJSSE provider is for TLS
protocols.
What if I set DTLS to be the default, though? Ex:
SSLContext.setDefault(SSLContext.getInstance("DTLS"));
Good point! Maybe, we also need to update the
SSLSocketFactory/SSLServerSocketFactory.getDefault() to return
inoperative factory.
I'm not sure the code path you're looking as the oneI see seems
pretty obscure.
Are you two talking about where SSL[Server]SocketFactory.getDefault()
uses a ssl.SocketFactory.provider property set to SunJSSE? If so,
can see that as a code review comment, but it seems very obscure for
the CSR.
Here's the code I would use:
SSLContext.setDefault(SSLContext.getInstance("DTLS"));
ServerSocketFactory fac = SSLServerSocketFactory.getDefault();
If I read the spec correctly, fac should be an "inoperative factory".
--Sean
Sure, but SSLServerSocketFactory.getDefault() typically return
SSLContext.getDefault().getServerSocketFactory(). Which is covered by
the planned exception change, unless I'm missing something here.
Now there is the atypically case where the property is set, but that
seems like a stretch to set the property to use SunJSSE,
Finally, even if there is a change to be made here. I'm not sure the
impact of the CSR.. It's seems easier to explain an obvious exception
than a nebulous "inoperative factory"
If our implementation throws an Exception that is not specified by the
API, then we are non-compliant (or the API needs to be updated to throw
that Exception).
--Sean
