More, Re: Weird problem: browsers refusing to connect; more "fun with ciphers clauses on the connector tag"

["James H. H. Lampert" <ja...@touchtonecorp.com>]

I just got finished going through 20 other customer Tomcat installations 
we administer.

First, I found that most of them were accepting the DHE ciphers I'd 
disabled on the problem installation, and SSLLabs was giving them bad 
ratings for doing so.

Second, I found that two of the other installations were accepting the 
ECDHE ciphers I'd disabled, and yet they were working just fine in 
Chrome 60 (one of them still on a "test" certificate that was 
self-signed, wrong domain, and expired! -- we can encourage them to pick 
a CA, and let us help them install a signed cert, but we can't MAKE them 
do it).

That one is running on an AS/400 at V7R3, with a JVM that IDs in Manager 
as "jvmap3270sr10fp1-20170215_012.6"; the other one that's working fine 
with the ECDHE certs active is an AS/400 at V7R1, with a JVM that IDs as 
"jvmap3260sr16fp15-20151029_01."

In all cases, SSL is via JSSE, not OpenSSL (we've never even heard of 
anybody getting Tomcat running via OpenSSL on an AS/400).

Could it be that the browser is trying to use the ECDHE ciphers, and 
something in the OS or the JVM is blowing up when it tries to use them?

--
JHHL

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

Re: More, Re: Weird problem: browsers refusing to connect; more "fun with ciphers clauses on the connector tag"

["James H. H. Lampert" <ja...@touchtonecorp.com>]

On 10/19/17, 10:02 AM, Christopher Schultz wrote:
> The browser tells the server what cipher suites it supports during the
> initial handshake, and the server decides which algorithm to use. The
> client doesn't try multiple different connections to see which one
> sticks. The server either replies saying "okay, were using "suite X"
> or "go away, we can't talk to each other because we don't have any
> algorithms in common".

That actually makes a certain amount of sense, if the JVM somehow 
*thinks* it can handle certain ciphers (e.g., the ECDHE ciphers), but 
can't. And if the Midrange box JVMs are deferring cipher implementation 
to the OS, rather than implementing it internally, I can see how that 
could happen. I'll note that the ones that have ECDHE ciphers enabled, 
and aren't blowing up not only Chrome 60 but a bunch of simulated 
browser handshakes, are all on a much newer revision of the OS, one 
that, I think, supports ECDHE at the OS level, whereas the ones on which 
I had to disable ECDHE are on an OS revision that does NOT support it at 
the OS level.

Some pretty big assumptions, but if they're right, it would explain much.

--
JHHL

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

Re: More, Re: Weird problem: browsers refusing to connect; more "fun with ciphers clauses on the connector tag"

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

James,

On 10/16/17 2:35 PM, James H. H. Lampert wrote:
> I just got finished going through 20 other customer Tomcat
> installations we administer.
> 
> First, I found that most of them were accepting the DHE ciphers
> I'd disabled on the problem installation, and SSLLabs was giving
> them bad ratings for doing so.

Just for completeness, there's nothing wrong with DHE other than that
it's slow. Your previous post showed that it was using "weak primes"
which IS a concern, but unfortunately there are very old clients that
don't support larger primes (I'm looking at YOU, Java 1.6) and so
options are limited.

> Second, I found that two of the other installations were accepting
> the ECDHE ciphers I'd disabled, and yet they were working just fine
> in Chrome 60 (one of them still on a "test" certificate that was 
> self-signed, wrong domain, and expired! -- we can encourage them to
> pick a CA, and let us help them install a signed cert, but we can't
> MAKE them do it).

You should enable ECDHE. It's the best per-CPU-cycle key-agreement
algorithm available today. EC keys (for authentication) are a little
less useful than RSA these days, but if you can support both, I would
recommend doing ahead to support both.

A thought just occurred to me: are some clients using libtcnative/APR
and others not? I believe Tomcat still prefers APR/tcnative to the
Java NIO connector is the libraries are available. For Tomcat 7, the
configuration is sensitive to the type of connector being used, so if
you "disabled a cipher suite" and it seems to be still enabled (e.g.
ECDHE) that could be an explanation.

> That one is running on an AS/400 at V7R3, with a JVM that IDs in
> Manager as "jvmap3270sr10fp1-20170215_012.6"; the other one that's
> working fine with the ECDHE certs active is an AS/400 at V7R1, with
> a JVM that IDs as "jvmap3260sr16fp15-20151029_01."

I think most of that is going to be meaningless to us, unfortunately.
The output of "java -version" is going to be more useful.

> In all cases, SSL is via JSSE, not OpenSSL (we've never even heard
> of anybody getting Tomcat running via OpenSSL on an AS/400).

Okay, that's good to know.

> Could it be that the browser is trying to use the ECDHE ciphers,
> and something in the OS or the JVM is blowing up when it tries to
> use them?

The browser tells the server what cipher suites it supports during the
initial handshake, and the server decides which algorithm to use. The
client doesn't try multiple different connections to see which one
sticks. The server either replies saying "okay, were using "suite X"
or "go away, we can't talk to each other because we don't have any
algorithms in common".

Is this just happening at a single client? Oh, maybe not, because you
said you tried to use Google Chrome yourself and it didn't work. I was
thinking "maybe some group policy disabled a whole swath of cipher
suites in the org" but that's unlikely to be the case unless your
Chrome instance was also affected.

Is it possible that the browsers within the org are contacting a
DIFFERENT server than the Tomcat itself? Perhaps a load-balancer or
reverse-proxy that was broken, and it only *appears* like Tomcat is
broken? You ran SSLLabs tool against the site and it says it supports
RSA-AES/CBC-SHA which is definitely a decent algorithm (though GCM
should be preferred over CBC mode in nearly all cases).

Honestly, your server should be supporting more than just those two
protocols, but those two should be sufficient to establish a
connection with a server that only supports those two.

Did you know that Qualys/SSLLabs also has a *client test* as well? Try
pointing your Google Chrome instance at this page and see what it says:
https://www.ssllabs.com/ssltest/viewMyClient.html

I just tried it with my Firefox 56 on Macos and these two cipher
suites are supported (as well as many other, of course):

TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)

I did the same with Chrome 60 (latest) and is says it supports a
virtually identical list of cipher suites that Firefox does. I didn't
check any old versions.

Maybe have someone from inside the client's org share their screen
with you and have them run SSLLabs test against the hostname as they
see it from within.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlno2pEACgkQHPApP6U8
pFhDGBAAk9FcFLmeNy/tScYF9S5SB557qHpGoCfcHMvMTGVy3n8eKsqv2OPT3mSq
JwYxDdil2opagLh061Pa1TiNBMfXqWOMdQi573bBeHdWgMrAllfd+hDVSUSqHpIL
3AqhTZI2NDC1Yvg8mAnoF7vbVFSDVnGVs5duyAjcbCJ+nrjBGK+oGteFAC2RiTN5
e4fZmte01Gie+9ihAWeTLc4YQlJT/cygIA1l4EJO0vwJJonwaR/1QGa8PhPxnIgj
XXL5zgg3KS6MEf9ioyhZKEJDjCACigal0OIwOGpDHHHkHjwKOHJQ2eJsUz24Ub6U
TNCKq1MJJ7yZ1PsBQJZ3QsHZNvkJ6vcXOY70M+t6mvdDGYalw8xTcnUFcdbT2RbZ
O+Q/rT0RhTQJaOkg3Jivd81KYdfxhE1+DX8Xz6E7e4Ygpblwa0hZokGk9fosttkK
yAMRJqD6zuRda5XLhiaFKN3qUiJH27RKKMTdHPmwYk0DljD8oEatUqxBJWT6+jeY
y/7BDRMnRoSLVoWs4IevuGsIbeW0//NBMq8/vTDo/GfJnMDe6iZe3Yj0+0mlBO7C
rQ/5OABGZBTouVDSN6gyZcGmU7R6vpYviEdb0Fwe0wPaMVyAdeuQNERtiY/QR8Ik
STslaBriDzHEDAK/TWj7ZHUg+HgyRrNUIKx3lT9mGJ99WBlwaRg=
=F0Q0
-----END PGP SIGNATURE-----

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