Re: Better support for OpenJSSE?

2019-09-23 Thread Rainer Jung

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?

2019-09-23 Thread Rémy Maucherat
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?

2019-09-23 Thread Rainer Jung

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?

2019-09-19 Thread 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)

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?

2019-09-19 Thread Rémy Maucherat
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?

2019-09-19 Thread Rainer Jung

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?

2019-09-19 Thread 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

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org