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
Order of Xml Attributes After Dom Processing
Why Does Changing the Returned Variable in a Finally Block Not Change the Return Value
How Does Auto Boxing/Unboxing Work in Java
How to Implement a Map with Multiple Keys
Main Thread VS. UI Thread in Java
Org.Apache.Tomcat.Util.Bcel.Classfile.Classformatexception: Invalid Byte Tag in Constant Pool: 15
Spring MVC: How to Perform Validation
Noclassdeffounderror: Wrong Name
Android.View.Inflateexception Error Inflating Class Android.Webkit.Webview
How to Load a Java Class Dynamically on Android/Dalvik
How to Print an Image on a Bluetooth Printer in Android
How to Get the Subscription Information from Google Play Android Developer API
How to Get Frequency from Fft Result
How to Use Vectordrawables in Android API Lower Than 21