Am 23.09.2019 um 12:56 schrieb Rémy Maucherat:
On Mon, Sep 23, 2019 at 12:42 PM Rainer Jung <rainer.j...@kippdata.de
<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 <r...@apache.org <mailto:r...@apache.org>>
> *Sent:* Thursday, September 19, 2019 5:02 AM
> *To:* Tomcat Developers List <dev@tomcat.apache.org
<mailto:dev@tomcat.apache.org>>
> *Subject:* Re: Better support for OpenJSSE?
>
> On Thu, Sep 19, 2019 at 12:01 PM Mark Thomas <ma...@apache.org
<mailto:ma...@apache.org>
> <mailto:ma...@apache.org <mailto:ma...@apache.org>>> wrote:
>
> On 19/09/2019 09:27, Rainer Jung wrote:
>
> <snip/>
>
> > 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
