[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16866796#comment-16866796
]
Hoss Man commented on SOLR-12988:
---------------------------------
bq. Hi guys, this is a problem belongs to HttpClient + Java 11 (TLSv1.3)
(HTTPCLIENT-1967).
Ok ... for start -- I don't think that's entirely true.
The bug as *originally* reported happened when a remote client was
communicating with jetty, and was evidently tied to jetty issue#2711? ... it
did not reproduce on the http2 branch at that time.
At some point after that, after http2 was merged to master, the nature of the
failure changed -- with openjdk 11.0.2 a _NEW_ *similar* looing failure caused
a similar looking stack trace from
TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName -- but only on the
internode communication -- *NOT* on the connection between the test client and
the first node.
This new manifestation of the failure appears to be directly realted to
JDK-8220723 / JDK-8212885, which are cited in the HTTPCLIENT-1967 issue you
mentioned ... but that has been fixed in OpenJDK 11.0.3.
IE: setting asside the changes you already commited: with a patch to revert the
test disabling SSL changes from Mark's decemeber commits,
TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName fails 100% of the time on
OpenJSK 11.0.2 ... but it passes 100% of the time (for me) using OpenJDK 11.0.3
(even w/o your changes to disable TLSv1.3)
----
I think it's a mistake to outright disable TLSv1.3 ... it's *DEFINITELY* a
mistake to claim this is because HttpClient doesn't work with (or doesn't
support) TLSv3, or that we must "Avoid using TLSv1.3 for HttpClient" ...
HttpClient works just fine with TLSv3, as long as it works correctly in the
JVM. (which is exactly what the comments in HTTPCLIENT-1967 already say)
In my opinion, as a last resort we should simply re-enable the tests, and leave
the TLSv3 handling up to the JVM, w/o any special changes. We can note in the
docs that to use checkPeerName on java11 you *must* have 11.0.3 or higher.
A better solution, if possible, would be if there is a way to programatically
detect when this bug exists in the jvm impl, so we can log a clear ERROR
instead of just SSLPeerUnverifiedException that would be prefered.
But i do *NOT* think the way things stand w/your commit to disable TLSv1.3 is a
good long term plan.
> Avoid using TLSv1.3 for HttpClient
> ----------------------------------
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
> Reporter: Hoss Man
> Assignee: Cao Manh Dat
> Priority: Major
> Labels: Java11, Java12
> Attachments: SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with
> TLSv1.3. It caused some test failures below, therefore we should enforce
> HttpClient to uses TLSv1.2 or lower versions.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
