Re: [OT] Outbound SSL?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Peter, On 6/1/19 03:27, Peter Kreuser wrote: > Crazy enough, but Google maps provides ciphers even for Java 6. > > https://www.ssllabs.com/ssltest/analyze.html?d=maps.google.com&s=216.5 8.195.78&latest > > So this would be the only strange but obvious difference. The list > has EVEN ECDH, GCM, AES 256. That's for Google Maps public web site, not the API. It would not surprise me to learn that the API is more restrictive in what it will accept. [checks] Oh, wow. Yeah, they support a log of old funky stuff. But they also support TLSv1.3, so that's nice :) - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlz1kkIACgkQHPApP6U8 pFivkg//euo8E9SD+2D6svh/M2gqFf2rz5ReqREM2YbLtvIoL9LrORxgfMES76SX thqW96PMJT6qPesQ6vSmi2u2YQp/u8veYpu/hx0FPTkZJ+2fvWrlLWzy6WnwWFx7 HnuknVtdohbqLcI4l7rnz98Is9hCYv/NMFdTX7b65hSx0hGUEbosu3OW+Dr99qtG eZCpD+vD+ngbp1zRZeH0lfOnmKksDDuN0KrxqG+uTN+KNCXzL6zkg+elWHRagIlQ I2uNTYnwqbSM5Et8NGr+8WjNYk5mFtetJJeT4pBtiCJj7Dl18pJ37WLj/OvYkVRw 4aDdkp0lCKCHtH9b2YQgUNiFOC8Y1o7oQFk9lS4UNlQy/7uQbWZK1OLxFBPabmv7 yXbYQ7zghVaKFYpLVzneFnkIMO53c2x2uk91HvOYF/bwYKmi2B7Yd7r+UR1oqI4W UbGFOJ7DOGrt0tYlpxzLjRqzQMrSpBnlTDpKs7kmRtxqRXao5hWmBwGbWxfzxluL XB8aqJO7vnb2rhWw2Jx1WQuOK6XBKQ6hPjDfLPQLSh041ebLdVBvtep9G+J6XBQ+ 6M+5xb72NqBIPkRQO5MnubzNclmfUhmVGUaThGONDd3yuX28qo678A3kRkOFHyba hC4lk1SgRW366rp7EMpI81r4gIZI8+44ZJIVNqSEL9BPTBgWUws= =3eKL -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AW: Outbound SSL?
What is your webapp using as HTTP client that handles the SSL? -Original Message- From: James Lampert Sent: Friday, May 31, 2019 3:41 PM To: Tomcat Users List Subject: Re: AW: Outbound SSL? This just keeps getting weirder and weirder. I extracted the actual request > https://maps.googleapis.com/maps/api/geocode/json?key=&addre > ss= from where it had been logged to catalina.out, and built a simple program to feed it to Scott Klement's HTTPAPI, an open-source HTTP interface for OS/400-native programs. It has a rather rich debugging capability. Once I got it working on our box, I sent it over to the "problem" box. And it worked perfectly: it got what appears to be the expected response. Of course, it's doing all of this natively, rather than through Java. We also know that Tomcat is running under a 64-bit Java 7 JVM on that box. And we also know that we've got this product running in Java 6, 7, and 8, on IBM Midrange boxes, WinDoze boxes, and Linux boxes, without the problem occurring. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Outbound SSL?
Tomcat can be setup in 2 modes = JSSE (Java) or APR (OpenSSL) If Java, turn Java debug log on and -Djavax.net.debug=ssl > Sent: Wednesday, May 29, 2019 at 1:57 PM > From: "James H. H. Lampert" > To: "Tomcat Users List" > Subject: Outbound SSL? > > We have a customer that is running our Tomcat-based webapp, and it is > apparently having trouble accessing a Google web service. > > The error message they're getting is: > > > Unable to find acceptable protocols. isFallback=false, > > modes=[ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, > > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, > > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, > > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, > > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, > > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, > > TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, > > TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, > > TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_2, TLS_1_1, > > TLS_1_0], supportsTlsExtensions=true), > > ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, > > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, > > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, > > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, > > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, > > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, > > TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, > > TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, > > TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_0], > > supportsTlsExtensions=true), ConnectionSpec()], supported > > protocols=[TLSv1] > > Is this something that could be caused by a Tomcat configuration issue? > > -- > James H. H. Lampert > > - > 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
Re: AW: Outbound SSL?
Chris, James > Am 01.06.2019 um 02:30 schrieb Christopher Schultz > : > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > James, > >> On 5/31/19 18:41, James H. H. Lampert wrote: >>> On 5/31/19, 3:34 AM, bernd.sch...@daimler.com wrote: >>> You can run a small java program on your jvm to print out the >>> supported And default protocols. Yet, I didn’t find a better >>> way. >>> >>> e.g. ==> >>> https://confluence.atlassian.com/stashkb/list-ciphers-used-by-jvm-679 > 609085.html >>> >> >>> >> If I set the same JAVA_HOME as Tomcat was launched under, and >> compile and run "Ciphers.java" from the above site, on the customer >> box, I get: >> >>> Default Cipher SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SH * >>> SSL_DHE_DSS_WITH_AES_128_CBC_SHA * >>> SSL_DHE_DSS_WITH_AES_128_CBC_SHA256 >>> SSL_DHE_DSS_WITH_AES_128_GCM_SHA256 * >>> SSL_DHE_DSS_WITH_AES_256_CBC_SHA * >>> SSL_DHE_DSS_WITH_AES_256_CBC_SHA256 >>> SSL_DHE_DSS_WITH_AES_256_GCM_SHA384 SSL_DHE_DSS_WITH_DES_CBC_SHA >>> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * >>> SSL_DHE_RSA_WITH_AES_128_CBC_SHA * >>> SSL_DHE_RSA_WITH_AES_128_CBC_SHA256 >>> SSL_DHE_RSA_WITH_AES_128_GCM_SHA256 * >>> SSL_DHE_RSA_WITH_AES_256_CBC_SHA * >>> SSL_DHE_RSA_WITH_AES_256_CBC_SHA256 >>> SSL_DHE_RSA_WITH_AES_256_GCM_SHA384 SSL_DHE_RSA_WITH_DES_CBC_SHA >>> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA >>> SSL_DH_anon_WITH_AES_128_CBC_SHA >>> SSL_DH_anon_WITH_AES_128_CBC_SHA256 >>> SSL_DH_anon_WITH_AES_128_GCM_SHA256 >>> SSL_DH_anon_WITH_AES_256_CBC_SHA >>> SSL_DH_anon_WITH_AES_256_CBC_SHA256 >>> SSL_DH_anon_WITH_AES_256_GCM_SHA384 SSL_DH_anon_WITH_DES_CBC_SHA >>> * SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA * >>> SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 >>> SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 * >>> SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA * >>> SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 >>> SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 >>> SSL_ECDHE_ECDSA_WITH_NULL_SHA * >>> SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA * >>> SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256 >>> SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * >>> SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA * >>> SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384 >>> SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384 >>> SSL_ECDHE_RSA_WITH_NULL_SHA * >>> SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA * >>> SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 >>> SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 * >>> SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA * >>> SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 >>> SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 >>> SSL_ECDH_ECDSA_WITH_NULL_SHA * >>> SSL_ECDH_RSA_WITH_AES_128_CBC_SHA * >>> SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256 >>> SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256 * >>> SSL_ECDH_RSA_WITH_AES_256_CBC_SHA * >>> SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384 >>> SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384 SSL_ECDH_RSA_WITH_NULL_SHA >>> SSL_ECDH_anon_WITH_AES_128_CBC_SHA >>> SSL_ECDH_anon_WITH_AES_256_CBC_SHA SSL_ECDH_anon_WITH_NULL_SHA >>> SSL_KRB5_EXPORT_WITH_DES_CBC_40_MD5 >>> SSL_KRB5_EXPORT_WITH_DES_CBC_40_SHA SSL_KRB5_WITH_DES_CBC_MD5 >>> SSL_KRB5_WITH_DES_CBC_SHA SSL_RSA_EXPORT_WITH_DES40_CBC_SHA >>> SSL_RSA_FIPS_WITH_DES_CBC_SHA * >>> SSL_RSA_WITH_AES_128_CBC_SHA * >>> SSL_RSA_WITH_AES_128_CBC_SHA256 SSL_RSA_WITH_AES_128_GCM_SHA256 * >>> SSL_RSA_WITH_AES_256_CBC_SHA * >>> SSL_RSA_WITH_AES_256_CBC_SHA256 SSL_RSA_WITH_AES_256_GCM_SHA384 >>> SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_NULL_MD5 >>> SSL_RSA_WITH_NULL_SHA SSL_RSA_WITH_NULL_SHA256 * >>> TLS_EMPTY_RENEGOTIATION_INFO_SCSV > > Other than the fact that none of those start with TLS_ like all modern > cipher suites do, the above looks okay. > Crazy enough, but Google maps provides ciphers even for Java 6. https://www.ssllabs.com/ssltest/analyze.html?d=maps.google.com&s=216.58.195.78&latest So this would be the only strange but obvious difference. The list has EVEN ECDH, GCM, AES 256. >> FOR COMPARISON PURPOSES, what we get on our box is: >>> Default Cipher * SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * >>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA * >>> SSL_DHE_DSS_WITH_AES_128_CBC_SHA * >>> SSL_DHE_DSS_WITH_AES_256_CBC_SHA * >>> SSL_DHE_DSS_WITH_DES_CBC_SHA * >>> SSL_DHE_DSS_WITH_RC4_128_SHA * >>> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * >>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA * >>> SSL_DHE_RSA_WITH_AES_128_CBC_SHA * >>> SSL_DHE_RSA_WITH_AES_256_CBC_SHA * >>> SSL_DHE_RSA_WITH_DES_CBC_SHA >>> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA >>> SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 >>> SSL_DH_anon_WITH_3DES_EDE_CBC_SHA >>> SSL_DH_anon_WITH_AES_128_CBC_SHA >>> SSL_DH_anon_WITH_AES_256_CBC_SHA SSL_DH_anon_WITH_DES_CBC_SHA >>> SSL_DH_anon_WITH_RC4_128_MD5 SSL_KRB5_EXPORT_WITH_DES_CBC_40_MD5 >>> SSL_KRB5_EXPORT_WITH_DES_CBC_40_SHA >>> SSL_KRB5_EXPORT_WITH_RC4_40_MD5 SSL_KRB5_EXPORT_WITH_RC4_40_SHA >>> SSL_KRB5_WITH_3DES_EDE_CBC_MD5 SSL_KRB5_WITH_3DES_EDE_CBC_SHA >>> SSL_KRB5_WITH_DES_CBC_MD5 SSL_KRB5_WITH_DES_CBC_SHA >>> SSL_KRB5_WITH_RC4_128_MD5 SSL_KRB5_WITH_RC4_128_SHA * >>> SSL_RSA_EXPORT_WITH_DES40_CBC_SHA * >>> SSL_RSA_EXPORT_WITH_RC2_C
Re: AW: Outbound SSL?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 5/31/19 18:41, James H. H. Lampert wrote: > On 5/31/19, 3:34 AM, bernd.sch...@daimler.com wrote: >> You can run a small java program on your jvm to print out the >> supported And default protocols. Yet, I didn’t find a better >> way. >> >> e.g. ==> >> https://confluence.atlassian.com/stashkb/list-ciphers-used-by-jvm-679 609085.html >> > >> > If I set the same JAVA_HOME as Tomcat was launched under, and > compile and run "Ciphers.java" from the above site, on the customer > box, I get: > >> Default Cipher SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SH * >> SSL_DHE_DSS_WITH_AES_128_CBC_SHA * >> SSL_DHE_DSS_WITH_AES_128_CBC_SHA256 >> SSL_DHE_DSS_WITH_AES_128_GCM_SHA256 * >> SSL_DHE_DSS_WITH_AES_256_CBC_SHA * >> SSL_DHE_DSS_WITH_AES_256_CBC_SHA256 >> SSL_DHE_DSS_WITH_AES_256_GCM_SHA384 SSL_DHE_DSS_WITH_DES_CBC_SHA >> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * >> SSL_DHE_RSA_WITH_AES_128_CBC_SHA * >> SSL_DHE_RSA_WITH_AES_128_CBC_SHA256 >> SSL_DHE_RSA_WITH_AES_128_GCM_SHA256 * >> SSL_DHE_RSA_WITH_AES_256_CBC_SHA * >> SSL_DHE_RSA_WITH_AES_256_CBC_SHA256 >> SSL_DHE_RSA_WITH_AES_256_GCM_SHA384 SSL_DHE_RSA_WITH_DES_CBC_SHA >> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA >> SSL_DH_anon_WITH_AES_128_CBC_SHA >> SSL_DH_anon_WITH_AES_128_CBC_SHA256 >> SSL_DH_anon_WITH_AES_128_GCM_SHA256 >> SSL_DH_anon_WITH_AES_256_CBC_SHA >> SSL_DH_anon_WITH_AES_256_CBC_SHA256 >> SSL_DH_anon_WITH_AES_256_GCM_SHA384 SSL_DH_anon_WITH_DES_CBC_SHA >> * SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA * >> SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 >> SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 * >> SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA * >> SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 >> SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 >> SSL_ECDHE_ECDSA_WITH_NULL_SHA * >> SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA * >> SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256 >> SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * >> SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA * >> SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384 >> SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384 >> SSL_ECDHE_RSA_WITH_NULL_SHA * >> SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA * >> SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 >> SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 * >> SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA * >> SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 >> SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 >> SSL_ECDH_ECDSA_WITH_NULL_SHA * >> SSL_ECDH_RSA_WITH_AES_128_CBC_SHA * >> SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256 >> SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256 * >> SSL_ECDH_RSA_WITH_AES_256_CBC_SHA * >> SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384 >> SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384 SSL_ECDH_RSA_WITH_NULL_SHA >> SSL_ECDH_anon_WITH_AES_128_CBC_SHA >> SSL_ECDH_anon_WITH_AES_256_CBC_SHA SSL_ECDH_anon_WITH_NULL_SHA >> SSL_KRB5_EXPORT_WITH_DES_CBC_40_MD5 >> SSL_KRB5_EXPORT_WITH_DES_CBC_40_SHA SSL_KRB5_WITH_DES_CBC_MD5 >> SSL_KRB5_WITH_DES_CBC_SHA SSL_RSA_EXPORT_WITH_DES40_CBC_SHA >> SSL_RSA_FIPS_WITH_DES_CBC_SHA * >> SSL_RSA_WITH_AES_128_CBC_SHA * >> SSL_RSA_WITH_AES_128_CBC_SHA256 SSL_RSA_WITH_AES_128_GCM_SHA256 * >> SSL_RSA_WITH_AES_256_CBC_SHA * >> SSL_RSA_WITH_AES_256_CBC_SHA256 SSL_RSA_WITH_AES_256_GCM_SHA384 >> SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_NULL_MD5 >> SSL_RSA_WITH_NULL_SHA SSL_RSA_WITH_NULL_SHA256 * >> TLS_EMPTY_RENEGOTIATION_INFO_SCSV Other than the fact that none of those start with TLS_ like all modern cipher suites do, the above looks okay. > FOR COMPARISON PURPOSES, what we get on our box is: >> Default Cipher * SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * >> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA * >> SSL_DHE_DSS_WITH_AES_128_CBC_SHA * >> SSL_DHE_DSS_WITH_AES_256_CBC_SHA * >> SSL_DHE_DSS_WITH_DES_CBC_SHA * >> SSL_DHE_DSS_WITH_RC4_128_SHA * >> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * >> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA * >> SSL_DHE_RSA_WITH_AES_128_CBC_SHA * >> SSL_DHE_RSA_WITH_AES_256_CBC_SHA * >> SSL_DHE_RSA_WITH_DES_CBC_SHA >> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA >> SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 >> SSL_DH_anon_WITH_3DES_EDE_CBC_SHA >> SSL_DH_anon_WITH_AES_128_CBC_SHA >> SSL_DH_anon_WITH_AES_256_CBC_SHA SSL_DH_anon_WITH_DES_CBC_SHA >> SSL_DH_anon_WITH_RC4_128_MD5 SSL_KRB5_EXPORT_WITH_DES_CBC_40_MD5 >> SSL_KRB5_EXPORT_WITH_DES_CBC_40_SHA >> SSL_KRB5_EXPORT_WITH_RC4_40_MD5 SSL_KRB5_EXPORT_WITH_RC4_40_SHA >> SSL_KRB5_WITH_3DES_EDE_CBC_MD5 SSL_KRB5_WITH_3DES_EDE_CBC_SHA >> SSL_KRB5_WITH_DES_CBC_MD5 SSL_KRB5_WITH_DES_CBC_SHA >> SSL_KRB5_WITH_RC4_128_MD5 SSL_KRB5_WITH_RC4_128_SHA * >> SSL_RSA_EXPORT_WITH_DES40_CBC_SHA * >> SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 * >> SSL_RSA_EXPORT_WITH_RC4_40_MD5 * >> SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA * >> SSL_RSA_FIPS_WITH_DES_CBC_SHA * >> SSL_RSA_WITH_3DES_EDE_CBC_SHA * >> SSL_RSA_WITH_AES_128_CBC_SHA * >> SSL_RSA_WITH_AES_256_CBC_SHA * SSL_RSA_WITH_DES_CBC_SHA >> SSL_RSA_WITH_NULL_MD5 SSL_RSA_WITH_NULL_SHA * >> SSL_RSA_WITH_RC4_128_MD5 * SSL_RSA_WITH_RC4_128_SHA Almost all of the above cipher suites are useless. Anything starting with SSL_*_DSS
Re: AW: Outbound SSL?
On 5/31/19, 3:34 AM, bernd.sch...@daimler.com wrote: You can run a small java program on your jvm to print out the supported And default protocols. Yet, I didn’t find a better way. e.g. ==> https://confluence.atlassian.com/stashkb/list-ciphers-used-by-jvm-679609085.html If I set the same JAVA_HOME as Tomcat was launched under, and compile and run "Ciphers.java" from the above site, on the customer box, I get: > Default Cipher > SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SH > * SSL_DHE_DSS_WITH_AES_128_CBC_SHA > * SSL_DHE_DSS_WITH_AES_128_CBC_SHA256 > SSL_DHE_DSS_WITH_AES_128_GCM_SHA256 > * SSL_DHE_DSS_WITH_AES_256_CBC_SHA > * SSL_DHE_DSS_WITH_AES_256_CBC_SHA256 > SSL_DHE_DSS_WITH_AES_256_GCM_SHA384 > SSL_DHE_DSS_WITH_DES_CBC_SHA > SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA > * SSL_DHE_RSA_WITH_AES_128_CBC_SHA > * SSL_DHE_RSA_WITH_AES_128_CBC_SHA256 > SSL_DHE_RSA_WITH_AES_128_GCM_SHA256 > * SSL_DHE_RSA_WITH_AES_256_CBC_SHA > * SSL_DHE_RSA_WITH_AES_256_CBC_SHA256 > SSL_DHE_RSA_WITH_AES_256_GCM_SHA384 > SSL_DHE_RSA_WITH_DES_CBC_SHA > SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA > SSL_DH_anon_WITH_AES_128_CBC_SHA > SSL_DH_anon_WITH_AES_128_CBC_SHA256 > SSL_DH_anon_WITH_AES_128_GCM_SHA256 > SSL_DH_anon_WITH_AES_256_CBC_SHA > SSL_DH_anon_WITH_AES_256_CBC_SHA256 > SSL_DH_anon_WITH_AES_256_GCM_SHA384 > SSL_DH_anon_WITH_DES_CBC_SHA > * SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA > * SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 > SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 > * SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA > * SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 > SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 > SSL_ECDHE_ECDSA_WITH_NULL_SHA > * SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA > * SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256 > SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > * SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA > * SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384 > SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > SSL_ECDHE_RSA_WITH_NULL_SHA > * SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA > * SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 > SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 > * SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA > * SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 > SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 > SSL_ECDH_ECDSA_WITH_NULL_SHA > * SSL_ECDH_RSA_WITH_AES_128_CBC_SHA > * SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256 > SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256 > * SSL_ECDH_RSA_WITH_AES_256_CBC_SHA > * SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384 > SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384 > SSL_ECDH_RSA_WITH_NULL_SHA > SSL_ECDH_anon_WITH_AES_128_CBC_SHA > SSL_ECDH_anon_WITH_AES_256_CBC_SHA > SSL_ECDH_anon_WITH_NULL_SHA > SSL_KRB5_EXPORT_WITH_DES_CBC_40_MD5 > SSL_KRB5_EXPORT_WITH_DES_CBC_40_SHA > SSL_KRB5_WITH_DES_CBC_MD5 > SSL_KRB5_WITH_DES_CBC_SHA > SSL_RSA_EXPORT_WITH_DES40_CBC_SHA > SSL_RSA_FIPS_WITH_DES_CBC_SHA > * SSL_RSA_WITH_AES_128_CBC_SHA > * SSL_RSA_WITH_AES_128_CBC_SHA256 > SSL_RSA_WITH_AES_128_GCM_SHA256 > * SSL_RSA_WITH_AES_256_CBC_SHA > * SSL_RSA_WITH_AES_256_CBC_SHA256 > SSL_RSA_WITH_AES_256_GCM_SHA384 > SSL_RSA_WITH_DES_CBC_SHA > SSL_RSA_WITH_NULL_MD5 > SSL_RSA_WITH_NULL_SHA > SSL_RSA_WITH_NULL_SHA256 > * TLS_EMPTY_RENEGOTIATION_INFO_SCSV FOR COMPARISON PURPOSES, what we get on our box is: > Default Cipher > * SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA > * SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA > * SSL_DHE_DSS_WITH_AES_128_CBC_SHA > * SSL_DHE_DSS_WITH_AES_256_CBC_SHA > * SSL_DHE_DSS_WITH_DES_CBC_SHA > * SSL_DHE_DSS_WITH_RC4_128_SHA > * SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA > * SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA > * SSL_DHE_RSA_WITH_AES_128_CBC_SHA > * SSL_DHE_RSA_WITH_AES_256_CBC_SHA > * SSL_DHE_RSA_WITH_DES_CBC_SHA > SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA > SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 > SSL_DH_anon_WITH_3DES_EDE_CBC_SHA > SSL_DH_anon_WITH_AES_128_CBC_SHA > SSL_DH_anon_WITH_AES_256_CBC_SHA > SSL_DH_anon_WITH_DES_CBC_SHA > SSL_DH_anon_WITH_RC4_128_MD5 > SSL_KRB5_EXPORT_WITH_DES_CBC_40_MD5 > SSL_KRB5_EXPORT_WITH_DES_CBC_40_SHA > SSL_KRB5_EXPORT_WITH_RC4_40_MD5 > SSL_KRB5_EXPORT_WITH_RC4_40_SHA > SSL_KRB5_WITH_3DES_EDE_CBC_MD5 > SSL_KRB5_WITH_3DES_EDE_CBC_SHA > SSL_KRB5_WITH_DES_CBC_MD5 > SSL_KRB5_WITH_DES_CBC_SHA > SSL_KRB5_WITH_RC4_128_MD5 > SSL_KRB5_WITH_RC4_128_SHA > * SSL_RSA_EXPORT_WITH_DES40_CBC_SHA > * SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 > * SSL_RSA_EXPORT_WITH_RC4_40_MD5 > * SSL_RSA_FI
Re: AW: Outbound SSL?
This just keeps getting weirder and weirder. I extracted the actual request > https://maps.googleapis.com/maps/api/geocode/json?key=&address= from where it had been logged to catalina.out, and built a simple program to feed it to Scott Klement's HTTPAPI, an open-source HTTP interface for OS/400-native programs. It has a rather rich debugging capability. Once I got it working on our box, I sent it over to the "problem" box. And it worked perfectly: it got what appears to be the expected response. Of course, it's doing all of this natively, rather than through Java. We also know that Tomcat is running under a 64-bit Java 7 JVM on that box. And we also know that we've got this product running in Java 6, 7, and 8, on IBM Midrange boxes, WinDoze boxes, and Linux boxes, without the problem occurring. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Outbound SSL?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 5/31/19 13:50, André Warnier (tomcat) wrote: > On 31.05.2019 18:12, James H. H. Lampert wrote: >> Thanks. >> >> We think that the customer has solved the cipher problem, >> because, at least as of when I checked on Wednesday, that error >> message was no longer appearing. >> >> Yet they're still not connecting. I can *ping* >> maps.googleapis.com from their box, with no trouble whatsoever, > > That is perhaps because "ping" does not use TCP/IP, it uses > another protocol called ICMP, which is (a) connection-less and (b) > not usually blocked by firewalls. At least, this shows that the DNS > part is working correctly, and that the customer's host has a > "route" to that server. But for example, if the server (or a > firewall) blocked connections to the port which the webapp is > trying to reach, you would still get the problem below. (Or if the > server simply is not listening on that port). +1 James, what if you: $ openssl s_client -connect maps.googleapis.com:443 Do you get a connection? If so, there is some other issue with the software and we'll have to dig-in. If that does NOT connect, then it is probably a network / firewall problem. That's the same IPv6 address that I get when I do "host maps.googleapis.com" so at least you aren't having DNS intercepted or something like that. You may also need to go through an HTTP proxy to get to the outside. You might want to ask the client is they require an HTTP proxy. Hmm. Intermittent connection failures, sometimes with cipher-suite mismatches and other weird things? Maybe they are one of those companies who MitM everything and their MitM box is badly configured... or they are playing with it. I'm putting the certificate actually presented by maps.googleapis.com to a clean source below. If you can connect with "openssl s_client" then check to see that they are the same. If the company is MitM'ing, then tell them to (a) stop it and (b) fix that component to that it works properly. > But when the webapp tries to connect, it gets >>> java.net.ConnectException: Failed to connect to >>> maps.googleapis.com/2607:f8b0:4009:807:0:0:0:200a:443 >> >> And the really weird part is that none of the messages in the >> resulting stacktrace appear to refer to any of our classes, or to >> any classes that appear to have anything to do with Tomcat. >> > > This is not so weird, if that webapp (as is likely) contains its > own classes to make the connection that /it/ tries to make to the > Google server. Or, like a lot of software, using something like Apache http-client. The package name for that starts with org.apache.http and there can be miles of stack frames in their traces. (IMO http-client has become far too complicated to be of use to casual programmers. I honestly can't believe it's that complicated to make an HTTP request. Spoiler alert: it's not.) Would you be willing to post some (or all!) of the stack trace? > The problem seems to be with the webapp, and you would have more > luck trying to get information from whoever supplied that webapp. > Maybe it has some parameter to increase its log level, which may > tell you in the log the details of why it cannot establish a TCP > connection with the Google server. (Who knows, the customer server > IP may even be blacklisted by Google..) That's an interesting thought, but Google doesn't usually do that without a really good reason. - -chris FYI, Google's certificate from maps.googleapis.com - -BEGIN CERTIFICATE- MIIJgjCCCGqgAwIBAgIQcK7vFJuw8fXplnyGbKi9QTANBgkqhkiG9w0BAQsFADBU MQswCQYDVQQGEwJVUzEeMBwGA1UEChMVR29vZ2xlIFRydXN0IFNlcnZpY2VzMSUw IwYDVQQDExxHb29nbGUgSW50ZXJuZXQgQXV0aG9yaXR5IEczMB4XDTE5MDUxNDEz MjkxM1oXDTE5MDgwNjEzMjAwMFowajELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNh bGlmb3JuaWExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxEzARBgNVBAoMCkdvb2ds ZSBMTEMxGTAXBgNVBAMMECouZ29vZ2xlYXBpcy5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC6XmMJ8cxe0oZB9J7hVKGmxaVUTDv68JPrhWeKpnd0 fXrUFGJsP9XREfdRQV+K30pwSFFfbHA/nZCvwPpsp63uuLq+NBXZ7bqylRKyafbL ThBzkv/2U8SSPQuriQAAkJOS7c+wDfx8eugSzDq1NEmbRAAvYcphszy2LLD8GpZm 2ueogwYDnojcolZ2n34nXPq6ae8BQSxJzbhirzBknNapRuos/knu3KNWq/a/LgPx SVa1yN6OcBoWWRKcVYz74mGEbVA9kwAmA2xhGd/lXHg7lotjRgBWHv1Bt+QumRFE XCPIWeFcY/eSVqcNK0RUydp5UnMpvSYd/QfQ2sZAk3pNAgMBAAGjggY4MIIGNDAT BgNVHSUEDDAKBggrBgEFBQcDATCCBQ0GA1UdEQSCBQQwggUAghAqLmdvb2dsZWFw aXMuY29tghQqLmNsaWVudHM2Lmdvb2dsZS5hZYIUKi5jbGllbnRzNi5nb29nbGUu YXSCFCouY2xpZW50czYuZ29vZ2xlLmJlghQqLmNsaWVudHM2Lmdvb2dsZS5jYYIU Ki5jbGllbnRzNi5nb29nbGUuY2iCFCouY2xpZW50czYuZ29vZ2xlLmNsghcqLmNs aWVudHM2Lmdvb2dsZS5jby5pZIIXKi5jbGllbnRzNi5nb29nbGUuY28uaWyCFyou Y2xpZW50czYuZ29vZ2xlLmNvLmlughcqLmNsaWVudHM2Lmdvb2dsZS5jby5qcIIX Ki5jbGllbnRzNi5nb29nbGUuY28ua3KCFyouY2xpZW50czYuZ29vZ2xlLmNvLm56 ghcqLmNsaWVudHM2Lmdvb2dsZS5jby51a4IXKi5jbGllbnRzNi5nb29nbGUuY28u dmWCFyouY2xpZW50czYuZ29vZ2xlLmNvLnphghUqLmNsaWVudHM2Lmdvb2dsZS5j b22CGCouY2xpZW50czYuZ29vZ2xlLmNvbS5hcoIYKi5jbGllbnRzNi5nb29nbGUu Y29tLmF1ghgqLmNsaWV
Re: AW: Outbound SSL?
On 31.05.2019 18:12, James H. H. Lampert wrote: Thanks. We think that the customer has solved the cipher problem, because, at least as of when I checked on Wednesday, that error message was no longer appearing. Yet they're still not connecting. I can *ping* maps.googleapis.com from their box, with no trouble whatsoever, That is perhaps because "ping" does not use TCP/IP, it uses another protocol called ICMP, which is (a) connection-less and (b) not usually blocked by firewalls. At least, this shows that the DNS part is working correctly, and that the customer's host has a "route" to that server. But for example, if the server (or a firewall) blocked connections to the port which the webapp is trying to reach, you would still get the problem below. (Or if the server simply is not listening on that port). But when the webapp tries to connect, it gets java.net.ConnectException: Failed to connect to maps.googleapis.com/2607:f8b0:4009:807:0:0:0:200a:443 And the really weird part is that none of the messages in the resulting stacktrace appear to refer to any of our classes, or to any classes that appear to have anything to do with Tomcat. This is not so weird, if that webapp (as is likely) contains its own classes to make the connection that /it/ tries to make to the Google server. I believe that someone mentioned before, that Tomcat does not contain any class for making outbound connections to another server. The connection is thus (probably, at a lower level) made by classes belonging to the JVM which you are using to run Tomcat (like the "java.net.ConnectException" above). In any case, Tomcat itself has no role in it. The problem seems to be with the webapp, and you would have more luck trying to get information from whoever supplied that webapp. Maybe it has some parameter to increase its log level, which may tell you in the log the details of why it cannot establish a TCP connection with the Google server. (Who knows, the customer server IP may even be blacklisted by Google..) -- JHHL - 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
Re: AW: Outbound SSL?
Thanks. We think that the customer has solved the cipher problem, because, at least as of when I checked on Wednesday, that error message was no longer appearing. Yet they're still not connecting. I can *ping* maps.googleapis.com from their box, with no trouble whatsoever, But when the webapp tries to connect, it gets java.net.ConnectException: Failed to connect to maps.googleapis.com/2607:f8b0:4009:807:0:0:0:200a:443 And the really weird part is that none of the messages in the resulting stacktrace appear to refer to any of our classes, or to any classes that appear to have anything to do with Tomcat. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Outbound SSL?
Hi, > -Ursprüngliche Nachricht- > Von: Peter Kreuser > Gesendet: Donnerstag, 30. Mai 2019 07:22 > Outbound SSL is usually handled by the underlying Java VM. ... and the problem occurs often if you use different jdks, like openjdk and ibmjdk. You can run a small java program on your jvm to print out the supported And default protocols. Yet, I didn’t find a better way. e.g. ==> https://confluence.atlassian.com/stashkb/list-ciphers-used-by-jvm-679609085.html -- Mit freundlichen Grüßen / Kind Regards/ नमस्ते(Namaste) Bernd Schatz ITI/FT - CoC Enterprise Platforms Services (PAI) HPC Z252 Gebäude VDZ Ost 1.OG Plieninger Str. 150 70567 Stuttgart Bernd Schatz Büro: +49 711 17 41463 Mobile: +49 151 5862 6591 FAX: +49 711 17 7904 1252 mailto:bernd.sch...@daimler.com https://matter.i.daimler.com openpgp-digital-signature.asc Description: PGP signature
Re: Outbound SSL?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Peter and James, On 5/30/19 01:22, Peter Kreuser wrote: > James, > > Outbound SSL is usually handled by the underlying Java VM. Yep. Tomcat doesn't have any code to make outgoing TLS connections. >> Am 29.05.2019 um 20:57 schrieb James H. H. Lampert >> : >> >> We have a customer that is running our Tomcat-based webapp, and >> it is apparently having trouble accessing a Google web service. >> >> The error message they're getting is: >> >>> Unable to find acceptable protocols. isFallback=false, >>> modes=[ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM _SHA256, >>> >>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, >>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, >>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, >>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, >>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, >>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, >>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA, >>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, >>> TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, >>> TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA], >>> tlsVersions=[TLS_1_2, TLS_1_1, TLS_1_0], >>> supportsTlsExtensions=true), >>> ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 , >>> >>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, >>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, >>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, >>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, >>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, >>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, >>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA, >>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, >>> TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, >>> TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA], >>> tlsVersions=[TLS_1_0], supportsTlsExtensions=true), >>> ConnectionSpec()], supported protocols=[TLSv1] > > These are the ciphers and protocols requested. Are these two > different services? If that is from server and client the ciphers > are OK and protocols also overlap. I don't think that's a list of the server, client supported protocols. There is also an empty one at the end (TLSv1, no cipher suites). > What strikes me though is the difference in TLS versions and > supported protocols. > >> Is this something that could be caused by a Tomcat configuration >> issue? > > Not really Tomcat. Java. Unless you set specific values on the > connection. Or on the commandline. > > Could you please let us know the Java version and maybe the > Connection settings? JAVA_OPTS? It would also be a good idea to run good 'ole SSLLabs server test against the service. If it's an internal service or one that can't be scanned by Qualys, then you can try this tool which is roughly equivalen t: https://github.com/ChristopherSchultz/ssltest Then check the capabilities of the client you are working with. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzwCo0ACgkQHPApP6U8 pFggbBAAtRZu9HL2h45cWeml1QA8vpMiq5aZTBvNAR+h6YuqRTsMwHPTC0SAJ3S+ COPsihXZe0xFSbYh8SjeZoxQSiZnP9Nu6r2EBSwlzOfNGaGBw7Bev9Ga2Mhbwg40 GJbwED9D4DIZ+5ALBRVJzrxgnl/zXeI5cbKVIgA3VtomFZtjGqxTmaRPX7O2dRoU 4GBQzBQIOHia1ppdWOYDtJ+1lqMMd8kuONTrUeEGAi/WjKvZ+IMhFzAtnKwh7MNO HzLnNy7f5c33wNjnLArJF0t406AOF+qm6izfFKQBJrmpX2SRiCgH8UcpClTlHj9u lnNevGM7YyY9f43BC64XZ2Wugpw0fUPvypyCmv7VkYvra17wOwl6qj2loj/eVB4b tuYvECogZZvGLiNDdXyZO/PKIATVJiVmFP1W/k7dHDLBN4hkn88REZj9IugWO9iU /NuPkLVcDC5S2YXMSk7MPlsxAAA6kpaXhf7dsDpIC7KrrrIyDt2gJsJNlU1o6v7L uL4HHyI+nVPGPqLCAsd4MNjt3j9lvhDqCxdnSoFUnhGJypLh9RttzhpBoKA7zN2T 56i84UkDoVYs+HWExZ6F4H8kgqm1/ZhwHuhdQK/pyl/B1uNi6TIjN5z/TbdIp9ZR SwrEKJ94od3dYG2w8lAbG18FDn154fh7/ZgvhIb3rWxs1YbSkgw= =Xqgz -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Outbound SSL?
James, Outbound SSL is usually handled by the underlying Java VM. > Am 29.05.2019 um 20:57 schrieb James H. H. Lampert : > > We have a customer that is running our Tomcat-based webapp, and it is > apparently having trouble accessing a Google web service. > > The error message they're getting is: > >> Unable to find acceptable protocols. isFallback=false, >> modes=[ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, >> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, >> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, >> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, >> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, >> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, >> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, >> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, >> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, >> TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_2, TLS_1_1, >> TLS_1_0], supportsTlsExtensions=true), >> ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, >> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, >> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, >> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, >> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, >> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, >> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, >> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, >> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, >> TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_0], >> supportsTlsExtensions=true), ConnectionSpec()], supported >> protocols=[TLSv1] These are the ciphers and protocols requested. Are these two different services? If that is from server and client the ciphers are OK and protocols also overlap. What strikes me though is the difference in TLS versions and supported protocols. > Is this something that could be caused by a Tomcat configuration issue? > Not really Tomcat. Java. Unless you set specific values on the connection. Or on the commandline. Could you please let us know the Java version and maybe the Connection settings? JAVA_OPTS? > -- > James H. H. Lampert > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Outbound SSL?
We have a customer that is running our Tomcat-based webapp, and it is apparently having trouble accessing a Google web service. The error message they're getting is: Unable to find acceptable protocols. isFallback=false, modes=[ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_2, TLS_1_1, TLS_1_0], supportsTlsExtensions=true), ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_0], supportsTlsExtensions=true), ConnectionSpec()], supported protocols=[TLSv1] Is this something that could be caused by a Tomcat configuration issue? -- James H. H. Lampert - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org