camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Vottner <r...@gmx.at>
Subject Re: 2.19.0 Jetty:Https javax.net.ssl.SSLHandshakeException: no cipher suites in common
Date Thu, 29 Jun 2017 10:15:26 GMT
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.freihalter@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&amp;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.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message