Discussion:
Tomcat 7 / Java 7 with TLS 1.2 algorithms
d***@sosnoski.com
2013-08-22 08:41:54 UTC
Permalink
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
Aurélien Terrestris
2013-08-22 12:24:15 UTC
Permalink
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
Post by 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
---------------------------------------------------------------------
Dennis Sosnoski
2013-08-22 12:47:54 UTC
Permalink
I've already done that, though as far as I can see that doesn't effect
the digest algorithms (only the encryption options).

- Dennis
Post by Aurélien Terrestris
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.
local_policy.jar
US_export_policy.jar
Regards
Post by 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
---------------------------------------------------------------------
---------------------------------------------------------------------
Aurélien Terrestris
2013-08-22 13:53:55 UTC
Permalink
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.
I've already done that, though as far as I can see that doesn't effect the
digest algorithms (only the encryption options).
- Dennis
Post by Aurélien Terrestris
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.
local_policy.jar
US_export_policy.jar
Regards
Post by 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
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
Aurélien Terrestris
2013-08-22 15:48:28 UTC
Permalink
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.
I've already done that, though as far as I can see that doesn't effect the
digest algorithms (only the encryption options).
- Dennis
Post by Aurélien Terrestris
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.
local_policy.jar
US_export_policy.jar
Regards
Post by 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
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
Dennis Sosnoski
2013-08-23 00:21:53 UTC
Permalink
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
Post by Aurélien Terrestris
http://www.ietf.org/rfc/rfc5246.txt
The JSSE Reference Guide also doesn't talk about this SHA384 as an
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
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.
I've already done that, though as far as I can see that doesn't effect the
digest algorithms (only the encryption options).
- Dennis
Post by Aurélien Terrestris
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.
local_policy.jar
US_export_policy.jar
Regards
Post by 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
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
Aurélien Terrestris
2013-08-23 10:06:27 UTC
Permalink
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.
Post by Dennis Sosnoski
Thanks, Aurélien. I'd seen the SHA384 versions listed in the JSSE Cipher
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.
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]);
}
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
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
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
Post by Aurélien Terrestris
http://www.ietf.org/rfc/rfc5246.txt
The JSSE Reference Guide also doesn't talk about this SHA384 as an
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
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.
I've already done that, though as far as I can see that doesn't effect the
digest algorithms (only the encryption options).
- Dennis
Post by Aurélien Terrestris
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.
local_policy.jar
US_export_policy.jar
Regards
Post by 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
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
Dennis Sosnoski
2013-08-23 20:14:08 UTC
Permalink
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
Post by Aurélien Terrestris
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
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.
Post by Dennis Sosnoski
Thanks, Aurélien. I'd seen the SHA384 versions listed in the JSSE Cipher
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.
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]);
}
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
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
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
Post by Aurélien Terrestris
http://www.ietf.org/rfc/rfc5246.txt
The JSSE Reference Guide also doesn't talk about this SHA384 as an
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
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.
I've already done that, though as far as I can see that doesn't effect the
digest algorithms (only the encryption options).
- Dennis
Post by Aurélien Terrestris
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.
local_policy.jar
US_export_policy.jar
Regards
Post by 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
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
Martin Gainty
2013-08-22 21:33:39 UTC
Permalink
point of confusion Eric Rescorla specifically cites SHA384 in his cipher examples for TLS 1.2 Update

http://www.ietf.org/rfc/rfc5246.txt
http://www.ietf.org/proceedings/70/slides/tls-0.pdf

Kuat Eshengazin used bltest as a test harness for SHA384

bltest -R -m prf_sha384 -k tests/prf_sha384/key0 -t
tests/prf_sha384/seed0 -h -g 148 -x

https://bugzilla.mozilla.org/show_bug.cgi?id=480514

Is this incorrect?
Martin
______________________________________________
Please do not alter or disrupt this transmission..Thank You
Date: Thu, 22 Aug 2013 14:53:55 +0100
Subject: Re: Tomcat 7 / Java 7 with TLS 1.2 algorithms
http://www.ietf.org/rfc/rfc5246.txt
The JSSE Reference Guide also doesn't talk about this SHA384 as an
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
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.
I've already done that, though as far as I can see that doesn't effect the
digest algorithms (only the encryption options).
- Dennis
Post by Aurélien Terrestris
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.
local_policy.jar
US_export_policy.jar
Regards
Post by 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
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
Aurélien Terrestris
2013-08-23 09:51:09 UTC
Permalink
It seems incorrect to me because RFC 5246 in "1.2 Major Differences
from TLS 1.1" says this :

..
"All cipher suites in this document use P_SHA256."
..
"Added HMAC-SHA256 cipher suites"

I can't read anywhere that SHA384 and others "SHOULD" or "MUST" be implemented.

Other RFCs updating this 5246 (5746, 5878, 6176 and Errata) don't talk
about this either.


However, in 5246 "5. HMAC and the Pseudorandom Function" we can read :

"In this section, we define one PRF, based on HMAC. This PRF with the
SHA-256 hash function is used for all cipher suites defined in this
document and in TLS documents published prior to this document when
TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a
PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a
stronger standard hash function.
"

This allows future usage of SHA384 and others, if defined correctly.


regards
A.T.
Post by Martin Gainty
point of confusion Eric Rescorla specifically cites SHA384 in his cipher examples for TLS 1.2 Update
http://www.ietf.org/rfc/rfc5246.txt
http://www.ietf.org/proceedings/70/slides/tls-0.pdf
Kuat Eshengazin used bltest as a test harness for SHA384
bltest -R -m prf_sha384 -k tests/prf_sha384/key0 -t
tests/prf_sha384/seed0 -h -g 148 -x
https://bugzilla.mozilla.org/show_bug.cgi?id=480514
Is this incorrect?
Martin
______________________________________________
Please do not alter or disrupt this transmission..Thank You
Date: Thu, 22 Aug 2013 14:53:55 +0100
Subject: Re: Tomcat 7 / Java 7 with TLS 1.2 algorithms
http://www.ietf.org/rfc/rfc5246.txt
The JSSE Reference Guide also doesn't talk about this SHA384 as an
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
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.
I've already done that, though as far as I can see that doesn't effect the
digest algorithms (only the encryption options).
- Dennis
Post by Aurélien Terrestris
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.
local_policy.jar
US_export_policy.jar
Regards
Post by 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
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
Martin Gainty
2013-08-22 12:26:39 UTC
Permalink
what's supposed to happen:


The specified cipher in SSLCipherSuiteSSLCipherSuite is supposed to be enabled when specified within

SSLCipherSuiteSSLCipherSuite=SHA256/384


to allow the Server to arbitrate the ordering of ciphers(instead of the client)

SSLHonorCipherOrder=true


http://tomcat.apache.org/tomcat-7.0-doc/config/http.html


does this not work for you?


Martin Gainty
______________________________________________
Please do not alter or disrupt this transmission..Thank You





From: ***@sosnoski.com
Subject: Tomcat 7 / Java 7 with TLS 1.2 algorithms
To: ***@tomcat.apache.org
CC:
Date: Thu, 22 Aug 2013 04:41:54 -0400

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-***@tomcat.apache.org For additional commands, e-mail: users-***@tomcat.apache.org
Loading...