On Thu, Jan 22, 2015 at 6:57 PM, Emmanuel Lécharny <[email protected]> wrote:
> Le 22/01/15 11:08, Emmanuel Lécharny a écrit : > > Le 22/01/15 00:07, Kiran Ayyagari a écrit : > >> On Thu, Jan 22, 2015 at 6:45 AM, Emmanuel Lécharny <[email protected] > > > >> wrote: > >> > >>> Some update : > >>> > >>> I have now set a list of existing and supported Cipher for the user to > >>> select. It looks like this : > >>> > >>> .--------------------------------. > >>> |V SSL Advanced Settings | > >>> +--------------------------------+ > >>> | [X] Require Client Auth | > >>> | [X] Request Client Auth | > >>> | Ciphers suite : | > >>> | +--------------------------+ | > >>> | |[X] xyz | | > >>> | |[X] abc | | > >>> | |[X] def | | > >>> | +--------------------------+ | > >>> | Enabled protocols : | > >>> | [X] SSLv3 [X] TLSv1 | > >>> | [X] TLSv1.1 [X] TLSv1.2 | > >>> +--------------------------------+ > >>> > >>> You can select one or more ciphers, all of them are selected by > default. > >>> The selection is done based on the underlying JAVA version used on the > >>> server, so I have to add a checkbox to select either Java 7 or Java 8. > >>> > >>> this setting can quickly become stale, especially at the pace java > >> versions are EOLed > >> > >> Instead I suggest we provide a textbox (in the advance options) to let > the > >> user key in > >> the desired cipher if none is needed beside the default ciphers. > > Ok, let's face reality here : > > > > do you really want users to type things like > > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 ? > definitely not typing but paste for sure, this is strictly under the assumption that the user is aware of what he is doing > > > > When using SSL, the security provider to use is JSSE, which comes with a > > list of supported ciphers, which are either enabled or disabled. This is > > quite a long list, and there is no mean to add some cipher from this > > list, because they won't be supported anyway. > > > > The issue is what list of ciphers will Java 9 support ? We don't know > > yet. But adding a support for those ciphers is just a matter of adding > > them to the SupportedCipher enum, and add a new JavaVersion in the combo > > I'm currently adding in this tab. > > A real problem here is that the list of ciphers supported in Java 7 is > smaller than the list supported in Java 8. We don't keep a track of the > Java version used on the server in the config, so we have to be quite > careful in the way we propose a list that will be stored in teh config. > Typically, if we set the list of supported ciphers to be the one that > Java 8 supports, but run the server on Java 7, there will be some > problem. It's not necessarily the right option to let the user select > the Java version the server will run of from Studio, it's likely to be > changed without notice. > > I have no clear solution for that, except that every cipher supported by > Java 7 are also supported by Java 8. At this point, I may simply use the > Java 8 ciphers, and up to the server to remove the ones that aren't > supported... > > All in all, I'm not anymore keen on proposing a Java version to use... > yeah, this becomes an unnecessary maintenance work -- Kiran Ayyagari http://keydap.com
