Which Cipher Suites to Enable for Ssl Socket

Which Cipher Suites to enable for SSL Socket?

Don't use anything with export in it. That's crippleware due to export restrictions on strong cryptography.

EDIT: Changed to use 2009 document.

A 2009 NIST recommendation lists the following, incluing TLS_RSA_WITH_AES_256_CBC_SHA (which you mentioned):

TLS_RSA_WITH_NULL_SHA (don't use this unless you're sure you don't need any privacy/confidentiality).

TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_PSK_WITH_3DES_EDE_CBC_SHA
TLS_PSK_WITH_AES_128_CBC_SHA
TLS_PSK_WITH_AES_256_CBC_SHA
TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA
TLS_DHE_PSK_WITH_AES_128_CBC_SHA
TLS_DHE_PSK_WITH_AES_256_CBC_SHA
TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA
TLS_RSA_PSK_WITH_AES_128_CBC_SHA
TLS_RSA_PSK_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

How to specify the ciphersuite to be used in SSL session

I found out that I added socket.getsession() before the
setEnableCipherSuite() in order to print out the enabled cipheres
before setting them. When I removed it, the cipher has been set. why
is that ?

As documented in the SSLSocket JavaDoc:

The initial handshake on this connection can be initiated in one of
three ways:

  • calling startHandshake which explicitly begins handshakes, or
  • any attempt to read or write application data on this socket causes an implicit handshake, or
  • a call to getSession tries to set up a session if there is no currently valid session, and an implicit handshake is done.

If you call getSession() before calling setEnabledCipherSuite(), the handshake has already been done when you try to set the enabled cipher suites, so this session's cipher suite has already been selected.

How to set ciphers in ssl python socket

I could include more than one cipher simple by separating the ciphers with : and send all the ciphers as one string.

cipher = 'DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-GCM-SHA256'
context.set_ciphers(cipher)

This way, the client offers all the ciphers. You can make sure from this by calling context.get_ciphers() and you will see only the ciphers you inserted using set_cipher.

[Unsupported ciphersuite][Java SSLSocket]

You can list the supported cipher suites using:

SSLSocketFactory socketFactory = SSLContext.getDefault().getSocketFactory();
for (String cipherSuite : socketFactory.getSupportedCipherSuites()) {
System.out.println(cipherSuite);
}

The following entry matches your requested suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.

You no longer need the JCE Unlimited Strength Jurisdiction Policy Files:

  • in Java 8 u151/u152 the policy files were included in the standard Java distribution, but needed to be enabled explicitly: Security.setProperty("crypto.policy", "unlimited");
  • since Java 8 u161+ (and in all upcoming Java versions), these policy files are included, and unlimited crypto policy enabled by default.

You can verify it as follows:
Cipher.getMaxAllowedKeyLength("AES") should return Integer.MAX_VALUE when unlimited strengh is enabled.

How to use ChaCha cipher in SSL ciphersuite using java

The problem is that the JSSE implementation (which implements the Java TLS support) does not support ChaCha20. That the ChaCha20 implementation is now available through a JCE provider does not change that.

These kind of cipher classes cannot just be dropped in; ciphers have specific requirements with regards to the key, IV, padding etc. etc. to be used. So you need to write code around the cipher to have it supported by your particular implementation of TLS.

So you need to either wait until it is supported (if ever) or use a JSSE (Java Secure Socket Extensions, TLS) provider that does support it. I guess that it may become available after 1.3 is finalized as that standardizes on AEAD (authenticated) ciphers, and ChaCha20 + Poly 1305 would be a pretty fast configuration.



Related Topics



Leave a reply



Submit