[wildfly-dev] Supporting FIPS in domain mode

[Ryan Emerson]

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
>