Hi, On Tue, Oct 6, 2015 at 1:20 PM, Silvio Bierman <[email protected]> wrote: > Hallo all, > > I have an embedded Jetty 9.3 server instance and am trying to control the > ciphers it supports via a number of call to > SslContextFactory.addExcludeCipherSuites. I have found a combination of > excludes that leaves the set of ciphers I need. Among the remaining > supported ciphers I have TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 and > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA. > > When I use sslscan from the Linux command line it reports that the latter is > the "preferrred server cipher". When I connect to the server with Chromium > it also selects this cipher and reports "obsolete encryption". If I disable > this cipher Chrome selects the first one and does not complain about > obsolete encryption. But without the latter cipher there are too many > (older) browsers that can not establish an SSL connection. > > How can I influence what clients conceive as being a preference for specific > ciphers over other ones?
Tricky, if at all possible. The TLS negotiation happens way before any server-side application can know what kind of client is connecting (e.g. via User-Agent string). Typically ordering by strength descending does the job, since older clients will not negotiate the stronger ones. SslContextFactory can be fed with a comparator that is used to sort the ciphers. -- Simone Bordet ---- http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts. _______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
