<html><body><div dir="ltr">Since the new Paradigma here is, that all Java Code needs to be trusted I guess there is less and less investive to get rid of those global statics. But besides the issue of Integration multiple codebases there is also a question of features - for example how to configure TLS features based on the Connection and Not with VM wide Security Properties.</div><div dir="ltr"><br></div><div dir="ltr">Both taken together, strengthening the SSLParams case, would be a useful area to explore. Maybe together with a better system for requesting a predefined context (Minimum Protocol Version).</div><div dir="ltr"><br></div><div dir="ltr">(Having said that, just dont use the default context if you care to keep Connection Parameters robust - unlike the security properties if you want to stick to JSSE). </div><div id="ms-outlook-mobile-body-separator-line" dir="ltr"><br></div><div id="ms-outlook-mobile-signature"><div dir="ltr">Gruß,</div><div dir="ltr">Bernd</div><div dir="ltr">-- </div><div dir="ltr">https://bernd.eckenfels.net</div></div><div> </div><hr style="display: inline-block; width: 98%;"><div id="divRplyFwdMsg" dir="ltr"><span style="font-family: Calibri, sans-serif;"><b>Von:</b> security-dev <security-dev-retn@openjdk.org> im Auftrag von Scott Lewis <scottslewis@gmail.com><br><b>Gesendet:</b> Donnerstag, April 3, 2025 7:46 PM<br><b>An:</b> Sean Mullan <sean.mullan@oracle.com>; security-dev@openjdk.org <security-dev@openjdk.org><br><b>Betreff:</b> Re: SSLContext instances</span><div style="font-family: Calibri, sans-serif;"> </div></div>On 4/3/2025 8:20 AM, Sean Mullan wrote:

<br>>

<br>>

<br>> On 3/13/25 3:44 PM, Scott Lewis wrote:

<br>>> But from the point of view of the OSGi framework implementation (for 

<br>>> example), has there been any discussion to alternatives to leaving 

<br>>> SSLContext.setDefault open to all code at all times?  e.g. 

<br>>> deprecation of public static setDefault, or changing the semantics of 

<br>>> setDefault so that it could only be called successfully once (on 

<br>>> startup).  I understand that may not be feasible due to api 

<br>>> conventions, but was wondering if this or other approaches (enhancing 

>> JCP) have been considered/discussed.

<br>>

<br>> I am not familiar with OSGi so I don't understand the scenario you are 

> describing. Can you provide more details?

<br>

<br>Although I'm referring to OSGi because that's my implementation context 

<br>of interest, the thoughts apply to any application where new 

<br>code/components are added/updated incrementally...e.g. many modern web 

servers, many client-side apps.

<br>

<br>The OSGI framework has been using the java mechanisms (built on sm and 

<br>permissions) to restrict these install/update dynamics as appropriate 

<br>for the application...e.g. only installing signed and 

user-approved/trusted code.

<br>

<br>SSLContext.setDefault seems to me to be a notably risky case for any 

<br>dynamic system, and particularly for java-based servers.   I say risky 

<br>not only because of potential for explicit attacks or sslcontext 

<br>provider bug exploits or configuration confusion, but also for the 

<br>potential for errors during installation and/or upgrade, or even just a 

vague level of trust in the component being installed.

<br>

<br>Unlike many of the jvm APIs, SSLContext.setDefault cannot be 

<br>overridden/replaced by the surrounding application and/or a runtime 

<br>framework like OSGi.   Thus the ideas for deprecating it, replacing it 

<br>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.

<br>

<br>I've proposed using OSGi service registry to support framework 

<br>customization and securing of access to creating SSLContext instances in 

<br>the OSGi framework [1].   This does not, however, address the issue of 

<br>the vulnerability resulting from uncontrollable access to 

SSLContext.setDefault...so that's why I asking about it here.

<br>

Thanks.

<br>

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

<br>

<br>

<br>>

<br>> --Sean

<br>>

<br>

<br></body></html>