-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Diarmuid,
I'm marking this as off-topic because it seems like Tomcat really has
nothing to do with the situation.
On 8/27/15 4:31 PM, dmccrthy wrote:
> Thanks for responding so quickly. My apologies, I should have been
> clearer on the topology. We have a Tomcat instance with a 3rd party
> web app deployed on it (the "Tomcat client") running on Windows
> 2008 . This connects via HTTPS to a 3rd party service running
> behind IBM Http Server on Solaris 10.
Okay, so, just to confirm:
Tomcat (app) -> HTTPS -> 3rd party service
Configurations and results:
0. prod Tomcat -> prod 3rd-party service
FAILS with TLS_RSA_WITH_AES_128_CBC_SHA
(do other ciphers work? or are you completely dead in the water?)
2. prod Tomcat -> prod 3rd-party service
with lower version of Tomcat and/or Java
WORKS with TLS_RSA_WITH_AES_128_CBC_SHA
1. test Tocmat -> test 3rd-party service
WORKS with TLS_RSA_WITH_AES_128_CBC_SHA
2. test client (command-line?) on production host -> prod 3rd parts
service
WORKS with TLS_RSA_WITH_AES_128_CBC_SHA
No changes are known/expected, other than Tomcat and Java version.
> So the tool we're using is our 3rd party client Web app (the
> "Tomcat client"). It shows the same negotiation from TLSv1.2 down
> to TLSv1. My reading of your comments is that the
> truststore/keystore has no bearing here because it's an outgoing
> client connection and there are no inbound connections at play.
Exactly. Neither the keystore nor the truststore have any bearing,
here. If the client library itself uses (or supports) a
truststore/keystore, then you'll likely know about it because you'd
have to make a call like client.setTruststore("3rdparty.jks") or whateve
r.
> * I don't know what the highest supported cipher suite is on either
> client or server hosts. I do know that TLSv1 is the highest
> supported by the 3rd party server.
Good to know, but not terribly relevant. The client and server should
negotiate a common cipher suite based upon those available on either
end. If they can't agree, the handshake fails.
> * we're not using JCE Unlimited Security because it hasn't been an
> issue and frankly I didn't think of it when we were doing the
> installations :)
Okay.
> Two additional pieces of analysis that came out of our
> investigations today are:
>
> 1) we are using NextGen Cisco devices. These are application and
> protocol aware. This means that the firewall might allow allow our
> standalone Java client to connect using HTTPS, but interfere with
> the HTTPS SOAP requests from our Tomcat/3rd party app "Tomcat
> client".
How can the device be "application aware"? How does the applicaiton
identify itself to the device? How is that authenticated? What is
stopping EvilApp.exe from claiming to be InnocentApp.exe?
> 2) there are some anecdotes of Java 7 clients failing to downgrade
> from TLSv1.2 to TLSv1. For example
> http://stackoverflow.com/questions/31579587/java-tls-1-2-downgrade-to-
tls-1-0-sometimes-error.
This
>
is not a "piece of analysis". This is something you found online
that might be related. But you haven't collected any information to
support the idea that it's related. I note that the experience is
different in that SO article: the user is getting a different error at
a different part of the handshake.
> Some takeaway actions for me to explore are below. I'll welcome any
> other thoughts that you may have.
>
> 1) compare the firewall rules on our working non-production client
> with the rules governing the failing production client
Firewalls are usually pretty dumb. I'd be surprised if the firewall is
breaking anything, here.
> 2) use openssl from our client server and see what it shows
Yes, please do that. Why wasn't that the first thing you tried?
> 3) consider forcing the Tomcat/3rd party Tomcat client to use
> TLSv1
This is a possibility, but you shouldn't have to hamper your own
application because there are some servers out there that are so old
they don't support TLSv1.2: you should always offer the best
encryption you can, and only fall-back when necessary.
> 4) check other logs on the server side to see if other clients are
> failing TLS handshakes
You didn't do this already?
> 5) investigate the supported ciphers on client and server
There is code available in the archives of this mailing list to do
that. Search for my name and "ssl" and poke-around.
> 6) consider upgrading Tomcat (as a last resort)
I thought the initial problem was that an upgrade to Tomcat "broke
something". I think it's more likely to be the Java upgrade that did
something, and not Tomcat itself.
Are you sure that the standalone test client is using the exact same
version of Java as the Tomcat server is?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJV4KNUAAoJEBzwKT+lPKRYPVMQAILQm/n33Mxh7cbYF3u0VfNg
eodcwvrXxWynhDX61ZjUGNTAPbEAsReLIuCzZjJpmB+LIaBsg8qsxpNL4zu+W4YA
ZYB2wiORHpgqXVXG3JuX2tlzKGmAaF8YnlWnsjaw+taZNWOwVvFvJN4esdp8eYYw
8xaLU1R0RLMZspIk73VigYhReRSrVpfOxhGomLE9uJle4tH5KoK+uicmWqk9rwaj
yRgM7fxrk5tctolnuzasKl/17JtWkdSpEHHhkGZiu+pgdBYkYmzAzkM9PmBIzkra
MLZ/6kG2R6UPg5HLuxfad+IYGZP7zppZAbIPfxw5zTQm7edfCSBl+2OoKnOdqFxS
dV/Tj5Jg1HkyReDDBH4A7+aYRCnXwurrM6XaLj++MxeNN94FmBiWo/Xo7KjH2S8j
EYWz/l8L1SheLm0/sGDO59giCFc32WNW9CFvHfL/qL7pmsX5AluE5BydesSOqias
AxyKMBci98zMgjOYw7SzOfr9fyag7NwW5hBTCfhf55tZSGnMWVGCWS6ihzDTDwl9
j+xWA04tQqNU2Qfd/7gmGtHSNEbJbBYKZ9U3EzjDWZYHEwDGoYe2EJAAQ61v2OsF
m7SWwlfAXQbGK85DO/n88beQ0w5QegfwFUNuYFfBvUVeK+cfJMIfbb05+wpme8g+
cUZATik9jXqZNIIJMMdm
=j1cd
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
