views:

592

answers:

1

I'm using Java's SSLSocket to secure communications between a client and a server program. The server program also serves up HTTPS requests from web browsers.

According to "Beginning Cryptography with Java", page 371, you should always call setEnabledCipherSuites on your SSLSocket / SSLServerSocket to ensure that the cipher suite that ends up being negotiated is sufficiently strong for your purposes.

That being said, a call to my SSLSocketFactory's getDefaultCipherSuites method yields some 180 options. These options range from TLS_RSA_WITH_AES_256_CBC_SHA (which I think is fairly secure) to SSL_RSA_WITH_RC4_128_MD5 (not so sure if that's secure, given MD5's current status) to SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (not entirely sure what that does).

What's a sensible list of cipher suites to restrict the sockets to?

Note that the client and server have access to the Bouncy Castle service provider, and that they may or may not have unlimited cryptographic policy files installed.

+2  A: 

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

EDIT: Changed to use 2008 document.

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

TLS_RSA_WITH_NULL_SHA
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
Matthew Flaschen
I'm a bit confused about TLS_RSA_WITH_NULL_SHA - doesn't that specify no encryption? In this context does this mean *no* or *any* encryption?
Zarkonnen
Zarkonnen, I think you're correct that TLS_RSA_WITH_NULL_SHA means no encryption. p. 34 of the draft I linked says NULL encryption is for, "cases where integrity protection is required but not encryption."
Matthew Flaschen