-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 James,
On 8/9/16 12:36 PM, James H. H. Lampert wrote: > On 8/9/16, 9:25 AM, Christopher Schultz wrote: >> There /is/ a POODLE variation which is against TLS 1.0 - 1.2 [1]. >> If SSLv3 is completely disabled (TLS1.0 is okay), then you >> aren't vulnerable to "classic" POODLE. If you aren't using >> CBC-based cipher suites with TLS1.0 - TLS1.2, then you should be >> okay. >> >> With a Java 1.6 (1.6.0_26) client, my server refuses connections >> due to too-small DH pairs when left to its own devices[2]. When >> the client is restricted to certain ciphers, these cipher suites >> are usable: >> >> Accepted TLSv1 TLS_RSA_WITH_AES_128_CBC_SHA Accepted TLSv1 >> TLS_RSA_WITH_AES_256_CBC_SHA Accepted TLSv1 >> SSL_RSA_WITH_3DES_EDE_CBC_SHA >> >> Of course, those CBC-based cipher suites are the ones vulnerable >> to the TLS flavor of POODLE. >> >> Ivan Ristic tends to know what he's doing, so I think you can >> trust Qualys's server-testing tool. > > My understanding is that it is only certain implementations of > TLSv1.0 that are vulnerable to POODLE-TLS. I believe that to be true. The original report was against a "widely-used TLS implementation" but I can't seem to find a direct reference for which implementation it was. I think it's F5's implementation in the load-balancers, but I can't find a broken-version-number or a fixed-version-number (I didn't look very hard) or whether they were using some third-party implementation. A "widely-used TLS implementation" is usually a euphemism for "OpenSSL", but that appears not to be the case, here. FWIW, Qualys's test tries both the SSL and TLS variants of POODLE and reports on them separately. (I had never noticed that before.) > The weirdest part is that everything I've tried (including the > manual test) tells ME that neither our Tomcat server, nor the > customer's, were accepting SSLv3 connections even before we began > this exercise, and that all our customers' Tomcat servers, at least > the ones we're responsible for, are similarly rejecting SSLv3, and > have been for some time. And yet, whoever is doing their security > audit is saying that we NEED to disable SSLv3. I'd sure like to > know what they're using, that's telling them it isn't already > disabled. I would ask them to show you what they are doing. At this point, it seems you have take all reasonable steps. Especially with a client, they may have something you weren't expecting, like an F5 load-balancer out in front of your server, out in front of your service. Another possibility is that your service may be protected, but another service isn't properly-configured, or is /intentionally/ open to SSLv3 connections in order to provide backward-compatibility to clients which require it. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJXqgrjAAoJEBzwKT+lPKRYGu8P/jV23x+u0qgB1Nu24J5psty7 4dxOTcIeSf1rubwa0i40/KAw6+On4iPacvxQq1PtRR5vj1py1x8viZeVgkiK87zC DU+O5Mygz2jPCc2XrI9LuGXGmjFEHWZItoRB4YaN5BYh2GHSvYyU576Oh6SimCbU Bq7oUNT+YMcl3z5qUeN1FiroGVvWoIMJeiqa2AJgLS6yqtnlZpzvSS1RZ33MtFnu QNu2ylhY0umv1Ghbs06U5DMtqYdjez1mRKwVAu6c5Q+eoPAo0ABOI/GeBV++4GwT 1ekF3HRD4HFL+7WjvOBdHowYbtwmL9Jmyp5+SFWB4LnApLC7BRCm1stmzRsKhm91 mcqqtu+7IRGP6ZhnFy3D45O2mtjaFuy5l57WgyApE3ImJfe4MgPhcFxJXaHVEeeM cRLBgr5fRRlIWX2UpPVx7ZlM5/sBcKfR33Pzc78LGyt3GBwtXjMm9ZVUeee0qGfv otaQOomids1bgMOXMVtoWfkpFa941DDbQnsYsrmogj+WQgRjH+D66fc4yavgC7Hh fNItQdx69R4f8eRRBQGlW3BQBtx+8Td51UZ2Kw+kdGOIaPhzAvBbbRwdLaGld2nh VG9VAkSgpPe+egQDQanI/zF51jSwob8fDpmax7x7B83kpN8rRxvFBHPbOLZMDd9c HCkBUyfHhLW+XC+neuUc =5hTY -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
