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