The use of SSLv3.0/TLSv1.0 in combination with certain encryption techniques (CBC block
ciphers) may allow for an attacker to predict the so-called Initialization Vector of subsequent SSL packets. Using this information the attacker can access the secure session of another user. This attack, named BEAST (Browser Exploit Against SSL/TLS), is aimed at the user’s browser and not at the web server. Nevertheless, it is possible to take countermeasures at the server side as well to prevent a successful attack.
The complete solution to this problem is disabling or deprioritizing the support for
vulnerable encryption ciphers (CBC block ciphers) when using SSLv3.0/TLSv1.0. Commonly, this can be achieved by prioritizing RC4 ciphers in the cipher negotiation process.
For Apache web servers that support SSLv3.0/TLSv1.0 this can be configured by adding the
following configuration:
SSLProtocol All –SSlv2
SSLHonorCipherOrder On
SSLCipherSuite RC4-SHA:HIGH:!ADH
For Apache web servers that support SSLv3.1/TLSv1.1 and higher, it is recommended to use the following configuration:
SSLProtocol All –SSlv2
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM
As far as I know, JBoss 7 is based on a version of Apache that supports SSLv3.1/TLSv1.1 (maybe I am wrong), so the second alternative can be applied to JBoss 7.
My question is: Where/How should I configure it?
Dont paranoid with beast attack. According to this Oracle fix the issue, its not related directly with JBoss its an JVM issue. As stated here its hard to apply beast attack in real world. Just make sure that your JVM and JBoss is up-to-date. If you have still question in your mind its best practice to run JBoss behind a reverse proxy such as apache or nginx.
Related
Friendly Disclaimer: I am new to working with Keycloak and IdP in general. So it's likely that I use incorrect terminology and/or am more confused than I think I am. Corrections are gratefully accepted.
My question is conceptual.
I have a TLS certificate that is terminated on my host machine by my host company. My reverse proxy (Traefik) is picking up that certificate.
Which of the following proxy modes should I use now to be able to deploy Keycloak to production: edge, reencrypt or passthrough? (see here for relevant documentation)
I can pretty much rule out passthrough, because as I wrote, the TLS certificate is terminated on the server. But I am unsure if I have to bring my own certificate and reencrypt or if it is considered safe to go along with edge?
I have done my best to keep this question short and general. However, I am happy to share configurations or further details if needed.
As far as I know, most organizations consider a request to be safe when the proxy validated and terminated the TLS. It also removes the performance overhead (depends on your load). Unless your organization is going for Zero Trust for its internal network, using the edge should be totally acceptable.
Reading an article about the cost of SSL handshake, I saw the possibility to have session tickets and session resumption to avoid paying the cost of re-establishing the session.
In my architecture, I use Netty in the client side and Tomcat on the server side. Googling I saw several guides to enable it on nginx and other server implementation, but for the netty implementation on the client side, I couldn't find anything.
At this point, I was wondering if it was directly managed by SSLEngine for me at the client side, and I have to do nothing, or there is some "secretive" config I have to turn on to benefit from the SSL resumption on the client side.
Is there any reason why I would like to disable it? (I saw several questions on SO)
Unfortunately Java's SSL implementaion don't support session tickets, I lodged a feature request for this a few years go.
https://bugs.openjdk.java.net/browse/JDK-8134497
Luckily Netty lets you switch to OpenSSL implementations that do support session tickets and better yet can be directly swapped into your code.
See http://netty.io/wiki/forked-tomcat-native.html for details but you basically just add:
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-tcnative-boringssl-static</artifactId>
<version>2.0.0.Final</version>
</dependency>
to your POM file and specify OpenSSL as your provider when setting up the context.
SslContext sslContext =
SslContextBuilder.forClient()
.sslProvider(SslProvider.OPENSSL)
.build();
Apache Portable Runtime and OpenSSL need to be installed on the system.
We have a legacy web application that runs in a tomcat under java 6, upgrading to 7 or 8 is infeasible as the application needs significant work to allow this and the fixes required are too large to implement in a legacy application. We now have a requirement to connect outbound (i.e. as a client) over TLS 1.2 however java 6 only supports 1.0. We use Apache as our web-server and OpenSSL for incoming connections and this happily supports TLS 1.2 etc.
Has anyone had to address a similar issue, or can you comment on the following potential work arounds:
Loopback to localhost (or otherwise redirect) and use OpenSSL to create a TLS 1.2 connection,
effectively an internal proxy
can openssl be a client?
do we need s_client?
Use our current the firewall to upgrade the connection
this would need to be selective
Obviously implementing this will depend on the firewall
Use “Bouncy Castle” (https://www.bouncycastle.org/)
Don't use openssl's s_client for this - it's slow, and intended more for debugging/testing.
Try using stunnel. It's designed for use cases like yours, and you can find plenty of example configs to get you started. You'd want to make sure to include the sslVersion = TLSv1.2 directive in your configuration to force use of TLS 1.2.
Is there a way to disable weak and medium ciphers suites for https, with the standalone Play Framework server?
Couldn't find anything about it.
The intention of the standalone server is not to deal with https traffic. The most common pattern is to use something like lighttpd, nginx or apache as a reverse proxy and offload the https processing to that.
Therefore, your question is more suited to whether it is possible to do what you need in one of the above http servers.
In Play 2.3, it is possible to do this with the AlgorithmChecker, and the AlgorithmChecker can be set up from a custom SSLEngine provider.
https://www.playframework.com/documentation/2.3.x/ConfiguringHttps
https://github.com/playframework/playframework/blob/2.3.x/framework/src/play-ws/src/main/scala/play/api/libs/ws/ssl/AlgorithmChecker.scala
Following on from the best answer here:
How much overhead does SSL impose?
Is there a way to optimise SSL beyond a simple apache SSL install?
From the best answer given on that page I infer that there is some way to set-up persistent SSL sessions over multiple calls (where there is less handshake overhead). Is that correct?
If so, what's the best resource to learn about configuring the server to work that way?
SSL session caching is one optimization, which you can configure for Apache by looking at the discussion here. Look at the SSLSessionCache directive and related.
This will boost your performance for usage patterns that have the same client hitting the server multiple times within the session timeout period. However, when the pattern tends more toward one server hit per client for numerous clients, you won't see any speedups.