Thank you Remy for fixing it and the explanation.
Am 27.02.24 um 15:33 schrieb Rémy Maucherat:
On Tue, Feb 27, 2024 at 1:32 PM Rainer Jung <rainer.j...@kippdata.de> wrote:
Hi Mark, hi all,
coming back to this: the reason, why you could not reproduce is, that I
explicitly set
test.sslImplementation=org.apache.tomcat.util.net.jsse.JSSEImplementation
when testing JSSE. It is not necessary but IMHO it should be supported.
The failure was probably triggered by
1064d250c9463d3604d14de6229cf9edd4f04710 changing class
test/org/apache/tomcat/util/net/TestSsl.java in combination with a
difference in TesterSupport between 9.0.x and 10.1.x.
In 9.0.x (and probably 8.5.x) in
test/org/apache/tomcat/util/net/TesterSupport.java method
isClientRenegotiationSupported contains:
...
240 String sslImplementation =
System.getProperty("tomcat.test.sslImplementation");
241 if (sslImplementation != null &&
!"${test.sslImplementation}".equals(sslImplementation)) {
242 // Assume custom SSL is not supporting this
243 return false;
244 }
...
In 10.1.x:
...
// Disabled for Tomcat Native (part of response to CVE-2009-3555)
// Only JRE provided JSSE implementation supports this
String sslImplementation = (String)
tomcat.getConnector().getProperty("sslImplementationName");
if
(!JSSEImplementation.class.getName().equals(sslImplementation)) {
return false;
}
...
So for 9.x setting JSSE explicitly result in returning false. In 10.1.x
the check !JSSEImplementation.class.getName().equals(sslImplementation)
makes sure it is not returning false.
Unfortunately taking over the code from 10.1.x to 9.x does not work,
because at this point
tomcat.getConnector().getProperty("sslImplementationName") returns null.
Possible fix:
--- a/test/org/apache/tomcat/util/net/TesterSupport.java
+++ b/test/org/apache/tomcat/util/net/TesterSupport.java
@@ -64,6 +64,7 @@ import org.apache.tomcat.util.descriptor.web.LoginConfig;
import org.apache.tomcat.util.descriptor.web.SecurityCollection;
import org.apache.tomcat.util.descriptor.web.SecurityConstraint;
import org.apache.tomcat.util.net.SSLHostConfigCertificate.Type;
+import org.apache.tomcat.util.net.jsse.JSSEImplementation;
public final class TesterSupport {
@@ -238,7 +239,8 @@ public final class TesterSupport {
return false;
}
String sslImplementation =
System.getProperty("tomcat.test.sslImplementation");
- if (sslImplementation != null &&
!"${test.sslImplementation}".equals(sslImplementation)) {
+ if (sslImplementation != null &&
!"${test.sslImplementation}".equals(sslImplementation) &&
+
!JSSEImplementation.class.getName().equals(sslImplementation)) {
// Assume custom SSL is not supporting this
return false;
}
Not sure this is the right fix, or it would be better to use a change
that is closer to 10.1.x and find out, why
tomcat.getConnector().getProperty("sslImplementationName") is null
inside isClientRenegotiationSupported.
Ok so I picked up your change.
Things are different in 10.1 because the tests are parametrized.
Actually when you run the test, for example TestSsl, it always does
the same tests regardless of what you configure (so JSSE, OpenSSL,
OpenSSL-FFM). This is mostly due to the APR connector being removed.
Rémy
Best regards,
Rainer
Am 18.01.24 um 21:48 schrieb Mark Thomas:
On 18/01/2024 12:33, Rainer Jung wrote:
Hi all,
after the refactorings for the testing of the forbidden client
initiated renegotiations, these unit tests fail for me for the last
tags of TC 8.5 and 9, but not for 10.1 and 11. I am using JSSE and the
tests fail consistently for all four JDK vendors I am testing against
on all linux distributions I am testing on. I saw it for Java 8 and
11. No info yet about 17 and 21, the test runs will arrive at Java 17
later today.
Very odd. I just ran the 9.0.x test with Java 8 / JSSE and it passed.
Example output (no indication for a reason):
<snip/>
Testcase: testClientInitiatedRenegotiation took 0.383 sec
FAILED
Renegotiation started when it should have failed
junit.framework.AssertionFailedError: Renegotiation started when it
should have failed
at
org.apache.tomcat.util.net.TestSsl.testClientInitiatedRenegotiation(TestSsl.java:250)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Odd. With JSSE and NIO, client initiated renegotiation should work.
I can't recreate this. If you can recreate this in a debugger then I'd
look at TesterSupport.isClientRenegotiationSupported()
Mark
I expect it is a new problem in the test after the refactoring, not a
real TLS issue.
Best regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
