SSLContext instances

[Peter Firmstone]

I think it would be useful to configure the JVM to prevent loading of 
untrusted (unsigned) code.   This might be useful in preventing 
injection attacks, where the attacker is attempting to have the JVM load 
remote untrusted code.

-- 
Regards,
  
Peter

On 4/04/2025 3:45 am, Scott Lewis wrote:
> 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
>>