Hi You are welcome to log a JIRA ticket and provide a github PR with a fix for this http://camel.apache.org/contributing
On Thu, Jun 29, 2017 at 12:15 PM, Roman Vottner <r...@gmx.at> wrote: > 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. > -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
