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

Reply via email to