-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 John,
On 1/8/18 10:23 PM, john.e.gr...@wellsfargo.com.INVALID wrote: > Chris, > > >> -----Original Message----- From: Christopher Schultz >> [mailto:ch...@christopherschultz.net] Sent: Monday, January 08, >> 2018 8:16 PM To: users@tomcat.apache.org Subject: Re: Why will >> Tomcat not accept EC cipher suites? >> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> John, >> >> On 1/8/18 6:28 PM, john.e.gr...@wellsfargo.com.INVALID wrote: >>> Chris and Mark, >>>> -----Original Message----- From: Christopher Schultz >>>> [mailto:ch...@christopherschultz.net] Sent: Monday, January >>>> 08, 2018 5:21 PM To: users@tomcat.apache.org Subject: Re: Why >>>> will Tomcat not accept EC cipher suites? >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>> >>>> Mark, >>>> >>>> On 1/8/18 3:36 PM, Mark Thomas wrote: >>>>> On 08/01/18 19:34, john.e.gr...@wellsfargo.com.INVALID >>>>> wrote: >>>>>> All, >>>>>> >>>>>> I'm using Tomcat 7.0.82 and java 1.8.0_152. >>>>>> >>>>>> I cannot get Tomcat to accept elliptic curve ciphers. >>>>>> I've written a small SSL socket server that uses the same >>>>>> certificate as the server and deployed it on the same >>>>>> machine using the same JDK. It accepts EC ciphers just >>>>>> fine so I don't think there is anything in the JDK that >>>>>> has disabled them, etc. With verbose SSL enabled, >>>>>> Tomcat, however, complains about "http-bio-7114-exec-4, >>>>>> handling exception: javax.net.ssl.SSLHandshakeException: >>>>>> no cipher suites in common." >>>>>> >>>>>> If I omit the "ciphers" property of the connector, I get >>>>>> this: >>>>>> >>>>>> No available cipher suite for TLSv1 No available cipher >>>>>> suite for TLSv1.1 No available cipher suite for TLSv1.2 >>>>>> >>>>>> If I set ciphers="ALL," I'm back to "no cipher suites in >>>>>> common." >>>>>> >>>>>> If I explicitly tell Tomcat to accept >>>>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, which works with >>>>>> my >>>> socket >>>>>> server, I get "No appropriate protocol (protocol is >>>>>> disabled or cipher suites are inappropriate)." >>>>>> >>>>>> BTW I have an RSA cert on the server with a 2048-bit key >>>>>> and signed using SHA256withRSA. >>>>>> >>>>>> One of the connector configs I've tried. >>>>>> >>>>>> <Connector port="7114" protocol="HTTP/1.1" >>>>>> SSLEnabled="true" maxThreads="400" >>>>>> maxKeepAliveRequests="100" keepAliveTimeout="10000" >>>>>> scheme="https" secure="true" clientAuth="true" >>>>>> sessionCacheSize="5" sslProtocol="TLS" >>>>>> keystoreFile="/path/to/keystore" >>>>>> keystorePass="${keystore.password}" keyAlias="test" >>>>>> truststoreFile="/path/to/cacerts" >>>>>> truststorePass="${truststore.password}" >>>>>> allowUnsafeLegacyRenegotiation="false" /> >>>>> >>>>> Try getting it to work without client authentication to >>>>> start with. >>>> >>>> +1 >>>> >>>>> I don't see anything that jumps out as wrong in the above. >>>> >>>> Also, John, what client are you using to test? >>>> >>>> - -chris >>> >>> At Mark's suggestion, I disabled client auth, but it didn't >>> make any difference. The handshake fails before it even gets >>> to that step. >>> >>> I'm using several different clients, including HP Performance >>> Center, openssl, and a couple of java clients that I wrote >>> myself (one uses SSLSocket directly and one uses >>> HttpsUrlConnection.) >>> >>> Currently I'm looking at the JDK's ServerHandshaker class to >>> make sure I understand the log messages. >> >> Are you doing something mundane such as: >> >> $ openssl s_client -connect example.com:8443 ? >> >> I would expect that to be able to negotiate a TLS connection with >> a pretty standard Tomcat with TLS enabled (and nothing in >> particular specified for ciphers, protocols, etc.). >> >> - -chris > > It turns out that we have elliptic curve ciphers explicitly > disabled with the system property > -Dcom.sun.net.ssl.enableECC=false. I know the OWASP cheat sheet > says to favor DHE over ECDHE but I'll have to ask around to find > out if that's the reason. So, *that's* interesting. What's also interesting is that without any (other?) cipher suite filtering, OpenSSL + Java 1.8 were not able to negotiate any compatible cipher suites outside of ECC-based cipher suites. I would have expected something like AES256-GCM-SHA256 or similar to be negotiated if ECC Wasn't available. Do you have other globally-disabled filters? As for the OWASP cheat-sheet, the current version is now 3 years old. I'm not sure their comments about DHE being preferable to ECDHE (due to "ECDHE lacks now of really reliable Elliptic Curves") is still considered the truth. For example, it appears that DJB's x25519 curve should be (a) reasonably trustworthy and (b) widely available. Also, OWASP recommends that you "prefer" DHE to ECDHE, not that you completely disable ECDHE, so I'd re-enable the use of EC if you have no specific directives against doing so. [Also, the NSA can get their hands on all of Wells Fargo's user data without compromising users' TLS connections... they just have to ask WFC directly and I'm sure they'll cough it all up. :)] - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpU5VcdHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFiZjw//c9BWTbNaOkx/UZvg RnZW4TnAfU35sq1KRQMvEF1aGuuJHId14/0QHij2Jiz1DgldR95CdvQxkLHptJxZ VemmVbZyVYIHob6VcuuvH7enEvu2nN26IQe3cer6hNS5be34896WlpAdoBbbCEiK PGhKzsQIsN/97nkg8EmriqemQuEBPAmF4xwHVYcy48HWk4tj/4yFFrVMt7GPiulm E4R8t4jl5EppOwILfJOT0g6IV0ZM2MeY3HkwDFLtOmu4kO8eHoTbTRltaBSOv+O5 2j49Fojzwwhtp14Ic7AXIU/fcgTgqF8i+RRu5Fu1vMXVOJc9mlXIatW/qVT/ESP3 QpR01qVblfOGN9CpIjdNTXMdJ/EJOWTYGh8lCT/mxopfZhsjEwe9SKpwg5V1cLJS EYhfhPli/iNUQkN4VI7A+q0TFnKJY1UMEF370MchLXcI/k0QERuCij8UarjxaHem VVonQZ1F5ivBaK/W4mXxj2pcWx+zs7XQat7PMRJj+257meLcjiRz1COqR6mkrAwg +aWjEmZIi0S+q8KWXL46vA6lQ2USkMkQn//l2PEympDxplnmw3n785Lk8THNdh/M Lcv28s+I7lrTbUJuJBBYzodez1OoXgGyKcCOUTGyDEjMsjF9Jl8AI1GWkjpamiDd Dg6Z3sFojoiyd+mAF+tMsu4+yco= =RS8K -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
