[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16866905#comment-16866905
]
Hoss Man commented on SOLR-12988:
---------------------------------
{quote}But that is the reason why you saw the nature of the failure changed....
{quote}
...ah , interesting yes.
FWIW: i realize now i may not have been very clear about the point i was trying
to make in that part of my comment: which was that we shouldn't lose sight of
the fact/appearance of 2 similar but possibly distinct bugs. but it looks like
fundementally it's the same bug (JDK-8212885) and only the _manifestation_
changed due to where/how we use Jetty client vs HttpCLient ... which is god to
know.
{quote}If possible I will try to do that enforcement for Java 11.0.2 or lower
versions. Does that makes sense Hoss Man?
{quote}
I think a better solution is that if they are running java <= 11.0.2 then we
should *WARN* that some SSL features are known to be problematic with that
version of java ... and then le it fail if it's going to fail.
I don't think we should force TLSv1.2 based purely on the version of java –
because IIUC: the problem isn't that TLSv1.3 doesn't work at all, on 11.0.2,
it's that if TLSv1.3 is used in 11.0.2 then checkPeerName doesn't work – which
means if you blanket force TLSv1.2 based on the java version you'll be silently
downgrading the security for people who may not be using checkPeerName=true and
may be completely unaffected.
We could potentially try to make the detection very sophisticated, and
dependent on checkPeerName, but that could still lead to weird situations
if/when people use non-OpenJDK based JVMs, or potentially use their own builds
of Open-JDK that they've patched, etc...
Fundementally i think it's a very bad idea to have Solr's behavior radically
change based on introspection of the JVM details – it makes it very hard to
test/reproduce problems. I think it makes a lot more sense for solr to simply
log "Your JVM is known to have some problems, see URL for details" and let the
failures happen if they are going to happen.
(on the Junit tests side, having assumes around JVM version is fine – because
even then it's not a "silent" behavior change, it's an explicitly "test ignored
because XYZ")
If there was a way to programatically inspect the SSLEngine to say "does this
impl of TLSv1.3 manifest this problem" and change behavior based on that, it
would be one thing – but just looking at the java version constants seems
dangerous for this type of situation
> 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]
