tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aurélien Terrestris <aterrest...@gmail.com>
Subject Re: Fwd: Tomcat 7 / Java 7 with TLS 1.2 algorithms
Date Fri, 23 Aug 2013 10:06:27 GMT
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 <dms@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 <dms@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  <dms@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-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message