Thanks for clarifying the JSSE issue. It's a shame that JSSE can't make
use of available JCE algorithms. I've just been trying to establish the
limits of the Java 7 implementation, and I think I understand that now.
Yes, the ECDHE ciphersuites are definitely the choice for strongest
secrecy with good performance, and the
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 that works on Oracle Java 7 using
TLS 1.2 should be a reasonable choice for now (or
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA256, for those who want really big keys).
- Dennis
On 08/23/2013 10:06 PM, Aurélien Terrestris wrote:
Hi
the JSSE Reference Guide defines which possibilities for anyone
implementing a JSSE provider (let's call it an API if you want).
Oracle's provider only implements a part of this API, misleading you
to believe SHA384 is available when it's unfortunately not.
About Bouncy Castle, I believe they only implement a JCE provider and
not any JSSE provider. Adding their jar to your providers in the
security file is not enough.. you would have to implement a full JSSE
provider using their JCE classes. A lot of work.
If you're looking for the best security, I would tell you to use the
available DHE and ECDHE ciphersuites which make things complicated to
decrypt. Have a look here for more information :
http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html
RFC 5288 is interesting, we probably have to wait some more years
before we can use all these new ciphers.
best regards
A.T.
2013/8/23 Dennis Sosnoski <d...@sosnoski.com>:
Thanks, Aurélien. I'd seen the SHA384 versions listed in the JSSE Cipher
Suite Names and thought they were available:
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#ciphersuites
I was really hoping to use one of the GCM suites, but I gather those are not
officially approved yet either: http://tools.ietf.org/html/rfc5288 It
appears there is growing support for these in the world, even if they're not
yet an official part of TLS 1.2.
On the client side, this:
SSLContext context = SSLContext.getInstance("TLS");
context.init(null, new TrustManager[] { tm }, null);
SSLParameters params = context.getSupportedSSLParameters();
String[] suites = params.getCipherSuites();
System.out.println("Connecting with " + suites.length + " cipher
suites supported:");
for (int i = 0; i < suites.length; i++) {
System.out.print(' ');
System.out.println(suites[i]);
}
gives me a list of "supported" cipher suites including:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
...
but when I try to connect using the socket factory from the context I get
the ssl debug information:
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
...
where all the variations using SHA256 or SHA384 are in this second list. But
explicitly setting a suite like:
System.setProperty("https.cipherSuites",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256");
works, while the SHA384 version fails with "Unsupported ciphersuite" (as
does any version I've tried using GCM in place of CBC).
I thought JSSE would use the JCE algorithms from BouncyCastle, but it looks
like this doesn't work. I'll have to dig into the JSSE code to see what's
going wrong on that part.
- Dennis
On 08/23/2013 03:48 AM, Aurélien Terrestris wrote:
According to RFC 5246 Appendix C (TLS 1.2), there is no SHA384. See :
http://www.ietf.org/rfc/rfc5246.txt
The JSSE Reference Guide also doesn't talk about this SHA384 as an
implementation requirement. See :
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl
This means you have a problem with SHA256 only. Maybe it's easier to
test on client-side, with one of the following ciphers (that you find
on the same Reference Guide ) for example :
TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Let me know if this works, or I will try to test by myself with my own
client.
2013/8/22 Dennis Sosnoski <d...@sosnoski.com>:
I've already done that, though as far as I can see that doesn't effect
the
digest algorithms (only the encryption options).
- Dennis
On 08/23/2013 12:24 AM, Aurélien Terrestris wrote:
Hello
I suppose you need to run your JVM with the unrestricted policy files
(on
b=
oth client and server sides). You have to download them from Oracle
website=
for your java version, and replace the old.
These files are :
local_policy.jar
US_export_policy.jar
Regards
2013/8/22 <d...@sosnoski.com>:
Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a
sslEnabledProtocols="TLSv1.2" attribute on the <Connector>. But I
haven't
been able to make it work with any of the SHA256/384 algorithms - they
always show up in the "Ignoring unsupported cipher suite" list. I get
the
same thing happening when I try to use them from client code, so I know
it's
not a Tomcat issue, but I'm hoping someone knows a workaround.
Any suggestions?
Thanks,
- Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
