SSLContext instances

[Scott Lewis]

On 4/3/2025 8:20 AM, Sean Mullan wrote:
>
>
> On 3/13/25 3:44 PM, Scott Lewis wrote:
>> But from the point of view of the OSGi framework implementation (for 
>> example), has there been any discussion to alternatives to leaving 
>> SSLContext.setDefault open to all code at all times?  e.g. 
>> deprecation of public static setDefault, or changing the semantics of 
>> setDefault so that it could only be called successfully once (on 
>> startup).  I understand that may not be feasible due to api 
>> conventions, but was wondering if this or other approaches (enhancing 
>> JCP) have been considered/discussed.
>
> I am not familiar with OSGi so I don't understand the scenario you are 
> describing. Can you provide more details?

Although I'm referring to OSGi because that's my implementation context 
of interest, the thoughts apply to any application where new 
code/components are added/updated incrementally...e.g. many modern web 
servers, many client-side apps.

The OSGI framework has been using the java mechanisms (built on sm and 
permissions) to restrict these install/update dynamics as appropriate 
for the application...e.g. only installing signed and 
user-approved/trusted code.

SSLContext.setDefault seems to me to be a notably risky case for any 
dynamic system, and particularly for java-based servers.   I say risky 
not only because of potential for explicit attacks or sslcontext 
provider bug exploits or configuration confusion, but also for the 
potential for errors during installation and/or upgrade, or even just a 
vague level of trust in the component being installed.

Unlike many of the jvm APIs, SSLContext.setDefault cannot be 
overridden/replaced by the surrounding application and/or a runtime 
framework like OSGi.   Thus the ideas for deprecating it, replacing it 
through some new non-static api, or changing the semantics to allow it 
to be used only (e.g. on startup), or disabled at runtime.

I've proposed using OSGi service registry to support framework 
customization and securing of access to creating SSLContext instances in 
the OSGi framework [1].   This does not, however, address the issue of 
the vulnerability resulting from uncontrollable access to 
SSLContext.setDefault...so that's why I asking about it here.

Thanks.

[1] https://github.com/osgi/osgi/issues/810


>
> --Sean
>