Re: Better support for OpenJSSE?
Am 23.09.2019 um 12:56 schrieb Rémy Maucherat: On Mon, Sep 23, 2019 at 12:42 PM Rainer Jung <mailto:rainer.j...@kippdata.de>> wrote: Hi dev@, hi George, Am 20.09.2019 um 01:36 schrieb George Stanchev: > Since I was the one that brought up a question about OpenJSSE on the > User Mailing List several weeks ago, just wanted to bring up to your > attention that there are quirks of OpenJSSE that people are discovering. > I was able to get TC85 to run with OpenJSSE but admitting haven’t done > extensive testing. For example this thread [1]. There are also other > projects (such as OkHttp http client) that have ran into specificities > on running with OpenJSSE. > > [1] https://github.com/openjsse/openjsse/issues/10#issuecomment-533318077 > > (sorry for top posting, Outlook doesn’t make it easy) I answered on tc-users to your test observations (warnings). IMHO they are not OpenJSSE related. Concerning the GH issue, I did not yet see any similar problems, at least not for TC 9. When using the security manager I added grant codeBase "file:/path/to/openjsse.jar" { permission java.security.AllPermission; }; to catalina.policy and again observed no problems. My updated patch implementing the ALPN check in the normal compat classes is here: http://home.apache.org/~rjung/patches/tc9-openjsse-v2.patch I will now check the unit tests for changed behavior. What would be interesting to know, is whether Graal supports the ALPN methods or not, so that I can check/implement the correct behavior of the new isAlpnSupported() ind GraalCompat. It looks a bit strange, that currently GraalCompat only overwrites one method from JreCompat whereas Jre9Compat overwrites all of them. Graal still only does Java 8 at the moment :) So no ALPN, but OTOH Java 8 doesn't otherwise cause too many problems. Graal works with tomcat-native/OpenSSL and HTTP/2 works fine there. Thanks Rémy, so I'll add fixed no-support for JSSE based ALPN into GraalCompat in the next version of my patch. Rémy Regards, Rainer > *From:*Rémy Maucherat mailto:r...@apache.org>> > *Sent:* Thursday, September 19, 2019 5:02 AM > *To:* Tomcat Developers List mailto:dev@tomcat.apache.org>> > *Subject:* Re: Better support for OpenJSSE? > > On Thu, Sep 19, 2019 at 12:01 PM Mark Thomas mailto:ma...@apache.org> > <mailto:ma...@apache.org <mailto:ma...@apache.org>>> wrote: > > On 19/09/2019 09:27, Rainer Jung wrote: > > > > > I made a patch to detect ALPN support at runtime using reflection. > > Please have a look. Feedback welcome, whether we want to include > that or > > whether we want to stick with the simpler approach we currently use. > > Past experience suggests a lot of users will be on Java 8 for quite some > time. I think it makes sense to support this. > > > Of > > course the windows for Java 8 plus OpenJSSE is getting smaller over > > time, and users could also use tcnative to get TLS 1.3 and HTTP/2. On > > the other hand integration of OpenJSSE is pretty simple and some > users > > don't like native code in their JVM (and its maintenance). IMHO > support > > for OpenJSSE (including HTTP/2) would be a nice addition. > > > > My TC 9 patch is available under: > > > > http://home.apache.org/~rjung/patches/tc9-openjsse.patch > > > > It moves the ALPN detection from classes Jre(9)Compat to class TLS in > > the same package and uses the same approach that we use for other > > runtime detection. It needs to make one method accessible, > because under > > Java 9+ the implementation class SSLEngineImpl is no longer a public > > class. Since it is accessed normally via SSLEngine, direct method > calls > > still work, but reflective calls no longer. > > Currently TLS.java is only used by the unit tests. > > We only need to use reflection on Java 8 since we know ALPN is available > on Java 9 onwards. > > The module system adds additional restrictions to calling > setAccessible() that might cause problems in the future. > > I was a bit worried about that too. > > > I wonder if a cleaner solution might be: > >
Re: Better support for OpenJSSE?
On Mon, Sep 23, 2019 at 12:42 PM Rainer Jung wrote: > Hi dev@, hi George, > > Am 20.09.2019 um 01:36 schrieb George Stanchev: > > Since I was the one that brought up a question about OpenJSSE on the > > User Mailing List several weeks ago, just wanted to bring up to your > > attention that there are quirks of OpenJSSE that people are discovering. > > I was able to get TC85 to run with OpenJSSE but admitting haven’t done > > extensive testing. For example this thread [1]. There are also other > > projects (such as OkHttp http client) that have ran into specificities > > on running with OpenJSSE. > > > > [1] > https://github.com/openjsse/openjsse/issues/10#issuecomment-533318077 > > > > (sorry for top posting, Outlook doesn’t make it easy) > > I answered on tc-users to your test observations (warnings). IMHO they > are not OpenJSSE related. > > Concerning the GH issue, I did not yet see any similar problems, at > least not for TC 9. When using the security manager I added > > grant codeBase "file:/path/to/openjsse.jar" { > permission java.security.AllPermission; > }; > > to catalina.policy and again observed no problems. > > My updated patch implementing the ALPN check in the normal compat > classes is here: > > http://home.apache.org/~rjung/patches/tc9-openjsse-v2.patch > > I will now check the unit tests for changed behavior. > > What would be interesting to know, is whether Graal supports the ALPN > methods or not, so that I can check/implement the correct behavior of > the new isAlpnSupported() ind GraalCompat. It looks a bit strange, that > currently GraalCompat only overwrites one method from JreCompat whereas > Jre9Compat overwrites all of them. > Graal still only does Java 8 at the moment :) So no ALPN, but OTOH Java 8 doesn't otherwise cause too many problems. Graal works with tomcat-native/OpenSSL and HTTP/2 works fine there. Rémy > > Regards, > > Rainer > > > *From:*Rémy Maucherat > > *Sent:* Thursday, September 19, 2019 5:02 AM > > *To:* Tomcat Developers List > > *Subject:* Re: Better support for OpenJSSE? > > > > On Thu, Sep 19, 2019 at 12:01 PM Mark Thomas > <mailto:ma...@apache.org>> wrote: > > > > On 19/09/2019 09:27, Rainer Jung wrote: > > > > > > > > > I made a patch to detect ALPN support at runtime using reflection. > > > Please have a look. Feedback welcome, whether we want to include > > that or > > > whether we want to stick with the simpler approach we currently > use. > > > > Past experience suggests a lot of users will be on Java 8 for quite > some > > time. I think it makes sense to support this. > > > > > Of > > > course the windows for Java 8 plus OpenJSSE is getting smaller > over > > > time, and users could also use tcnative to get TLS 1.3 and > HTTP/2. On > > > the other hand integration of OpenJSSE is pretty simple and some > > users > > > don't like native code in their JVM (and its maintenance). IMHO > > support > > > for OpenJSSE (including HTTP/2) would be a nice addition. > > > > > > My TC 9 patch is available under: > > > > > > http://home.apache.org/~rjung/patches/tc9-openjsse.patch > > > > > > It moves the ALPN detection from classes Jre(9)Compat to class > TLS in > > > the same package and uses the same approach that we use for other > > > runtime detection. It needs to make one method accessible, > > because under > > > Java 9+ the implementation class SSLEngineImpl is no longer a > public > > > class. Since it is accessed normally via SSLEngine, direct method > > calls > > > still work, but reflective calls no longer. > > > > Currently TLS.java is only used by the unit tests. > > > > We only need to use reflection on Java 8 since we know ALPN is > available > > on Java 9 onwards. > > > > The module system adds additional restrictions to calling > > setAccessible() that might cause problems in the future. > > > > I was a bit worried about that too. > > > > > > I wonder if a cleaner solution might be: > > > > - Move isTlsv13Available to TesterSupport and deprecate TLS.java > > > > - Add isAlpnAvailable() to JreCompat where: > >- Java 7 (for 8.5.x) hard codes to false > >- Java 8 uses reflection > >- Java 9 hard codes to true > > > > +1 > > > > Personally I wouldn't use OpenJSSE over tomcat-native (performance ? > > long term support ?), but since it's only about making the Tomcat code a > > bit more flexible that works for me. > > > > Rémy > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Better support for OpenJSSE?
Hi dev@, hi George, Am 20.09.2019 um 01:36 schrieb George Stanchev: Since I was the one that brought up a question about OpenJSSE on the User Mailing List several weeks ago, just wanted to bring up to your attention that there are quirks of OpenJSSE that people are discovering. I was able to get TC85 to run with OpenJSSE but admitting haven’t done extensive testing. For example this thread [1]. There are also other projects (such as OkHttp http client) that have ran into specificities on running with OpenJSSE. [1] https://github.com/openjsse/openjsse/issues/10#issuecomment-533318077 (sorry for top posting, Outlook doesn’t make it easy) I answered on tc-users to your test observations (warnings). IMHO they are not OpenJSSE related. Concerning the GH issue, I did not yet see any similar problems, at least not for TC 9. When using the security manager I added grant codeBase "file:/path/to/openjsse.jar" { permission java.security.AllPermission; }; to catalina.policy and again observed no problems. My updated patch implementing the ALPN check in the normal compat classes is here: http://home.apache.org/~rjung/patches/tc9-openjsse-v2.patch I will now check the unit tests for changed behavior. What would be interesting to know, is whether Graal supports the ALPN methods or not, so that I can check/implement the correct behavior of the new isAlpnSupported() ind GraalCompat. It looks a bit strange, that currently GraalCompat only overwrites one method from JreCompat whereas Jre9Compat overwrites all of them. Regards, Rainer *From:*Rémy Maucherat *Sent:* Thursday, September 19, 2019 5:02 AM *To:* Tomcat Developers List *Subject:* Re: Better support for OpenJSSE? On Thu, Sep 19, 2019 at 12:01 PM Mark Thomas <mailto:ma...@apache.org>> wrote: On 19/09/2019 09:27, Rainer Jung wrote: > I made a patch to detect ALPN support at runtime using reflection. > Please have a look. Feedback welcome, whether we want to include that or > whether we want to stick with the simpler approach we currently use. Past experience suggests a lot of users will be on Java 8 for quite some time. I think it makes sense to support this. > Of > course the windows for Java 8 plus OpenJSSE is getting smaller over > time, and users could also use tcnative to get TLS 1.3 and HTTP/2. On > the other hand integration of OpenJSSE is pretty simple and some users > don't like native code in their JVM (and its maintenance). IMHO support > for OpenJSSE (including HTTP/2) would be a nice addition. > > My TC 9 patch is available under: > > http://home.apache.org/~rjung/patches/tc9-openjsse.patch > > It moves the ALPN detection from classes Jre(9)Compat to class TLS in > the same package and uses the same approach that we use for other > runtime detection. It needs to make one method accessible, because under > Java 9+ the implementation class SSLEngineImpl is no longer a public > class. Since it is accessed normally via SSLEngine, direct method calls > still work, but reflective calls no longer. Currently TLS.java is only used by the unit tests. We only need to use reflection on Java 8 since we know ALPN is available on Java 9 onwards. The module system adds additional restrictions to calling setAccessible() that might cause problems in the future. I was a bit worried about that too. I wonder if a cleaner solution might be: - Move isTlsv13Available to TesterSupport and deprecate TLS.java - Add isAlpnAvailable() to JreCompat where: - Java 7 (for 8.5.x) hard codes to false - Java 8 uses reflection - Java 9 hard codes to true +1 Personally I wouldn't use OpenJSSE over tomcat-native (performance ? long term support ?), but since it's only about making the Tomcat code a bit more flexible that works for me. Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Better support for OpenJSSE?
Since I was the one that brought up a question about OpenJSSE on the User Mailing List several weeks ago, just wanted to bring up to your attention that there are quirks of OpenJSSE that people are discovering. I was able to get TC85 to run with OpenJSSE but admitting haven’t done extensive testing. For example this thread [1]. There are also other projects (such as OkHttp http client) that have ran into specificities on running with OpenJSSE. [1] https://github.com/openjsse/openjsse/issues/10#issuecomment-533318077 (sorry for top posting, Outlook doesn’t make it easy) From: Rémy Maucherat Sent: Thursday, September 19, 2019 5:02 AM To: Tomcat Developers List Subject: Re: Better support for OpenJSSE? On Thu, Sep 19, 2019 at 12:01 PM Mark Thomas mailto:ma...@apache.org>> wrote: On 19/09/2019 09:27, Rainer Jung wrote: > I made a patch to detect ALPN support at runtime using reflection. > Please have a look. Feedback welcome, whether we want to include that or > whether we want to stick with the simpler approach we currently use. Past experience suggests a lot of users will be on Java 8 for quite some time. I think it makes sense to support this. > Of > course the windows for Java 8 plus OpenJSSE is getting smaller over > time, and users could also use tcnative to get TLS 1.3 and HTTP/2. On > the other hand integration of OpenJSSE is pretty simple and some users > don't like native code in their JVM (and its maintenance). IMHO support > for OpenJSSE (including HTTP/2) would be a nice addition. > > My TC 9 patch is available under: > > http://home.apache.org/~rjung/patches/tc9-openjsse.patch > > It moves the ALPN detection from classes Jre(9)Compat to class TLS in > the same package and uses the same approach that we use for other > runtime detection. It needs to make one method accessible, because under > Java 9+ the implementation class SSLEngineImpl is no longer a public > class. Since it is accessed normally via SSLEngine, direct method calls > still work, but reflective calls no longer. Currently TLS.java is only used by the unit tests. We only need to use reflection on Java 8 since we know ALPN is available on Java 9 onwards. The module system adds additional restrictions to calling setAccessible() that might cause problems in the future. I was a bit worried about that too. I wonder if a cleaner solution might be: - Move isTlsv13Available to TesterSupport and deprecate TLS.java - Add isAlpnAvailable() to JreCompat where: - Java 7 (for 8.5.x) hard codes to false - Java 8 uses reflection - Java 9 hard codes to true +1 Personally I wouldn't use OpenJSSE over tomcat-native (performance ? long term support ?), but since it's only about making the Tomcat code a bit more flexible that works for me. Rémy
Re: Better support for OpenJSSE?
On Thu, Sep 19, 2019 at 12:01 PM Mark Thomas wrote: > On 19/09/2019 09:27, Rainer Jung wrote: > > > > > I made a patch to detect ALPN support at runtime using reflection. > > Please have a look. Feedback welcome, whether we want to include that or > > whether we want to stick with the simpler approach we currently use. > > Past experience suggests a lot of users will be on Java 8 for quite some > time. I think it makes sense to support this. > > > Of > > course the windows for Java 8 plus OpenJSSE is getting smaller over > > time, and users could also use tcnative to get TLS 1.3 and HTTP/2. On > > the other hand integration of OpenJSSE is pretty simple and some users > > don't like native code in their JVM (and its maintenance). IMHO support > > for OpenJSSE (including HTTP/2) would be a nice addition. > > > > My TC 9 patch is available under: > > > > http://home.apache.org/~rjung/patches/tc9-openjsse.patch > > > > It moves the ALPN detection from classes Jre(9)Compat to class TLS in > > the same package and uses the same approach that we use for other > > runtime detection. It needs to make one method accessible, because under > > Java 9+ the implementation class SSLEngineImpl is no longer a public > > class. Since it is accessed normally via SSLEngine, direct method calls > > still work, but reflective calls no longer. > > Currently TLS.java is only used by the unit tests. > > We only need to use reflection on Java 8 since we know ALPN is available > on Java 9 onwards. > > The module system adds additional restrictions to calling > setAccessible() that might cause problems in the future. > I was a bit worried about that too. > > I wonder if a cleaner solution might be: > > - Move isTlsv13Available to TesterSupport and deprecate TLS.java > > - Add isAlpnAvailable() to JreCompat where: > - Java 7 (for 8.5.x) hard codes to false > - Java 8 uses reflection > - Java 9 hard codes to true > +1 Personally I wouldn't use OpenJSSE over tomcat-native (performance ? long term support ?), but since it's only about making the Tomcat code a bit more flexible that works for me. Rémy
Re: Better support for OpenJSSE?
Am 19.09.2019 um 12:01 schrieb Mark Thomas: On 19/09/2019 09:27, Rainer Jung wrote: I made a patch to detect ALPN support at runtime using reflection. Please have a look. Feedback welcome, whether we want to include that or whether we want to stick with the simpler approach we currently use. Past experience suggests a lot of users will be on Java 8 for quite some time. I think it makes sense to support this. Of course the windows for Java 8 plus OpenJSSE is getting smaller over time, and users could also use tcnative to get TLS 1.3 and HTTP/2. On the other hand integration of OpenJSSE is pretty simple and some users don't like native code in their JVM (and its maintenance). IMHO support for OpenJSSE (including HTTP/2) would be a nice addition. My TC 9 patch is available under: http://home.apache.org/~rjung/patches/tc9-openjsse.patch It moves the ALPN detection from classes Jre(9)Compat to class TLS in the same package and uses the same approach that we use for other runtime detection. It needs to make one method accessible, because under Java 9+ the implementation class SSLEngineImpl is no longer a public class. Since it is accessed normally via SSLEngine, direct method calls still work, but reflective calls no longer. Currently TLS.java is only used by the unit tests. We only need to use reflection on Java 8 since we know ALPN is available on Java 9 onwards. The module system adds additional restrictions to calling setAccessible() that might cause problems in the future. I wonder if a cleaner solution might be: - Move isTlsv13Available to TesterSupport and deprecate TLS.java - Add isAlpnAvailable() to JreCompat where: - Java 7 (for 8.5.x) hard codes to false - Java 8 uses reflection - Java 9 hard codes to true As long as we only talk about OpenJSSE I like the above. We can vary it, once more solutions come into play that might change behavior for Java below or above 8. But probably that will never happen. I can provide an updated version of the patch for review later today. Thanks for your feedback. Any other opinion? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Better support for OpenJSSE?
On 19/09/2019 09:27, Rainer Jung wrote: > I made a patch to detect ALPN support at runtime using reflection. > Please have a look. Feedback welcome, whether we want to include that or > whether we want to stick with the simpler approach we currently use. Past experience suggests a lot of users will be on Java 8 for quite some time. I think it makes sense to support this. > Of > course the windows for Java 8 plus OpenJSSE is getting smaller over > time, and users could also use tcnative to get TLS 1.3 and HTTP/2. On > the other hand integration of OpenJSSE is pretty simple and some users > don't like native code in their JVM (and its maintenance). IMHO support > for OpenJSSE (including HTTP/2) would be a nice addition. > > My TC 9 patch is available under: > > http://home.apache.org/~rjung/patches/tc9-openjsse.patch > > It moves the ALPN detection from classes Jre(9)Compat to class TLS in > the same package and uses the same approach that we use for other > runtime detection. It needs to make one method accessible, because under > Java 9+ the implementation class SSLEngineImpl is no longer a public > class. Since it is accessed normally via SSLEngine, direct method calls > still work, but reflective calls no longer. Currently TLS.java is only used by the unit tests. We only need to use reflection on Java 8 since we know ALPN is available on Java 9 onwards. The module system adds additional restrictions to calling setAccessible() that might cause problems in the future. I wonder if a cleaner solution might be: - Move isTlsv13Available to TesterSupport and deprecate TLS.java - Add isAlpnAvailable() to JreCompat where: - Java 7 (for 8.5.x) hard codes to false - Java 8 uses reflection - Java 9 hard codes to true Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org