You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Brian Braun <br...@gmail.com> on 2012/09/14 09:06:00 UTC
SSL Vulnerability in Tomcat and/or JVM?
Hi,
In my site I’m using a certificate from www.securitymetrics.com. Today they
disabled my certificate. This is supposed to be the main reason:
Description: SSL/TLS Protocol Initialization Vector Implementation
Information Disclosure Vulnerability Synoposis: It may be possible to
obtain sensitive information from the remote host with SSL/TLS-enabled
services. Impact: A vulnerability exists in SSL 3.0 and TLS 1.0 that could
allow information disclosure if an attacker intercepts encrypted traffic
served from an affected system. TLS 1.1, TLS 1.2, and all cipher suites
that do not use CBC mode are not affected. This script tries to establish
an SSL/TLS remote connection using an affected SSL version and cipher
suite, and then solicits return data. If returned application data is not
fragmented with an empty or one-byte record, it is likely vulnerable.
OpenSSL uses empty fragments as a countermeasure unless the
'SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS' option is specified when OpenSSL is
initialized. Microsoft implemented one-byte fragments as a countermeasure,
and the setting can be controlled via the registry key H
KEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\SecurityProviders
\\SCHANNEL\\SendExtraRecord <file://schannel/SendExtraRecord>. Therefore,
if multiple applications use the same SSL/TLS implementation, some may be
vulnerable while others may not, depending on whether or not a
countermeasure has been enabled. Note that this script detects the
vulnerability in the SSLv3/TLSv1 protocol implemented in the server. It
does not detect the BEAST attack where it exploits the vulnerability at
HTTPS client-side (i.e., Internet browser). The detection at server-side
does not necessarily mean your server is vulnerable to the BEAST attack
because the attack exploits the vulnerability at client-side, and both
SSL/TLS clients and servers can independently employ the split record
countermeasure. See also : http://www.openssl.org/~bodo/tls-cbc.txt
http://vnhacker.blogspot.com/2011/09/beast.html
http://technet.microsoft.com/en-us/security/bulletin/ms12-006
http://support.microsoft.com/kb/2643584
http://blogs.msdn.com/b/kaushal/archive/2012/01/21/fixing-the-beast.aspxData
Received: Negotiated cipher suite: EDH-RSA-DES-
CBC3-SHA|SSLv3|Kx=DH|Au=RSA|Enc=3DES(168)|Mac=SHA1 Resolution: Configure
SSL/TLS servers to only use TLS 1.1 or TLS 1.2 if supported. Configure
SSL/TLS servers to only support cipher suites that do not use block
ciphers. Apply patches if available. Note that additional configuration may
be required after the installation of the MS12-006 security update in order
to enable the split-record countermeasure. See
http://support.microsoft.com/kb/2643584 for details. Risk Factor: Medium/
CVSS2 Base Score: 4.3 (AV:N/AC:M/Au:N/C:P/I:N/A:N) CVE: CVE-2011-3389
This is supposed to explain it further:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389
What should I do? Should I modify the parameters in my Tomcat Connector?
Should I upgrade my JVM? Should I upgrade Tomcat to a most recent version?
Should I use Windows instead of Linux? (I’m joking with the last one!)
Some information you may need to answer this:
- Linux Centos 5.8
- I’m using an SSL certificate from geotrust, a very current one (as far as
I know).
- JVM: 1.6.0_11-b03
- Tomcat 7.0.10 (Even though I disguised it as 7.0.25, actually so
securitymetrics don’t bother me with some very obscure vulnerabilities that
would force me to update it otherwise)
- This is the relevant entry in my server.xml file:
<Connector
connectionTimeout="10000"
enableLookups="true"
port="8443"
scheme="https"
secure="true"
clientAuth="false"
keystoreFile="conf/certificate.kdb"
minSpareThreads="4"
maxThreads="1000"
sslProtocol="SSLv3"
ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA"
protocol="HTTP/1.1"
SSLEnabled="true">
</Connector>
Thanks in advance!
Brian
Re: SSL Vulnerability in Tomcat and/or JVM?
Posted by Brian Braun <br...@gmail.com>.
Thanks a lot Dan. I will do. I just hope all internet visitors will still
be able to browse by site. Do you think they will? How important could the
CBC ciphers be?
On Sat, Sep 15, 2012 at 10:57 AM, Dan Chernoff <da...@gmail.com>wrote:
> Your only other real option is remove any CBC and diffehelmen ciphers from
> your supported cipher list. This really only leaves you with RC4 ciphers.
>
> Dan
>
> On Sep 14, 2012, at 5:14 PM, Brian Braun <br...@gmail.com> wrote:
>
> > Hi Dan,
> >
> > Thanks a lot for your response!
> > Contacting them will not work. I have had false positives in the past and
> > they just don't fix it. I need to do something on my side to solve this
> > situation.
> > I'm certainly NOT using OpenSSL. I'm using a Geotrust certificate, and
> > therefore the JSSE implementation.
> > Is there any other value I could give to the parameters in my "connector"
> > section to solve this problem? Maybe any way to force TLS1.1 instead of
> > allow TLS1.0? I'm very confussed.
> >
> >
> >
> > On Fri, Sep 14, 2012 at 9:59 AM, Dan <da...@gmail.com> wrote:
> >
> >> I experienced this exact same issue with McAfee secure scan. If you are
> you
> >> using JSSE as your provider you should be okay. You can submit this as a
> >> false positive scan and let them know you are using JSSE instead of
> >> OpenSSL.
> >>
> >>
> >> You can check to see which provider you are using by looking at your
> >> connector.
> >>
> >> JSSE
> >> <Connector protocol="org.apache.coyote.http11.Http11Protocol"
> port="443"
> >> .../>
> >>
> >> APR/OpenSSL
> >> <Connector protocol="org.apache.coyote.http11.Http11AprProtocol"
> port="443"
> >> .../>
> >>
> >>
> >> Dan
> >>
> >> -----Original Message-----
> >> From: Brian Braun [mailto:brianbraun@gmail.com]
> >> Sent: Friday, September 14, 2012 1:06 AM
> >> To: Tomcat Users List
> >> Subject: SSL Vulnerability in Tomcat and/or JVM?
> >>
> >> Hi,
> >>
> >>
> >>
> >> In my site I'm using a certificate from www.securitymetrics.com. Today
> >> they
> >> disabled my certificate. This is supposed to be the main reason:
> >>
> >>
> >>
> >> Description: SSL/TLS Protocol Initialization Vector Implementation
> >> Information Disclosure Vulnerability Synoposis: It may be possible to
> >> obtain
> >> sensitive information from the remote host with SSL/TLS-enabled
> services.
> >> Impact: A vulnerability exists in SSL 3.0 and TLS 1.0 that could allow
> >> information disclosure if an attacker intercepts encrypted traffic
> served
> >> from an affected system. TLS 1.1, TLS 1.2, and all cipher suites that do
> >> not
> >> use CBC mode are not affected. This script tries to establish an SSL/TLS
> >> remote connection using an affected SSL version and cipher suite, and
> then
> >> solicits return data. If returned application data is not fragmented
> with
> >> an
> >> empty or one-byte record, it is likely vulnerable.
> >> OpenSSL uses empty fragments as a countermeasure unless the
> >> 'SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS' option is specified when OpenSSL is
> >> initialized. Microsoft implemented one-byte fragments as a
> countermeasure,
> >> and the setting can be controlled via the registry key H
> >> KEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\SecurityProviders
> >> \\SCHANNEL\\SendExtraRecord <file://schannel/SendExtraRecord>.
> Therefore,
> >> if
> >> multiple applications use the same SSL/TLS implementation, some may be
> >> vulnerable while others may not, depending on whether or not a
> >> countermeasure has been enabled. Note that this script detects the
> >> vulnerability in the SSLv3/TLSv1 protocol implemented in the server. It
> >> does
> >> not detect the BEAST attack where it exploits the vulnerability at HTTPS
> >> client-side (i.e., Internet browser). The detection at server-side does
> not
> >> necessarily mean your server is vulnerable to the BEAST attack because
> the
> >> attack exploits the vulnerability at client-side, and both SSL/TLS
> clients
> >> and servers can independently employ the split record countermeasure.
> See
> >> also : http://www.openssl.org/~bodo/tls-cbc.txt
> >> http://vnhacker.blogspot.com/2011/09/beast.html
> >> http://technet.microsoft.com/en-us/security/bulletin/ms12-006
> >> http://support.microsoft.com/kb/2643584
> >>
> >>
> http://blogs.msdn.com/b/kaushal/archive/2012/01/21/fixing-the-beast.aspxData
> >> Received: Negotiated cipher suite: EDH-RSA-DES-
> >> CBC3-SHA|SSLv3|Kx=DH|Au=RSA|Enc=3DES(168)|Mac=SHA1 Resolution: Configure
> >> SSL/TLS servers to only use TLS 1.1 or TLS 1.2 if supported. Configure
> >> SSL/TLS servers to only support cipher suites that do not use block
> >> ciphers.
> >> Apply patches if available. Note that additional configuration may be
> >> required after the installation of the MS12-006 security update in
> order to
> >> enable the split-record countermeasure. See
> >> http://support.microsoft.com/kb/2643584 for details. Risk Factor:
> Medium/
> >> CVSS2 Base Score: 4.3 (AV:N/AC:M/Au:N/C:P/I:N/A:N) CVE: CVE-2011-3389
> >>
> >>
> >>
> >> This is supposed to explain it further:
> >> http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389
> >>
> >>
> >> What should I do? Should I modify the parameters in my Tomcat Connector?
> >> Should I upgrade my JVM? Should I upgrade Tomcat to a most recent
> version?
> >> Should I use Windows instead of Linux? (I'm joking with the last one!)
> >>
> >>
> >>
> >> Some information you may need to answer this:
> >>
> >>
> >> - Linux Centos 5.8
> >> - I'm using an SSL certificate from geotrust, a very current one (as
> far as
> >> I know).
> >>
> >> - JVM: 1.6.0_11-b03
> >>
> >> - Tomcat 7.0.10 (Even though I disguised it as 7.0.25, actually so
> >> securitymetrics don't bother me with some very obscure vulnerabilities
> that
> >> would force me to update it otherwise)
> >>
> >> - This is the relevant entry in my server.xml file:
> >>
> >>
> >>
> >> <Connector
> >>
> >> connectionTimeout="10000"
> >>
> >> enableLookups="true"
> >>
> >> port="8443"
> >>
> >> scheme="https"
> >>
> >> secure="true"
> >>
> >> clientAuth="false"
> >>
> >> keystoreFile="conf/certificate.kdb"
> >>
> >> minSpareThreads="4"
> >>
> >> maxThreads="1000"
> >>
> >> sslProtocol="SSLv3"
> >>
> >>
> >>
> >>
> ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_DHE_RSA_WITH_
> >> 3DES_EDE_CBC_SHA"
> >>
> >> protocol="HTTP/1.1"
> >>
> >> SSLEnabled="true">
> >>
> >> </Connector>
> >>
> >> Thanks in advance!
> >>
> >>
> >> Brian
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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: SSL Vulnerability in Tomcat and/or JVM?
Posted by Dan Chernoff <da...@gmail.com>.
Your only other real option is remove any CBC and diffehelmen ciphers from your supported cipher list. This really only leaves you with RC4 ciphers.
Dan
On Sep 14, 2012, at 5:14 PM, Brian Braun <br...@gmail.com> wrote:
> Hi Dan,
>
> Thanks a lot for your response!
> Contacting them will not work. I have had false positives in the past and
> they just don't fix it. I need to do something on my side to solve this
> situation.
> I'm certainly NOT using OpenSSL. I'm using a Geotrust certificate, and
> therefore the JSSE implementation.
> Is there any other value I could give to the parameters in my "connector"
> section to solve this problem? Maybe any way to force TLS1.1 instead of
> allow TLS1.0? I'm very confussed.
>
>
>
> On Fri, Sep 14, 2012 at 9:59 AM, Dan <da...@gmail.com> wrote:
>
>> I experienced this exact same issue with McAfee secure scan. If you are you
>> using JSSE as your provider you should be okay. You can submit this as a
>> false positive scan and let them know you are using JSSE instead of
>> OpenSSL.
>>
>>
>> You can check to see which provider you are using by looking at your
>> connector.
>>
>> JSSE
>> <Connector protocol="org.apache.coyote.http11.Http11Protocol" port="443"
>> .../>
>>
>> APR/OpenSSL
>> <Connector protocol="org.apache.coyote.http11.Http11AprProtocol" port="443"
>> .../>
>>
>>
>> Dan
>>
>> -----Original Message-----
>> From: Brian Braun [mailto:brianbraun@gmail.com]
>> Sent: Friday, September 14, 2012 1:06 AM
>> To: Tomcat Users List
>> Subject: SSL Vulnerability in Tomcat and/or JVM?
>>
>> Hi,
>>
>>
>>
>> In my site I'm using a certificate from www.securitymetrics.com. Today
>> they
>> disabled my certificate. This is supposed to be the main reason:
>>
>>
>>
>> Description: SSL/TLS Protocol Initialization Vector Implementation
>> Information Disclosure Vulnerability Synoposis: It may be possible to
>> obtain
>> sensitive information from the remote host with SSL/TLS-enabled services.
>> Impact: A vulnerability exists in SSL 3.0 and TLS 1.0 that could allow
>> information disclosure if an attacker intercepts encrypted traffic served
>> from an affected system. TLS 1.1, TLS 1.2, and all cipher suites that do
>> not
>> use CBC mode are not affected. This script tries to establish an SSL/TLS
>> remote connection using an affected SSL version and cipher suite, and then
>> solicits return data. If returned application data is not fragmented with
>> an
>> empty or one-byte record, it is likely vulnerable.
>> OpenSSL uses empty fragments as a countermeasure unless the
>> 'SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS' option is specified when OpenSSL is
>> initialized. Microsoft implemented one-byte fragments as a countermeasure,
>> and the setting can be controlled via the registry key H
>> KEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\SecurityProviders
>> \\SCHANNEL\\SendExtraRecord <file://schannel/SendExtraRecord>. Therefore,
>> if
>> multiple applications use the same SSL/TLS implementation, some may be
>> vulnerable while others may not, depending on whether or not a
>> countermeasure has been enabled. Note that this script detects the
>> vulnerability in the SSLv3/TLSv1 protocol implemented in the server. It
>> does
>> not detect the BEAST attack where it exploits the vulnerability at HTTPS
>> client-side (i.e., Internet browser). The detection at server-side does not
>> necessarily mean your server is vulnerable to the BEAST attack because the
>> attack exploits the vulnerability at client-side, and both SSL/TLS clients
>> and servers can independently employ the split record countermeasure. See
>> also : http://www.openssl.org/~bodo/tls-cbc.txt
>> http://vnhacker.blogspot.com/2011/09/beast.html
>> http://technet.microsoft.com/en-us/security/bulletin/ms12-006
>> http://support.microsoft.com/kb/2643584
>>
>> http://blogs.msdn.com/b/kaushal/archive/2012/01/21/fixing-the-beast.aspxData
>> Received: Negotiated cipher suite: EDH-RSA-DES-
>> CBC3-SHA|SSLv3|Kx=DH|Au=RSA|Enc=3DES(168)|Mac=SHA1 Resolution: Configure
>> SSL/TLS servers to only use TLS 1.1 or TLS 1.2 if supported. Configure
>> SSL/TLS servers to only support cipher suites that do not use block
>> ciphers.
>> Apply patches if available. Note that additional configuration may be
>> required after the installation of the MS12-006 security update in order to
>> enable the split-record countermeasure. See
>> http://support.microsoft.com/kb/2643584 for details. Risk Factor: Medium/
>> CVSS2 Base Score: 4.3 (AV:N/AC:M/Au:N/C:P/I:N/A:N) CVE: CVE-2011-3389
>>
>>
>>
>> This is supposed to explain it further:
>> http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389
>>
>>
>> What should I do? Should I modify the parameters in my Tomcat Connector?
>> Should I upgrade my JVM? Should I upgrade Tomcat to a most recent version?
>> Should I use Windows instead of Linux? (I'm joking with the last one!)
>>
>>
>>
>> Some information you may need to answer this:
>>
>>
>> - Linux Centos 5.8
>> - I'm using an SSL certificate from geotrust, a very current one (as far as
>> I know).
>>
>> - JVM: 1.6.0_11-b03
>>
>> - Tomcat 7.0.10 (Even though I disguised it as 7.0.25, actually so
>> securitymetrics don't bother me with some very obscure vulnerabilities that
>> would force me to update it otherwise)
>>
>> - This is the relevant entry in my server.xml file:
>>
>>
>>
>> <Connector
>>
>> connectionTimeout="10000"
>>
>> enableLookups="true"
>>
>> port="8443"
>>
>> scheme="https"
>>
>> secure="true"
>>
>> clientAuth="false"
>>
>> keystoreFile="conf/certificate.kdb"
>>
>> minSpareThreads="4"
>>
>> maxThreads="1000"
>>
>> sslProtocol="SSLv3"
>>
>>
>>
>> ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_DHE_RSA_WITH_
>> 3DES_EDE_CBC_SHA"
>>
>> protocol="HTTP/1.1"
>>
>> SSLEnabled="true">
>>
>> </Connector>
>>
>> Thanks in advance!
>>
>>
>> Brian
>>
>>
>> ---------------------------------------------------------------------
>> 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: SSL Vulnerability in Tomcat and/or JVM?
Posted by Brian Braun <br...@gmail.com>.
Hi Dan,
Thanks a lot for your response!
Contacting them will not work. I have had false positives in the past and
they just don't fix it. I need to do something on my side to solve this
situation.
I'm certainly NOT using OpenSSL. I'm using a Geotrust certificate, and
therefore the JSSE implementation.
Is there any other value I could give to the parameters in my "connector"
section to solve this problem? Maybe any way to force TLS1.1 instead of
allow TLS1.0? I'm very confussed.
On Fri, Sep 14, 2012 at 9:59 AM, Dan <da...@gmail.com> wrote:
> I experienced this exact same issue with McAfee secure scan. If you are you
> using JSSE as your provider you should be okay. You can submit this as a
> false positive scan and let them know you are using JSSE instead of
> OpenSSL.
>
>
> You can check to see which provider you are using by looking at your
> connector.
>
> JSSE
> <Connector protocol="org.apache.coyote.http11.Http11Protocol" port="443"
> .../>
>
> APR/OpenSSL
> <Connector protocol="org.apache.coyote.http11.Http11AprProtocol" port="443"
> .../>
>
>
> Dan
>
> -----Original Message-----
> From: Brian Braun [mailto:brianbraun@gmail.com]
> Sent: Friday, September 14, 2012 1:06 AM
> To: Tomcat Users List
> Subject: SSL Vulnerability in Tomcat and/or JVM?
>
> Hi,
>
>
>
> In my site I'm using a certificate from www.securitymetrics.com. Today
> they
> disabled my certificate. This is supposed to be the main reason:
>
>
>
> Description: SSL/TLS Protocol Initialization Vector Implementation
> Information Disclosure Vulnerability Synoposis: It may be possible to
> obtain
> sensitive information from the remote host with SSL/TLS-enabled services.
> Impact: A vulnerability exists in SSL 3.0 and TLS 1.0 that could allow
> information disclosure if an attacker intercepts encrypted traffic served
> from an affected system. TLS 1.1, TLS 1.2, and all cipher suites that do
> not
> use CBC mode are not affected. This script tries to establish an SSL/TLS
> remote connection using an affected SSL version and cipher suite, and then
> solicits return data. If returned application data is not fragmented with
> an
> empty or one-byte record, it is likely vulnerable.
> OpenSSL uses empty fragments as a countermeasure unless the
> 'SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS' option is specified when OpenSSL is
> initialized. Microsoft implemented one-byte fragments as a countermeasure,
> and the setting can be controlled via the registry key H
> KEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\SecurityProviders
> \\SCHANNEL\\SendExtraRecord <file://schannel/SendExtraRecord>. Therefore,
> if
> multiple applications use the same SSL/TLS implementation, some may be
> vulnerable while others may not, depending on whether or not a
> countermeasure has been enabled. Note that this script detects the
> vulnerability in the SSLv3/TLSv1 protocol implemented in the server. It
> does
> not detect the BEAST attack where it exploits the vulnerability at HTTPS
> client-side (i.e., Internet browser). The detection at server-side does not
> necessarily mean your server is vulnerable to the BEAST attack because the
> attack exploits the vulnerability at client-side, and both SSL/TLS clients
> and servers can independently employ the split record countermeasure. See
> also : http://www.openssl.org/~bodo/tls-cbc.txt
> http://vnhacker.blogspot.com/2011/09/beast.html
> http://technet.microsoft.com/en-us/security/bulletin/ms12-006
> http://support.microsoft.com/kb/2643584
>
> http://blogs.msdn.com/b/kaushal/archive/2012/01/21/fixing-the-beast.aspxData
> Received: Negotiated cipher suite: EDH-RSA-DES-
> CBC3-SHA|SSLv3|Kx=DH|Au=RSA|Enc=3DES(168)|Mac=SHA1 Resolution: Configure
> SSL/TLS servers to only use TLS 1.1 or TLS 1.2 if supported. Configure
> SSL/TLS servers to only support cipher suites that do not use block
> ciphers.
> Apply patches if available. Note that additional configuration may be
> required after the installation of the MS12-006 security update in order to
> enable the split-record countermeasure. See
> http://support.microsoft.com/kb/2643584 for details. Risk Factor: Medium/
> CVSS2 Base Score: 4.3 (AV:N/AC:M/Au:N/C:P/I:N/A:N) CVE: CVE-2011-3389
>
>
>
> This is supposed to explain it further:
> http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389
>
>
> What should I do? Should I modify the parameters in my Tomcat Connector?
> Should I upgrade my JVM? Should I upgrade Tomcat to a most recent version?
> Should I use Windows instead of Linux? (I'm joking with the last one!)
>
>
>
> Some information you may need to answer this:
>
>
> - Linux Centos 5.8
> - I'm using an SSL certificate from geotrust, a very current one (as far as
> I know).
>
> - JVM: 1.6.0_11-b03
>
> - Tomcat 7.0.10 (Even though I disguised it as 7.0.25, actually so
> securitymetrics don't bother me with some very obscure vulnerabilities that
> would force me to update it otherwise)
>
> - This is the relevant entry in my server.xml file:
>
>
>
> <Connector
>
> connectionTimeout="10000"
>
> enableLookups="true"
>
> port="8443"
>
> scheme="https"
>
> secure="true"
>
> clientAuth="false"
>
> keystoreFile="conf/certificate.kdb"
>
> minSpareThreads="4"
>
> maxThreads="1000"
>
> sslProtocol="SSLv3"
>
>
>
> ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_DHE_RSA_WITH_
> 3DES_EDE_CBC_SHA"
>
> protocol="HTTP/1.1"
>
> SSLEnabled="true">
>
> </Connector>
>
> Thanks in advance!
>
>
> Brian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
RE: SSL Vulnerability in Tomcat and/or JVM?
Posted by Dan <da...@gmail.com>.
I experienced this exact same issue with McAfee secure scan. If you are you
using JSSE as your provider you should be okay. You can submit this as a
false positive scan and let them know you are using JSSE instead of OpenSSL.
You can check to see which provider you are using by looking at your
connector.
JSSE
<Connector protocol="org.apache.coyote.http11.Http11Protocol" port="443"
.../>
APR/OpenSSL
<Connector protocol="org.apache.coyote.http11.Http11AprProtocol" port="443"
.../>
Dan
-----Original Message-----
From: Brian Braun [mailto:brianbraun@gmail.com]
Sent: Friday, September 14, 2012 1:06 AM
To: Tomcat Users List
Subject: SSL Vulnerability in Tomcat and/or JVM?
Hi,
In my site I'm using a certificate from www.securitymetrics.com. Today they
disabled my certificate. This is supposed to be the main reason:
Description: SSL/TLS Protocol Initialization Vector Implementation
Information Disclosure Vulnerability Synoposis: It may be possible to obtain
sensitive information from the remote host with SSL/TLS-enabled services.
Impact: A vulnerability exists in SSL 3.0 and TLS 1.0 that could allow
information disclosure if an attacker intercepts encrypted traffic served
from an affected system. TLS 1.1, TLS 1.2, and all cipher suites that do not
use CBC mode are not affected. This script tries to establish an SSL/TLS
remote connection using an affected SSL version and cipher suite, and then
solicits return data. If returned application data is not fragmented with an
empty or one-byte record, it is likely vulnerable.
OpenSSL uses empty fragments as a countermeasure unless the
'SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS' option is specified when OpenSSL is
initialized. Microsoft implemented one-byte fragments as a countermeasure,
and the setting can be controlled via the registry key H
KEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\SecurityProviders
\\SCHANNEL\\SendExtraRecord <file://schannel/SendExtraRecord>. Therefore, if
multiple applications use the same SSL/TLS implementation, some may be
vulnerable while others may not, depending on whether or not a
countermeasure has been enabled. Note that this script detects the
vulnerability in the SSLv3/TLSv1 protocol implemented in the server. It does
not detect the BEAST attack where it exploits the vulnerability at HTTPS
client-side (i.e., Internet browser). The detection at server-side does not
necessarily mean your server is vulnerable to the BEAST attack because the
attack exploits the vulnerability at client-side, and both SSL/TLS clients
and servers can independently employ the split record countermeasure. See
also : http://www.openssl.org/~bodo/tls-cbc.txt
http://vnhacker.blogspot.com/2011/09/beast.html
http://technet.microsoft.com/en-us/security/bulletin/ms12-006
http://support.microsoft.com/kb/2643584
http://blogs.msdn.com/b/kaushal/archive/2012/01/21/fixing-the-beast.aspxData
Received: Negotiated cipher suite: EDH-RSA-DES-
CBC3-SHA|SSLv3|Kx=DH|Au=RSA|Enc=3DES(168)|Mac=SHA1 Resolution: Configure
SSL/TLS servers to only use TLS 1.1 or TLS 1.2 if supported. Configure
SSL/TLS servers to only support cipher suites that do not use block ciphers.
Apply patches if available. Note that additional configuration may be
required after the installation of the MS12-006 security update in order to
enable the split-record countermeasure. See
http://support.microsoft.com/kb/2643584 for details. Risk Factor: Medium/
CVSS2 Base Score: 4.3 (AV:N/AC:M/Au:N/C:P/I:N/A:N) CVE: CVE-2011-3389
This is supposed to explain it further:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389
What should I do? Should I modify the parameters in my Tomcat Connector?
Should I upgrade my JVM? Should I upgrade Tomcat to a most recent version?
Should I use Windows instead of Linux? (I'm joking with the last one!)
Some information you may need to answer this:
- Linux Centos 5.8
- I'm using an SSL certificate from geotrust, a very current one (as far as
I know).
- JVM: 1.6.0_11-b03
- Tomcat 7.0.10 (Even though I disguised it as 7.0.25, actually so
securitymetrics don't bother me with some very obscure vulnerabilities that
would force me to update it otherwise)
- This is the relevant entry in my server.xml file:
<Connector
connectionTimeout="10000"
enableLookups="true"
port="8443"
scheme="https"
secure="true"
clientAuth="false"
keystoreFile="conf/certificate.kdb"
minSpareThreads="4"
maxThreads="1000"
sslProtocol="SSLv3"
ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_DHE_RSA_WITH_
3DES_EDE_CBC_SHA"
protocol="HTTP/1.1"
SSLEnabled="true">
</Connector>
Thanks in advance!
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org