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
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
