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
On Tue, 29 Jan 2019 at 11:51, Silvio Bierman
<[email protected] <mailto:[email protected]>>
wrote:
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
[email protected] <mailto:[email protected]>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
--
Greg Wilkins <[email protected] <mailto:[email protected]>> CTO
http://webtide.com
_______________________________________________
jetty-users mailing list
[email protected]
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
[email protected]
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
[email protected]
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
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
