[wildfly-dev] Supporting FIPS in domain mode

Darran Lofthouse darran.lofthouse at jboss.com
Fri Nov 20 10:58:38 EST 2015

Still thinking about the initial report a complete solution is seeming 
very ambitious at the moment.

However an alternative option to overcome this specific error could be a 
new set of system properties to define how the SSLContext is assembled 
for the AS->HC connections.  If these properties are set then they are 
used to create the stores, managers and resulting SSLContext - if not 
set we keep the existing behaviour.

The risk however is that as this is FIPS related using system properties 
to contain anything sensitive is probably not an option.

This does still leave the scenario of using a FIPS configured JVM but no 
TLS to the HostController although I am still inclined to believe that 
is more the edge case.

Also note I am not considering the standard system properties for this 
as they may already be being used for another purpose within the 
application server process.

Darran Lofthouse.

On 20/11/15 11:22, Ryan Emerson wrote:
> Thank you for all the input.  Clearly this is a substantial RFE, which is unrealistic for backporting.
> I have update the original JIRA to reflect that this is a RFE.
> Thanks
> Ryan
> ----- Original Message -----
> From: "Vaclav Tunka" <vtunka at redhat.com>
> To: "Ryan Emerson" <remerson at redhat.com>
> Cc: wildfly-dev at lists.jboss.org, "Jean-Frederic" <jclere at redhat.com>
> Sent: Friday, 20 November, 2015 10:16:59 AM
> Subject: Re: [wildfly-dev] Supporting FIPS in domain mode
> Enabling the implementation itself to be "FIPS compliant" is just one
> part (although quite complicated itself), second part is the audit by a
> third party agency, lot of paperwork and lot of costs to be able to mark
> something as truly FIPS compliant. So this is definitely a big RFE.
> Ryan if you want to find out more, I suggest you get in touch with
> Jean-Frederic Clere - I tried to organize a call with platform
> developers about FIPS, not sure if that already happened.
> Cheers,
> Vaclav
> On 11/19/2015 02:59 PM, Ryan Emerson wrote:
>> This issue originated from a downstream customer issue (BZ now linked in JIRA), so there is some demand.  Originally the intention was to try and backport the upstream fix, however as FIPS support now appears to be a complex RFE this may not be possible.
>> ----- Original Message -----
>> From: "Anil Saldanha" <anilsaldhana at gmail.com>
>> To: "Darran Lofthouse" <darran.lofthouse at jboss.com>
>> Cc: wildfly-dev at lists.jboss.org
>> Sent: Thursday, 19 November, 2015 1:07:32 PM
>> Subject: Re: [wildfly-dev] Supporting FIPS in domain mode
>> I agree with Darran that this is a complicated exercise that should be backed by a business demand.
>> The potential for the feature -- if implemented -- to break in the long run is high -- if any custom configuration is involved.
>>> On Nov 19, 2015, at 6:50 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
>>> The problem with this issue is that it is going to be quite complex to
>>> solve, especially once we start to expand on all the scenarios we need
>>> to support.  Add to that it becomes even more complex once we need to
>>> consider backwards compatibility.
>>> Generally the scenarios we need are: -
>>>    - Using a FIPS configured JVM
>>>    - Using a non-FIPS configured JVM
>>> Combined with: -
>>>    - TLS enabled for the host controller connection.
>>>    - TLS not enabled.
>>> Although the issue raised only talks about an error message for one we
>>> need to ensure we cover them all.
>>> Firstly the connection that is being talked about here is the connection
>>> from the individual application server process back to it's host
>>> controller all running on the same machine.  The reason for the simple
>>> trusting solution is because although a connection is used it is always
>>> local - the reason we need to be able to support TLS for this connection
>>> is because we connect to the same Remoting connector as remote clients
>>> also used so once TLS is enabled it is enabled for all.
>>> Firstly I think it is worth exploring if there is anything else we can
>>> do to automatically configure the client side of this connection without
>>> requiring any additional configuration from the administrator.
>>> If we can identify the certificate the server will be using for the
>>> connection there may be something we can do to send this to the
>>> application server process so that it can instantiate a SunJSSE
>>> compatible KeyStore and subsequently a SunJSSE TrustManager that will be
>>> accepted into the SSLContext.
>>> When it comes to host controller and application server initialisation
>>> those two processes are always guaranteed to be the same version so this
>>> gives us some leeway on how the application server process is initially
>>> configured.
>>> If that is not possible then an alternative is that to achieve a FIPS
>>> mode compliant connection from the application server to the host
>>> controller is going to require a custom configuration.  The problem is
>>> we do not have the management model available on the application server
>>> at this time so we would probably still need a way to define it within
>>> the host controller and convert it to a format that can be used on the
>>> application server.  In this case I don't think using the standard
>>> system properties would be a good idea as existing installations could
>>> already be relying on these elsewhere.
>>> If we needed to go down the custom configuration route then I would
>>> suggest lack of configuration means stick with the current behaviour so
>>> existing installations are unaffected leaving the configuration to be
>>> set by those that do require it.
>>> If automatically obtaining the certificate is viable then that could be
>>> used for all cases without breaking compatibility but additional
>>> verification is probably needed there.
>>> Regards,
>>> Darran Lofthouse.
>>>> On 19/11/15 10:25, Ryan Emerson wrote:
>>>> Hello All,
>>>> Currently domain mode is unable to execute when the JVM has FIPS enabled. See [1] for example config files and the resulting stacktrace.
>>>> I am looking into this issue (SET engineer), however my current knowledge of core and FIPS is limited.  What are your thoughts on how to implement FIPS compatibility? Is there any fundamental reasons why such a feature shouldn't be supported?
>>>> [1] https://issues.jboss.org/browse/WFCORE-1135
>>>> Thanks
>>>> Ryan
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

More information about the wildfly-dev mailing list