Hi Otavio,
According to [1], both TLS 1.0 & 1.1 are now disabled in Oracle Java.
SSLv3 has actually been disabled sinsce Java 8 I believe.
There is a related OpenJDK issue as well [2]. I also don't have access
to the CI server but it would make sense that it's updated to use the
latest Java versions.
@Claus, would it make sense to disable the SSLv3 integration tests?
1. https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8202343
2. https://bugs.openjdk.java.net/browse/JDK-8257122
Regards,
Karen
On 23/06/2021 17:17, Otavio Rodolfo Piske wrote:
Hello Karen,
Thanks for checking this! I can't say for sure because I don't have access
to the CI server.
In my case, I do have a custom java.security file that I use to run the
tests (I do this because of some changes applied to Fedora some time ago
[1]). It may be possible that a recent upgrade on the servers or their
configurations changed the java.security there in a similar way to what
Fedora did in the past.
1.
https://www.orpiske.net/2020/12/sslhandshakeexception-no-cipher-suites-in-common/
Kind regards
On Wed, Jun 23, 2021 at 3:29 PM Karen Lease <karenlease...@gmail.com> wrote:
Hi all,
If it's of interest, I *can* reproduce the SSL errors in the camel-ftp
integration tests in my local environment.
After enabling javax.net.debug, the root cause is visible:
javax.net.ssl|ERROR|01|main|2021-06-22 19:05:23.068
CEST|TransportContext.java:341|Fatal (HANDSHAKE_FAILURE): Couldn't
kickstart handshaking (
"throwable" : {
javax.net.ssl.SSLHandshakeException: No appropriate protocol
(protocol is disabled or cipher suites are inappropriate)
at
java.base/sun.security.ssl.HandshakeContext.<init>(HandshakeContext.java:170)
My java version is:
OpenJDK 64-Bit Server VM (build 11.0.11+9-Ubuntu-0ubuntu2.20.04, mixed
mode, sharing)
I found that most of the failing tests ran if I removed SSLv3 from the
property jdk.tls.disabledAlgorithms in the java.security file.
However the tests using SSLContextParameters with the socketProtocol set
to SSLv3 still failed. This is because the SSLv3 is excluded by the
default filter in BaseSSLContextParameters and the only other available
protocol for the created sockets was TLSv1 which was also excluded in
the default java.security configuration.
By also removing that from the jdk.tls.disabledAlgorithms property those
tests pass as well.
It seems normal that these old protocols are disabled on Java 11 or
later and that the IT tests fail. But if it works for Otavio & Claus, is
it due to a leniant java.security configuration or some other difference
in the system configuration?
Regards,
Karen Lease
On 21/06/2021 17:24, Otavio Rodolfo Piske wrote:
@Claus
I tried reproducing the FTP errors locally and I couldn't as well.
Neither
locally nor on my own CI.
If it doesn't get fixed by Thursday, I will try to take a look at it by
Friday.
On Mon, Jun 21, 2021 at 12:54 PM Claus Ibsen <claus.ib...@gmail.com>
wrote:
Hi
Okay so we are down to a few JIRAs for 3.11.
On thing I wanted to bring up is that the CI server reports some SSL
errors with testing camel-ftp.
I cannot reproduce this locally
https://ci-builds.apache.org/job/Camel/job/Camel%20JDK11/job/main/lastCompletedBuild/testReport/
The IOTA test errors is also due to security error as it seems the
online service it uses for testing is not accepting the certificate.
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
