Hello all,
I finally tested this with a server (Jetty 9.4.14) running on JDK8
and running on JDK11 with -Djdk.tls.server.protocols=TLSv1.2. With
both configurations I was unable to trigger this issue. For sake of
completeness I also tried JDK11 with default TLS settings and a
non-wildcard certificate. Same result there.
From all this I conclude that a JDK11 client with TLSv1.3 enabled
(which is the default) intermittently fails to complete a HTTPS
request to a Jetty server running on JD11 also with TLSv1.3 enabled
if the used domain name is covered by a wildcard certificate.
Forcing a SslContext#reload on the server immediately triggers the
issue after which it sometimes disappears within a couple of minutes
but I have also observed the issue to persist for multiple hours.
The issue may also occur spontaneously and in that case it also
takes up to several hours to go away. The issue has been reproduced
with Jetty versions 9.4.11, 9.4.13 and 9.4.14.
Running the server with TLSv1.3 disabled seems to be the best way to
suppress the issue for now.
Kind regards,
Silvio
On 01-02-19 16:32, Silvio Bierman
wrote:
Hello all,
Another follow up on the same issue:
I have not yet set up a server on JDK8 but I have tried some other
variation to further narrow things down. Using
-Djdk.tls.client.protocols=TLSv1.2 on the client side of the
connection forces the use of TLSv1.2 (as opposed to 1.3 which is
the JDK11 default) and in that case everything works fine. The
server still uses 1.3 if available and therefore still fails for
1.3 clients at the same time. But the 1.2 clients work without
issues.
My next try will be running the server with TLSv1.2 but I expect
that will simply suppress the issue for all clients.
I do not know if this is useful information at all. I have read
somewhere that the 1.3 code in JDK11 results in a different
ordering of some callbacks to the code managing server sockets but
I have too little experience there to make any educated guesses.
I will return soon with more information.
Kind regards,
Silvio
On 30-01-19 00:48, Silvio Bierman
wrote:
Hi Greg,
I just want to let you all know that I have reproduced the same
issue with a server running on Jetty 9.4.11.v20180605. I
triggered an SslContextFactory.reload on the server and
immediately got the same error on the client.
Since this version by far predates the first occurrence of the
issue on our servers I am now convinced this is something that
was introduced with our move from JDK10 (actually JDK11 early
builds on Ubuntu 18.04) to JDK11 (and Ubuntu 18.10) which
coincided with our move from Jetty 9.4.13 to 9.4.14. Now we know
the Jetty version is clearly not causing this it must be
something related to JDK11.
Since it is triggered by manipulating the server I am still
looking in that direction. My next step will be testing against
a server (with Jetty 9.4.14) running on JDK8. I will keep you
posted.
Kind regards,
Silvio
On 29-01-19 08:30, Greg Wilkins
wrote:
Silvio,
I am reading your emails... but so far I've had no
idea pop into my head.
The only thing I can think of is perhaps replacing
the SslContextFactory with exactly the code
from 9.4.12 (I think 13 was a bad release for other
reasons) and see if that makes any difference. If it
works, then you could probably bisect the commits
(only about 8 done last year).
cheers
Hello all,
Another followup on the same topic: triggering a
SslContextFactory.reload on the server consistently and
immediately
triggers the problem on the client side, restarting the
server is close
to 100% (seems timing related). I was still leaning toward
something
fishy in the client code or even the JDK11 SSL client
socket code but
now I am almost certain this is going awry on the server
side.
Still JDK11 on both client and server side and Jetty
9.4.14.v20181114
server, using domain names that are covered by wildcard
certificates.
I am busy setting up a server with 9.4.11 and JDK8 to see
what happens
there but since I am packed it may take another week or so
to get results.
I will keep you posted.
>> One addition: this morning I replaced the
keystore file on one of the
>> servers because some almost-expired certificates
had been updated and
>> subsequently triggered a SslContextFactory.reload
through the
>> application. Within 15 minutes the logging showed
about two dozen
>> failed requests. Then it silently went away. May
be a coincidence of
>> course.
>>
>> Silvio
>>
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
--
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
|
