CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS

Anthony Scarpino anthony.scarpino at oracle.com
Tue Aug 14 17:56:51 UTC 2018


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"

Tony



More information about the security-dev mailing list