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
