You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "James H. H. Lampert" <ja...@touchtonecorp.com> on 2016/08/08 16:35:56 UTC
More, Re: Question about vulnerability report
On 7/27/16, 11:59 AM, Mark Thomas wrote:
> ciphers="SSL_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_AES_128_CBC_SHA"
Ladies and Gentlemen:
Thanks, Mark; that raises the SSLLabs rating from "F" to "C," and seems
to have dealt with most of the concerns raised by the customer.
Except for one. It seems that whoever is doing the customer's security
audit is concerned with POODLE vulnerability.
Can this be dealt with in Tomcat 7 under Java 6? If so, how?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: More, Re: Question about vulnerability report
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 8/8/16, 10:32 AM, Coty Sutherland wrote:
> So you've already mitigated POODLE and the scanner is just
> complaining about your TLS version.
Or SSLLabs isn't actually checking to see if it can connect via SSLv3:
> At present, SSL Labs has the following limitations:
>
> In general, cipher suite support is done using only the
> best-supported server protocol. This means that SSL Labs might not
> show all supported suites when used against servers that enable
> different cipher suites depending on the best protocol version
> offered by the client. In practice, SSL Labs has additional tests for
> BEAST (done with SSL 3 and TLS 1) and obsolete suites (done with the
> oldest supported protocol except SSL 2); this means that it will
> catch all suites in the majority of cases. A future SSL Labs version
> will test cipher suites separately for each supported protocol.
Is there another test service I could try?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: More, Re: Question about vulnerability report
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: More, Re: Question about vulnerability report
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
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.
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.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: More, Re: Question about vulnerability report
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 8/8/16 2:31 PM, James H. H. Lampert wrote:
> Hmm. This is interesting.
>
> pentest-tools.com says that neither our server nor the customer
> server is vulnerable to POODLE.
>
> But Site24x7.com says ours IS vulnerable to POODLE. Then (when I
> click "View Result") it says it isn't. Then (when I actually run
> the test again) it once again says it is. (I haven't tested the
> customer site because results are posted on the test home page,
> which would compromise the customer's privacy.)
>
> Some other POODLE test sites don't appear to work at all. Others
> say we're not vulerable.
>
> Manually testing both servers with
>> curl -v3 -X HEAD https://www.example.com
> from a BASH session on my Mac, as per
> <http://chrisburgess.com.au/how-to-test-for-the-sslv3-poodle-vulnerabi
lity/>
>
>
>
> comes back with the desired "failed handshake" message on both
> servers.
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.
- -chris
[1] https://en.wikipedia.org/wiki/POODLE#POODLE_attack_against_TLS
[2] The TLS handshake protocol doesn't include key sizes as part of
its cipher suite negotiation, so the server and client agree that they
will use a DH-based cipher suite, but then the client doesn't like the
key size (> 1024 bits) that the server chose.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJXqgP1AAoJEBzwKT+lPKRYv38P/3YeNilJnpcMgNMQ+ZQE9VFn
Y1pBY7qb7wZYp3cxnNlRRnSBkhUIho/rwZ88vpUAPUEBK2oVVwpFovAlIPOZmV2K
ARB1KYhFxV3pInfrOLbDNMjWW6AWxPcK7n+7dbT0ZZI5aoZjl9w+Vsa16EC7Xapn
RqwUHnyOHnXLYi5YHGTLvIOIl5Wdcn1HzPbvbHhl4qjJ4n1t2PSRGqykolBSW18p
AVyNXsJgKwpuIRCjTsJ9nsc0mtO+ovr01OLySViJ33KcIyZoyOk2PWu73yHDMp4l
pUl7mYzuYmzFmMwU6s6HbDTbkxHSWBgZ+IcWH2cdQv1Uwa1VL6lQFprFC7kS/27F
bH5PUN8fnQ7F9DpH2usokkc+mto9gWpK9/J2Kj6Fk/IDdwsYd2TYEM85VAkX6GL8
xSqoAUlyRGBxyUNp6MlGmTJOM91u5KhRm2Y6kuwjF/4Orl/ZHG8sLf2racfQ71t1
eD2OuJGo0YgEpnwElMAFYvZNsNhv8fTElvFfv9FINFWORDFLCrgqldF7XGfgKBDi
QBf9A++27rFhTq+7C4emPiADJ9VMEKJP0cdzkmTBWL1Axp3lf914jmg9vwzx7Rtu
5yIa9iYBhTwSyGd2Nkfpi73TkBKWPlqTrOO1T5blQhL27QsLvGj1awe/WAc8kN4p
w5Kj+TagsFa1qHomoedo
=ZjKF
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: More, Re: Question about vulnerability report
Posted by Coty Sutherland <cs...@redhat.com>.
Vulnerability scanners are always iffy when it comes to finding actual
issues IMO. They're good for running a quick scan to get an overall
feel for weaknesses, but the effectiveness varies from tool to tool
(some only check versions, etc). I think that the best way to test if
you're vulnerable to POODLE is to try and connect via SSLv3, as you've
already done, or with s_client (openssl s_client -ssl3 -connect
$HOST:$PORT). If that fails to connect, then you're good. As far as
the TLS issues, TLSv1.0 is vulnerable to BEAST
(https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2011-3389) so you
may want to consider disabling CBC ciphers, or even upgrading to java7
if that's causing your audit to fail.
On Mon, Aug 8, 2016 at 2:31 PM, James H. H. Lampert
<ja...@touchtonecorp.com> wrote:
> Hmm. This is interesting.
>
> pentest-tools.com says that neither our server nor the customer server is
> vulnerable to POODLE.
>
> But Site24x7.com says ours IS vulnerable to POODLE. Then (when I click "View
> Result") it says it isn't. Then (when I actually run the test again) it once
> again says it is. (I haven't tested the customer site because results are
> posted on the test home page, which would compromise the customer's
> privacy.)
>
> Some other POODLE test sites don't appear to work at all. Others say we're
> not vulerable.
>
> Manually testing both servers with
>>
>> curl -v3 -X HEAD https://www.example.com
>
> from a BASH session on my Mac, as per
> <http://chrisburgess.com.au/how-to-test-for-the-sslv3-poodle-vulnerability/>
>
> comes back with the desired "failed handshake" message on both servers.
>
>
> --
> JHHL
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: More, Re: Question about vulnerability report
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
Hmm. This is interesting.
pentest-tools.com says that neither our server nor the customer server
is vulnerable to POODLE.
But Site24x7.com says ours IS vulnerable to POODLE. Then (when I click
"View Result") it says it isn't. Then (when I actually run the test
again) it once again says it is. (I haven't tested the customer site
because results are posted on the test home page, which would compromise
the customer's privacy.)
Some other POODLE test sites don't appear to work at all. Others say
we're not vulerable.
Manually testing both servers with
> curl -v3 -X HEAD https://www.example.com
from a BASH session on my Mac, as per
<http://chrisburgess.com.au/how-to-test-for-the-sslv3-poodle-vulnerability/>
comes back with the desired "failed handshake" message on both servers.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: More, Re: Question about vulnerability report
Posted by Coty Sutherland <cs...@redhat.com>.
So you've already mitigated POODLE and the scanner is just complaining
about your TLS version. Unfortunately, TLSv1.0 is the only TLS
protocol version available on java6, unless your on u111 (from
https://blogs.oracle.com/java-platform-group/entry/diagnosing_tls_ssl_and_https).
If you need TLSv1.2, then you'll have to update to java7+.
On Mon, Aug 8, 2016 at 1:13 PM, James H. H. Lampert
<ja...@touchtonecorp.com> wrote:
> On 8/8/16, 9:59 AM, Coty Sutherland wrote:
>>
>> To mitigate POODLE you must disable SSLv3 and only use TLS. Please
>> visit the wiki page for more info:
>> https://wiki.apache.org/tomcat/Security/POODLE
>
>
> Actually, I found that on my own, only a few minutes after I posted my
> question.
>
> So would the existing
> . . .
>>
>> clientAuth="false" sslProtocol="TLS" />
>
>
> become this?
> . . .
>>
>> clientAuth="false" sslProtocol="TLS"
>> sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" />
>
>
> But what I currently get in an SSLLabs scan is
>>
>> The server supports only older protocols, but not the current best TLS
>> 1.2. Grade capped to C.
>
> . . .
>>
>> Protocols
>> TLS 1.2 No
>> TLS 1.1 No
>> TLS 1.0 Yes
>> SSL 3 No
>> SSL 2 No
>
>
> from which I gather that (1) SSLLabs seems to think SSLv3 is already
> disabled, and (2) TLSv1.1 and TLSv1.2 are unavailable.
>
> Something doesn't make sense here.
>
>
> --
> JHHL
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: More, Re: Question about vulnerability report
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 8/8/16, 9:59 AM, Coty Sutherland wrote:
> To mitigate POODLE you must disable SSLv3 and only use TLS. Please
> visit the wiki page for more info:
> https://wiki.apache.org/tomcat/Security/POODLE
Actually, I found that on my own, only a few minutes after I posted my
question.
So would the existing
. . .
> clientAuth="false" sslProtocol="TLS" />
become this?
. . .
> clientAuth="false" sslProtocol="TLS" sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" />
But what I currently get in an SSLLabs scan is
> The server supports only older protocols, but not the current best TLS 1.2. Grade capped to C.
. . .
> Protocols
> TLS 1.2 No
> TLS 1.1 No
> TLS 1.0 Yes
> SSL 3 No
> SSL 2 No
from which I gather that (1) SSLLabs seems to think SSLv3 is already
disabled, and (2) TLSv1.1 and TLSv1.2 are unavailable.
Something doesn't make sense here.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: More, Re: Question about vulnerability report
Posted by Coty Sutherland <cs...@redhat.com>.
> Except for one. It seems that whoever is doing the customer's security audit is concerned with POODLE vulnerability.
To mitigate POODLE you must disable SSLv3 and only use TLS. Please
visit the wiki page for more info:
https://wiki.apache.org/tomcat/Security/POODLE
On Mon, Aug 8, 2016 at 12:35 PM, James H. H. Lampert
<ja...@touchtonecorp.com> wrote:
> On 7/27/16, 11:59 AM, Mark Thomas wrote:
>
>> ciphers="SSL_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_AES_128_CBC_SHA"
>
>
> Ladies and Gentlemen:
>
> Thanks, Mark; that raises the SSLLabs rating from "F" to "C," and seems to
> have dealt with most of the concerns raised by the customer.
>
> Except for one. It seems that whoever is doing the customer's security audit
> is concerned with POODLE vulnerability.
>
> Can this be dealt with in Tomcat 7 under Java 6? If so, how?
>
> --
> JHHL
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org