How to resolve Sweet32 vulnerability on Apache Tomcat? - apache

I am having some trouble getting rid of a server vulnerability. The Sweet32 vulnerability deals with medium strength cipher suites on my web server. The scanner output reads as follows, "The remote host supports the use of SSL ciphers that offer medium strength encryption. Nessus regards medium strength as any encryption that uses key lengths at least 64 bits and less than 112 bits, or else that uses the 3DES encryption suite."
The following medium strength ciphers were found on the server:
EDH-RSA-DES-CBC3-SHA;
ECDHE-RSA-DES-CBC3-SHA;
DES-CBC3-SHA
I tried editing the server.xml file for Apache Tomcat. There is a SSL connector portion of the server.xml file that I have been editing. It reads as follows, but the vulnerability is still getting flagged. I've also played around with disabling certain ciphers suits in the registry, such as 3DES. Any ideas on how to fix this vulnerability would be so helpful.
<Connector URIEncoding="UTF-8"
clientAuth="false"
port="443"
scheme="https"
minSpareThreads="5"
enableLookups="true"
acceptCount="100"
maxThreads="200"
secure="true"
SSLEnabled="true"
keystoreFile="**********"
keystorePass="*********"
sslProtocol="TLSv1.2"
algorithm="IbmX509"
compression="on"
noCompressionUserAgents="gozilla, traviata"
compressableMimeType="text/html,text/xml,text/css,text/plain,text /javascript,application/javascript,application/x-javascript"
SSLCipherSuite="TLS_EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:ECDHE-RSA-AES128-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA128:DHE-RSA-AES128-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA128:ECDHE-RSA-AES128-SHA384:ECDHE-RSA-AES128-SHA128:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA128:DHE-RSA-AES128-SHA128:DHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA384:AES128-GCM-SHA128:AES128-SHA128:AES128-SHA128:AES128-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!3DES:!ECDHE-RSA-DES-CBC3-SHA"
/>

Removing the Ciphers you listed from the server.xml file should fix this.
Like this:
SSLCipherSuite="TLS_EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:ECDHE-RSA-AES128-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA128:DHE-RSA-AES128-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA128:ECDHE-RSA-AES128-SHA384:ECDHE-RSA-AES128-SHA128:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA128:DHE-RSA-AES128-SHA128:DHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES128-GCM-SHA384:AES128-GCM-SHA128:AES128-SHA128:AES128-SHA128:AES128-SHA:AES128-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!3DES"

Related

Tomcat 8.5.29 HTTP/2 is not supporting GZIP compression

I am using Tomcat 8.5.29 and using the respective configuration,I have enabled the HTTP2 support for the site. Below is the configuration in server.xml file.
<Connector port="443" protocol="org.apache.coyote.http11.Http11AprProtocol"
maxThreads="150" SSLEnabled="true" compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json" compression="on" compressionMinSize="1024"
>
<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
<SSLHostConfig>
<Certificate certificateKeyFile="conf/localhost-key.pem"
certificateFile="conf/localhost-cert.pem"
certificateChainFile="conf/cacert.pem"
type="RSA" />
</SSLHostConfig>
</Connector>
When i tried to compare the page load time for the site which is supporting HTTPS 1.1 and HTTP2, it is not consistent. Sometime it is taking more time to load and sometime it is taking less time to load compare to HTTPS 1.1.
To measure the page load time i am using Developer tools from Chrome Browser.
Later, I have found that Load time for HTTP/2 is higher because "content-encoding" in response is not gzip. Using HTTP/1.1, a script file size is 4 MB ( gzip) where as with HTTP/2, same file is of 8 MB ( no content-encoding). Compression is not happening. We have also tried with useSendfile and compression as "force" but it did not work.
We have also tried with Tomcat version 8.5.31 but no luck !! Facing same issue.
We have used Tomcat version 9 and using following configuration, got content in gzip (compressed). Now file size got reduced by 2 MB with a quick page load.
<Connector port="443" protocol="org.apache.coyote.http11.Http11AprProtocol"
maxThreads="150" SSLEnabled="true"
>
<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json" compression="on" compressionMinSize="1024" />
<SSLHostConfig>
<Certificate certificateKeyFile="conf/localhost-key.pem"
certificateFile="conf/localhost-cert.pem"
certificateChainFile="conf/cacert.pem"
type="RSA" />
</SSLHostConfig>
</Connector>
It looks like Tomcat version 8.5 is not supporting gzip with HTTP2. Any idea on this?
According to the Tomcat documentation:
Note: There is a tradeoff between using compression (saving your bandwidth) and using the sendfile feature (saving your CPU cycles). If the connector supports the sendfile feature, e.g. the NIO2 connector, using sendfile will take precedence over compression. The symptoms will be that static files greater that 48 Kb will be sent uncompressed. You can turn off sendfile by setting useSendfile attribute of the protocol, as documented below, or change the sendfile usage threshold in the configuration of the DefaultServlet in the default conf/web.xml or in the web.xml of your web application.
So try adding useSendfile="false" to your UpgradeProtocol setting
<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json" compression="on" compressionMinSize="1024" useSendfile="false" />
Note this option does not appear in the 8.5 documentation so not sure if it exists for that (there is a reference to it "You can turn off sendfile by setting useSendfile attribute of the protocol, as documented below" but then nothing below), though you can also turn off at a server level.
Weirdly I wouldn't have expected this to work in Tomcat 9 either without turning off this option, but you say it does? Are you sure you have not turned this off? Or are you testing with a smaller than 48KB file on that?
Tomcat 8.5.33 fixes this issue; compression works with http/2 then.

Turn off SSLv3 on JBoss AS 7.1.1

I have Spring MVC App running on JBoss AS 7.1.1. I need to turn off SSLv3 to protect against Poodle vulnerability. JBoss documentation at https://access.redhat.com/solutions/1232233 suggests I need to make sure that SSLv3 is not listed in the SSL Protocol attributes.
I have tried that but I can still connect to my website after only enabling SSL in Internet explorer options displayed below. Below is my standalone.xml configuration:
<connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true">
<ssl name="foo-ssl" key-alias="foo" password="secret" certificate-key-file="C:\Dev\Java\jdk1.6.0_34\bin\foo.keystore" protocol="TLSv1"/>
</connector>
Can someone suggest what I'm missing here?
I finally figured a way to fix it. If you change 'protocol' to 'protocols' in the above mentioned configuration and make sure sslv3 is not in the protocol list then it disables SSLv3.
Notice the protocols attribute in the config below
<connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true">
<ssl name="foo-ssl" key-alias="foo" password="secret" certificate-key-file="C:\Dev\Java\jdk1.6.0_34\bin\foo.keystore" protocol="TLSv1,TLSv1.1,TLSv1.2"/>
</connector>
After making this change, if you open IE and disable all other protocols except SSL 3.0 - and then try to access the web page, you should not be able see the web page.
More details available here: http://abhirampal.com/2015/07/23/disable-ssl-v3-on-jboss-as-7-1-1/

ServletRequest.getAttribute("javax.servlet.request.X509Certificate") returns null

I've got a stop-ship problem that is driving me crazy. I hope that one of you experts out there can help.
I'm running the latest release version of TomEE+ (1.6.0.2) and the latest version of Java 8 (build 1.8.0_05-b13). No matter what I try, the following line of code in my HttpServlet always returns null.
X509Certificate certs[] = (X509Certificate[])request.getAttribute("javax.servlet.request.X509Certificate");
I initially assumed that I had specified the attribute name incorrectly, so to diagnose the problem, I decided to take a look at the full list of attributes using the following:
Enumeration<String> enums = request.getAttributeNames();
However that showed me were only two attributes: one for the cipher suite and the other for the key strength.
I read the other articles and verified that my connector was correct and that it had the clientAuth attribute set properly. Here's the connector:
<Connector port="4449" protocol="org.apache.coyote.http11.Http11AprProtocol"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
clientAuth="true" sslProtocol="TLSv1.2"
SSLCertificateFile="/etc/unipagos/certs/pay.crt"
SSLCertificateKeyFile="/etc/unipagos/certs/pay.key"
SSLVerifyClient="required"
SSLHonorCipherOrder="true"
ciphers="TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384"/>
The connection seems to work, however using openssl s_client with -msg shows that the server isn't asking for the client certificate.
Why is the server not asking for a client certificate? What am I doing wrong?
I have a working connector configuration for tomee and server is requesting client cert.
you can try
<Connector port="7443" protocol="org.apache.coyote.http11.Http11AprProtocol"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
SSLProtocol="TLSv1.2"
SSLVerifyClient="require"
SSLCertificateFile="/opt/_cdrom_apache/certs/ec-dev-apr.pem"
SSLCertificateKeyFile="/opt/_cdrom_apache/certs/ec-dev.key"
SSLCACertificateFile="/opt/_cdrom_apache/certs/CA.pem"
/>

How to Change SSL Version for HTTPS Connections in JBoss EAP 6.1

I have a simple HTTPS connector configured on my JBoss EAP 6.1 server for SSL connections to a bunch of RESTful web services I am working on. I am not sure if JBoss EAP 6.1 comes with TLS 1.2 (or SSL 3.2, since I believe TLS is really just later versions of SSL), but I want to use that version of TLS or later.
What is the default SSL version of JBoss EAP 6.1 , if my standalone.xml file tags that handle this connector look like this? :
<connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true">
<ssl name="https" key-alias="localhost" password="something" certificate-key-file="${jboss.server.config.dir}/localhost.jks"/>
</connector>
There is no SSL version information given in the standalone.xml entry above, as you can see, so I've no idea.
I have read on the JBoss community web site that you can add something like sslProtocol="TLS" in the tag, and protocol="TLSv2" in the tag, but is that really all there is to it?
i.e.
<connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" sslProtocol="TLS">
<ssl name="https" key-alias="localhost" password="something" certificate-key-file="${jboss.server.config.dir}/localhost.jks" protocol="TLSv2" />
</connector>
Will the above work, and if so, how can I tell?
According to redhat documentation for EAP 6.1
protocol
The version of the SSL protocol to use. Supported values include SLv2, SSLv3, >TLSv1, SSLv2+SSLv3, and ALL. The default is ALL
Adding sslProtocol="TLS" and protocol="TLSv2" should work fine. Not to sound condescending, but the easiest way to see if it works is by testing it.
If this question did get moved to another SE site could you please provide the link?

How can I get client certificate authentication working in JBoss 5.1.0.GA when I'm using APR, and not all web deployments use CLIENT-CERT auth?

Note: I will be answering my own question... just wanted to add this tidbit to the collective wisdom of The Internets.
I've successfully configured certificate authentication on my JBoss 5.1.0.GA server, largely with the help of the information on this page: http://docs.jboss.org/jbossas/jboss4guide/r1/html/ch8.chapter.html
I have one context (let's call it /openContext) that doesn't require any authentication, and another context (let's call it /securedContext) that requires client certificate authentication (i.e., it's configured to use CLIENT-CERT in web.xml). When using JBoss's default web connector, this works splendidly. I can hit http://myhost/openContext and I'm not prompted for a certificate, but when I hit http://myhost/securedContext, I'm prompted for a client certificate as I'd expect.
However, when I install JBossWeb Native and use APR as my web connector, I'm no longer prompted for a certificate when I hit http://myhost/securedContext.
My APR connector config in server.xml looks like:
<Connector protocol="HTTP/1.1" SSLEnabled="true"
port="8443" address="${jboss.bind.address}"
scheme="https" secure="true" clientAuth="false"
SSLProtocol="SSLv3+TLSv1"
SSLCipherSuite="ALL:!ADH:!SSLv2:!EXPORT40:!EXP:!LOW"
SSLRandomSeed="/dev/urandom"
SSLCertificateFile="/etc/pki/tls/certs/mycert.crt"
SSLCertificateKeyFile="/etc/pki/tls/private/mycert.key"
SSLPassword="mypasswordwhichiassureyouisbetterthanthisone"
SSLCACertificateFile="/etc/pki/tls/certs/clientCAs.crt"
/>
I've also tried adding the SSLVerifyClient parameter to that configuration and setting it to optional, but that prompts for a certificate in both /openContext and /securedContext, which isn't the behavior I want.
How can I get JBoss with APR to require certificate authentication for one web context, but not another web context?
What worked for me was to just add a whole new web connector, and have clients use that alternate port for the secured web context. My connectors config now looks like:
<Connector protocol="HTTP/1.1" SSLEnabled="true"
port="8443" address="${jboss.bind.address}"
scheme="https" secure="true" clientAuth="false"
SSLProtocol="SSLv3+TLSv1"
SSLCipherSuite="ALL:!ADH:!SSLv2:!EXPORT40:!EXP:!LOW"
SSLRandomSeed="/dev/urandom"
SSLCertificateFile="/etc/pki/tls/certs/mycert.crt"
SSLCertificateKeyFile="/etc/pki/tls/private/mycert.key"
SSLPassword="mypasswordwhichiassureyouisbetterthanthisone"
/>
<Connector protocol="HTTP/1.1" SSLEnabled="true"
port="8543" address="${jboss.bind.address}"
scheme="https" secure="true" clientAuth="true"
SSLProtocol="SSLv3+TLSv1"
SSLCipherSuite="ALL:!ADH:!SSLv2:!EXPORT40:!EXP:!LOW"
SSLRandomSeed="/dev/urandom"
SSLCertificateFile="/etc/pki/tls/certs/mycert.crt"
SSLCertificateKeyFile="/etc/pki/tls/private/mycert.key"
SSLPassword="mypasswordwhichiassureyouisbetterthanthisone"
SSLCACertificateFile="/etc/pki/tls/certs/clientCAs.crt"
SSLVerifyClient="require"
/>
Now, if I hit http://myhost:8443/openContext, I'm not prompted for a certificate, but when I hit http://myhost:8543/securedContext, I am prompted for a certificate. Of course, I can still access either web app with the "wrong" port, but the consequences are negligible for my purposes. If a client hits http://myhost:8443/securedContext, they simply get an HTTP authentication error. If a client hits http://myhost:8543/openContext, they're prompted for a client certificate. If they provide one, great (though I don't care who you are), and if they don't provide one or provide an invalid one, they get an HTTP auth error (they should have used the correct port in the first place).
I'm pretty sure there's an alternative way to get this working without requiring a second connector by putting httpd in front of JBoss and doing some clever configuration there, but this worked well enough for my purposes.