Fight the POODLE in JBoss 4 and 5, JON 3 and more

The POODLE bug (CVE-2014-3566) affects nearly everything and everybody is trying to secure all of their systems. That includes your JBoss servers. Securing your JBoss 4 or 5 has one pitfall, which I am going to explain in this post. Apart from that it’s easy.

I stumbled on this issue when securing the web interface of a customer’s JON server. (Important note: the following snippet will not work around POODLE for communication from JON server to JON agent!) JON is by default configured to use TLS, so there is a poodle protection installed by default.

Yeahh, well… let’s verify that:

echo "" | openssl s_client -ssl3 -connect  your.server.dns.or.ip:7443

Surprise, surprise: Even with TLS configured the SSL-Session using SSLv3 was established successfuly!

SSL-Session:
    Protocol  : SSLv3
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: XXX
    Session-ID-ctx:
    Master-Key: XXX
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1413471616
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)

The cause for that is that the tomcat configuration doesn’t work as I would expect it. The following configuration does NOT do the trick (server.xml of the deployed tomcat):

<!-- Does NOT work! -->
<Connector port="7443"
    address="0.0.0.0"
    protocol="HTTP/1.1"
    scheme="https"
    ...
    secure="true"
    SSLEnabled="true"
    sslProtocol="TLS"
    ... >
<!-- Does NOT work! -->

The RedHat guys actually posted the solution but it’s easy to mistake the important point. The following configuration bans your evil poodle:

<Connector port="7443"
    address="0.0.0.0"
    protocol="HTTP/1.1"
    scheme="https"
    ...
    secure="true"
    SSLEnabled="true"
    sslProtocols="TLSv1,TLSv1.1,TLSv1.2"
    ... >

Ok there is one obvious (and also important!) difference and one subtle difference. The obvious one is that it is "TLSv1,TLSv1.1,TLSv1.2" and not "TLS". By the way TLSv1.2 is only available from JDK 1.7 on.

But there is also the subtle difference of a single “s” which is very important, because without it it does NOT work. To make it clear, it will only work with "sslProtocols" and will NOT work with "sslProtocol".

That is confusing for me because I have never seen that option documented but the documented option seems to have no effect at all. So I suspect there is a typo in either the code or the documentation.

Hope I could help you somehow! If you’ve got any questions feel free to comment on this post. Good luck on your poodle fighting!

Deploying applications continuously with SCP

The last blog post (Jumping into continuous delivery with Jenkins and SSH) demonstrated how to build and deploy an application continuously using Jenkins, SSH and Nexus. In that scenario, the application was packaged and deployed on Nexus by Jenkins, and then retrieved from Nexus by the host. However, what about doing it without Nexus? You might have no other need for Nexus or even Maven. Or perhaps you prefer to deploy your application only after you have tested it in several environments. So, how to deploy your application without Nexus?

This post explains how to use the Jenkins SCP plugin to copy the freshly built application to another machine using SCP. This is useful when you need to copy an application to a specific machine or another environment without exposing it publicly.

Although this post is focused on Jenkins, other continuous integration servers have equivalent capabilities.
Continue reading

Jumping into continuous delivery with Jenkins and SSH

Let’s imagine the following situation. You’re working on an application for a customer. Despite a firm deadline and a roadmap given to your customer, he’d like to check the progress regularly, let’s say weekly or even daily, and actually give you feedback.

So to make everybody happy, you start releasing the application weekly. However, releasing is generally a hard-core process, even for the most automated processes, and requires human actions. As the release date approaches, stress increases. The tension reaches its climax one hour before the deadline when the release process fails, or worse, when the deployment fails. We’ve all been in situations like that, right?

This all-too-common nightmare can be largely avoided. This blog post presents a way to deal with the above situation using Jenkins, Nexus and SSH. The application is deployed continuously and without human intervention on a test environment, which can be checked and tested by the customer. Jenkins, a continuous integration server, is used as the orchestrator of the whole continuous delivery process.

Continue reading