Hi, Camel 2.19.0 upgraded its Jetty9 version to 9.3.x which only supports TLSv1.2 out of the box. As all ciphers used for TLSv1 (and TLSv1.1) are considered unsafe they get blocked by Jetty9 now and hence no ciphers are available in case of TLSv1 or TLSv1.1. connection attempts. (See https://github.com/eclipse/jetty.project/issues/860 for more information).
According to the Jetty SSL configuration documentation (https://www.eclipse.org/jetty/documentation/9.3.x/configuring-ssl.html) this can be prevented on setting a custom excludeCipherSuites policy. However, Camel seems to not push this settings to the SslContextFactory. I.e. we specify FilterParameters filter = new FilterParameters(); filter.getInclude().add(".*"); List<String> exclusions = filter.getExclude(); exclusions.add("^.*_(MD5|SHA1)$"); scp.setCipherSuitesFilter(filter); inside our SSLContextParameters setup, though through debugging we learned that the SslContextFactory still has the default exclusion pattern „^.*_(MD5|SHA|SHA1)$“ which prevents using TLSv1 or TLSv1.1 compatible ciphers and therefore prevents connections from these protocols. We currently subclassed JettyHttpComponent and specified the exclusion cipher suites manually, which solves the TLSv1/1.1 connection issue: /** * A custom jetty http component which explicitly sets the excludedCipherSuites during creation of the jetty connector. * * Why? It seems camel does not push included/excluded cipherSuites from {@link SSLContextParameters} to the * {@link SslContextFactory} nor does push explicitly listed cipher suites (i.e. like TLS_RSA_WITH_AES_256_CBC_SHA) to * the Jetty SSL context factory. * * @see https://github.com/ecosio/issues/issues/1810 */ public static class HackedJettyHttpComponent extends JettyHttpComponent9 { @Override protected AbstractConnector createConnectorJettyInternal(Server server, JettyHttpEndpoint endpoint, SslContextFactory sslcf) { sslcf.setExcludeCipherSuites("^.*_(MD5|SHA1)$"); return super.createConnectorJettyInternal(server, endpoint, sslcf); } } Once we added this custom JettyHttpComponent we were able to connect via TLSv1 or TLSv1.1 again. (i.e. curl -v -XGET —tlsv1.0 https://localhost:443/api/v1/someResource). Also sslscan localhost:443 listed all available cipher suites. So, basically this seems to be a bug in the JettyHttpComponent not copying the defined filters or parameters properly to the SslContextFactory. HTH, Roman > Am 23.05.2017 um 00:14 schrieb Thomas Freihalter > <thomas.freihal...@my-box.de>: > > Hello > I am using Camel 2.19.0 (on Karaf 4.1.1 with Jetty9) > > My route is > <from > uri="jetty:https://0.0.0.0:4711?matchOnUriPrefix=true&sslContextParametersRef=sslContextParameters"/> > ..... > > When I try to access the URL with my browser I get: > javax.net.ssl.SSLHandshakeException: no cipher suites in common > > I found this Bug-Report: > https://issues.apache.org/jira/browse/CAMEL-10628 > > Is this Bug still not fixed? > Does a workaround for 2.19.0 exists? > (2.17.3 with jetty8 works okay) > > Regards > Thomas > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/2-19-0-Jetty-Https-javax-net-ssl-SSLHandshakeException-no-cipher-suites-in-common-tp5800043.html > Sent from the Camel - Users mailing list archive at Nabble.com.
