WildFly 8-10 and JBoss EAP 7 verbose HTTP headers

As a developer I am really happy to have an easy way to determine which version of a software I’m running. But I do not like it if my software tells everyone its name and version, as this gives important fingerprinting information to possible attackers.

If you use WildFly versions 8 through 10 or JBoss EAP version 7 the default configuration includes some HTTP headers that are too verbose in my opinion. JBoss EAP 6 is not affected by the way. The headers you get look like this

Server: JBoss-EAP/7
X-Powered-By: Undertow/1

Getting rid of these headers is really easy. So I think the tiny effort to remove these headers should be put into any project even if the probability of getting attacked and the possible impact are really small.

To fix the problem let’s have a look at the default configuration in the standalone.xml:

Continue reading

Red Hat JBoss Middleware: A technology stack for IoT-Applications

JBoss EAP 7 and ActiveMQ Artemis as connector between temperature and humidity and the application architecture

Most IoT-Applications face similar challenges on its way from sensor to final aggregation in terms of usage and, where applicable relaying of data. In this article, we introduce an architecture based on the new Red Hat JBoss Enterprise Application Platform (JBoss EAP) in Version 7 to outline a IoT application as a showcase.

MQTT has certainly become a standard protocol for IoT and in this context the Internet of Things is integrated via MQTT.

One new major update of JBoss EAP 7 is ActiveMQ Artemis as Messaging Broker with support for MQTT as transport protocol. JBoss EAP 7 is our preferred technology, i.a. for IoT architectures because of its outstanding technological capabilities thus facilitating efficient development of scalable and secure applications.

A combined temperature and humidity sensor, the Bosch XDK, and Harting’s Mica Box are used to supply data. It is the MQTT and the JBoss EAP 7 Middleware that connect and build a bridge between this sensor setup and the rest of the world.

Continue reading

Red Hat JBoss Enterprise Application Platform 7 (JBoss EAP 7) – final release

A few days ago, Red Hat released the major version 7 of the open source Java EE application server, Red Hat JBoss Enterprise Application Platform (JBoss EAP).

Red Hat JBoss Enterprise Application Platform (JBoss EAP) is the supported and quality assured version of the WildFly application server from the JBoss community.

jboss-eap-wildfly-upstream-history

The JBoss EAP 7 is based on the version 10 of the WildFly application server. In 2013 Red Hat renamed the JBoss AS community project to WildFly to avoid confusion with the JBoss brand which referred to several different things at once, the application server, the JBoss Community, and a range of other JBoss Products.

The main improvements and highlights of the JBoss EAP 7 release

This article focuses on the following main improvements and highlights of the new major release of the JBoss EAP 7:

  • implementation of the new specifications of the Java Enterprise Edition 7
  • enhanced modularity
  • management improvements
  • component updates
  • compatibility and interoperability

Continue reading

Red Hat JBoss EAP 6.4 now supports Java 1.8 / JDK 8

A few weeks ago Red Hat release the Red Hat JBoss EAP 6.4.0 Beta1 as tech preview. Featuring many updates, with additional supported and updated database certifications and the EAP 6.4.0 Beta1 including targeted support of Java 8 / JDK 8.

Oracle JDK 8
Oracle Java Platform, Standard Edition 1.8 (JDK 8) has been added to the list of supported configurations.

OpenJDK 8
Support for OpenJDK 8 has been added, but at the moment support is limited to Red Hat Enterprise Linux 6.

Try it today!
Continue reading

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!

JBoss EAP / Wildfly Management Interfaces and Clients

The JBoss EAP / Wildfly provides a powerful concept for management, configuration, and monitoring of the application server itself and its Java EE applications.

In the previous post we focused on some useful runtime metrics, which are of interest when monitoring your application server and applications. This post introduces the management clients provided by the JBoss EAP / Wildfly Application Server to manage and configure server instances.

Continue reading

Secure JSF Application – why you should always define a servlet mapping

If you deploy a JSF application in WildFly 8, you can omit to define the JSF serlvet mapping. In this case three default mappings will be active out of the box.

  • <context-root>/faces/*
  • <context-root>/*.jsf
  • <context-root>/*.faces

Tested on WildFly 8.0.0.CR1 and JBoss EAP 6.2.0.GA

This behavior is not mentioned in the JSF 2.1 spec. But it explicitly allows implementations to use proprietary means to invoke the JSF lifecycle.

In addition to FacesServlet, JSF implementations may support other ways to invoke the JavaServer Faces request processing lifecycle, but applications that rely on these mechanisms will not be portable.

This default mapping can be problematic as it provides several path to access resources within your web application. Especially if you use security constraints to protect parts of your application. For instance if you restrict access to <context-root>/secure/* using a security constraint in your web.xml, web resources can still be accessed via <context-root>/faces/.
Continue reading