WildFly SSL configuration - some of ideas
inspector Mar 13, 2015 10:07 AMHi everybody,
I like to work with JBoss and WildFly. It's a valuable piece of software and I'm quite happy with it. Working with JBoss AS7 (and EAP 6) and later WildFly 8.2 I realized more and more a wish for an improved security configuration especially for TLS / SSL. I'd like to start a discussion about this topic. Let me start with some thoughts and ideas:
In the AS7 you configure SSL for the...
- ... management interfaces in the management realm
- ... remote ejb and jndi clients via the corresponding realm
- ... messaging in the hornetq subsystem with options in the connectors and acceptors
- ... tomcat in the web subsystem (which featured a very flexible security configuration that I liked)
Now with WildFly we also configure undertow in a corresponding realm. This is a step I appreciate in terms of centralization of the configuration. But I miss the freedom to configure ciphers for the other interfaces than undertow. I'm not sure if that's just on my system (Oracle JDK 1.7) but for the management interface I have ciphers like RC4 with MD5 active! So I feel quite a need to configure that.
Seeing that, I started thinking about what I would expect from an application server in terms of security configuration:
- the security configuration should be highly customizable fore every single interface, that includes including and excluding ciphers and protocol versions (sometimes TLS1.2 only is required)
- the security configuration should have rather secure defaults (exclude ciphers like RC4)
- the security configuration should be centralized
- the security implementation should be exchangeable (like with the old tomcat based web subsystem where you could choose between OpenSSL and JSSE)
I'm not sure if the Realm concept is up to that but I see it as a starting point in terms of centralization. In WildFly it is even more decentralized as you specify the keystore etc. in the realm and the ciphers for undertow in the undertow subsystem.
Beeing quite visionary I imagined a thin SSL api that could be used by the different interfaces (undertow, hornetq, ...). This api would pull it's configuration from a central configuration and delegate to some implementation like OpenSSL or JSSE. I know this would require every changes in every place where SSL is being used. But I see this as quite beneficial as you could quickly react to recent security problems (bugs, broken algorithms/protocols) by either reconfiguring the ciphers or completely switching to another SSL implementation.
What do you think about the current state of the security config?
What do you think is doable to improve the current situation?
How do other people cope with similar problems?
Last but not least a question to the WildFly devs: Do you have anything security related on your agenda?
Regards!