Operating System: All
Platform: All

Looking for various vulnerable components, found these so far:

• PCEP - uses TLS transport option
• Openflow plugin - uses TLS transport option
• Jetty - jetty used by RESTCONF or karaf components such as webconsole can use ssl for transport
• Tomcat - in configuration folder there is a config file for tomcat with SSL enabled by default. This is for AD-SAL ?

Started looking at PCEP and its cipher suits, listing default enabled cipher suits returns following list:

ENABLED = [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_RC4_128_MD5
TLS_EMPTY_RENEGOTIATION_INFO_SCSV]

There is no DHE with EXPORT among them so my question is, how to move on with this. Do we want to review this list and reorder/filter these ciphers and set this new list as enabled ciphers where SSL is used ?

This contains RC4 which is banned by RFC7465 https://tools.ietf.org/html/rfc7465

It will be good if we can pull crypto initialization into a utility class for all to use. Otherwise when people for example resolve 3554 https://bugs.opendaylight.org/show_bug.cgi?id=3554 they will reintroduce the same problem once more.

Yeah, we should provide a utility class for this. We need to find out exactly what will it do. First thing would be to disable RC4 ciphers (similar what patch for 3554 does). It should also disable EXPORT and NULL ciphers. What else ?

Also we need to find a place for it somewhere, available for all projects.

This would fix the vulnerabilities in the code started components, but we should also modify the xml configs for tomcat and jetty in a similar fashion.

My proposal for a common "CryptoUtils" class:

https://git.opendaylight.org/gerrit/#/c/21880/

Its located in the protocol framework in controller project for now.

Adding Robert as a watcher, a testcase to verify his proposed approach will be attached shortly.

Attached is a java cipher list example courtesy of Atlassian.

If you specify RC4, etc in the disabled cipher list the security.properties they disappear from the list (good).

However the actual ciphers involved in Logjam - the export 40 bit ones cannot be removed this way. While in theory that (rather badly documented) property should be able to take f.e. DES keylength < 56 it does not. The cipher stays. Specifying DES40 also does not remove it.

So unless I am missing a possible option on how to configure it, this approach does not work (besides it being documented as sun specific and not guaranteed to be supported across the board).

Attachment Ciphers.java has been added with description: Java cipher list test courtesy of Atlassian

Anton, can you show me the exact settings for
jdk.tls.disabledAlgorithms
jdk.certpath.disabledAlgorithms
that you tested with ?

Also, you are mentioning keylength, shouldnt it be keySize ?

My final security.properties which seems to yield what we want is:

jdk.tls.disabledAlgorithms=EXPORT, RC4, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5, TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA, anon

This works. The problem was that I had it scripted for testing and the -D argument ended up after the java file, not before. As a result the property was not being set. After fixing my testcase it all worked fine (with these settings).

It works with OpenJDK, it works with Oracle JDK and it is honoured by IBM (if they ever decide to contribute something). That for me is good enough. We can close this one and leave the relevant settings to the actual packagers.

Can we propose a patch which will add these properties to the base karaf-empty (or whichever) distribution, that way they will get picked up by integration as well per-project distros.

I can do that tomorrow... if anyone else is interested in taking it, feel free.

https://git.opendaylight.org/gerrit/#/c/22261/

This commit introduces custom odl.java.security config file and modifies the startup scripts to include this file by default.

Thanks for the patch, Maros. It would be great if we can get this merged in time for GA of Lithium.