Topic
  • 4 replies
  • Latest Post - ‏2018-05-23T19:01:42Z by 77MX_John_Skelton
Scottmitch
Scottmitch
2 Posts

Pinned topic Non Standard TLS Cipher Names

‏2017-07-03T17:51:43Z | ciphers security tls

IBM J9's cipher suites are all prefixed with "SSL_" [1]. This is different than the standard JSSE cipher suite names [2] which generally follow the cipher names as defined in their respective RFCs. J9's custom naming convention for ciphers necessitates that applications which want to run on J9 and other JVM implementations must account for this custom naming convention.

 

FWIW this may have originated from the following text in the standard JSSE cipher suite names [2]:

 

The following list contains the standard JSSE cipher suite names. Over time, various groups have added additional cipher suites to the SSL/TLS namespace. Some JSSE cipher suite names were defined before TLSv1.0 was finalized, and were therefore given the SSL_ prefix. The names mentioned in the TLS RFCs prefixed with TLS_ are functionally equivalent to the JSSE cipher suites prefixed with SSL_.

 

However my interpretation of this statement doesn't allow JVM implementations to required the "SSL_" prefix for all ciphers and push this naming convention on applications. The JVM should be allowed to accept "SSL_" prefixed ciphers but should also handle the "TLS_" ciphers as defined in the JSSE cipher suite names [2] and the respective TLS RFCs [3][4][5][6].

 

Can someone from IBM J9's team clarify the following:

- rational behind the custom cipher names and expected implications on applications which run on JVMs other than J9

- if support can be added for standard cipher names (I'm assuming support for existing "SSL_" prefix wouldn't be impacted)

 

For additional application layer context see [7].

 

[1] https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/ciphersuites.html

[2] http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#ciphersuites

[3] https://tools.ietf.org/html/rfc2246

[4] https://tools.ietf.org/html/rfc4346

[5] https://tools.ietf.org/html/rfc5246

[6] https://tools.ietf.org/html/rfc7919

[7] https://github.com/netty/netty/commit/a94b23df7d367ecb57ed89a9e882e2f47df59306#commitcomment-22797383

  • Tim_Ellison
    Tim_Ellison
    3 Posts

    Re: Non Standard TLS Cipher Names

    ‏2017-07-04T13:12:40Z  

    Hi,

    You say:

    "The JVM should be allowed to accept "SSL_" prefixed ciphers but should also handle the "TLS_" ciphers as defined in the JSSE cipher suite names [2] and the respective TLS RFCs"

    The IBM JSSE2 provider will accept either TLS_ or SSL_ prefix on the cipher suite names, as described in your link [1].

     

    And then you ask:

    - rational behind the custom cipher names and expected implications on applications which run on JVMs other than J9

    My understanding is that this is somewhat historical, based upon the earlier days of defining and extending the cipher suite names, but as you point out the real meaning has now been diminished/lost, which is why the provider does not consider it any longer.

    - if support can be added for standard cipher names (I'm assuming support for existing "SSL_" prefix wouldn't be impacted)

    As I wrote above, you can use either prefix.  Note, however, that if you ask for the supported suites, e.g. using SSLServerSocketFactory#getSuppotedCipherSuites then the set of names will only contain the ssl_ prefixed versions of the names.

  • Scottmitch
    Scottmitch
    2 Posts

    Re: Non Standard TLS Cipher Names

    ‏2017-07-04T13:44:14Z  

    Hi,

    You say:

    "The JVM should be allowed to accept "SSL_" prefixed ciphers but should also handle the "TLS_" ciphers as defined in the JSSE cipher suite names [2] and the respective TLS RFCs"

    The IBM JSSE2 provider will accept either TLS_ or SSL_ prefix on the cipher suite names, as described in your link [1].

     

    And then you ask:

    - rational behind the custom cipher names and expected implications on applications which run on JVMs other than J9

    My understanding is that this is somewhat historical, based upon the earlier days of defining and extending the cipher suite names, but as you point out the real meaning has now been diminished/lost, which is why the provider does not consider it any longer.

    - if support can be added for standard cipher names (I'm assuming support for existing "SSL_" prefix wouldn't be impacted)

    As I wrote above, you can use either prefix.  Note, however, that if you ask for the supported suites, e.g. using SSLServerSocketFactory#getSuppotedCipherSuites then the set of names will only contain the ssl_ prefixed versions of the names.

    Thanks for confirming that SSL_ and TLS_ ciphers should be supported.

     

    Is there a reason why the TLS_ prefixed ciphers are not returned in the supported cipher suites? Exposing these to the application still means the application must be aware of the custom naming convention.

  • Tim_Ellison
    Tim_Ellison
    3 Posts

    Re: Non Standard TLS Cipher Names

    ‏2017-07-04T14:33:36Z  

    Thanks for confirming that SSL_ and TLS_ ciphers should be supported.

     

    Is there a reason why the TLS_ prefixed ciphers are not returned in the supported cipher suites? Exposing these to the application still means the application must be aware of the custom naming convention.

    I agree that returning both the SSL_ and TLS_ names would be helpful, and raised a Request For Enhancement to the effect back in 2105.  Given it has not been actioned, I've stopped holding my breath!

     

    In the meantime you should just be aware of the flexibility in the name prefix.

  • 77MX_John_Skelton
    77MX_John_Skelton
    1 Post

    Re: Non Standard TLS Cipher Names

    ‏2018-05-23T19:01:42Z  

    I have run into a problem related to this issue.   My program obtains a SSLSocket and connects to an application on z/os which is under control of IBM's AT-TLS product.  Everything works fine except when running with the IBM JDK as the AT-TLS product only supports the TLS_ prefixed ciphers.   Any suggestions on how to workaround this problem?